Simplicity and clarity as design tools

For the past week or so I’ve been customizing my WordPress install by adding a number of plugins. I plan on writing an article soon about what plugins I’m using, but first I’d like to talk about something that I’ve noticed about WordPress plugins. Installing plugins is easy. There’s plugin directory in every WordPress installation, generally under wp-content and you just drop a plugin folder in this directory and WordPress will detect it. If you’re using a recent version of WordPress, you can actually search the plugin repository and install a plugin from inside WordPress itself. This is really useful feature and makes using plugins much easier. However, the one gripe I have is that the settings to control the plugin get spread all over the WordPress interface.

Here’s a screenshot of my WordPress Dashboard. Along the left side you can see buttons for various drop down menus:

My WordPress Dashboard

My WordPress Dashboard

I’m currently using 8 plugins, each of which have various settings and interfaces to change those settings. One of those plugins (StatPress) has it’s very own sidebar menu. Two of them are under the Plugin menu, one is under the Tools menu and the rest are under the Settings menu. That means that if I have to find the settings for a particular plugin, I potentially have to look in 3 different places to find them. For me this is a clear design and organization mistake. Things that do the same thing should be in the same place. I’ve picked WordPress as the example because it’s what’s been striking me most recently, but it’s not the only one. Office 2008 for the Mac allows users to change the default saving format to the old formats. This option is in the same place for Word and Powerpoint, but is different from Excel.

Simplicity favors regularity. User interfaces need to be both simple and regular. Google’s interface is probably the simplest you can get. WordPress’ interface in general is pretty regular and simple, but the organization of the plugins is not regular at all and so there’s an extra level of complexity added in which users really shouldn’t have to deal with. It’s not just user interfaces. Indenting your code properly is also recommended for the same reason. All code that gets executed as part of the same operation should have the same indent level. It’s a visual clue that’s much easier to follow if done right than keeping track of curly braces. One of the criticisms of Perl is how it uses contexts: variables and operations can mean different things depending on what’s surrounding them. That isn’t always a bad thing, but it does mean that you have to consciously keep track of the context your code is in.

Similarly the development of the RISC processor architecture was motivated in part by the fact that most processor instruction sets are highly irregular with lots of instructions that seem very similar but actually operate quite differently (or have some seemingly arbitrary limitations). The book Computer Organization and Design which was co-authored by one of the creators of the RISC architecture, states 4 design principles, one of which is that Simplicity Favors Regularity. I must say I have to agree

While designers should try to contain functionality within regular components, it’s also possible to go overboard. Typical electrical installations in buildings are controlled by rows of identical switches. Very regular, but also perfectly impossible to tell which switch does what. Things that do different things should look different. Clarity is key. In the Design of Everyday Things, the author talks about how employees in power plants distinguish switches on their consoles by attaching different handles to them. One of the reasons that Lisp looks scary to a lot of programmers is that it can easily look all the same, as opposed to C-like languages where a for-loop looks very different from a function call or object creation. To be more specific, the external design of an object (or interface) should suggest it’s possible function. Admittedly this is harder for on-screen software than it is for physical object.

But these two principles seem contradictory. How do we reconcile regularity with easy differentiation. Part of the answer is that there is an underlying concept which is pretty powerful: ambiguity is bad. On Reddit today I saw an article criticizing Xfce’s settings interface. The author couldn’t figure out how to increase his text size. There is some comparison with the Windows 3.1 interface, but the central reason is that the Xfce settings interface is ambiguous: should text size be under Window Manager Settings, Display or User Interface Settings, all of which seem equally probable to the casual user. It’s the exact same case for my WordPress plugins. I think plugin settings should be under Plugins, but it does make sense to put them under Settings or Tools.


Xfce settings manager

So the question then is: how does one avoid ambiguity and achieve clarity, especially when there really are a number of logical alternatives (like WordPress)? In some cases it’s possible to use clear labels to distinguish what operation will be performed. Taking another example out of design of everyday things: a flat bar across a door makes it clear that the door is to be pushed, not pulled. When it comes to designing software interfaces like WordPress or XFCE, it’s not quite so simple because there can be a lot of debate over which design is correct. After all, plugin settings can go under Plugins or Settings. I feel that the key here is to just make a choice and then make that decision known. In the case of WordPress, plugin settings could go in either Plugins or Settings, though I would personally prefer Plugins so that there is one place for all plugin-related activities. But equally importantly, plugins should not be given a choice as to where in the UI to go. The case for XFCE is made more complicated by the fact that the text size for the window title bars can be changed independently of the rest of the UI and hence text size control is spread over two places. I would still argue that the two should be pulled into a single interface, but this is a case where the interface is heavily influenced by the functionality. The thing to remember in this case is that even if something might seem clear and logical for the developer or engineer, it might not seem that way for a casual user. Users don’t want to spend any time actively learning where things are, they just want to use it and they want it to work. Beta testing products with users is a great tool and it’s also essential that design decisions be well documented in easy to read manuals.

