The pursuit of simplicity

As developers and designers we're especially predisposed to be problem solvers. We strive for perfection and innovative solutions. We want simplicity. Yet we still aren't sure what it exactly means. In this article we’ll discuss what the idea of simplicity means when it comes to application development, some ways developers and designers try to achieve simplicity and look at the potential benefits and drawbacks of each strategy.

Simplicity can be defined in numerous ways. Probably there are as many interpretations as there are dictionaries. We’ll focus on this one:

simplicity [noun]                        

• The quality or condition of being easy to understand or do.       
• The quality or condition of being plain or uncomplicated in form or design (which results in freedom from complexity).

This obviously suggests that simple things are easy to understand and use — which is a goal for all of us as designers and developers. As designers we want to create appealing experiences and intuitive interfaces which can be used by millions, regardless of their level of expertise. As developers we want to write quality code which will be readable and transparent enough for anyone who might contribute to or maintain the project. On the other hand, is the lack of complexity an indispensable ingredient of simplicity?

"We often talk about pursuing simplicity to reduce complexity. But complexity is quite valuable."
- Simon Collison

Complex and sophisticated solutions are also in high demand. There are many startups offering complicated functionality in the form of highly usable interfaces which can be appealing to a less tech-savvy audience (Github, is one example). Simplification doesn't mean removing features by making the assumption that they're too complex to be used. On the other hand intricacy can be hidden within the layers of a project, and result in performance or usability issues.

Simplicity is focus, on the core and the essence, of the product or piece of software.

Although simplicity itself is a goal for all the things we're creating for our users, we're also constantly trying to apply it to processes and workflow. We live in exciting times when the number of open source projects is growing rapidly, with many providing us tools designed to help streamline tasks. We take advantage of what we're offered but often these tools fail because we lacked a real justification for using them.

Tools are extremely practical when used in the right way. Before starting a new workflow, use caution, and research the pros and cons, to determine the level of complication they may bring.

Let's review some popular tools:

Frameworks

Frameworks are typically collections of reusable code snippets. Thanks to frameworks, everyone can work with their own boilerplate (and many of you do). Frameworks introduce certain level of simplification in terms of making processes more efficient and faster. Since they're generally created by respected experts, they are likely to follow best practices. Common issues and browser bugs are often already addressed by resets or hacks. But...

"Frameworks are not a substitute for thinking."
- Stephen Hay

No tool is. Always carefully consider and justify your decisions to use a framework.

Consider these advantages of using frameworks:

Faster development

Once you are over the learning curve, discussed later, the development process using a framework can be faster than without one. UI elements are often ready and functional. The markup can usually be copied, and various tools include functionality which enables you to simply enter one word and have a whole framework boilerplate appear (like the clips functionality in Coda).

Testing made easy

Testing takes up significant amount of time during the development cycle. Thanks to open source frameworks (which by definition are community driven) this time can be reduced. The markup has already been tested by authors and the community. If there is an issue, more than likely it has already been discovered on Github or StackOverflow.

Mobile testing is especially difficult because of the wide variety of devices and their associated cost. This can be overcome thanks to growing number of open mobile device labs. Still, these are not yet accessible to everyone and frameworks introduce some level of certainty that the markup will be work reliably across devices (to some extent).

Beginner friendly

Frameworks are a good starting point for beginning developers. They are easy to play around with and there are frequently many beginner tutorials to get you started.  You can also analyze the code and learn best practices.

And then there are some drawbacks:

Semantics

It is a known issue that CSS frameworks based on grids can introduce issues with semantic markup. Instead of taking advantage of native HTML5 elements which hold actual semantic value, pages contain great numbers of DIV tags and SPAN tags with rather meaningless naming conventions (such as column twelve, row, and other generic names). These classes make sense within the grid itself but don't indicate the content type when you simply read through the code.

One potential way of solving this issue, or at least improving the semantics, is assigning ARIA roles to elements. While ARIA was designed to improve accessibility and make the web friendlier for people with disabilities, it can also enhance code readability and make your code easier to scan.

For example, instead of writing this line:

<div class="row"></div>

You could write this instead:

<div class="row" role="main"></div>

Of course, you can simply add more classes to your code without using ARIA, but if you use ARIA you get the added value of making your web content more accessible for everyone.

The learning curve

There is always a certain amount of time required to familiarize yourself with a new tool. As Matt Wilcox says:

"Frameworks are useful for speeding up the production of a project, once you’ve learned them."

You must devote time to read the documentation, acclimate to the framework, and understand the code before you can use a framework effectively. Initially, the time you invest may be comparable to developing your own solution. You can make an educated decision about whether to use a framework after evaluating the trade-offs you are willing to make.

For example, if you want to prototype quickly, then a framework usually makes  that process faster. If you want complete control of the markup from the very beginning, you should develop your own solution. There are multiple considerations and all of them are based on the type, size, and other technical requirements of each project.

Update management

Open source projects are changing rapidly. Maintainers proactively resolve issues, and the community helps to improve them by opening more and more pull requests. This means that you devise a strategy to manage the updates to the framework or frameworks you use.

For example, when using Bootstrap, you may decide that the generic default UI elements need to be updated. You can achieve this modifying the main stylesheet and changing some of the colors and styles. However, if a new version is rolled out overnight, even using version control, the process of managing merges can be a very painful process. You have to decide whether to create a separate style sheet, which won’t be affected by updates, or acknowledge the fact that you'll need to address these challenging merges as they occur.

