Category Archives: Others

How Much Coding Should Designers Know?


Many designers think each discipline should mind their own business, while others see no problem in professionals wearing multiple hats. Many developers see designers who code as a threat, while others see it as a facilitator. This is a hotly debated subject, and although I think some great designers are also superb at coding, I will always defend that the more you focus on a particular area the best you will be at it. But this shouldn’t be a reason for you to miss out on the benefits of having another skill under your belt.

designers coding

Learn how to code and make yourself a great asset to any multi-disciplinary team.

As a designer who has gone as far to set up Linux servers and program back-end, I see no question that understanding ‘the basics’ of coding would benefit any designer. The question really is, how much coding should designers learn? At what point might designers be wasting their time, or really stepping over the line into the territory of developers?

In order to provide some insight into the potential benefits of learning to code, I’ve broken the different levels of coding knowledge down into degrees of usefulness.

Step 1: Know the basics of HTML and CSS

Any designer would greatly benefit from knowing the foundations of HTML and CSS and would be surprised by how easy it can be. Stop being lazy and just learn this, it will make you a better designer, guaranteed.

When is front-end just coding, not programming?

Is front-end coding? Yes! Is it programming? Only after a certain point.

HTML and CSS don’t involve programming logics. You can see that in HTML – HyperText Markup Language the letter M stands for Markup, what means that it’s nothing more than a coded structure of the page/screen elements. It works like a puzzle, but it doesn’t require a lot of mathematical thinking.

In laymen’s terms, HTML is an architectural map that tells the browser what to display. The HTML map will influence how search engine crawlers will interpret the site. So, the concern here is to make sure the code is very well structured and that those systems can understand it and rank it well.

CSS, or Cascading Style Sheets, is the code that tells the browser how to display things. Metaphorically, if HTML is the skeleton of a page or screen, CSS would be the skin and eyes colors, hairstyle, body shape, limbs sizes, etc. The language has a very simple code structure that determines typography, colors, positions and dimensions. The concern with HTML is to keep it very organized for maintenance and optimized for good performance.

Understanding code means understanding your pixels

Learning how to code gives you the opportunity to know how things work. Why do we need to worry about pixel-perfection, is it only for the sake of symmetry?

If you play with HTML and CSS, you’ll notice that everything is measured in pixels (there are other measurement units – not relevant here – but they will ultimately be converted to pixels). Understanding these mechanics will change your mindset and will care for design in a more efficient way for the development process. As a consequence, not only your projects will be easier to program as your projects may look much more structured.

Step 2: Front-end JavaScript and AJAX could make you a unique asset

This is where things can start to get complicated, but it’s also where a lot of fun happens. If you’re an analytical thinker, or specially motivated, you’ll get a lot out of learning JavaScript and AJAX. As well, your design perspective will improve in knowing exactly how far technology can take you and how far you can push it to be innovative. I don’t think going this deep is necessary though, because if you know the basics of HTML and CSS you’ll already be ahead of most competitors. However, you may find some fun in making things coming to life with the knowledge.

When does front-end become programming?

Although we could stop here and have the back-end implemented, we can make our project more dynamic by adding some scripting, like if we could give a few acrobatic abilities to the beautifully structured and painted body we created with HTML / CSS.

For that, we have our dear JavaScript, which is an actual logical programming language. JavaScript can be used to display dynamic interactions, animate elements, create a very responsive communication with the back-end or server, as well as other things. As there aren’t many limits to what can be accomplished with Javascript in front-end development, now we are talking about a programming language: functions, objects, logics, conditionals, math, math and more math so that it may be a little challenging. But it’s not that hard to learn, especially considering what most clients will require.

In my opinion if you want to say you’re a front-end developer, knowing (at least the basics of) JavaScript is mandatory. You should understand how AJAX works (which is used by nearly any modern website). You should test your interactions in real time, and if you’re a motion designer, like me, you can do some animations yourself rather than having to explain it to a programmer, which may not have the same eye for the kind of detail that you see as a designer.

As well, there are the pre-processors for HTML (Haml, Jade, etc.) and CSS (SCSS, LESS, etc.), which are languages that aim to facilitate and streamline the coding process using programming concepts (such as logics, modulation, among others). The code, as it states, is then pre-processed, generating the pure HTML and CSS (also called vanilla). Even if you know only the basics of programming, these could be real time-savers.

Knowing how to program informs the limitations of devices

If you, a designer, learn front-end you will clearly see various advantages for knowing it, such as knowing how things work and see the limitations of each device.

Even browsers behave differently – let alone separate devices – so knowing this when you are creating gives you a sense of making something solid, lowering the chances of future complications in projects. Every programmer I know got a layout that was impossible to reproduce at some point in their lives.

Knowing the mechanics behind a digital project will not only give you an idea of what limits your work, but also what boundaries of technology you can push. I remember when several agencies, such as Fantasy and Firstborn, made a reputation in the early 2000’s for using Javascript in a different and very creative way.

Step 3: Back-end JavaScript might be overkill

Well, maybe we’re going too far here. Knowing the basics of back-end JavaScript can be useful depending on the stack your team uses (like MEAN stack, for example). But, you don’t have to go too far if all you need to know is how to run a project. However, if you dream of leading product teams, this may be helpful. But, if you call yourself a designer, not developer, your returns are seriously diminishing at this point, so you’d be better off expanding your creative skills.

Learn to code and collaborate better with developers

Would romantic relationships be easier if men could read the minds of women? Many would think so. I wonder the same thing about designers and developers.

Knowing how developers think and what they need to be able to do their job may sound like stepping on their territory, but it will make you a great asset to any multi-disciplinary team.

This can be very useful both for internal communications, as well as in idea pitches, because you know what to expect from the other members of the team. If you can do this, know your limitations (and how to push them), then you will be able to propose much more robust solutions to clients.

A designer who can code will see more job opportunities

One of the reasons why I closed my small company (RIP!), was the fact that I started international relationships that became increasingly more attractive than local businesses. For these contacts, today I work exclusively for this the global market, so 99% of my network is foreign. The opportunity that opened up this market for me was a scenario that required an individual who could do it all, including front-end. And I fit the bill; I could even program back-end. By then I ended up getting involved more and more with the dark side of the force, even to the point of setting up and managing Linux servers.

In every opportunity I had since then, knowing how to program made a big difference both in the screening processes and the day to day work. At Toptal we see a bunch of opportunities for professionals with this hybrid profile, and startups out there are eager to find people that can take over both the design and front-end of their early-stage applications.

designers coding

Learning how to code might lead to some unexpected opportunities.

Still, there are some designers and programmers who dislike one another snooping into each other’s businesses. Why might this be? Some may be afraid of losing work, and some may be lazy to learn something new. But the truth is that you should analyze your options, and focus on what will increase your chances of success. You may not have enough time now to learn everything, but maybe knowing vanilla HTML and CSS should be sufficient to add a significant differential to your career. It should be quick and easy for you to take the first steps. The more you know, the more you expand your opportunities. So, by experience, I would never discourage any opportunity to learn new skills.

Step 4: Database Architecture and Software Engineering Won’t Get Designers Anywhere

Unless algebra and complex computing are your thing, I would say “Dear God, no!”. There are other useful side skills you could learn instead (like knitting). People are just as likely to want to hire a designer who knows how to knit as one who knows how to architect databases. Besides, you don’t want to be in a place where you need to take care of everything, believe me.

So, should designers program?

I would say no. You don’t need to. But more and more the work opportunities in the design field add web-development, or at least front-end notions, as a requirement or a differential. So you don’t need to, but maybe you should if you want to have something else to offer, especially if you’re having trouble finding work. Sometimes we can’t find an opportunity that fits our profile, and that’s when we need to adapt to what is out there.

Conclusion

All of this said, we all know that it is not mandatory for a designer to know how to program. I know a lot of designers that don’t, excellent ones in fact.

However, in some cases, I notice deficiencies from a development point-of-view, in details that could even harm a project’s productivity.

You don’t need to be a designer who is also an expert in front-end development to have these differential skills added to your CV or applied to your projects, and you have a lot of online resources to start walking down this road. Simple skills can impact your potential for success in a very positive way.

Do some research, look at what job offers are requesting, see the profile of designers startups are looking for, and maybe you can agree with me when I say you don’t need to learn how to code, but you should.

Think about it!

Article from Toptal

The 10 Most Common Mistakes That WordPress Developers Make


We are only human, and one of the traits of being a human is that we make mistakes. On the other hand, we are also self-correcting, meaning we tend to learn from our mistakes and hopefully are thereby able to avoid making the same ones twice. A lot of the mistakes I have made in the WordPress realm originate from trying to save time when implementing solutions. However, these would typically rear their heads down the road when issues would crop up as a result of this approach. Making mistakes is inevitable. However, learning from other people’s oversights (and your own of course!) is a road you should proactively take.

WordPress

Engineers look like superheroes, but we’re still human. Learn from us.

Common Mistake #1: Keeping the Debugging Off

Why should I use debugging when my code is working fine? Debugging is a feature built into WordPress that will cause all PHP errors, warnings, and notices (about deprecated functions, etc.) to be displayed. When debugging is turned off, there may be important warnings or notices being generated that we never see, but which might cause issues later if we don’t deal with them in time. We want our code to play nicely with all the other elements of our site. So, when adding any new custom code to WordPress, you should always do your development work with debugging turned on (but make sure to turn it off before deploying the site to production!).

To enable this feature, you’ll need to edit the wp-config.php file in the root directory of your WordPress install. Here is a snippet of a typical file:

// Enable debugging
define('WP_DEBUG', true);

// Log all errors to a text file located at /wp-content/debug.log
define('WP_DEBUG_LOG', true);

// Don’t display error messages write them to the log file /wp-content/debug.log
define('WP_DEBUG_DISPLAY', false);

// Ensure all PHP errors are written to the log file and not displayed on screen
@ini_set('display_errors', 0);

This is not an exhaustive list of configuration options that can be used, but this suggested setup should be sufficient for most debugging needs.

Common Mistake #2: Adding Scripts and Styles Using wp_head Hook

What is wrong with adding the scripts into my header template? WordPress already includes a plethora ofpopular scripts. Still, many developers will add additional scripts using the wp_head hook. This can result in the same script, but a different version, being loaded multiple times.

Enqueuing here comes to the rescue, which is the WordPress friendly way of adding scripts and styles to our website. We use enqueuing to prevent plugin conflicts and handle any dependencies a script might have. This is achieved by using the inbuilt functions wp_enqueue_script or wp_enqueue_style to enqueue scripts and styles respectively. The main difference between the two functions is that with wp_enqueue_script we have an additional parameter that allows us to move the script into the footer of the page.

wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false )
wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false )

wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' )
wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