In conclusion: ambiguity is the enemy. Fighting ambiguity requires a two-pronged approached. Interfaces must be simple and regular so that the user is not overwhelmed with choices. But at the same time, there must be sufficient cues to let the user know that different objects have different functions and how required functionality can be accessed. This can be done by using labels (different text and images) and by offering easily accessible documentation. However, good design requires many decisions and compromises and the best way to figure out which ones are best is by watching actual users and adjusting accordingly.

It’s time for web 1.0 to die

Yes, this is going to be a controversial topic to write on and yes, I have a history of terribly messing up controversial topics. But I’m going to make an effort to keep my thoughts clear and justifiable. Without sounding too academic, let me first present my thesis:

The original internet and World Wide Web was one of the greatest technological innovations of human history. It has an interesting history fundamentally linked to many other developments in the past few decades. Any self-respecting computer geek should take a few hours and read about the start and growth of the net. However, in the 21st century, the old web is no longer enough. It is time for us to accept that the old days of plain HTML and static links are just that: old days. I’m going to show that important developments have made it necessary for us to look at the web in a new light and we must actively embrace these changes so that we can have a hope of shaping them into something as monumental as the original web.

Clarification: I’ve received my comments that made me realize that I should clarify what I mean by web 1.0. For the rest of this post I’ll take it to mean the web in terms of mostly human-generated, static pages with mostly static content. By contrast web 2.0 can be defined to be mostly auto-generated, constantly changing content where the main human role is to create the content, not manage its organization or delivery.

Trip down memory lane

In many ways the start of the internet can be traced back to Douglas Engelbart’s famous Mother of All Demos in 1968. This demo showed of the revolutionary NLS (oNLine System) which was years ahead of its time and presented important concepts such as voice and video conferencing, complex document formats and hyperlinks.

Fast forward a few decades and the internet was slightly more mainstream by the early 1990’s. Though the internet had implemented Engelbart’s vision to some extent, it was actually quite primitive by the standards of the demo. Hyperlinks were simple one-way roads instead of the ubiquitous and powerful cross-linking system that was part of the demo. Rich media communication was still years away. However, the key parts were in place. The early web was a rather simple place to live in. Mostly text, followed later by simple graphics. Pages were static and more often than not crafted by hand. For much of the 1990s the web bore the signs of the academic and somewhat austere and information dense culture that had spawned it.

That web is not the web of today. With low bandwidth, information density needs to be maximized, presentation is often an afterthought. While there are a small number of producers and a large number of viewers, it’s fairly simple to do things by hand. The drastic change of the internet in the past few years can be attributed to two main causes:

  1. The growth of scripting languages and applications built on them have allowed a massive explosion in the number of content producers. It’s possible to build a fairly high quality website without writing a single line of code.
  2. Bandwidth, storage and processing prices have fallen, opening the door for rich media applications, which can be distributed across the Internet.

Dynamism’s Day

The game of web development has changed at a fundamental level. You can no longer ship a website to a customer and expect it to stay the same way for months at a time. Dynamic content is the order of the day. Blogs are no longer creations of random individuals with too much time on their hands. Instead, if you want to have a viable web presence, you’d better have a blog and you’d better update it regularly. This goes for individuals as well as corporations (especially those whose business is the web). This in turns means that hand-rolling a website is impractical at best and downright stupid at worst. A recent article proclaimed that Dreamweaver is Dying, and I have to grudgingly agree. Over the past two years, I tried maintaining an old style website by hand with mostly static content, but it’s simply not worth it. I would rather spend 5 minutes working on a new post than fiddling around with HTML and CSS to get things to look right. And don’t even get me started with keeping links and navbars up to date. Dreamweaver and similar tools help. A lot. But they’re not enough.

Web 2.0 is showing us an important fact that we must not ignore: content creators do not need to be programmers as well. What that means for you and me is that if you want to create a content-focused site (and that’s what most of us want really) then an automated content management system like WordPress or Drupal combined with good themes and widgets should be our first pick. Only if the need for customization becomes overbearing (ie. you need to forge a brand image with a custom logo and theme) should you consider diving into the code.

For web developers, this means that you should pick a content platform or two and learn it back to front and inside out. Try porting some previous designs and suggest that customers take a more active role in creating their web presence. The web’s hallmark is that it is by definition a bidirectional medium. If anyone wants to be successful on the web, that bidirectionalim must be respected and utilized.

To generate the best content, you want to have good tools. Unfortunately HTML and CSS simply aren’t good tools for writers, journalists or artists. They want, no, they need WYSIWYG editors where they can see what their content will look like without worrying about the layers beneath. Cheap bandwidth means you can now use heavier technologies like Flash to build better looking tools. Cheap storage and processing power means that you can generate the webpages on the fly while keeping the actual content neatly stored in a backend database. HTML and CSS aren’t the core technologies of the web anymore; they’re a thin veneer that hides the raw power underneath and gives everyone a simpler, focused view of what they need to see.

Let’s face it, HTML is ugly. It’s angle-bracket hell and you know it!! No human should have to write that sort of thing by hand. CSS is better, but not by much. A lot of people complain that autogenerators create really bad, really redundant HTML and CSS. That’s true and I thought that was a bad thing and I hand crafted my code until not too long ago. But the fact is: no one cares!! No one is ever going to really read your generated code except browsers and they’re mostly pretty tolerant of what they’re fed as long as it’s not downright wrong. The massive boost in productiveness far outweighs any aesthetic qualms you may have. Sure you still need to do some amount of tweaking to get things just right, but it’s very easy to get good enough without doing any tweaking at all.

On another note, the database + dynamic code creates far better presentation/data separation than HTML/CSS ever could. You had to be really disciplined to not mix presentation consideration into your supposedly semantically structured HTML and you never got it quite right. Admit it, you know you bent the rules. But with web 2.0, such separation is natural. Theming is at the heart of almost every major CMS out there and the web is a better place thanks to it.

But wait, there’s more…

CMS’s are just the tip of the iceberg. Web 2.0 is becoming an application platform, much closer to Engelbart’s vision than to Web 1.0’s “information highway”. It’s not just content creation and delivery, it’s active interaction that is getting the spotlight. And HTML/CSS utterly fails at this. Text and graphics are ok, sound and video are good, but active interaction is even better. Web apps may not be as feature-rich as their desktop equivalents, but they’re not far behind either. I use Google Docs almost as much as I use Word and web-based IDEs are starting to become a reality. Take a look at the SproutCore and Cappuccino web frameworks for some examples of what’s on the horizon.

The limitations of Web 1.0 have spawned the developments of multiple ways around them. The web is a now a mix of different document formats and PDFs are gradually becoming the document interchange format of choice for many organizations and companies. Streaming media has proved to be a much more popular alternative than simply offering up files for download. The dynamic web is a much faster and more interesting place than 1.0 could ever be.

We’re only starting to explore the web as a core component of personal computing. Cloud computing is still a very nascent technology, but one that looks like will it progress by leaps and bounds in the years to come. Amazon S3 lets you store practically unlimited amounts of data for really cheap making it possible for any technologically savvy individual or group to roll their own webapp without investing in massive computing resources first. Why buy a external hard drive when you can pay a small monthly free for crash-proof, access-anywhere storage? (If you trust them with your data that is, but that’s for another post…

Web 1.0 is simple and for the past two decades it has served the needs of human society admirably. But we need more now. There is a massive amount of computing power in the world today, but we can’t use it properly if we stick to old fashioned HTML. The internet is no longer a web of statically linked pages. It’s a complex network of rapidly changing web applications interfacing with each other on a number of levels. It’s more like a growing, vibrant ecosystem than it is a spider-web. Web 2.0 is alive.

In the near future…

We must learn to start treating the web like a vast collection of interacting programs and not just as a simple file hierarchy. The author of the Dreamweaver is dying article says (quite rightly):

In the relatively near future every website will be a dynamically-generated web application and all of today’s sites built on multiple static pages will be ripped out and replaced.

I think that is pretty close to the truth. Sure there will be still be some holdovers, but any serious website will have no choice but to become a distributed webapp: part of it running on a server (or server farm) and part of it running as a scripted application in your browser. Sure you’ll still need a grasp of HTML/CSS and their descendants (for a while at least), but you’ll use them in much the same you people do baking nowadays: you make special treats now and then, but you’d hardly ever bake your own bread.

Web 1.0 is dying. It’s passing can be painful, but it doesn’t have to be. Start using content management systems. I would recommend open source systems like Drupal, WordPress and Joomla. If you’re a developer, learn PHP and JavaScript while keeping your HTML/CSS knowledge in fair shape. If you’re building a web application or framework, make it easier for non-browser clients like other webapps to access data and functionality. The easier it is to use your servive, the more people will use it. Twitter and Google Maps seem to do this quite well. Don’t worry about supporting every version or every browser ever built. Pick 2 or 3 modern browsers and make sure versions released in the last year or two work well. Above all, don’t do anything to turn away the early adopters.

It’s time for web 1.0 to die an honorable death. It’s time for the rest of us to move on.