As much you may want to limit HTTP requests and minimize the number of CSS files in a project, you may be forced to create a separate style sheet that contains your own styles. On the other hand, the main style sheet file is full of code which might not be necessary for you (for example, you may not need a modal window in your project), so you could also choose to leave the the generic style sheet as-is and move specific styles into a customized style sheet that won’t be affected by framework updates.

Heavyweight code

If you look at most popular so-called full stack (HTML, CSS, and JS) frameworks and the size of their main CSS file, you may be surprised:

• HTML5 Boilerplate: 299 lines
• ZURB Foundation: 1074 lines
• Twitter Bootstrap: 5894 lines

While these numbers are pretty impressive, they aren’t really comparable — HTML5 Boilerplate only offers a basic skeleton while the others include various UI elements which may come in handy. Still, it is a very important fact to consider: How much code weight are you willing to accept? We are living in the age of mobile devices, and optimization has become even more crucial than before. Try to keep your stack to the minimum.

Libraries are equally as popular as frameworks. As much as frameworks try to solve broad range of issues, libraries should, by definition, address a specific problem. (To see some examples, check out this collection of micro JavaScript libraries).

“Worst case of copying and pasting I saw going on around the Web? My answer: jQuery”

Peter-Paul Koch (known online as @ppk) conducted a large survey on JavaScript libraries and the results were very surprising. Over 80% of participants stated that they are using jQuery in over 50% of their projects. 60% said that they would be able to tackle these challenges themselves but they have decided to use a library instead. Therefore more than 50% of projects include some sort of library (based on an impressive 80,000 responses).

The advantages and disadvantages of libraries are fairly similar to those discussed for frameworks, so I’d like to focus on something else: jQuery. jQuery is probably the most popular library at the moment. Loved by millions, hated by a few. Still, it is commonly used instead of achieving the same or similar effects with plain CSS. The capabilities of CSS selectors (also document.querySelectorAll) and CSS animations are fairly advanced, and that’s why jQuery is arguably overused in a significant number of cases.

When it’s not a matter of cross-browser support, is it laziness and a fake impression of simplification that drives us to choose a library when it may not be necessary? It's important to evaluate if a project depends on a huge, monolithic library to achieve a simple effect, which could have been implemented just as simply without using the library.

For many designers, preprocessing is a salvation. While CSS preprocessors offer a number of advantages, you must also be aware of some potential disadvantages. CSS preprocessors include tools like LESS, Sass, Stylus, RCSS, and others.

Here are some advantages:

Feature-rich

Preprocessors offer features not yet implemented (or not even scheduled for implementation) in CSS, but impatiently awaited, such as mixins or variables.

Easier and faster

Thanks to syntax improvements (such as omitting semicolons or curly brackets), easy file imports, variables, and mixins, the level of redundancy within the code is reduced and easier to read.

It’s all CSS anyway

No matter which preprocessor you use, the final project can still be compiled to pure CSS, familiar to every developer. You can choose the tool of your trade for development purposes and still have minified CSS for production environments.

However, there are some drawbacks:

Problematic debugging

Debugging has been an issue for preprocessors and compiled languages for a long time. Web Inspector, Firebug, and other developer tools are part of our daily routine. Not being able to easily select an element and see what it correlates to in the style sheet can make debugging more challenging. Thankfully, this is already handled with source maps for Coffeescript. However, support for Sass or Less is not yet available. In the meantime, there are several less reliable solutions, such as FireSass, Sass Inspector or Sass Sleuth.

New level of complexity

The problem of the learning curve strikes again. Some of advanced features, like mixins, seem more like writing JavaScript or regular expressions than CSS, which is not desireable. Certain features can also increase the level of complexity and redundancy, such as the famous @extend rule.

With all these tools (and many others not mentioned above), how can we avoid overcomplicating? A lot of new projects get immediate attention and become viral in minutes. The hype isn’t always justified though. Don’t allow yourself to get overly excited with technologies just because they are new and popular. Don't fall into a trap of using fancy effects without justification.

Ask the right questions. Think carefully about what you are trying to achieve and whether the tool you have chosen is the right one for the job. What are the downsides of using it? Why is it better than other tools that may be available? More importantly, ask yourself if it is the best solution for your specific use case. Intentionally evaluate your decision and view it from as many perspectives as possible to be sure you've selected the best choice.

Remember that beautiful doesn’t always equal usable. Heavyweight designs often don’t serve the purpose of the user; they may be created to please the eye rather than to facilitate functionality. Think about optimization, page load, number of requests, code minification, and image compression. Treat accessibility and usability as top priorities.

Try not to confuse simplicity with minimalism, which is a very popular trend within web design at the moment. As mentioned earlier, less doesn’t necessarily means better. Simplicity is achieved by thoughtful reduction. When reducing, be mindful of your organization. Even if you are dealing with a large number of UI elements or a great deal of code, a proper hierarchy and structure can convey the feeling of simplicity.

Consider adding more focus on optimization as a way of boosting usability. Speed is often associated with simplicity—if an action is completed quickly, it can be perceived by the end user as being easy to accomplish.

Hopefully the guidelines provided in this article will be as helpful to you as they have been to my development workflow. Remember that things are only as complicated as you make them.

To learn more tips to develop projects more efficiently, see the following resources:

• HTML5, CSS3, and JavaScript Development Center
• Mobile and Tablet Developer Center