If the script is not required to render content above the fold, we can safely move it to the footer to make sure the content above the fold loads quickly. It’s good practice to register the script first before enqueuing it, as this allows others to deregister your script via the handle in their own plugins, without modifying the core code of your plugin. In addition to this, if the handle of a registered script is listed in the array of dependencies of another script that has been enqueued, that script will automatically be loaded prior to loading that highlighted enqueued script.

Common Mistake #3: Avoiding Child Themes and Modifying WordPress Core Files

Always create a child theme if you plan on modifying a theme. Some developers will make changes to the parent theme files only to discover after an upgrade to the theme that their changes have been overwritten and lost forever.

To create a child theme, place a style.css file in a subdirectory of the child theme’s folder, with the following content:

/*
 Theme Name:   Twenty Sixteen Child
 Theme URI:    http://example.com/twenty-fifteen-child/
 Description:  Twenty Fifteen Child Theme
 Author:       John Doe
 Author URI:   http://example.com
 Template:     twentysixteen
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  twenty-sixteen-child
*/

The above example creates a child theme based on the default WordPress theme, Twenty Sixteen. The most important line of this code is the one containing the word “Template” which must match the directory name of the parent theme you are cloning the child from.

The same principles apply to WordPress core files: Don’t take the easy route by modifying the core files. Put in that extra bit of effort by employing WordPress pluggable functions and filters to prevent your changes from being overwritten after a WordPress upgrade. Pluggable functions let you override some core functions, but this method is slowly being phased out and replaced with filters. Filters achieve the same end result and are inserted at the end of WordPress functions to allow their output to be modified. A trick is always to wrap your functions with if ( !function_exists() ) when using pluggable functions since multiple plugins trying to override the same pluggable function without this wrapper will produce a fatal error.

Common Mistake #4: Hardcoding Values

Often it looks quicker to just hardcode a value (such as a URL) somewhere in the code, but the time spent down the road debugging and rectifying issues that arise as a result of this is far greater. By using the corresponding function to generate the desired output dynamically, we greatly simplify subsequent maintenance and debugging of our code. For example, if you migrate your site from a test environment to production with hardcoded URLs, all of a sudden you’ll notice your site it is not working. This is why we should employ functions, like the one listed below, for generating file paths and links:

// Get child theme directory uri
stylesheet_directory_uri();
//  Get parent theme directory
get_template_directory_uri();
// Retrieves url for the current site
 site_url();

Another bad example of hardcoding is when writing custom queries. For example, as a security measure, we change the default WordPress datatable prefix from wp_ to something a little more unique, like wp743_. Our queries will fail if we ever move the WordPress install, as the table prefixes can change between environments. To prevent this from happening, we can reference the table properties of the wpdb class:

global $wpdb;
$user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Notice how I am not using the value wp_users for the table name, but instead, I’m letting WordPress work it out. Using these properties for generating the table names will help ensure that we return the correct results.

Common Mistake #5: Not Stopping Your Site From Being Indexed

Why wouldn’t I want search engines to index my site? Indexing is good, right? Well, when building a website, you don’t want search engines to index your site until you have finished building it and have established a permalink structure. Furthermore, if you have a staging server where you test site upgrades, you don’t want search engines like Google indexing these duplicate pages. When there are multiple pieces of indistinguishable content, it is difficult for search engines to decide which version is more relevant to a search query. Search engines will in such cases penalize sites with duplicate content, and your site will suffer in search rankings as a result of this.

As shown below, WordPress Reading Settings has a checkbox that reads “Discourage search engines from indexing this site”, although this does have an important-to-note underneath stating that “It is up to search engines to honor this request”.

WordPress Reading Settings

Bear in mind that search engines often do not honor this request. Therefore, if you want to reliably prevent search engines from indexing your site, edit your .htaccess file and insert the following line:

Header set X-Robots-Tag "noindex, nofollow"

Common Mistake #6: Not Checking if a Plugin is Active

Why should I check if a plugin function exists if my plugin is always switched on? For sure, 99% of the time your plugin will be active. However, what about that 1% of the time when for some reason it has been deactivated? If and when this occurs, your website will probably display some ugly PHP errors. To prevent this, we can check to see if the plugin is active before we call its functions. If the plugin function is being called via the front-end, we need to include the plugin.php library in order to call the function is_plugin_active():

include_once( ABSPATH . 'wp-admin/includes/plugin.php' );
if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) {
// Run plugin code
}

This technique is usually quite reliable. However, there could be instances where the author has changed the main plugin directory name. A more robust method would be to check for the existence of a class in the plugin:

if( class_exists( ‘WooCommerce’ ) ) {
	// The plugin WooCommerce is turned on
}

Authors are less likely to change the name of a plugin’s class, so I would generally recommend using this method.

Common Mistake #7: Loading Too Many Resources

Why should we be selective in loading plugin resources for pages? There is no valid reason to load styles and scripts for a plugin if that plugin is not used on the page that the user has navigated to. By only loading plugin files when necessary, we can reduce our page loading time, which will result in an improved end user experience. Take, for example, a WooCommerce site, where we only want the plugin to be loaded on our shopping pages. In such a case, we can selectively remove any files from being loaded on all the other sites pages to reduce bloating. We can add the following code to the theme or plugin’s functions.php file:

function load_woo_scripts_styles(){
	
if( function_exists( 'is_woocommerce' ) ){
    // Only load styles/scripts on Woocommerce pages   
	if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { 		
		
		// Dequeue scripts.
		wp_dequeue_script('woocommerce'); 
		wp_dequeue_script('wc-add-to-cart'); 
		wp_dequeue_script('wc-cart-fragments');
		
		// Dequeue styles.	
		wp_dequeue_style('woocommerce-general'); 
		wp_dequeue_style('woocommerce-layout'); 
		wp_dequeue_style('woocommerce-smallscreen'); 
			
		}
	}	
}

add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Scripts can be removed with the function wp_dequeue_script($handle) via the handle with which they were registered. Similarly, wp_dequeue_style($handle) will prevent stylesheets from being loaded. However, if this is too challenging for you to implement, you can install the Plugin Organizer that provides the ability to load plugins selectively based on certain criteria, such as a post type or page name. It’s a good idea to disable any caching plugins, like W3Cache, that you may have switched on to stop you from having to refresh the cache constantly to reflect any changes you have made.

Common Mistake #8: Keeping the Admin Bar

Can’t I just leave the WordPress Admin Bar visible for everyone? Well, yes, you could allow your users access to the admin pages. However, these pages very often do not visually integrate with your chosen theme and don’t provide a seamless integration. If you want your site to look professional, you should disable the Admin Bar and provide a front-end account management page of your own:

add_action('after_setup_theme', 'remove_admin_bar');

function remove_admin_bar() {
if (!current_user_can('administrator') && !is_admin()) {
  show_admin_bar(false);
}
}

The above code, when copied into your theme’s functions.php file will only display the Admin Bar for administrators of the site. You can add any of the WordPress user roles or capabilities into the current_user_can($capability) function to exclude users from seeing the admin bar.

Common Mistake #9: Not Utilizing the GetText Filter

I can use CSS or JavaScript to change the label of a button, what’s wrong with that? Well, yes, you can. However, you’re adding superfluous code and extra time to render the button, when you can instead use one of the handiest filters in WordPress, called gettext. In conjunction with a plugin’s textdomain, a unique identifier that ensures WordPress can distinguish between all loaded translations, we can employ the gettextfilter to modify the text before the page is rendered. If you search the source code for the function load_plugin_textdomain($domain), it will give you the domain name we need to override the text in question. Any reputable plugin will ensure that the textdomain for a plugin is set on initialization of the plugin. If it’s some text in a theme that you want to change, search for the load_theme_textdomain($domain) line of code. Using WooCommerce once again as an example, we can change the text that appears for the “Related Products” heading. Insert the following code into your theme’s functions.php file:

function translate_string( $translated_text, $untranslated_text, $domain ) {
	if ( $translated_text == 'Related Products') {
			$translated_text = __( 'Other Great Products', 'woocommerce' );
	}
	return $translated_text;
}

add_filter( 'gettext', 'translate_string', 15, 3 );

This filter hook is applied to the translated text by the internationalization functions __() and _e(), as long as the textdomain is set via the aforementioned functions.

_e( 'Related Products', 'woocommerce' );

Search your plugins for these internationalization functions to see what other strings you can customize.

By default, WordPress uses a query string with the post’s ID to return the specified content. However, this is not user-friendly and users may remove pertinent parts of the URL when copying it. More importantly, these default permalinks do not use a search engine friendly structure. Enabling what we call “pretty” permalinks will ensure our URLs contain relevant keywords from the post title to improve performance in search engine rankings. It can be quite a daunting task having to retrospectively modify your permalinks, especially if your site has been running for a significant period of time, and you’ve got hundreds of posts already indexed by search engines. So after you’ve installed WordPress, ensure you promptly change your permalinks structure to something a little more search engine friendly than just a post ID. I generally use the post name for the majority of sites I build, but you can customize the permalink to whatever format you like using the availablepermalink structure tags.

WordPress Permalink Settings

Conclusion

This article is by no means an exhaustive list of mistakes made by WordPress developers. If there’s one thing you should take away from this article, though, it’s that you should never take shortcuts (and that’s true in any development platform, not just in WordPress!). Time saved now by poor programming practices will come back to haunt you later. Feel free to share with us some mistakes that you have made in the past – and more importantly any lessons learned – by leaving a comment below.

Source: Toptal

Scaling Scala: How to Dockerize Using Kubernetes


Kubernetes is the new kid on the block, promising to help deploy applications into the cloud and scale them more quickly. Today, when developing for a microservices architecture, it’s pretty standard to choose Scala for creating API servers.

Microservices are replacing classic monolithic back-end servers with multiple independent services that communicate among themselves and have their own processes and resources.

If there is a Scala application in your plans and you want to scale it into a cloud, then you are at the right place. In this article I am going to show step-by-step how to take a generic Scala application and implement Kubernetes with Docker to launch multiple instances of the application. The final result will be a single application deployed as multiple instances, and load balanced by Kubernetes.

All of this will be implemented by simply importing the Kubernetes source kit in your Scala application. Please note, the kit hides a lot of complicated details related to installation and configuration, but it is small enough to be readable and easy to understand if you want to analyze what it does. For simplicity, we will deploy everything on your local machine. However, the same configuration is suitable for a real-world cloud deployment of Kubernetes.

Scale Your Scala Application with Kubernetes

Be smart and sleep tight, scale your Docker with Kubernetes.

What is Kubernetes?

Before going into the gory details of the implementation, let’s discuss what Kubernetes is and why it’s important.

You may have already heard of Docker. In a sense, it is a lightweight virtual machine.

Docker gives the advantage of deploying each server in an isolated environment, very similar to a stand-alone virtual machine, without the complexity of managing a full-fledged virtual machine.

