design

Two Game Changing CSS 3 Features

by Gordon. 1 Comment

HTML and CSS has always been filled with frustration when it comes to being able to intuitively create layouts and designs. Web developers have long since sacrificed ease of implementation for accessibility and semantic purity. Basic layouts and simple aesthetics frequently require very non-trivial implementations. This is especially apparent to developers who have tasted the forbidden fruit of other platforms such as Flex, Android, et al.

Until the near future. Two CSS 3 features in particular are finally solving this in a major way, making web design palatable to the code minimalist in all of us.

Flexible Box Layouts

The CSS 3 spec has introduced a new module which is supported by all major non-IE browsers as well as the IE 10 preview. This module is the Flexible Box Layout.

Gone are the days of forcing a layout into a float-based implementation. No more negative margins, excessive floating, and clear fixes. This also eliminates the added complexity of having to take into account margins, padding, and border when creating layout styling.

Anyone coming from a Flex or Android background will immediately see the value of this. In Flex and Android, vertical and horizontal box layouts are the backbone of any application. For layouts which aren’t flow based, this is much more intuitive.

For example, consider the following layout:

Child One
Child Two
Child Three
Child Four

With the associated markup (styling and browser-specific markup removed):

<div style="display:box;">
  <div>Child One</div>
  <div style="box-flex: 1;">Child Two</div>
  <div>Child Three</div>
  <div>Child Four</div>
</div>

I’m not going to go into detail as to what the code for this layout would look like today, but suffice it to say that any web developer should be intimately acquainted with such code.

There are other new layout modules as well (such as Grid Layout), but none that will play as big of a role in the micro-layout of small items on any website as the flexible box layout.

Nine Grid Backgrounds

I had previously created a jQuery plugin which enables 9-grid scaling support for javascript/css. This plugin has been made obsolete by the border-image style that is finally gaining widespread browser support. Similarly, 9-grid backgrounds have also been supported by frameworks such as Flex and Android for years.

Consider the following image:

Aqua Background

Using the border-image style, the following background can be created:

With the associated markup:

<div style="border-width: 25px; border-image: url('/wp-content/uploads/2011/11/aqua_bg.png') 25 25 25 25 repeat; width: 500px; height: 100px;"></div>

This allows for beautiful raster based backgrounds to be easily applied to fluid width elements. The one caveat here is that additional calculations will be required to take into account the additional border widths (which will be eventually mitigated by the border-image-outset property). In fact, the grid background (only visible on higher resolution screens) on the current theme for this blog is styled using border-image.

Game Changing

Having developed on platforms where these two features are standard, I can say that having these available as tools for web design will enable a new class of beautiful designs. Although nothing here was previously unrealizable with a lot of complex markup and styling, this will go a long way towards HTML becoming a much richer language for user interface.

Having lived through the era of table-based layouts, the era of accessibility driven div hell, and now the onset of CSS 3, I envy the next generation of programmers who take these types of tools for granted.

Design Tools Are Broken

by Gordon. 13 Comments

Spending lots of time both coding and designing has given me an acute awareness of how poor design tools are. Design itself has come a long way, but the design process has not. As a disclaimer, most of what is about to be said applies to user interface and graphic design, as opposed to illustration and the creative process.

The culture around design is primarily focused on the end product and not the process behind it. Photoshop, the industry standard for user interface design, is pixel-centric (limited vector support being a later addition). Trivial things such as rounding corners or changing resolutions are often non-trivial to accomplish. Re-usable assets, such as those found on Smashing Magazine, often consist of static images, hopefully in multiple resolutions. Cascading stylesheets, the lifeblood of web design, are exceedingly repetitive and usually degrade into an unmaintainable soup.

For comparison, the culture of software development largely evolves around getting things done cleanly, efficiently, and maintainably. Entire programming frameworks and communities arise around the idea of making the process of doing something developers are already able to do (e.g build websites) simpler. Existing bodies of code are re-factored entirely to be cleaner, despite having less features. New languages emerge with the goal of making software easier to develop. Re-usable libraries exist for almost every language and programming task imaginable.

The stereotypical developer is horrible at graphic design, but much of this is due to an impedance mismatch between software development and design practices. From the perspective of a good developer, many of the techniques that are required to create good design are appalling and contrary to their core philosophy.

Massive Violation of DRY

From Wikipedia:

Don’t Repeat Yourself (DRY) or Duplication is Evil (DIE) is a principle of software development aimed at reducing repetition of information of all kinds…

A rule of thumb for this is if you find yourself doing the same thing often, there is probably/should be a better way to do it. Whether I am writing CSS or creating layouts and graphics in Fireworks or Photoshop, I repeat myself all the time. As a response to this for CSS, developers have created tools such as SASS and LESS. The elephant in the room, however, is graphic design. Accomplishing commonplace visual effects such as curved drop shadows and glossy buttons usually requires following multi-step rote processes every time they are needed.

Poor Extensibility and Reusability

Perhaps causally related with the violation of DRY principles is the lack of ways to extend graphics design tools and reuse existing graphical designs.

In the case of software development, common design patterns and features can easily be modularized and re-used in various projects and components. Existing frameworks are also designed with plugin architecture’s in mind. The prevalence of rails extensions, for example, has made creating web applications with Ruby on Rails amazingly easy, far beyond what the original framework intended.

Graphic design tools are quite the opposite. One could imagine things like glossy buttons, advanced shadows, and other effects being easily scripted or packaged into custom filters, but it’s not so in reality. Despite having limited scripting support, the really useful plugins for tools like Photoshop and Fireworks were all built years ago in native code. These tools are used by thousands of programmers and designers, but the ecosystem around extending and contributing to these products is almost non-existant. I have personally put immense amounts of effort towards scripting Adobe Fireworks, but this has simply made the limitations more apparent.

CSS3 has actually made great strides in this area, but it will never be a complete substitute for graphics design. I can imagine a future ecosystem consisting of a robust open source graphics editing program(s) accompanied by a plethora of plugins, filters and assets freely distributed and written in a modern scripting language.

Immutability

Finished designs are often immutable and hard to change (and this has nothing to do with the good type of immutability). Source .psd files often consist of layers of flattened pixels, the exact combination of actions which created the layer lost forever. In many cases, this starkly contrasts with the underlying software being designed, which is in a constant state of flux and improvement.

The software equivalent of this would be software development tools which produce raw binaries without source code, the only possibility of change through a finite number of parameters. The natural solution would be to have graphics software which preserves the entire process by which an image was created. For this reason, I personally tend towards Adobe Fireworks, which is slightly better at this, dealing with items at the object level rather than the layer level.

Another solution would be to have the underlying format for the source of an image be an imperative graphics description language, e.g. Degrafa. SVG is theoretically nice, but is poorly implemented and monolithic, but still might ultimately be the answer.

Lack of Version Control

Binary source files don’t mesh well with version control. Merging conflicts is near impossible. Viewing and understanding the history of a file is not easy. I have seen workflows where all the design assets are passed around in shared folders with no version control at all. In the developer world, this would be almost unheard of. This also translates to the web, where design assets are clumsily distributed and the techniques used to create the asset are usually lost.

Reliance on Proprietary Tools

Almost no one would argue with the fact that Adobe Photoshop is the industry standard for graphic design, supplemented by Illustrator and sometimes Fireworks. Other open source tools such as GIMP and Inkscape are slightly sub par and suffer from the same lack of innovation. This state of affairs has been relatively the same for the last decade or more.

Not only does this restrict innovation, but it also restricts the platforms able to do graphics design. This prevents many developers and designers from using operating systems like Ubuntu as their primary OS. Moreover, I would argue that this has contributed to poor design in many OSS applications. Witnessing open-source software transforming the landscape of software development, one can only hope that the same will eventually happen to design.