By Peter-Paul Koch
Published on July 25, 2003
On a few occasions, Java programmers mailed me the URLs of the JavaScript libraries they had created, asking me to take a look at them and suggest improvements. I reject the whole idea of JavaScript libraries, so I never answered these mails.
They made me think, though, “Why do people write complex JavaScript libraries?”
Improving JavaScript
The most revealing purpose of a JavaScript library I ever encountered was “to make this-and-that Java functionality or structure available in JavaScript.” The hidden assumption is that JavaScript isn’t working properly. It should be improved. It really ought to be Java.
For some reason, people think JavaScript is simple. Sure, writing “Hello World” in a form field is simple, but creating an accessible, usable, and cross-browser compatible W3C DOM script is anything but.
Nonetheless, the misperception that JavaScript is simple (therefore low status) still survives, especially among “hard” programmers. Some of them don’t find it necessary to understand JavaScript. Instead, they want it to understand them. They want it to behave like the languages they already know. They want it to be a complicated, high status language like, for instance, Java.
These programmers don’t get the point of JavaScript but are arrogant enough to think they get it better than anyone else. Even worse, they write JavaScript libraries.
They should remember that JavaScript is not Java. It is a programming language in its own right with its own purpose, functionalities, and structures. It does not need to become Java either. If they want to write Java they should write Java. If they want to write JavaScript they should learn how to write it properly.
Size matters
When you add a script to a Web page you create a small, local effect that enhances the usability of that particular page. That’s the purpose of JavaScript. Such a small effect requires only a small script.
Unfortunately, library writers don’t understand this. Every JavaScript library grows and grows and grows until its sheer size and download time bears no relation to the rather meager results it delivers.
I once tested the DynAPI library by installing one of its pre-packed code examples that makes a layer bounce through the browser window. I then measured the weight of the required JavaScript files. The download necessary for this simple effect was nearly 40K!
Any competent JavaScripter could obtain this effect with 1K of code, if not less. I concluded that the DynAPI programmers, though they know far more about programming than I’ll ever learn, are not competent JavaScripters.
The huge size of libraries is caused by diligently construed layers of programming on top of other diligently construed layers of programming. That’s an excellent strategy for creating large applications, but in a Web environment it’s like using heavy artillery to kill a fly.
Objection
Sooner, rather than later, library writers smugly mention their object-oriented approach. Lo and behold, they ride to the rescue of poor JavaScript! It is not object oriented enough—a truly heinous heresy.
Browsers automatically create an astonishing amount of objects—for instance, the entire W3C DOM tree. These objects are already there, though, so they don’t count towards making JavaScript more object oriented. To prove their OO orthodoxy, library writers are forced to inflict their own flocks of obscure objects on an unsuspecting world.
Again, the writers refuse to consider the structure and purpose of JavaScript. I feel that JavaScript’s object-oriented approach mainly serves to keep access to the DOM simple. In any case, there are more than enough objects to create small, localized effects on Web pages. No one needs yet another bunch.
Finding fault
A purpose of many script libraries is to eliminate browser differences. This is usually praised as a great advantage, but to me it is their worst disadvantage.
These libraries cause the same problems as WYSIWYGs. If you stumble upon a difference not covered by the library because, for instance, a browser doesn’t behave as the programmer expected, you’re out of luck, especially when you’ve only worked with libraries and don’t have the faintest idea how to work with browsers.
Even if you do know something about browsers, it’s very difficult to find the offending line of code because it’s buried in some vague object at the lowest level of programming, the proper place for such aberrations. Even if you find it, chances are you have to scramble the library’s browser detect object first.
The documentation doesn’t give a clue either. Mere browser differences are not object oriented enough to merit inclusion in these pages devoted exclusively to the cleverly crafted library structure.
Writing simple scripts
When I create a JavaScript, I write procedural code: do this, then that, then that, then end the script. Only when a certain action occurs twice or more do I create a separate function for it. This keeps my scripts simple, clear, and easy to update even for another Web developer. It also keeps my scripts short because I don’t need a herd of overhead objects.
So my scripts aren’t reusable. I’ve never seen this as a problem. The real core of the script (finding the position of an element, accessing a DHTML layer) is reusable. I only have to copy a few key lines to get it working on any page in any browser that supports it. I usually document and publish this core code so that it’s readily available to all.
I have to rewrite the unique parts of the script (doing something with the position of the element, changing the styles of the DHTML layer), but I’d have to do that anyway, even when I’d use objects and libraries.
Don’t bother
So I disagree with all purposes of JavaScript libraries. I want a clear view of the browsers my script runs in, of their problems and quirks. My view should not be obstructed by a programming layer that is far too large and complex for the simple effects I need, that hides crucial lines of code deep inside a convoluted clutter of obscure objects, and is a monument to the absurd notion that JavaScript really ought to be Java.
My advice to library writers is: Don’t bother. Keep it simple.
Thursday, October 4, 2007
Fluid Thinking
By Peter-Paul Koch
Published on October 2, 2002
Times have changed for the better since the advent of Web standards. We can write a script or a CSS declaration, confident that Mozilla, Explorer and Opera will interpret it in roughly the same way. That confidence is a tremendous luxury, when compared to what we faced even a few years ago.
Not all incompatibilities between modern browsers have disappeared, though, and we ought to pay attention to the few remaining ancient browsers, too. What should we do? Hack the incompatibilities out of existence? Browser-detect undesired software and cast its users into oblivion?
...Or can we cater to incompatibilities and unusual browsers by flowing around the problems?
A weighty decision
A year ago I coded a site that looks distinctly worse in Netscape 4 than in more powerful user agents. I did this on purpose. I wanted to use modern CSS to apply an old-fashioned design without worrying about crappy browsers.
Nonetheless it was a weighty decision. I've been educated with the axiom that any design should render perfectly to the last pixel in any major browser, and dropping Netscape 4 compatibility would have been inconceivable.
I kept looking nervously over my shoulder, expecting snide remarks that the design was badly implemented and that I didn't know what I was doing. Fortunately no one else connected to the project thought of checking the site in Netscape 4.
Later I understood that even if they had checked, it wouldn't have mattered anyway. I'd managed to flow around the problems while doing what I was hired to do: the site was readable and the navigation worked. It degraded gracefully.
Graceful degradation
Apart from being the most... er... graceful term in the Web's working glossary, "graceful degradation" is a simple but powerful technique. The first step in adapting that technique successfully is fluid thinking: accepting the unpredictability that rules the user interface of the Web.
Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don't work (no CSS in Netscape 3, no images in speech browsers). Add whatever special effects you like, just make sure the site is usable without them.
Graceful degradation has two basic rules:
1. Any browser must be able to view the content of the site.
2. Any browser must be able to navigate the site.
View the plain HTML file without any CSS or JavaScript. Is the entire text legible? Is the page content ordered logically? Are all links in proper working order? If so, you have built a fluid, simple foundation for your site.
Now you can add extra layers of complexity, thinking fluidly all the time. How will the site look at a less-than-optimal resolution? Will the site be accessible without the DHTML navigation? What about unreliable CSS implementations? What if some effects work and others don't? What if everything goes wrong at the same time?
Don't worry about the answers, asking the questions is far more important. Take an extra day for your next site and half a day for the one after that. Ponder the questions. Before your third site is done you'll find the answers flowing into your head all by themselves.
Flowing out of the box
Fluid thinking will help you through a quagmire of minor bugs and differences, too. As an example, let's take a look at the conflicting box models, arguably one of the most complex browser compatibility problems in CSS-based design as it's practiced now.
* In the W3C box model, the width of a box determines the width of the content area, thus excluding the padding and border of the box.
* The Microsoft implementation measures width from border to border, so it includes padding and border.
Mozilla and Opera hold to the W3C standard, but Explorer uses the Microsoft model, so we poor Web Developers have one more browser incompatibility to solve.
It is possible to switch Explorer 6 to W3C standards mode by judicious use of doctype declarations, and conversely we can switch Mozilla to Microsoft mode. Finally a CSS hack is also available.
So we've got plenty of tools for complex workarounds... but can't we keep it simple?
The simplest way to avoid box model problems is to make sure they don't matter much. If your box has a fixed width, a 5px padding and a 1px border, Explorer will show it 12px smaller than the other browsers. If the design is fluid enough to accommodate this difference you don't need to worry.
Sometimes there isn't much room for fluidity. Start by asking yourself: Isn't the design too complex? Beginning Web designers can show a tendency to think too rigidly and to assume a site must look exactly as they created it. In those cases a quick lesson in liquid design is the best solution.
Conclusion
In my view graceful degradation and liquid design are both subsets of fluid thinking, one explaining how to flow around browser support problems, and the other helping us to let go of pixel-precision in graphical design.
Think fluid. The WWW isn't a fixed medium. It's unpredictable. It will do unexpected things to your site, and the best you can do is go with the flow.
Keep it simple. The fluidity of the Web is not the problem, it's the solution. If you accept that your site will never be viewed exactly as you want it, you understand the spirit of the Web and its standards.
Published on October 2, 2002
Times have changed for the better since the advent of Web standards. We can write a script or a CSS declaration, confident that Mozilla, Explorer and Opera will interpret it in roughly the same way. That confidence is a tremendous luxury, when compared to what we faced even a few years ago.
Not all incompatibilities between modern browsers have disappeared, though, and we ought to pay attention to the few remaining ancient browsers, too. What should we do? Hack the incompatibilities out of existence? Browser-detect undesired software and cast its users into oblivion?
...Or can we cater to incompatibilities and unusual browsers by flowing around the problems?
A weighty decision
A year ago I coded a site that looks distinctly worse in Netscape 4 than in more powerful user agents. I did this on purpose. I wanted to use modern CSS to apply an old-fashioned design without worrying about crappy browsers.
Nonetheless it was a weighty decision. I've been educated with the axiom that any design should render perfectly to the last pixel in any major browser, and dropping Netscape 4 compatibility would have been inconceivable.
I kept looking nervously over my shoulder, expecting snide remarks that the design was badly implemented and that I didn't know what I was doing. Fortunately no one else connected to the project thought of checking the site in Netscape 4.
Later I understood that even if they had checked, it wouldn't have mattered anyway. I'd managed to flow around the problems while doing what I was hired to do: the site was readable and the navigation worked. It degraded gracefully.
Graceful degradation
Apart from being the most... er... graceful term in the Web's working glossary, "graceful degradation" is a simple but powerful technique. The first step in adapting that technique successfully is fluid thinking: accepting the unpredictability that rules the user interface of the Web.
Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don't work (no CSS in Netscape 3, no images in speech browsers). Add whatever special effects you like, just make sure the site is usable without them.
Graceful degradation has two basic rules:
1. Any browser must be able to view the content of the site.
2. Any browser must be able to navigate the site.
View the plain HTML file without any CSS or JavaScript. Is the entire text legible? Is the page content ordered logically? Are all links in proper working order? If so, you have built a fluid, simple foundation for your site.
Now you can add extra layers of complexity, thinking fluidly all the time. How will the site look at a less-than-optimal resolution? Will the site be accessible without the DHTML navigation? What about unreliable CSS implementations? What if some effects work and others don't? What if everything goes wrong at the same time?
Don't worry about the answers, asking the questions is far more important. Take an extra day for your next site and half a day for the one after that. Ponder the questions. Before your third site is done you'll find the answers flowing into your head all by themselves.
Flowing out of the box
Fluid thinking will help you through a quagmire of minor bugs and differences, too. As an example, let's take a look at the conflicting box models, arguably one of the most complex browser compatibility problems in CSS-based design as it's practiced now.
* In the W3C box model, the width of a box determines the width of the content area, thus excluding the padding and border of the box.
* The Microsoft implementation measures width from border to border, so it includes padding and border.
Mozilla and Opera hold to the W3C standard, but Explorer uses the Microsoft model, so we poor Web Developers have one more browser incompatibility to solve.
It is possible to switch Explorer 6 to W3C standards mode by judicious use of doctype declarations, and conversely we can switch Mozilla to Microsoft mode. Finally a CSS hack is also available.
So we've got plenty of tools for complex workarounds... but can't we keep it simple?
The simplest way to avoid box model problems is to make sure they don't matter much. If your box has a fixed width, a 5px padding and a 1px border, Explorer will show it 12px smaller than the other browsers. If the design is fluid enough to accommodate this difference you don't need to worry.
Sometimes there isn't much room for fluidity. Start by asking yourself: Isn't the design too complex? Beginning Web designers can show a tendency to think too rigidly and to assume a site must look exactly as they created it. In those cases a quick lesson in liquid design is the best solution.
Conclusion
In my view graceful degradation and liquid design are both subsets of fluid thinking, one explaining how to flow around browser support problems, and the other helping us to let go of pixel-precision in graphical design.
Think fluid. The WWW isn't a fixed medium. It's unpredictable. It will do unexpected things to your site, and the best you can do is go with the flow.
Keep it simple. The fluidity of the Web is not the problem, it's the solution. If you accept that your site will never be viewed exactly as you want it, you understand the spirit of the Web and its standards.
Keep it Simple
By Peter-Paul Koch
Published on August 26, 2002
The first site I made as a professional web developer used 17 frames.
My first professional assignment was coding the World Press Photo site. In those days sites had to be compatible with Netscape and Explorer 3 and 4. That wasn't a problem - that's what I'd been hired for.
The site needed three content areas inside a static design of navigation and decoration. Nowadays we might use iframes for the content areas, but back then only one of the four popular browsers supported them. So I coded the site in frames and found that... I needed more than expected.
The cause was Netscape. It was impossible to be certain that in Netscape a frame had the exact width and height you defined, so I devised a workaround to make sure all frames fit snugly, whatever their actual width and height might be. I ended up with 17 frames.
Nothing wrong with that, I thought, and proceeded to add boatloads of JavaScripts to make sure the frames cooperated properly (and without which, incidentally, the site wouldn't work).
When the site went online, I felt proud. I'd proven to myself and to the world that I was a web developer.
Complexity
One year later all of the photos on the site had to be republished. I'd gained a lot of experience meanwhile, was promoted to head of Client Side Programming at my company and consequently made responsible for the cleanliness of our code.
I looked at the site anew and had a vague feeling of unease. Mightn't it contain slightly too many frames and scripts? Unfortunately the budget didn't call for a redesign, merely for new content. I nonetheless spent an entire day in study and judiciously merged two frames, making for a total of 16. I couldn't remove more frames without destroying the cross-browser compatibility of the design.
It took me another six months to realize that the whole thing was too complex. Since I was paid to worry about such matters, I thought long and hard. What had gone wrong? Could we avoid making the same mistakes again?
At first I blamed the design. In a literal sense this was correct: if the design hadn't called for three content frames and one very problematical line, the coding could have been much cleaner. But this only meant shifting the blame from myself to the designer, so it wasn't a real answer. Why had the design been so complicated? Why didn't we keep it simple?
The answer I found is that for most people
KISS
People were already protesting against this point of view. "Keep It Simple, Stupid!", they said. Of course other people disagreed. One mail succinctly stated: "KISS leads to LOVE (Leave Out Virtually Everything)".
This reaction accurately mirrored my fears. If we'd leave out the newest technologies, the well-designed Flash movie, the nifty DHTML script, what kind of site would remain? Just text and the tiniest bit of HTML? Booooring.
But then I discovered two things.
First of all sites should be exciting only when their purpose is to be exciting. An entertainment site should be exciting, sure. But what about an e-commerce site? A corporate site? A government site should be a bit dull, I'd think, to underline the importance of the information it provides.
Secondly, the whole idea of exciting vs. simple is a beginner's mistake, and in 1999 I was very much a beginner. Clients make this mistake all the time because they are beginners by definition. They (and many developers) are misled by the magic words "interactive multimedia". A site should be interactive! It should be multimedial! (whatever that may mean) The site should move, dance, prance, and who cares whether the subject calls for it? We're creative, right?
Simplicity
The old World Press Photo site was a typical example of this school of thought. It didn't contain any moving stuff, but to make up for that we used a tiny Java applet to mimic a dropdown box navigation - why keep it dull if we can make it complex? I replaced it with JavaScript during the review a year later. It can be argued that the site is still too complicated.
The good news is that in 2001 I got the chance to completely recreate the site, this time on better principles. We stopped using frames, and we changed the complex navigation scripts to slightly less complex DHTML scripts that enhanced the site but didn't contain vital functions. The result is a site that fulfills its purpose: showing the World Press Photos of the Year.
This made me rethink the whole complex-but-exciting approach and at the moment I'm on the move toward simplicity. I keep the purpose of the site firmly in mind and don't add unnecessary stuff just because it's possible. The newest browsers help a lot: CSS goes a long way towards creating appealing but simple sites.
In the next months I'll share my thoughts on simplicity in this column on Digital Web Magazine. Why do people make complex sites? When does a site become too complex? How should you judge whether a site needs to be complex? What techniques should you use to avoid complexity?
To make it absolutely clear, at the moment I write this I don't have the faintest idea what the answers will be. Let's hope they'll be simple...
Published on August 26, 2002
The first site I made as a professional web developer used 17 frames.
My first professional assignment was coding the World Press Photo site. In those days sites had to be compatible with Netscape and Explorer 3 and 4. That wasn't a problem - that's what I'd been hired for.
The site needed three content areas inside a static design of navigation and decoration. Nowadays we might use iframes for the content areas, but back then only one of the four popular browsers supported them. So I coded the site in frames and found that... I needed more than expected.
The cause was Netscape. It was impossible to be certain that in Netscape a frame had the exact width and height you defined, so I devised a workaround to make sure all frames fit snugly, whatever their actual width and height might be. I ended up with 17 frames.
Nothing wrong with that, I thought, and proceeded to add boatloads of JavaScripts to make sure the frames cooperated properly (and without which, incidentally, the site wouldn't work).
When the site went online, I felt proud. I'd proven to myself and to the world that I was a web developer.
Complexity
One year later all of the photos on the site had to be republished. I'd gained a lot of experience meanwhile, was promoted to head of Client Side Programming at my company and consequently made responsible for the cleanliness of our code.
I looked at the site anew and had a vague feeling of unease. Mightn't it contain slightly too many frames and scripts? Unfortunately the budget didn't call for a redesign, merely for new content. I nonetheless spent an entire day in study and judiciously merged two frames, making for a total of 16. I couldn't remove more frames without destroying the cross-browser compatibility of the design.
It took me another six months to realize that the whole thing was too complex. Since I was paid to worry about such matters, I thought long and hard. What had gone wrong? Could we avoid making the same mistakes again?
At first I blamed the design. In a literal sense this was correct: if the design hadn't called for three content frames and one very problematical line, the coding could have been much cleaner. But this only meant shifting the blame from myself to the designer, so it wasn't a real answer. Why had the design been so complicated? Why didn't we keep it simple?
The answer I found is that for most people
simple = dull. A site made by a creative web development company must never be dull, ergo it should be complicated.KISS
People were already protesting against this point of view. "Keep It Simple, Stupid!", they said. Of course other people disagreed. One mail succinctly stated: "KISS leads to LOVE (Leave Out Virtually Everything)".
This reaction accurately mirrored my fears. If we'd leave out the newest technologies, the well-designed Flash movie, the nifty DHTML script, what kind of site would remain? Just text and the tiniest bit of HTML? Booooring.
But then I discovered two things.
First of all sites should be exciting only when their purpose is to be exciting. An entertainment site should be exciting, sure. But what about an e-commerce site? A corporate site? A government site should be a bit dull, I'd think, to underline the importance of the information it provides.
Secondly, the whole idea of exciting vs. simple is a beginner's mistake, and in 1999 I was very much a beginner. Clients make this mistake all the time because they are beginners by definition. They (and many developers) are misled by the magic words "interactive multimedia". A site should be interactive! It should be multimedial! (whatever that may mean) The site should move, dance, prance, and who cares whether the subject calls for it? We're creative, right?
Simplicity
The old World Press Photo site was a typical example of this school of thought. It didn't contain any moving stuff, but to make up for that we used a tiny Java applet to mimic a dropdown box navigation - why keep it dull if we can make it complex? I replaced it with JavaScript during the review a year later. It can be argued that the site is still too complicated.
The good news is that in 2001 I got the chance to completely recreate the site, this time on better principles. We stopped using frames, and we changed the complex navigation scripts to slightly less complex DHTML scripts that enhanced the site but didn't contain vital functions. The result is a site that fulfills its purpose: showing the World Press Photos of the Year.
This made me rethink the whole complex-but-exciting approach and at the moment I'm on the move toward simplicity. I keep the purpose of the site firmly in mind and don't add unnecessary stuff just because it's possible. The newest browsers help a lot: CSS goes a long way towards creating appealing but simple sites.
In the next months I'll share my thoughts on simplicity in this column on Digital Web Magazine. Why do people make complex sites? When does a site become too complex? How should you judge whether a site needs to be complex? What techniques should you use to avoid complexity?
To make it absolutely clear, at the moment I write this I don't have the faintest idea what the answers will be. Let's hope they'll be simple...
Simplicity vs. Innovation
By Peter-Paul Koch
Published on November 25, 2002
Last month's column focused on the general concept of user-centered design. This month presents a look at the more limited field of usability and offers a way around the simple = dull equation that threatens good usability design.
Conservatism
A site should be innovative in design and content, but, when it comes to usability, a slightly conservative mindset is the best option.
Your visitors are used to particular ways of navigating sites and entering data in forms. If you keep it simple by sticking to those well-known ways, you're reasonably certain that most of your users will understand how your site works.
In practice, this may mean copying usability concepts from other sites. If thousands of well-known sites have a navigation bar on the left, your users will immediately understand what the off-color bar to the left with the many underlined bits of text is for.
Copying well-known concepts can be dull, even though it may be simple. As the first column explained, simple sites are often mistaken for dull sites.
New ideas
Not surprisingly, the simple = dull equation is a fundamental part of the mental make-up of all web designers, who have fallen in love with the endless empty spaces of the web. Web design is attractive because designers want to leave their mark on these spaces and fill them with new ideas. Yet, on the web, there are few fundamental rules; therefore, your ideas could become the new fundamental rules.
Suppose you have a great usability idea and try it in a few sites. Other web designers might pick it up and copy it or write about it. It's quite possible that, only one year after you originally conceived it, your idea could have grown into a basic law of usability.
Granted, this won't happen most of the time, but it is a distinct possibility. Even this small chance to create a fundamental law of a new medium is enough to dazzle the minds of creative, innovative people all over the world and to send them running for their computers.
Web designers and developers are, almost by definition, concerned with new ideas and with trying them in their sites. New ideas usually start as quite complicated affairs, mainly because the inventor doesn't yet know which parts of his or her idea will be important in the long run and which parts can be safely removed.
If web developers want to avoid complicated sites at all costs, they should avoid new ideas. Understandably, they don't like that idea, and, in fact, like it so little that simplicity and dullness have become one and the same.
One idea at a time
How do web designers avoid dullness while maintaining simplicity? How do they strike a balance that will satisfy both innovative web developers and conservative end users?
Use only one new idea in any web site. The users can concentrate on understanding this single new idea, while the rest of the site is comfortably familiar.
Suppose you create a web site which contains lots of forms. An extensive navigation provides access to these forms, and the visitors need some help entering the data. Finally, the data has to be validated and the results of this validation presented to the user.
Of these three usability problems, only one should be solved by a new idea. If you opt for a totally new way of navigating the forms, the help and validation functions should be based on old, well-known concepts. If you want to create an extensive and innovative help function, the navigation and validation should be as simple as possible.
Scientific approach
This approach has three distinct advantages. First, it reduces user confusion, which is always a good idea.
Secondly, this approach forces you to think and rethink the site and your ideas on a fundamental level. Which site feature is the most important: navigation, help function, or validation? Which of your new ideas is the best?
Finally, the goal of incorporating new ideas in your sites is to find out if they work, if they make a certain task easier and more intuitive, or if they provide a better interface for it. Therefore, the site you use them in is an experiment to find out if your idea is a good one. This experiment should be as scientifically correct as possible.
In any scientific experiment, if you want to find out if something works you isolate it. You make sure that all other factors that may influence the outcome of the experiment are as predictable as possible. Thus any reaction to the experiment is a reaction to the one unknown factor you allow.
In web design terms, any user feedback on or statistics of the site as a whole should ideally reflect only on your new idea. All items other than your new idea should be well known, even a bit boring, so that your visitors will use them without thinking and won't comment on them.
Of course, web development is not an exact science--far from it. Truly scientific experiments cannot be performed on web sites, since even the simplest site contains far too many unknown factors.
Nonetheless, it's a good idea to be as exact as you can, to isolate new ideas and test them "in the void," as it were, without a clutter of other new ideas that may distort the outcome of the experiment. Even if your data won't be scientific evidence, you'll have a better chance to discover how your idea works in practice and how you can improve on it.
Allowing only one new idea at a time is the best way to keep your site simple while still allowing for innovation.
Published on November 25, 2002
Last month's column focused on the general concept of user-centered design. This month presents a look at the more limited field of usability and offers a way around the simple = dull equation that threatens good usability design.
Conservatism
A site should be innovative in design and content, but, when it comes to usability, a slightly conservative mindset is the best option.
Your visitors are used to particular ways of navigating sites and entering data in forms. If you keep it simple by sticking to those well-known ways, you're reasonably certain that most of your users will understand how your site works.
In practice, this may mean copying usability concepts from other sites. If thousands of well-known sites have a navigation bar on the left, your users will immediately understand what the off-color bar to the left with the many underlined bits of text is for.
Copying well-known concepts can be dull, even though it may be simple. As the first column explained, simple sites are often mistaken for dull sites.
New ideas
Not surprisingly, the simple = dull equation is a fundamental part of the mental make-up of all web designers, who have fallen in love with the endless empty spaces of the web. Web design is attractive because designers want to leave their mark on these spaces and fill them with new ideas. Yet, on the web, there are few fundamental rules; therefore, your ideas could become the new fundamental rules.
Suppose you have a great usability idea and try it in a few sites. Other web designers might pick it up and copy it or write about it. It's quite possible that, only one year after you originally conceived it, your idea could have grown into a basic law of usability.
Granted, this won't happen most of the time, but it is a distinct possibility. Even this small chance to create a fundamental law of a new medium is enough to dazzle the minds of creative, innovative people all over the world and to send them running for their computers.
Web designers and developers are, almost by definition, concerned with new ideas and with trying them in their sites. New ideas usually start as quite complicated affairs, mainly because the inventor doesn't yet know which parts of his or her idea will be important in the long run and which parts can be safely removed.
If web developers want to avoid complicated sites at all costs, they should avoid new ideas. Understandably, they don't like that idea, and, in fact, like it so little that simplicity and dullness have become one and the same.
One idea at a time
How do web designers avoid dullness while maintaining simplicity? How do they strike a balance that will satisfy both innovative web developers and conservative end users?
Use only one new idea in any web site. The users can concentrate on understanding this single new idea, while the rest of the site is comfortably familiar.
Suppose you create a web site which contains lots of forms. An extensive navigation provides access to these forms, and the visitors need some help entering the data. Finally, the data has to be validated and the results of this validation presented to the user.
Of these three usability problems, only one should be solved by a new idea. If you opt for a totally new way of navigating the forms, the help and validation functions should be based on old, well-known concepts. If you want to create an extensive and innovative help function, the navigation and validation should be as simple as possible.
Scientific approach
This approach has three distinct advantages. First, it reduces user confusion, which is always a good idea.
Secondly, this approach forces you to think and rethink the site and your ideas on a fundamental level. Which site feature is the most important: navigation, help function, or validation? Which of your new ideas is the best?
Finally, the goal of incorporating new ideas in your sites is to find out if they work, if they make a certain task easier and more intuitive, or if they provide a better interface for it. Therefore, the site you use them in is an experiment to find out if your idea is a good one. This experiment should be as scientifically correct as possible.
In any scientific experiment, if you want to find out if something works you isolate it. You make sure that all other factors that may influence the outcome of the experiment are as predictable as possible. Thus any reaction to the experiment is a reaction to the one unknown factor you allow.
In web design terms, any user feedback on or statistics of the site as a whole should ideally reflect only on your new idea. All items other than your new idea should be well known, even a bit boring, so that your visitors will use them without thinking and won't comment on them.
Of course, web development is not an exact science--far from it. Truly scientific experiments cannot be performed on web sites, since even the simplest site contains far too many unknown factors.
Nonetheless, it's a good idea to be as exact as you can, to isolate new ideas and test them "in the void," as it were, without a clutter of other new ideas that may distort the outcome of the experiment. Even if your data won't be scientific evidence, you'll have a better chance to discover how your idea works in practice and how you can improve on it.
Allowing only one new idea at a time is the best way to keep your site simple while still allowing for innovation.
Subscribe to:
Posts (Atom)