For these reasons, it is already one of the more widely used tools for deploying applications in clouds. A Docker image is pretty easy and fast to build and duplicable, much easier than a traditional virtual machine like VMWare, VirtualBox, or XEN.

Kubernetes complements Docker, offering a complete environment for managing dockerized applications. By using Kubernetes, you can easily deploy, configure, orchestrate, manage, and monitor hundreds or even thousands of Docker applications.

Kubernetes is an open source tool developed by Google and has been adopted by many other vendors. Kubernetes is available natively on the Google cloud platform, but other vendors have adopted it for their OpenShift cloud services too. It can be found on Amazon AWS, Microsoft Azure, RedHat OpenShift, and even more cloud technologies. We can say it is well positioned to become a standard for deploying cloud applications.

Prerequisites

Now that we covered the basics, let’s check if you have all the prerequisite software installed. First of all, you need Docker. If you are using either Windows or Mac, you need the Docker Toolbox. If you are using Linux, you need to install the particular package provided by your distribution or simply follow the official directions.

We are going to code in Scala, which is a JVM language. You need, of course, the Java Development Kit and the scala SBT tool installed and available in the global path. If you are already a Scala programmer, chances are you have those tools already installed.

If you are using Windows or Mac, Docker will by default create a virtual machine named default with only 1GB of memory, which can be too small for running Kubernetes. In my experience, I had issues with the default settings. I recommend that you open the VirtualBox GUI, select your virtual machine default, and change the memory to at least to 2048MB.

VirtualBox memory settings

The Application to Clusterize

The instructions in this tutorial can apply to any Scala application or project. For this article to have some “meat” to work on, I chose an example used very often to demonstrate a simple REST microservice in Scala, called Akka HTTP. I recommend you try to apply source kit to the suggested example before attempting to use it on your application. I have tested the kit against the demo application, but I cannot guarantee that there will be no conflicts with your code.

So first, we start by cloning the demo application:

git clone https://github.com/theiterators/akka-http-microservice

Next, test if everything works correctly:

cd akka-http-microservice
sbt run

Then, access to http://localhost:9000/ip/8.8.8.8, and you should see something like in the following image:

Akka HTTP microservice is running

Adding the Source Kit

Now, we can add the source kit with some Git magic:

git remote add ScalaGoodies https://github.com/sciabarra/ScalaGoodies
git fetch --all
git merge ScalaGoodies/kubernetes

With that, you have the demo including the source kit, and you are ready to try. Or you can even copy and paste the code from there into your application.

Once you have merged or copied the files in your projects, you are ready to start.

Starting Kubernetes

Once you have downloaded the kit, we need to download the necessary kubectl binary, by running:

bin/install.sh

This installer is smart enough (hopefully) to download the correct kubectl binary for OSX, Linux, or Windows, depending on your system. Note, the installer worked on the systems I own. Please do report any issues, so that I can fix the kit.

Once you have installed the kubectl binary, you can start the whole Kubernetes in your local Docker. Just run:

bin/start-local-kube.sh

The first time it is run, this command will download the images of the whole Kubernetes stack, and a local registry needed to store your images. It can take some time, so please be patient. Also note, it needs direct accesses to the internet. If you are behind a proxy, it will be a problem as the kit does not support proxies. To solve it, you have to configure the tools like Docker, curl, and so on to use the proxy. It is complicated enough that I recommend getting a temporary unrestricted access.

Assuming you were able to download everything successfully, to check if Kubernetes is running fine, you can type the following command:

bin/kubectl get nodes

The expected answer is:

NAME        STATUS    AGE
127.0.0.1   Ready     2m

Note that age may vary, of course. Also, since starting Kubernetes can take some time, you may have to invoke the command a couple of times before you see the answer. If you do not get errors here, congratulations, you have Kubernetes up and running on your local machine.

Dockerizing Your Scala App

Now that you have Kubernetes up and running, you can deploy your application in it. In the old days, before Docker, you had to deploy an entire server for running your application. With Kubernetes, all you need to do to deploy your application is:

  • Create a Docker image.
  • Push it in a registry from where it can be launched.
  • Launch the instance with Kubernetes, that will take the image from the registry.

Luckily, it is way less complicated that it looks, especially if you are using the SBT build tool like many do.

In the kit, I included two files containing all the necessary definitions to create an image able to run Scala applications, or at least what is needed to run the Akka HTTP demo. I cannot guarantee that it will work with any other Scala applications, but it is a good starting point, and should work for many different configurations. The files to look for building the Docker image are:

docker.sbt
project/docker.sbt

Let’s have a look at what’s in them. The file project/docker.sbt contains the command to import the sbt-docker plugin:

addSbtPlugin("se.marcuslonnberg" % "sbt-docker" % "1.4.0")

This plugin manages the building of the Docker image with SBT for you. The Docker definition is in the docker.sbt file and looks like this:

imageNames in docker := Seq(ImageName("localhost:5000/akkahttp:latest"))

dockerfile in docker := {
  val jarFile: File = sbt.Keys.`package`.in(Compile, packageBin).value
  val classpath = (managedClasspath in Compile).value
  val mainclass = mainClass.in(Compile, packageBin).value.getOrElse(sys.error("Expected exactly one main class"))
  val jarTarget = s"/app/${jarFile.getName}"
  val classpathString = classpath.files.map("/app/" + _.getName)
    .mkString(":") + ":" + jarTarget
  new Dockerfile {
    from("anapsix/alpine-java:8")
    add(classpath.files, "/app/")
    add(jarFile, jarTarget)
    entryPoint("java", "-cp", classpathString, mainclass)
  }
}

To fully understand the meaning of this file, you need to know Docker well enough to understand this definition file. However, we are not going into the details of the Docker definition file, because you do not need to understand it thoroughly to build the image.

The beauty of using SBT for building the Docker image is that
the SBT will take care of collecting all the files for you.

Note the classpath is automatically generated by the following command:

val classpath = (managedClasspath in Compile).value

In general, it is pretty complicated to gather all the JAR files to run an application. Using SBT, the Docker file will be generated with add(classpath.files, "/app/"). This way, SBT collects all the JAR files for you and constructs a Dockerfile to run your application.

The other commands gather the missing pieces to create a Docker image. The image will be built using an existing image APT to run Java programs (anapsix/alpine-java:8, available on the internet in the Docker Hub). Other instructions are adding the other files to run your application. Finally, by specifying an entry point, we can run it. Note also that the name starts with localhost:5000 on purpose, because localhost:5000 is where I installed the registry in the start-kube-local.sh script.

Building the Docker Image with SBT

To build the Docker image, you can ignore all the details of the Dockerfile. You just need to type:

sbt dockerBuildAndPush

The sbt-docker plugin will then build a Docker image for you, downloading from the internet all the necessary pieces, and then it will push to a Docker registry that was started before, together with the Kubernetes application in localhost. So, all you need is to wait a little bit more to have your image cooked and ready.

Note, if you experience problems, the best thing to do is to reset everything to a known state by running the following commands:

bin/stop-kube-local.sh
bin/start-kube-local.sh

Those commands should stop all the containers and restart them correctly to get your registry ready to receive the image built and pushed by sbt.

Starting the Service in Kubernetes

Now that the application is packaged in a container and pushed in a registry, we are ready to use it. Kubernetes uses the command line and configuration files to manage the cluster. Since command lines can become very long, and also be able to replicate the steps, I am using the configurations files here. All the samples in the source kit are in the folder kube.

Our next step is to launch a single instance of the image. A running image is called, in the Kubernetes language, a pod. So let’s create a pod by invoking the following command:

bin/kubectl create -f kube/akkahttp-pod.yml

You can now inspect the situation with the command:

bin/kubectl get pods

You should see:

NAME                   READY     STATUS    RESTARTS   AGE
akkahttp               1/1       Running   0          33s
k8s-etcd-127.0.0.1     1/1       Running   0          7d
k8s-master-127.0.0.1   4/4       Running   0          7d
k8s-proxy-127.0.0.1    1/1       Running   0          7d

Status actually can be different, for example, “ContainerCreating”, it can take a few seconds before it becomes “Running”. Also, you can get another status like “Error” if, for example, you forget to create the image before.

You can also check if your pod is running with the command:

bin/kubectl logs akkahttp

You should see an output ending with something like this:

[DEBUG] [05/30/2016 12:19:53.133] [default-akka.actor.default-dispatcher-5] [akka://default/system/IO-TCP/selectors/$a/0] Successfully bound to /0:0:0:0:0:0:0:0:9000

Now you have the service up and running inside the container. However, the service is not yet reachable. This behavior is part of the design of Kubernetes. Your pod is running, but you have to expose it explicitly. Otherwise, the service is meant to be internal.

Creating a Service

Creating a service and checking the result is a matter of executing:

bin/kubectl create -f kube/akkahttp-service.yaml
bin/kubectl get svc

You should see something like this:

NAME               CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
akkahttp-service   10.0.0.54                  9000/TCP   44s
kubernetes         10.0.0.1     <none>        443/TCP    3m

Note that the port can be different. Kubernetes allocated a port for the service and started it. If you are using Linux, you can directly open the browser and type http://10.0.0.54:9000/ip/8.8.8.8 to see the result. If you are using Windows or Mac with Docker Toolbox, the IP is local to the virtual machine that is running Docker, and unfortunately it is still unreachable.

I want to stress here that this is not a problem of Kubernetes, rather it is a limitation of the Docker Toolbox, which in turn depends on the constraints imposed by virtual machines like VirtualBox, which act like a computer within another computer. To overcome this limitation, we need to create a tunnel. To make things easier, I included another script which opens a tunnel on an arbitrary port to reach any service we deployed. You can type the following command:

bin/forward-kube-local.sh akkahttp-service 9000

Note that the tunnel will not run in the background, you have to keep the terminal window open as long as you need it and close when you do not need the tunnel anymore. While the tunnel is running, you can open: http://localhost:9000/ip/8.8.8.8 and finally see the application running in Kubernetes.

Final Touch: Scale

So far we have “simply” put our application in Kubernetes. While it is an exciting achievement, it does not add too much value to our deployment. We’re saved from the effort of uploading and installing on a server and configuring a proxy server for it.

Where Kubernetes shines is in scaling. You can deploy two, ten, or one hundred instances of our application by only changing the number of replicas in the configuration file. So let’s do it.

We are going to stop the single pod and start a deployment instead. So let’s execute the following commands:

bin/kubectl delete -f kube/akkahttp-pod.yml
bin/kubectl create -f kube/akkahttp-deploy.yaml

Next, check the status. Again, you may try a couple of times because the deployment can take some time to be performed:

NAME                                   READY     STATUS    RESTARTS   AGE
akkahttp-deployment-4229989632-mjp6u   1/1       Running   0          16s
akkahttp-deployment-4229989632-s822x   1/1       Running   0          16s
k8s-etcd-127.0.0.1                     1/1       Running   0          6d
k8s-master-127.0.0.1                   4/4       Running   0          6d
k8s-proxy-127.0.0.1                    1/1       Running   0          6d

Now we have two pods, not one. This is because in the configuration file I provided, there is the value replica: 2, with two different names generated by the system. I am not going into the details of the configuration files, because the scope of the article is simply an introduction for Scala programmers to jump-start into Kubernetes.

Anyhow, there are now two pods active. What is interesting is that the service is the same as before. We configured the service to load balance between all the pods labeled akkahttp. This means we do not have to redeploy the service, but we can replace the single instance with a replicated one.

We can verify this by launching the proxy again (if you are on Windows and you have closed it):

bin/forward-kube-local.sh akkahttp-service 9000

Then, we can try to open two terminal windows and see the logs for each pod. For example, in the first type:

bin/kubectl logs -f akkahttp-deployment-4229989632-mjp6u

And in the second type:

bin/kubectl logs -f akkahttp-deployment-4229989632-s822x

Of course, edit the command line accordingly with the values you have in your system.

Now, try to access the service with two different browsers. You should expect to see the requests to be split between the multiple available servers, like in the following image:

Kubernets in action

Conclusion

Today we barely scratched the surface. Kubernetes offers a lot more possibilities, including automated scaling and restart, incremental deployments, and volumes. Furthermore, the application we used as an example is very simple, stateless with the various instances not needing to know each other. In the real world, distributed applications do need to know each other, and need to change configurations according to the availability of other servers. Indeed, Kubernetes offers a distributed keystore (etcd) to allow different applications to communicate with each other when new instances are deployed. However, this example is purposefully small enough and simplified to help you get going, focusing on the core functionalities. If you follow the tutorial, you should be able to get a working environment for your Scala application on your machine without being confused by a large number of details and getting lost in the complexity.

This article was written by Michele Sciabarra, a Toptal Scala developer.

Who Knew Adobe CC Could Wireframe?


Wireframing is a major step in designing any user interface whether a website, application or software product. Without distraction in the form of visuals, colours, typography, styles and effects you can be more focused on defining content hierarchy and user experience.

Doing low fidelity wireframes and prototypes will help you test and iterate more often and in earlier phases, work faster and develop products that your users will love.

There are a lot of different wireframing tools to choose from in the wild. Which one you choose will depend on your personal preferences and workflow style.

Just like a lot of designers moving to digital design from the print world, I’m an expert in the Adobe applications like Illustrator, InDesign, and Photoshop. I can use them efficiently, everywhere and at any time (even if someone wakes me up in the middle of the night and refuses to give me a cup of coffee). However, these have also become the tools I use to do web and application visual design. So, for my workflow to be the most efficient I use them for wireframing too.

Who knew Adobe CC Could Wireframe

With every project, I usually start designing by doing very rough sketches on paper, or lately more often, if not near my office desk, on my iPad or smartphone screen. These sketches are there only to focus my thoughts regarding the chosen concept and the client will probably never see any of them. When I feel confident enough that my idea works, I jump right away into wireframing. I usually use Adobe Illustrator and InDesign combined. Illustrator for creating most of the UI kit elements and InDesign for wireframing itself.

In this article, I’ll explain a step by step process of how to incorporate those tools into your wireframing workflow as well. But, before I go into details, let me show you what the strengths and weaknesses are of using InDesign as a primary wireframing tool.

The Pros and Cons of Using Adobe InDesign as a Wireframe and Prototyping Tool

For some time now Adobe InDesign has been not only a desktop publishing application, but it’s also widely used for digital publishing and EPUB creation, and there are also some reasons why it is a suitable tool for wireframing too:

  • Master pages – You can quickly and consistently apply global design elements like navigation, headers, footers and so on. You can create as many master pages as you need, and on top of it, one master can be based on another.
  • Solid grid support – Allows you to create easily and apply different kinds of grids, complementing columns, horizontal and vertical guides to create modules, and subgrids for greater complexity and precision.
  • Alternate layouts – Enables wireframes for multiple devices and orientations in the same file.
  • CC Libraries – Give easy access and reuse different assets like commonly used objects, colours, character and paragraph styles. Create assets in InDesign, Illustrator, Photoshop or with the Adobe Capture mobile app, whichever you prefer.
  • Layers – Provide you the ability to organize, group, show/hide and lock/unlock objects and content selectively in the wireframe. Every page of a multi-page InDesign document has the same number and order of layers. All of the changes you make to layers are reflected on all pages, like visibility, stacking order or deletion.
  • Styles and tables – Give complete control over the look of your text, objects and tables through the use of InDesign styles. Styles can be based on each other providing the ability to cascade desired formatting easily throughout the document. Creation and formatting of tables that you can use as wireframe content elements or even helpers for layout purpose is very simple.
  • Typekit integration – In high fidelity mock-ups, you can use any of the Typekit fonts that sync to the desktop.
  • Interactivity and animations – You can use Adobe InDesign built-in interactivity and animation features to create different states of the web or application design for interaction. Most people use these features while creating magazines for Digital Publishing Solution and fixed layout EPUB export but they can be suited for prototyping as well.
  • Export options – InDesign can export the wireframes and prototypes you create in a variety of formats. Interactive PDF will probably be your format of choice in the majority of cases, but you can also use quite new Publish Online Feature to convert your document to interactive HTML that can be viewed in modern desktop and mobile browsers. Unfortunately, you don’t have any control over the export using Publish Online, and exported file is hosted on Adobe servers. You can share the prototype URL to your client, or embed it into your site. For more control and direct export to HTML5 you can use the in5 extension from Ajar Productions.

Adobe InDesign has many pros to be used as a wireframe and prototyping tool, but it also has some disadvantages:

  • Lack of predefined wireframe templates and elements – Since InDesign is not meant to be a wireframing tool, you have to create and prepare templates and object assets by yourself. (I’ll show you how to make that preparation step later in this article.) The good news is that most of this work will be done only once and after a few hours of work you’ll be ready to jump start your InDesign wireframing. Also, there are a lot of assets and wireframe kits that you can download from the internet, so there is no need to draw everything yourself.
  • Interactivity and animation features are limited and can be time-consuming – Although you can easily connect pages and add some interactivity and animations that process sometimes takes a long time. Some of the simple interactions can not be achieved simply, and you have to figure out how to do it. If you haven’t been using InDesign interactivity features yet, you’ll have a slight learning curve before you’ll be able to apply them efficiently.
  • InDesign documents can’t export directly as layered PSD files – If you do your visual design in Adobe Photoshop and want to have separated wireframe elements from building your design on, then you have to export your wireframes to PDF first, then open that PDF in Illustrator and export as layered PSD. People working on the Mac can also use a free script written by Rob Day to save InDesign files as a layered PSD.

Good Wireframe Preparation is Half of the Work

Start by fine tuning your working environment. If you do not already have a saved Workspace in Illustrator and InDesign for this kind of work, create one. In Illustrator start with predefined Web workspace and adapt it to your convenience: close panels you will not use often and open the ones you will, then rearrange them to suit your work style. When done, save the workspace by choosing Window > Workspace > New Workspace… Do the same thing in InDesign using Digital Publishing workspace as a starter.

Assembling Wireframe/Mockup/Prototype Kits

Efficient wireframing workflow using Illustrator and InDesign requests that you invest some time in making your user interface assets kit first. Since the introduction of Adobe Creative Cloud, CC Libraries are the best way for storing all your UI kits components.

You can create one or more Libraries for wireframing and prototyping purposes. For example, you can create one Library for websites wireframing, other for iOS application, third for Android applications and so on.

To create library Open Libraries panel and choose Create New Library from additional drop-down menu. Assets you put in libraries can be made and used in different Adobe desktop or mobile apps on all devices you log into with your Adobe ID. That means you can start with the project on your iPad or iPhone, continue on the desktop computer in the office and made last minute changes on home laptop with all the same assets available on all devices. If you work as a part of a larger team, library assets can be shared between team members and you can collaborate on them. Libraries can contain colours, graphics, layer styles (Photoshop only), paragraph and character styles. You add asset in library by clicking on the corresponding button at the bottom of CC Library panel with respective element selected. You can also add graphic assets by dragging them directly from your artboard to Libraries panel. Assets in libraries are organized by categories. To stick with good practices, rename each asset with meaningful name. Libraries are searchable, and finding an asset in a hip by typing beginning of it’s name will save you tons of time, especially when you have many different items in libraries. You can search only current or all libraries created. To change asset name just double click on it and type a new one.

Creating Kits Components

Although Adobe InDesign has some basic drawing tools that are pretty similar to Illustrator’s, Illustrator is a much better choice for drawing different kinds of elements in your wireframe. As a rule of thumb, make all kit elements that request some drawing beyond basic geometric shapes in Illustrator and simpler elements, that contain text you’ll need to change in layout, like simple buttons, in InDesign.

For starters, make a list of all the elements in the wireframe you’ll need, like navigation elements, page elements including images, video frames and text boxes, icons, avatars, form elements and all other interface elements. After your list is completed you can head to Illustrator and InDesign for elements creation. Start by creating a new document for wireframe or mockup kit components. Double-check that you choose either Web/Devices Profile in Illustrator or Web/Digital Publishing Intent from New Document dialog box, so pixels are used as units, and color mode is RGB.

Make wireframe kit assets as simple as possible, because they need to give fast visual cues for what they represent without been too much detailed. You should use very limited colour palettes of preferably a few shades of grey. Visually accentuate elements that are more important by coloring them with darker shades, or by giving them bigger contrast. For higher fidelity mockups or prototypes, you’ll create UI kits with more detailed elements that use each project’s respective color palette. For easy access to color palettes add them to CC Libraries too.

Who knew Adobe CC Could Wireframe

Adobe Illustrator assets in CC Libraries

Assets you add to Libraries from Illustrator are linked by default (since Adobe CC 2015). That means that when you modify a library asset in Illustrator, changes are reflected in all instances used. If you want to add unlinked asset to document press Option/Alt key while dragging it from the panel.

Who knew Adobe CC Could Wireframe

When you use linked Illustrator assets in InDesign they have little cloud icon in the upper left corner when document is viewed in Normal mode and they are all listed in Links panel. If you modify Library asset in Illustrator changes in the InDesign document won’t be done automatically. Cloud icon will be replaced with Modified Link exclamation mark icon, and you’ll have to update these links.

InDesign assets you place in InDesign document are not linked. That means that you can edit instances independently of the original, and when the original asset is modified those changes are not reflected on assets you already put into layout.

Who knew Adobe CC Could Wireframe

Use those properties when creating wireframes on your behalf: add assets to Library from Illustrator when you assume they’ll need to be modified and updated globally or add them from InDesign when you know you’ll want to modify them individually. Note that you can also make graphics in Illustrator and then Copy/Paste them to InDesign, modify if needed and then add to Library as InDesign asset.

If you happen to forgot which graphic asset is created by which application look at the right side of each item in Library panel while using Show items as a list preview more.

Adobe InDesign Flexibility with Texts

Since you’ll probably want to be able to easily change texts and its formatting create text based assets in InDesign. InDesign has a nice feature for filling text boxes with placeholder text. When you draw text box just make a right mouse click on it and choose Fill With Placeholder Text. You can easily add text box to Library like any other graphic element just by dragging. When you use those text assets later as a part of your wireframes layout you can modify text box itself or text it contains however you like.

Consider to make button UI elements in InDesign too. To create a button, make text frame first, type respective text in it and then use Object > Text Frame Options to define Inset spacing. Adjust Vertical Justification of text inside a box by choosing desired option from Align drop-down menu. Switch to Auto-Size tab and choose appropriate Auto-Sizing (that would probably be Width Only), and convenient reference point. If you do not want let InDesign break your text in more than a one line check No Line Breaks option.

Give Yourself a Hand

There are lot of Adobe Illustrator wireframing and prototyping UI kits available on the internet you can buy or even download for free if you want to fasten your wireframing preparation phase. Maybe you already have lot of those elements drawn that you can dig from your achieved projects. Open those documents, tweak any previously made elements if needed, and put them into respective Libraries.

If you are designing for a particular platform, for example iOS or an Android application be sure that you carefully read their human interface guidelines and use appropriate assets. Don’t put pressure on yourself that every asset possible has to be in your Libraries before you start with actual wireframing process because you can also add assets to your libraries later and on the go.

Creating InDesign Wireframe Templates

Who knew Adobe CC Could Wireframe

There is another important preparation step left that you also need to do: create InDesign templates you’ll use for making wireframes. Start by creating a new document with Web or Digital Publishing Intent and define appropriate page size for the screens you are designing for. Since it is recommended that you use some kind of a grid for laying out your wireframe elements set up the margins and create column grid by setting number of columns and the gutter space. You can change those settings later from Layout > Margins and Columns with respective master page (or pages) selected in Pages panel. If you need horizontal guides and complementary vertical guides, create them manually or make additional grid by using Layout > Create Guides… When creating grid you can help yourself with one of the online grid calculator tools like the Gridulator.

You can also create additional templates for presentation purposes with device mockup as a frame for your wireframes. Since one InDesign document can be placed into another, you can create wireframes in one InDesign document and then place it into another one for presentation purposes. Although it might seem complicated at first it is actually very simple and offers effective workflow. Keeping actual wireframe in separate document makes it easier to continue building from approved wireframes to polished visual design. On the other hand, you have presentation ready template to place wireframes into, add labels and comments and you are all set up to show your best to the client. When you make modifications on wireframe file just update it like any other link in presentation document, and ta-daaa! all changes are in your presentation too.

In the Layers panel you can prepare separate layers for different kind of the content: user interface elements, interactive features, gestures, labels or notes. If you’ll need more layers for a specific project you’ll be able to easily add them anytime during the wireframing process.

When you are done with creating save your templates as InDesign .indt template files. After all the templates you need are saved you are finally ready to start with wireframing efficiently.

Building Wireframes

First things first – start with the Master page. Drag all elements that will be the same on all screens of your project from Library. If you are designing website those are usually headers with logo and navigation and footer. Since you can make more than one Master page and they can be based on each other don’t forget to take advantage of that feature. For example, depending on the project, you can create a Master page for one website category, then make new Masters based on the first one and change on them only elements that need to be different for other categories you’re also having.

Who knew Adobe CC Could Wireframe

You can’t select, change or delete Master elements on regular document pages unless you click on them while holding Command/Control + Shift to override the master. Once your element is overridden you can change any of its parameters or completely delete it from layout. Keep in mind that even when you override the element, it’s parameters that you haven’t change are still dependent on the Master. For example, if you override an element and change it’s color, it’s size is still connected to Master’s and if you change it on Master page it will also be modified on that element you previously overrided. When inserting additional pages to your wireframing document remember to base them on the respective master. If you need to change the Master for pages already in layout, select them in Pages panel, make a right click and choose Apply Master to Pages… When you are finished with Masters, move along with pages for all screens of your project. Use Library assets and arrange them using Smart Guides and Align options to create final UI wireframe layout.

If you are making design for more than one screen size, make alternate layouts from Layouts > Create Alternate Layout or Pages panel. You can use liquid layout rules when creating alternate layouts to automatically or semi-automatically adopt page elements from one size and orientation to another or you can manually control them. For applying and testing Liquid Layout Rules use Page Tool or open panel: Window > Interactive > Liquid Layout.

Who knew Adobe CC Could Wireframe

Adding interactivity

Adobe InDesign has a bunch of interactivity features that you can take advantage of when creating wireframes or prototypes. Which features you’ll include depends on the final format you plan to save your wireframes, prototypes or presentation into. If you are exporting as PDF, interactivity is limited but you can at least make links between screens work. You’ll use Hyperlinks panel to create them. Select the item you want to behave as a link and click on New Hyperlink icon. From Link To drop down menu choose Page and enter desired page number. Repeat that action on all items you want to behave as links between the screens. You can also add hyperlinks to objects residing on the Master pages, and that can be a real time saver: create links on Master page once and they will work on all screens of your document.

Another interactive feature that you can use in interactive PDF format is button with Show/Hide action and that you can use to build all kinds of pop-up content.

You can create button from any graphic, text, image or a group. To create a button from a selected object use Window > Interactive > Buttons and Forms panel and click on the Convert to Button icon. Buttons can have different states created for Normal, Rollover and Click appearance. To add rollover or click state to button click on them in Buttons panel to activate and then edit button appearance for that state the way you want it to look. To add an action to a button, click on a plus sign and choose it from the list. Take into account that actions under SWF/EPUB will not work in interactive PDF. For creating popup elements choose Show/Hide Buttons and Forms. To hide buttons until triggered check Hidden Until Triggered option. You can include multistate objects in interactive PDF, but only if you export them as SWF first and then place those SWFs back in InDesign layout for PDF export. That workflow is tedious and those PDFs can not be properly seen in all PDF readers so you better avoid doing this unless really necessary.

If you want to convert your document to HTML prototype using InDesign CC 2015 Publish Online feature you can use much more interactive options like animations, multistate objects, multiple button actions, including all those intended for SWF/EPUB export.

You can add simple animations using Animation panel and choosing one of the built-in Presets from drop-down menu and setting its properties. One object can have only one animation applied, but if you need to add more of them, group your object with empty box and use the new animation on that newly created object. And repeat that few times if needed. For objects you need to show different states create multi state object. Create object for each state. Object can be a single element (picture, text box, graphic) or a group of different elements. Open Window > Interactive > Object States panel, select all objects you created for multi state object and click on the New button at the panel bottom. After your multi state object is made you’ll need to create buttons to go from one object state to another. Go To Next State or Go To Previous State actions reveal the specific object state with Go to State action.

If you want to have scrollable frame in your wireframe/prototype easiest way to create one is by usingUniversal Scrolling Frames extension from Ajar Productions. After you download and install extension you can use it as InDesign panel. For scrollable frame you’ll need to make content and one frame for container. Content can be text frame, picture, or more elements combined. If using more than one element as a content don’t forget to group them. When you are finished with making content and container box select the content and do Edit > Cut. Then select container and paste content inside by using Edit > Paste Into. Select container and using Universal Scrolling Frames adjust desired scroll direction.

By combining buttons, multistate objects, animations and scrollable frames you can achieve rich interactive experience.

To test interactivity in InDesign use EPUB Interactivity Preview panel. You can preview single page or whole document. Enlarge preview panel to your convenience.

If you haven’t being using Adobe InDesign interactive features yet be prepared that they have some learning curve, but with a little practice and few trial and error attempts you’ll quickly master them.

Exporting finished documents

When you are done with the wireframe and presentation file making all that is left is show your great ideas to the client in best way possible. For that purpose you’ll need to export your wireframes in one of the formats your client can preview. Although InDesign files can be exported in variety of formats you are probably going to use the most common Interactive PDF, or Publish Online feature if testing functional low or high fidelity prototypes. To save as interactive PDF choose Adobe PDF (Interactive) from Format drop-down menu in Export dialog box and adjust properties as needed. Do not forget to tick Forms and Media if there are interactive elements that you want to include. Clients can view PDF wireframes in free Adobe Reader and write all their comments in that same file.

You can also use PDF document you export from InDesign to create InVision (or some other tool that supports PDFs) prototype. If your standard prototyping tool, perhaps Marvel, can’t import PDF export your InDesign wireframe pages as JPEG or PNG images.

To export interactive HTML prototype that can be seen in modern browsers on different devices go to File > Publish Online or click on the Publish Online button from Application Bar. After the document is prepared to be published online and then uploaded you can copy document URL to share with all the stakeholders and start with reviewing process. You can also embed that published prototype on your site.

Downside of Publish Online feature is that it doesn’t have any additional control over the export and files are always stored at Adobe’s servers. Also it’s still preview feature and you can’t be sure in which direction Adobe is going to develop it or even discontinue.

Once your wireframe/prototype is exported it’s time for testing, reviewing and iterating process to start.

This article was written by  IVANA MILIČIĆ, a Toptal freelance designer.

The 5 Most Common UI Design Mistakes


Although the title UI Designer suggests a sort of departure from the traditional graphic designer, UI design is still a part of the historical trajectory of the visual design discipline.

With each movement or medium, the discipline has introduced new graphic languages, layouts, and design processes. Between generations, the designer has straddled the transition from press to xerox, or paper to pixel. Across these generations, graphic design has carried out the responsibility of representing the visual language of each era respectively.

Therefore, as UI Design makes the transition out of its infancy, what sort of graphic world can we expect to develop? Unfortunately, based on the current trajectory, the future may look bleak. Much of UI Design today has become standardized and repeatable. Design discussions online involve learning the rules to get designs to safely work, rather than push the envelope, or imagine new things. The tendency for UI Designers to resort to patterns and trends has not only created a bland visual environment, but also diminished the value of the designer as processes become more and more formulaic. The issue is precisely not one of technicalities, but of impending visual boredom.

Thus, the Top Five Common UI Design mistakes are:

  • Following Design Rules
  • Abusing the Grid
  • Misunderstanding Typefaces
  • Patterns and the Standardization of UI Design
  • Finding Safety in Contrast

UI Design Rule Book

Understand principles and be creative within their properties. Following the rules will only take your where others have been.

Common Mistake #1: UI Designers Follow the Rules

The world of graphic design has always followed sets of rules and standards. Quite often in any design discipline, the common mistakes that are made can closely coincide with a standard rule that has been broken. Thus, from this perspective the design rules seem to be pretty trustworthy to follow.

However, in just about any design discipline, new design movements and creative innovation has generally resulted from consciously breaking said rule book. This is possible because design is really conditional, and requires the discretion of the designer, rather than a process with any sort of finite answers. Therefore, the design rules should likely be considered as guidelines more so rather than hard and fast rules. The experienced designer knows and respects the rule book just enough to be able break the box.

Unfortunately, the way that design is often discussed online is within sets of do’s and don’ts. Top mistakes and practices for design in 10 easy steps! Design isn’t so straightforward, and requires a much more robust understanding of principles and tendencies, rather than checklists to systematically carry out.

The concern is that if designers were to cease ‘breaking the rules’, then nothing new creatively would ever be made. If UI designers only develop their ability to follow guidelines, rather than make their own decisions, then they may quickly become irrelevant. How else will we argue a value greater than off the shelf templates?

Be Wary of Top Ten Design Rules

The issue with design rules in today’s UI design community is they are so abundant. In the interest of solving any problem, the designer can look to the existing UI community and their set of solutions, rather than solve an issue on their own. However, the abundance of these guides and rules have made themselves less credible.

A google search for “Top UI Design Mistakes” yields a half million search results. So, what are the chances that most, if any of these authors of various articles agree with one another? Or, will each design tip that is discussed coincide accurately with the design problems of a reader?

Often the educational articles online discuss acute problems, rather than the guiding design principles behind the issue. The result is that new designers will never learn why design works the way that it does. Instead, they only become able to copy what has come before. Isn’t it concerning that in none of these sorts of articles is something like play encouraged?

The designer should have a tool kit of principles to guide them, rather than a book of rules to follow predetermined designs. Press x for parallax scrolling and y for carousels. Before choosing, refer to most recent blog post on which navigational tool is trending. Boring!

Trends are like junk food for designers. Following trends produces cheap designs that may offer some initial pay back, but little worth in the long run. This means that not only may trendy designers become dated, or ineffective quickly. But, for you the designer, don’t expect to experience any sense of reward when designing in this way. Although working to invent your own styles and systems is a lot of work, it’s so worth it day in and day out. There’s just something about copying that never seems to feed the soul.

Common Mistake #2: Allowing the Grid to Restrict UI Design

Despite my treatise against rules – here’s a rule: there is no way for a UI Designer to design without a grid. The web or mobile interface is fundamentally based on a pixel by pixel organization – there’s no way around it. However, this does not necessarily mean that the interface has to restrict designers to gridded appearances, or even gridded processes.

Using the Grid as a Trendy Tool

Generally, making any design moves as a response to trends can easily lead to poor design. Perhaps what results is a satisfactory, mostly functional product. But it will almost certainly be boring or uninteresting. To be trendy is to be commonplace. Therefore, when employing the grid in a design, understand what the grid has to offer as a tool, and what it might convey. Grids generally represent neutrality, as everything within the restraints of a grid appear equal. Grids also allow for a neutral navigational experience. Users can jump from item to item without any interference from the designer’s curatorial hand. Whereas, with other navigational structures, the designer may be able to group content, or establish desired sequences.

UI Design Rule Book

Although a useful tool, the grid can be very limiting to designers.

Defaulting to the Grid as a Work Flow

Dylan Fracareta, faculty of RISD and director of PIN-UP Magazine, points out that “most people start off with a 12 – column grid…because you can get 3 and 4 off of that”. The danger here is that immediately the designer predetermines anything that they might come up with. Alternatively, Fracareta resides to only using the move tool with set quantities, rather than physically placing things against a grid line. Although this establishes order, it opens up more potential for unexpected outcomes. Although designing for the browser used to mean that we would input some code, wait, and see what happens. Now, web design has returned to a more traditional form of layout designer that’s “more like adjusting two sheets of transparent paper”. How can we as designers benefit from this process? Working Without a Grid Although grids can be restricting, they are one of our most traditional forms of organization. The grid is intuitive. The grid is neutral and unassuming. Therefore, grids allow content to speak for itself, and for users to navigate at their will and with ease. Despite my warnings towards the restrictiveness of grids, different arrays allow for different levels of guidance or freedom.

Common Mistake #3:The Standardization of UI Design with Patterns

The concept of standardized design elements predates UI design. Architectural details have been frequently repeated in practice for typical conditions for centuries. Generally this practice makes sense for certain parts of a building that are rarely perceived by a user. However, once architects began to standardize common elements like furniture dimensions, or handrails heights, people eventually expressed disinterest in the boring, beige physical environment that resulted. Not only this, but standardized dimensions were proven to be ineffective, as although generated as an average, they didn’t really apply to the majority of the population. Thus, although repeatable detail have their place, they should be used critically.

If we as designers choose to automate, what value are we providing?

If we as designers choose to automate, what value are we providing?

Designers Using the Pattern as Product

Many UI designers don’t view the pattern as a time saving tool, but rather an off the shelf solution to design problems. Patterns are intended to take recurring tasks or artefacts and standardize them in order to make the designer’s job easier. Instead, certain patterns like F Pattern Layouts, Carousels or Pagination have become the entire structure of many of our interfaces.

Justification for the Pattern is Skewed

Designers tell themselves that the F shaped pattern exists as a result of the way that people read on the web.Espen Brunborg points out that perhaps people read this way as a result of us designing for that pattern. “What’s the point of having web designers if all they do is follow the recipe,” Brunborg asks.

Common Mistake #4: Misunderstanding Typefaces

Many designer’s quick tips suggest hard and fast rules about fonts as well. Each rule is shouted religiously, “One font family only! Monospaced fonts are dead! Avoid thin fonts at all costs!”. But really, the only legitimate rules on type, text and fonts should be to enforce legibility, and convey meaning. As long as type is legible, there may very well be an appropriate opportunity for all sorts of typefaces. The UI Designer must take on the responsibility of knowing the history, uses, and designed intentions for each font that they implement in a UI.

Consider a Typeface Only for Legibility

Typefaces convey meaning as well as affect legibility. With all of the discussion surrounding rules for proper legibility on devices etc, designers are forgetting that type is designed to augment a body of text with a sensibility, as much as it is meant to be legible. Legibility is critical, I do not dispute this – but my point is that legibility really should be an obvious goal. Otherwise, why wouldn’t we have just stopped at Helvetica, or maybe Highway Gothic. However, the important thing to remember is that fonts are not just designed for different contexts of legibility. Typefaces are also essential for conveying meaning or giving a body of text a mood.

Typefaces are each designed for their own uses. Don’t allow narrow minded rules to restrict an exploration of the world of type.

Avoiding Thin Fonts At All Costs

Now that the trend has come (and almost gone?), a common design criticism is to avoid thin fonts entirely. In the same way thin fonts came as a trend, they may leave as one also. However, the hope should be to understand the principles of the typefaces rather than follow trends at all.

Some say that they’re impossible to read or untrustworthy between devices. All legitimate points. Yet, this represents a condition in the current discussion of UI design. The font choice is only understood by designers as technical choice in regards to legibility, rather than also understanding the meaning and value of typefaces. The concern is that if legibility is the only concern that a designer carried, would thin fonts be done away with entirely?

Understand why you are using a thin font, and within what contexts. Bold, thick text is actually much more difficult to read at length than thinner fonts. Yet, as bold fonts carry more visual weight they’re more appropriate for headings, or content with little text. As thin fonts are often serifs, its suitability for body text is entirely objective. As serif characters flow together when read in rapid succession, they make for much more comfortable long reading.

As well, thin fonts are often chosen because they convey elegance. So, if a designer was working on an interface for a client whose mandate was to convey elegance, they might find themselves hard pressed to find a heavy typeface to do the job.

Not Enough Variation

A common mistake is to not provide enough variation between fonts in an interface. Changing fonts is a good navigational tool to establish visual hierarchy, or potentially different functions within an interface. A crash course on hierarchy will teach you that generally the largest items, or boldest fonts, should be the most important, and carry the most visual weight. Visual importance can convey content headings, or perhaps frequently used functions.

Too Much Variation

A common UI Design mistake is to load in several different typefaces from different families that each denote a unique function. The issue with making every font choice special, when there is many fonts, is that no font stands out. Changing fonts is a good navigational tool to establish visual hierarchy, or potentially different functions within an interface. Therefore, if every font is different, there is too much confusion for a user to recognize any order.

Common Mistake #5: Under/Over Estimating the Potential of Contrast

A common mistake that appears on many Top UI Design Mistake lists is that designers should avoid low contrast interfaces. There are many instances in which low contrast designs are illegible and ineffective – true. However, as with the previous points, my worry is that this use of language alternatively produces a high contrast design culture in response.

Defaulting to High Contrast

The issue is that high contrast is aesthetically easy to achieve. High contrast visuals are undeniably stimulating or exciting. However, there are many more moods in the human imagination to convey or communicate with, other than high stimulation. To be visually stimulating may also be visually safe.

The same issue is actually occurring in sci-fi film. The entire industry has resorted to black and neon blue visuals as a way to trick viewers into accepting ‘exciting’ visuals, instead of new, creative, or beautiful visuals. This article points out what the sci-fi industry is missing out on by producing safe visuals.

Functionally, if every element in an interface is in high contrast to another, then nothing stands out. This defeats the potential value of contrast as a hierarchical tool. Considering different design moves as tools, rather than rules to follow is essential in avoiding stagnant, trendy design.

Illegibly Low Contrast

The use of low contrast fonts and backgrounds is a commonly made mistake. However, rather than being a design issue. This could potentially be discussed as a beta testing mistake, rather than a design mistake.

How the design element relates as a low contrast piece to the rest of the interface is a design concern. The issue could be that the most significant item hierarchically is low in contrast to the rest of the interface. For the interface to communicate its organizational structure, the elements should contrast one another in a certain way. This is a design discussion. Whether or not it is legible is arguably a testing mistake.

The point is that in only discussing contrast as a technical issue resolvable by adjusting a value, designers miss out on the critical understanding of what contrast is principally used for.

Conclusion

As with the previous 4 mistakes, the abuse of patterns will rarely result in a dysfunctional website, but rather just a boring one. The mistake is in being safe. This overly cautious method of design may not cause the individual project to fail. However, this series of safe mistakes performed by the greater web community can mean greater failures beyond the individual UI design project. The role of the designer should be to imagine, thoughtfully experiment and create – not to responsibly follow rules and guidelines.

The original article is found on the Toptal Design Blog.

Top 10 Most Common Mobile App Design Mistakes


The mobile app market is saturated with competition. Trends turn over quickly, but no niche can last very long without several competitors jumping onto the bandwagon. These conditions result in a high failure rate across the board for the mobile app market. Only 20% of downloaded apps see users return after the first use, whereas 3% of apps remain in use after a month.

If any part of an app is undesirable, or slow to get the hang of, users are more likely to install a new one, rather than stick it out with the imperfect product. Nothing is wasted for the consumer when disposing of an app – except for the efforts of the designers and developers, that is. So, why is it that so many apps fail? Is this a predictable phenomenon that app designers and developers should accept? For clients, is this success rate acceptable? What does it take to bring your designs into the top 3% of prosperous apps?

The common mistakes span from failing to maintain consistency throughout the lifespan of an app, to attracting users in the first place. How can apps be designed with intuitive simplicity, without becoming repetitive and boring? How can an app offer pleasing details, without losing sight of a greater purpose? Most apps live and die in the first few days, so here are the top ten most common mistakes that designers can avoid.

Only 3% of mobile apps are in use after being downloaded.

Only 3% of mobile apps are in use after being downloaded.

Common Mistake #1: A Poor First Impression

Often the first use, or first day with an app, is the most critical period to hook a potential user. The first impression is so critical that it could be an umbrella point for the rest of this top ten. If anything goes wrong, or appears confusing or boring, potential users are quickly disinterested. Although, the proper balance for first impressions is tricky to handle. In some cases, a lengthy onboarding, or process to discover necessary features can bores users. Yet, an instantly stimulating app may disregard the need for a proper tutorial, and promote confusion. Find the balance between an app that is immediately intuitive, but also introduces the users to the most exciting, engaging features quickly. Keep in mind that when users are coming to your app, they’re seeing it for the first time. Go through a proper beta testing process to learn how others perceive your app from the beginning. What seems obvious to the design team, may not be for newcomers.

Improper Onboarding

Onboarding is the step by step process of introducing a user to your app. Although it can be a good way to get someone quickly oriented, onboarding can also be a drawn out process that stands in the way of your users and their content. Often these tutorials are too long, and are likely swiped through blindly.

Sometimes, users have seen your app used in public or elsewhere, such that they get the point and just want to jump in. So, allow for a sort of quick exit strategy to avoid entirely blocking out the app upon its first use. To ensure that the onboarding process is in fact effective, consider which values this can communicate and how. The onboarding process should demonstrate the value of the app in order to hook a user, rather than just an explanation.

Go easy on the intro animation

Some designers address the issue of a good first impression with gripping intro animations to dazzle new users. But, keep in mind that every time someone wants to run the app, they’re going to have to sit through the same thing over and over. If the app serves a daily function, then this will tire your users quickly. Ten seconds of someone’s day for a logo to swipe across the screen and maybe spin a couple times don’t really seem worth it after a while.

Common Mistake #2: Designing an App Without Purpose

Avoid entering the design process without succinct intentions. Apps are often designed and developed in order to follow trends, rather than to solve a problem, fill a niche, or offer a distinct service. What is the ambition for the app? For the designer and their team, the sense of purpose will affect every step of a project. This sensibility will guide each decision from the branding or marketing of an app, to the wireframe format, and button aesthetic. If the purpose is clear, each piece of the app will communicate and function as a coherent whole. Therefore, have the design and development team continually consider their decisions within a greater goal. As the project progresses, the initial ambition may change. This is okay, as long as the vision remains coherent.

Conveying this vision to your potential users means that they will understand what value the app brings to their life. Thus, this vision is an important thing to communicate in a first impression. The question becomes how quickly can you convince users of your vision for the app? How it will improve a person’s life, or provide some sort of enjoyment or comfort. If this ambition is conveyed quickly, then as long as your app is in fact useful, it will make it into the 3%.

Often joining a pre-existing market, or app niche, means that there are apps to study while designing your own. Thus, be careful how you choose to ‘re-purpose’ what is already out there. Study the existing app market, rather than skimming over it. Then, improve upon existing products with intent, rather than thoughtlessly imitating.

Common Mistake #3: Missing Out On UX Design Mapping

Be careful not to skip over a thoughtful planning of an app’s UX architecture before jumping into design work. Even before getting to a wireframing stage, the flow and structure of an app should be mapped out. Designers are often too excited to produce aesthetics and details. This results in a culture of designers who generally under appreciate UX, and the necessary logic or navigation within an app. Slow down. Sketch out the flow of the app first before worrying too much about the finer brush strokes. Often apps fail from an overarching lack of flow and organization, rather than imperfect details. However, once the design process takes off always keep the big picture in mind. The details and aesthetic should then clearly evoke the greater concept.

Common Mistake #4: Disregarding App Development Budget

As soon as the basis of the app is sketched, this is a good time to get a budget from the development team. This way you don’t reach the end of the project and suddenly need to start cutting critical features. As your design career develops, always take note of the average costs of constructing your concepts so that your design thinking responds to economic restraints. Budgets should be useful design constraints to work within.

Many failed apps try to cram too many features in from launch.

Many failed apps try to cram too many features in from launch.

Common Mistake #5: Cramming in Design Features

Hopefully, rigorous wireframing will make the distinction between necessary and excessive functions clear. The platform is already the ultimate swiss army knife, so your app doesn’t need to be. Not only will cramming an app with features lead to a likely disorienting User Experience, but an overloaded app will also be difficult to market. If the use of the app is difficult to explain in a concise way, it’s likely trying to do too much. Paring down features is always hard, but it’s necessary. Often, the best strategy might be to gain trust in the beginning with a single or few features, then later in the life of the app can new ones be ‘tested’. This way, the additional features are less likely to interfere with the crucial first few days of an apps’ life.

Common Mistake #6: Dismissing App Context

Although the conditions of most design offices practically operate within a vacuum, app designers must be aware of wider contexts. Although purpose and ambition are important, they become irrelevant if not directed within the proper context. Remember that although you and your design team may know your app very well, and find its interfacing obvious, this may not be the case for first time users, or different demographics.

Consider the immediate context or situation in which the app is intended to be used. Given the social situation, how long might the person expect to be on the app for? What else might be helpful for them to stumble upon given the circumstance? For example, UBER’s interface excels at being used very quickly. This means that for the most part, there isn’t much room for other content. This is perfect because when a user is out with friends and needing to book a ride, your conversation is hardly interrupted in the process. UBER hides a lot of support content deep within the app, but it only appears once the scenario calls for it.

Who is the target audience for the app? How might the type of user affect how the design of the app? Perhaps, consider that an app targeted for a younger user may be able to take more liberties in assuming a certain level of intuition from the user. Whereas, many functions may need to be pointed out for a less tech savvy user. Is your app meant to be accessed quickly and for a short period of time? Or, is this an app with lots of content that allows users to stay a while? How will the design convey this form of use?

A good app design should consider the context in which it is used.

A good app design should consider the context in which it is used.

Common Mistake #7: Underestimating Crossing Platforms

Often apps are developed quickly as a response to changing markets or advancing competitors. This often results in web content being dragged into the mobile platform. A constant issue, which you’d think would be widely understood by now, is that often apps and other mobile content make poor transitions between the desktop, or mobile platforms. No longer can mobile design get away with scaling down web content in the hope of getting a business quickly into the mobile market. The web to mobile transition doesn’t just mean scaling everything down, but also being able to work with less. Functions, navigation and content must all be conveyed with a more minimal strategy. Another common issue appears when an app developing team aspires to release a product simultaneously on all platforms, and through different app stores. This often results in poor compatibility, or a generally buggy, unpolished app.The gymnastics of balancing multiple platforms may be too much to add onto the launch of an app. However, it doesn’t hurt to sometimes take it slowly with one OS at a time, and iron out the major issues, before worrying about compatibility between platforms.

Common Mistake #8: Overcomplicating App Design

The famous architect Mies Van der Rohe once said, “It’s better to be good than to be unique”. Ensure that your design is meeting the brief before you start breaking the box or adding flourishes. When a designer finds themselves adding things in order to make a composition more appealing or exciting, these choices will likely lack much value. Continue to ask throughout the design process, how much can I remove? Instead of designing additively, design reductively. What isn’t needed? This method is directed as much towards content, concept and function as it is aesthetics. Over complexity is often a result of a design unnecessarily breaking conventions. Several symbols and interfaces are standard within our visual and tactile language. Will your product really benefit from reworking these standards? Standard icons have proven themselves to be universally intuitive. Thus, they are often the quickest way to provide visual cues without cluttering a screen. Don’t let your design flourishes get in the way of the actual content, or function of the app. Often, apps are not given enough white space. The need for white space is a graphic concept that has transcended both digital and print, thus it shouldn’t be underrated. Give elements on the screen room to breath so that all of the work you put into navigation and UX can be felt.

The app design process can be reductive, rather than additive.

The app design process can be reductive, rather than additive.

Common Mistake #9: Design Inconsistencies

To the point on simplicity, if a design is going to introduce new standards, they have to at least be consistent across the app. Each new function or piece of content doesn’t necessarily have to be an opportunity to introduce a new design concept. Are texts uniformly formatted? Do UI elements behave in predictable, yet pleasing ways throughout the app? Design consistency must find the balance between existing within common visual language, as well as avoiding being aesthetically stagnant. The balance between intuitive consistency and boredom is a fine line.

Common Mistake #10: Under Utilizing App Beta Testing

All designers should analyze the use of their apps with some sort of feedback loop in order to learn what is and isn’t working. A common mistake in testing is for a team to do their beta testing in-house. You need to bring in fresh eyes in order to really dig into the drafts of the app. Send out an ad for beta testers and work with a select audience before going public. This can be a great way to iron out details, edit down features, and find what’s missing. Although, beta testing can be time consuming, it may be a better alternative to developing an app that flops. Anticipate that testing often takes 8 weeks for some developers to do it properly. Avoid using friends or colleagues as testers as they may not criticize the app with the honesty that you need. Using app blogs or website to review your app is another way to test the app in a public setting without a full launch. If you’re having a hard time paring down features for your app, this is a good opportunity to see what elements matter or not.

The app design market is a battleground, so designing products which are only adequate just isn’t enough. Find a way to hook users from the beginning – communicate, and demonstrate the critical values and features as soon as you can. To be able to do this, your design team must have a coherent vision of what the app is hoping to achieve. In order to establish this ambition, a rigorous story-boarding process can iron out what is and isn’t imperative. Consider which types of users your app may best fit with. Then refine and refine until absolutely nothing else can be taken away from the project without it falling apart.

The original article was written by KENT MUNDLE – TECHNICAL EDITOR @ TOPTAL on the Toptal Design Blog

Top Ten Front-End Design Rules For Developers


As front-end developers, our job is, essentially, to turn designs into reality via code. Understanding, and being competent in, design is an important component of that. Unfortunately, truly understanding front-end design is easier said than done. Coding and aesthetic design require some pretty different skill sets. Because of that, some front-end devs aren’t as proficient in the design aspect as they should be, and as a result, their work suffers.

My goal is to give you some easy-to-follow rules and concepts, from one front-end dev to another, that will help you go from start to finish of a project without messing up what your designers worked so hard on (or possibly even allowing you to design your own projects with decent results).

Of course, these rules won’t take you from bad to magnificent in the time it takes to read one article, but if you apply them to your work, they should make a big difference.

Do Stuff In A Graphics Program

It’s truly rare that you complete a project, and go from start to finish while maintaining every single aesthetic mutation in the design files. And, unfortunately, designers aren’t always around to run to for a quick fix.

Therefore, there always comes a point in any front-end job where you end up having to make some aesthetic-related tweaks. Whether it’s making the checkmark that shows when you check the checkbox, or making a page layout that the PSD missed, front-enders often end up handling these seemingly minor tasks. Naturally, in a perfect world this wouldn’t be the case, but I have yet to find a perfect world, hence we need to be flexible.

A good front-end developer has to use professional graphics tools. Accept no substitute.

A good front-end developer has to use professional graphics tools. Accept no substitute.
For these situations, you should always use a graphics program for mockups. I don’t care which tool you choose: Photoshop, Illustrator, Fireworks, GIMP, whatever. Just don’t just attempt to design from your code. Spend a minute launching a real graphics program and figuring out how it should look, then go to the code and make it happen. You may not be an expert designer, but you’ll still end up with better results.

Match the Design, Don’t Try To Beat It

Your job is not to impress with how unique your checkmark is; your job is to match it to the rest of the design.

Those without a lot of design experience can easily be tempted to leave their mark on the project with seemingly minor details. Please leave that to the designers.

Developers have to match the original front-end design as closely as possible.

Developers have to match the original front-end design as closely as possible.
Instead of asking “Does my checkmark look amazing?” you should be asking, “How well does my checkmark match the design?”

Your focus should always be on working with the design, not on trying to outdo it.

Typography Makes All the Difference

You’d be surprised to know how much of the end look of a design is influenced by typography. You’d be just as surprised to learn how much time designers spend on it. This is not a “pick-it-and-go” endeavor, some serious time and effort goes into it.

If you end up in a situation where you actually have to choose typography, you should spend a decent amount of time doing so. Go online and research good font pairings. Spend a few hours trying those pairings and making sure you end up with the best typography for the project.

Is this font right for your project? When in doubt, consult a designer.

Is this font right for your project? When in doubt, consult a designer.
If you’re working with a design, then make sure you follow the designer’s typography choices. This doesn’t just mean choosing the font, either. Pay attention to the line spacing, letter spacing, and so on. Don’t overlook how important it is to match the typography of the design.

Also, make sure you use the right fonts in the correct spot. If the designer uses Georgia for headers only and Open Sans for body, then you shouldn’t be using Georgia for body and Open Sans for headers. Typography can make or break aesthetics easily. Spend enough time making sure you are matching your designer’s typography. It will be time well spent.

Front-end Design Doesn’t Tolerate Tunnel Vision

You’ll probably be making small parts of the overall design.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.
An example I’ve been going with is making the checkmark for a design that includes custom checkboxes, without showing them checked. It’s important to remember that the parts you are making are small parts of an overall design. Make your checks as important as a checkmark on a page should look, no more, no less. Don’t get tunnel vision about your one little part and make it something it shouldn’t be.

In fact, a good technique for doing this is to take a screenshot of the program so far, or of the design files, and design within it, in the context in which it will be used. That way, you really see how it affects other design elements on the page, and whether it fits its role properly.

Relationships And Hierarchy

Pay special attention to how the design works with hierarchy. How close are the titles to the body of text? How far are they from the text above them? How does the designer seem to be indicating which elements/titles/text bodies are related and which aren’t? They’ll commonly do these things by boxing related content together, using varying white space to indicate relationships, using similar or contrasting colors to indicate related/unrelated content, and so on.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.
It’s your job to make sure that you recognize the ways in which the design accomplishes relationships and hierarchy and to make sure those concepts are reflected in the end product (including for content that was not specifically designed, and/or dynamic content). This is another area (like typography) where it pays to take extra time to make sure you’re doing a good job.

Be Picky About Whitespace And Alignment

This is a great tip for improving your designs and/or better implementing the designs of others: If the design seems to be using spacings of 20 units, 40 units, etc., then make sure every spacing is a multiple of 20 units.

This is a really drop-dead simple way for someone with no eye for aesthetics to make a significant improvement quickly. Make sure your elements are aligned down to the pixel, and that the spacing around every edge of every element is as uniform as possible. Where you can’t do that (such as places where you need extra space to indicate hierarchy), make them exact multiples of the spacing you’re using elsewhere, for example two times your default to create some separation, three times to create more, and so on.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.
A lot of devs achieve this for specific content in the design files, but when it comes to adding/editing content, or implementing dynamic content, the spacing can go all over the place because they didn’t truly understand what they were implementing.

Do your best to understand how the designer used whitespace and follow those concepts in your build. And yes, spend time on this. Once you think your work is done, go back and measure the spacing to ensure you have aligned and uniformly spaced everything as much as possible, then try out the code with lots of varying content to make sure it’s flexible.

If You Don’t Know What You’re Doing, Do Less

I’m not one of those people that thinks every project should use minimalist design, but if you’re not confident in your design chops and you need to add something, then less is more.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.
The designer took care of the main stuff; you only need to do minor fillers. If you’re not very good at design, then a good bet is to do as minimal amount as you can to make that element work. That way, you’re injecting less of your own design into the designer’s work, and affecting it as little as possible.

Let the designer’s work take center stage and let your work take the back seat.

Time Makes Fools Of Us All

I’ll tell you a secret about designers: 90 percent (or more) of what they actually put down on paper, or a Photoshop canvas, isn’t that great.

They discard far more than you ever see. It often takes many revisions and fiddling with a design to get it to the point where they’d even let the guy in the next cubicle see their work, never mind the actual client. You usually don’t go from a blank canvas to good design in one step; there’s a bunch iterations in between. People rarely make good work until they understand that and allow for it in their process.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.
So how do you implement this? One important method is taking time between versions. Work until it looks like something you like then put it away. Give it a few hours (leaving it overnight is even better), then open it up again and take a look. You’ll be amazed at how different it looks with fresh eyes. You’ll quickly pick out areas for improvement. They’ll be so clear you’ll wonder how you possibly missed them in the first place.

In fact, one of the better designers I’ve known takes this idea a lot further. He would start by making three different designs. Then, he’d wait at least 24 hours, look at them again and throw them all out and start from scratch on a fourth. Next, he’d allow a day between each iteration as it got better and better. Only when he opened it up one morning, and was totally happy, or at least, as close as a designer ever gets to totally happy, would he send it to the client. This was the process he used for every design he made, and it served him very well.

I don’t expect you to take it that far, but it does highlight how helpful time without “eyes on the design” can be. It’s an integral part of the design process and can make improvements in leaps and bounds.

Pixels Matter

You should do everything in your power to match the original design in your finished program, down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.
In some areas you can’t be perfect. For example, your control over letter-spacing might not be quite as precise as that of the designer’s, and a CSS shadow might not exactly match a Photoshop one, but you should still attempt to get as close as possible. For many aspects of the design, you really can get pixel-perfect precision. Doing so can make a big difference in the end result. A pixel off here and there doesn’t seem like much, but it adds up and affects the overall aesthetic much more than you’d think. So keep an eye on it.

There are a number of [tools] that help you compare original designs to end results, or you can just take screenshots and paste them into the design file to compare each element as closely as possible. Just lay the screenshot over the design and make it semi-transparent so that you can see the differences. Then you know how much adjustment you have to make to get it spot on.

Get Feedback

It’s hard to gain an “eye for design.” It’s even harder to do it on your own. You should seek the input of othersto really see how you can make improvements.

I am not suggesting you grab your neighbor and ask for advice, I mean you should consult real designers and let them critique your work and offer suggestions.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.
It takes some bravery to do so, but in the end it is one of the most powerful things you can do to improve the project in the short-term, and to improve your skill level in the long run.

Even if all you have to fine tune is a simple checkmark, there are plenty of people willing to help you. Whether it’s a designer friend, or an online forum, seek out qualified people and get their feedback.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.
It may sound time consuming, and may cause friction between you and your designers, but in the big scheme of things, it’s worth it. Good front-end developers rely on valuable input from designers, even when it’s not something they like to hear.

Therefore, it’s vital to build and maintain a constructive relationship with your designers. You’re all in the same boat, so to get the best possible results you have to collaborate and communicate every step of the way. The investment in building bonds with your designers is well worth it, as it will help everyone do a better job and execute everything on time.

Conclusion

To summarize, here is a short list of design tips for front-end developers:

  • Design in a graphics program. Don’t design from code, not even the small stuff.
  • Match the design. Be conscious of the original design and don’t try to improve it, just match it.
  • Typography is huge. The time you spend making sure it’s right should reflect its importance.
  • Avoid tunnel vision. Make sure your additions stand out only as much as they should. They’re not more important just because you designed them.
  • Relationships and hierarchy: Understand how they work in the design so that you can implement them properly.
  • Whitespace and alignment are important. Make them accurate to the pixel and make them evenly throughout anything you add.
  • If you’re not confident in your skills, then make your additions as minimally styled as you can.
  • Take time between revisions. Come back later to see your design work with fresh eyes.
  • Pixel-perfect implementation is important wherever possible.
  • Be brave. Seek out experienced designers to critique your work.

Not every front-end developer is going to be a fantastic designer, but every front-end dev should at least becompetent in terms of design.

You need to understand enough about design concepts to identify what’s going on, and to properly apply the design to your end product. Sometimes, you can get away with blind copying if you’ve got a thorough designer (and if you’re detail oriented enough to truly copy it pixel for pixel).

However, in order to make large projects shine across many variations of content, you need some understanding of what’s going through the designer’s head. You don’t merely need to see what the design looks like, you need to know why it looks the way it does, and that way you can be mindful of technical and aesthetic limitations that will affect your job.

So, even as a front-end developer, part of your regular self-improvement should always include learning more about design.

The original article was written by  BRYAN GREZESZAK – FREELANCE SOFTWARE ENGINEER @ TOPTAL and can be read here.

To learn more about Toptal designer resources, check this out – https://www.toptal.com/designers/resources

Getting started with Java interview questions


Are you getting ready for your next career move? And Java is your preferred tool -well its worth getting through interviewers mind set and acquaint with commonly asked questions. Yeah, agree, a simple Google search will get you a “lot of stuff” -one specific can be tried here. In fact this is bit uncommon, I have not faced 50% of these in any of my interview! but then who knows, writer can turn out to be next interviewer 🙂

Top 10 mistakes by Java programmer


Recently stumbled upon this post which outlines few common mistakes made by Java Programmer. Forgetting to write break statements in switch case constructs reminded me of my initial days -although now editors are capable to giving a warning about such oversight. Running a code quality will uncover few of these errors as well for example resource not closed or probability of getting ConcurrentModificationException. But  a good read, complete article here: