Interface Design Under the Hood

The philosophy that a web site ought to be designed with human users in mind is (thankfully) well-entrenched into the thinking of modern web design.  But I think that it ought to apply to the whole web site.

Any designer worth his or her weight in pixels spends a lot of thought not just designing a pretty display, but also thinking like their eventual users: making the presentation clear and the navigation intuitive. After all, we build web sites for people, not the computers that run them.

But there is another user of your web site that usually goes completely unconsidered.  The interface for this user is virtually always left in a state decipherable by only those few who had their hands on it during construction.

The forgotten user is anyone who follows you. Including yourself. The forgotten interface? The code.

With all of the justifiably righteous attention paid to the public face of the web site, it would seem like a no-brainer that the same user-first philosophy would be a guidepost in the construction of the code base. But that’s rarely the case.

I don’t mean that it’s poorly written code, or that it has utilized a sub-standard framework, or sub-standard technologies. It could be the best of all possible worlds, written with sizzling textbook perfection.

And yet, how common is it to spend twenty minutes tracking down a line of code, buried in a sea of similar-looking lines, or tucked perfectly away in an include, or stored in some component of the framework.  Even if it’s your own code, written only a few weeks or a few months before?

How much time do you spend looking at another developer’s code, making sense of where some set of client-requested changes need to be made? We’ve all seen it. Code soup is not just a product of bad developers. It’s a product of language written with a machine (or a textbook) in mind, written in a hurry, or written in the fuzzy flurry of the dog days of any get-it-done-tomorrow web project.

So I submit that code should be written not just for the machine, but also (perhaps primarily) for the developers who follow you – including you.

The Obvious, Title-inspiring Example

Let me make this case by inviting you to look under the hood of your car, at the physical equivalent of the code we write. The interior, the dashboard, and shiny paint job are the graphic design and user interface of your car. Polished and perfected for people to look at and make easy use of. But under the hood? That’s code. It’s machine parts doing the work of machine parts. And it’s designed functionally, precisely, and (typically) still with human beings in mind.

The radiator cap, oil cap, battery, and other high-maintenance parts are accessible and labeled. The battery is placed where it can be jump-started. The oil pan is placed where it can be drained. The gas tank isn’t accessible – it doesn’t need to be – but the gas cap is exactly where a human being will need it.

The elements under the hood of your car don’t need to be positioned that way to make the car operate. In fact, it’s easy to imagine that a perfectly designed engine might not have an accessible battery, oil cap, filters, spark plugs, or any labels at all. Elements may be tucked under other elements to limit the amount of tubes and wires and such between them.

But they’re not. They’re designed with the full understanding that the needs of the technology must compromise with the need of the few human beings who will need to operate under the hood.

And those of us who write code should follow the same example.

Suggestions

• Use comments religiously. They are easy little signposts to leave for yourself and others. Consider using comments to:
• Mark the beginning and the end tags of a <div> element. Frequently, a page ends in </div> soup. Knowing which ends which can save a lot of time.
• Explain browser hacks, specific to the browser and the intended effect
• Identify the color of hex values .for_example { color:#000; /* BLACK */ }
• Label include statements and add a super-brief overview of their contents
• Denote the position of related code in other files of a framework
• Leave notes for future developers where easy maintenance tips may help

Peppering your code with simple well-written, well-placed comments can save countless hours of maintenance time, especially when future developers come into the project fresh.  And remember, saving time means saving money.

Strong commenting can enable other members of your team (especially those with a lower level of programming knowledge as the code author) to participate in the project, where otherwise a bottleneck might occur as every new issue has to go back to the code author for a solution - slowing down the project and limiting the inclusion of the rest of the technical team.

And commenting can also serve as a self-check on why you’re doing things in the first place. Leaving a note about a browser hack might occasionally shine a light on the fact that you’re using a hack. Maybe there’s a better way. If something is worth a comment, maybe it’s worth a considering a simpler alternative that does not need explanation.

• Use multiple blanks lines to visually separate different sections of code. Just like a graphical design uses white space to keep elements from running together, you can use white space in your code to make it easy to see where one section ends and another begins.
  
  Purists may tell you that blank lines and copious comments increase page length and perhaps file size, and cause the server and/or the browser to do extra work when processing the code. That’s true. But it’s hogwash. Modern sites aren’t run on Commodore 64s, and we’re not talking about writing War and Peace in between every if/then statement. We’re talking about a few extra kilobytes (at best) which will virtually always pass unnoticed in any real-world use.
• Use includes (or the equivalent) wherever possible, provided the include files are accessible and thoroughly logical. A good use of an include is any section of code that is identical on multiple pages of your site. Using includes makes maintenance easier and shortens the length of your code on the pages where they are used.
• Indent the lines of those sections of your code where a little horizontal separation can help identify it as a self-contained element.  You may choose to do this for an entire section of code, or for the second and subsequent lines of a section, to show that it belongs to the first, un-indented line.  However, be careful with this technique. Too much indenting can lead to a chaotic looking page of code, especially if excessive text wrap needlessly brings the ends of lines around to the left side of your window.
• Make decisions and stay consistent about the use of capitals, dashes, underscores, initial caps, etc. in your statements.  Consider the following suggestions:
• Use all caps for comments (they shout, so use them where you want to communicate above the level of the code itself /* PAY ATTENTION TO THIS */), and limit the use of caps elsewhere.
• Use underscores instead of dashes in file names, ids, and classes. Dashes are smaller and higher, so they don’t visually separate from the alphanumeric characters around them the way that the wider, lower underscore does.
  
  Avoid initial caps in filenames especially, but also throughout your code. In filenames, you can run into case-sensitivity issues that are simple to solve, but you have other bugs to track down, don’t you? Elsewhere in your code, initial caps add a small extra dimension of complexity, and will also tend to visually blend your markup into the content it surrounds.  Separating the markup from the content in any way possible, even on such slight visual grounds, is always a good thing.
• Don’t use dots in any naming convention. No good things can come of it. It’ll confuse file extensions, class definitions, and a whole host of other fodder for all night debuggery. Besides which, they’re small and hard to see.

Leadership

It’s important when multiple developers are working on a project, that some leadership is enforced, to keep the team employing the same tactics with the same consistency across the board. If one team member is doing what she think makes sense, and another team member is doing what he thinks makes sense, it’s highly likely that the two will end up with a cacophony of stylistic choices that only leave the same level of confusion they were both working against.

The Logical Progression of UI

Bringing the principles of user interface to the code base just makes sense. It’s another step in the web’s lifelong battle to fight confusion and complexity, and to promote inclusion and standards.

It’s not enough to write great code – no more than it would be enough to build a great engine for a great car. People have to work under the hood. Not just you. Maybe not even just your team. Maybe your clients, or their future employees or vendors. Maybe others.

In the language of the web, these people are users. They are humans. Our code should be written and presented with them as the priority, just as the front-end was written and presented. 

[Link to Interface Design Under the Hood]

The Right Tool for the Blogging Job

Blogs are taking over the web, and with good reason. But these blogging tools are too blogging complicated and too blogging expensive for small sites and individuals to put a professional blog online. Right? Wrong! There are world-class options available to fit any circumstance, even a budget of zero blogging dollars.

A blog is a powerful tool that organizations and individuals can use to connect with their web users, attract new ones, and keep them all coming back regularly.  In many cases, blogs replace the classic news/announcement/update/event pages of yesterday’s sites, and become their author’s primary means of communication with their users. To be effective, a blog must be kept current (since a stale web site creates the impression of a stale organization), and it must be relevant. You have to post things your users want to read.

If you can do that, then a blog would likely serve you very well. It’s just a matter of choosing which tool is the right one for your particular job.

There are two basic flavors of blogs. We’ll call them hosted and installed.

Installed Blogs / Content Management Systems

An installed blog consists of a set of scripts installed on your web server, which are usually connected to a database, also on your server. In most cases, their included tool set is powerful and broad enough that they’re considered full content management systems.  Packages such as Expression Engine, Joomla, WordPress, Moveable Type, and others allow your site to be built with your own design and front-end code, and they let you fully customize their powers, look, and behavior. They usually come with an assortment of features and plug-in modules, and their configuration is limited only by your imagination. However, the downside is that they require significant expertise and time to set up properly, place specific technology requirements on your web server, and they may not as easy to use as you imagine.

All of this can become a significant obstacle to those working with minimal resources, and make this solution the wrong one for many small web sites.

Hosted Blogs

Hosted blogs are complete blogging systems that are offered as a service on a third party web site.  Blogger, TypePad, and WordPress.com (a hosted version of WordPress itself) are good examples of these types of services. Your blog and your administration tools are hosted and presented by your provider on their site, running on their server. As a result, these blogs are very easy to create. You go to the site, sign up, write your blog, and bingo, you’re online. But, frequently the drawback is that you’re online at their web address (though it usually contains some customization based on the name of your blog).

The other commonly considered drawback of hosted blogs is that you end up dealing with a limited set of blogging / content management tools, which cannot be easily customized (if at all). But this varies from service to service, and it’s a pretty subjective point. If your blogging needs are minimal, then you’re not likely to notice many of the limitations. You may never feel limited at all.

When looking at your options, it becomes a question of cost vs. benefit. If you have the resources, and could benefit from the power of a content management system, then the installed option may indeed be for you. But I work with a number of organizations and individuals who have small sites and limited resources and they simply don’t need the power of an installed system. Partly for that reason, they can’t justify the resources such systems require. For them, a hosted blog can be a perfect solution.

What’s Available?

Let’s take a very quick look at three major hosted blogs, from the perspective of establishing a blog for a small, professional site.

Blogger

http://www.blogger.com
Blogger is probably the best known of the hosted blog services, largely due to its being one of the early players in this field and the fact that it is now owned by Google. Everything is free at Blogger. There are no premium fees or add-ons for you to buy. You can fully customize the look of your blog, and even publish it to your own web site using their FTP controls - which is a potentially big plus, and unique among the blogs I’m comparing here. The only area, in my opinion, where Blogger falls short is in information management - it’s somewhat limited if your blog is going to have a number of authors and you want it sortable by categories and other criteria, or if you want to show a partial entry and “click for more” in your presentation.

TypePad

http://www.typepad.com
TypePad is a very solid service, with a depth of features, from a very well respected design team. TypePad’s cheapest service level is $4.95 per month, but for the purposes of this comparison, we need to look at their Pro plan, which is $14.95 per month. For that you get the ability to fully customize the look of your blog. You also get the ability to have multiple authors, categories, tags, and other information management tools. TypePad deserves to be in the conversation because it does remain somewhat popular and it is very well regarded, but TypePad just doesn’t offer anything unique to justify the cost.

WordPress.com

http://www.wordpress.com
WordPress offers strong solutions for a hosted blog and an installed blogs / content management system. But here, I’m looking only at their hosted service, WordPress.com. The basic version of WordPress.com is free, but if you want premium features (and you probably do), then you’ll pay some small fees. Custom CSS is $15 per year, and you need that in order to fully customize your look and feel.  WordPress.com will also occasionally show advertisements on your blog, unless you pay them $30. per year not to - an annoying little pill to swallow. And there are other minimal additional fees for other upgrades. WordPress.com is an extremely professional, well regarded, and well supported system. It excels in information management, and battles only TypePad in its content management features. If you’re posting content from multiple authors, or in multiple categories, or you’re concerned about post length or searching/taging/etc., then WordPress.com is hard to beat, even for a few dollars a year.

One size does not fit all, so what works for one organization or individual may not work for you. But in almost every blogging case, there are options available to blogging match your blogging needs and resources.

[Link to The Right Tool for the Blogging Job]

The Attention Span Principle

Every user comes to a site with a set attention span. Short or long, it is what it is. You have the extent of that span to hook your user. With each hook, they’ll grant you another span of attention. So making use of the spans you have is critical. Bring flowers.

In the first span of attention, you’re a blank slate stacked up against your user’s unknown set of expectations. Your first and only mission is to tell the user three things.

• Who you are
• What you do
• What makes you different

You must do this on your home page, the first page they come to, and you have to make it your priority message. You can do it with any combination of words and images and razzle-dazzle. Maybe you do it overtly. Maybe it’s a subtle combination of elements. Missing any of those three targets will very likely result in the user leaving your web site. They have come for a reason, they want to know if you have what they need. If their attention span runs out before they know, they become bored or frustrated, and that’s goodbye.

Call it the first date. Hello. How are you. You look nice. Hands to yourself.

If you can hook them in their first span of attention, you’ll have earned a click, and another, longer span of attention. A second date.

On that second date, you have just one job to do: get them from where they are (your home page) to a page on your site that has the more specific content they seek. You’ve met or exceeded their initial expectation. They are prepared to like you. Now it’s time to answer some questions and make some offers.

So if I sell sparkly paint, and a user comes to my site looking to buy some, they need to know right away that I’m Sparkly Paint Company, I sell sparkly paint, and that my paint is sparklier than all other sparkly paints.

My users will smile, gratified that they have come to the right place, and hooked by my clear and compelling information.

The web user will then feel motivated to delve into the section of my site where I detail my selection of sparkly paints, or whatever sparkly paint offer I may have at the time. The second date. The click. It’s here that your UI design is critical. If they can’t find a compelling link, or if the desired page doesn’t exist, or if it’s badly presented, the user will become bored or frustrated, unable to answer their questions, and unsure if answers exist. There are other fish in the sea, other sites to look at, so if my beloved user cannot find their answers easily, it’s very likely that I won’t get a third date.

Ah, the third date.

Once someone gives you a third span of attention, when they’ve held you up to expectations twice and you’ve met or exceeded them, they’re a little bit hooked. They’ll give you more attention, and more leeway, and you’ll be able to present them with more, deeper, content. These are users who will sign up for email newsletters, buy products, and contact your sales team. These are the people who will read technical specs, fill out forms, and bookmark you for a return visit. Not always, not automatically, and not immediately, but they are now in reach. They’re in reach because you’ve earned their attention over a wisely spent period of just a couple of minutes.

No doubt it’s temping to go for the sale right away, but resist that temptation. Be wise, and be patient with your UX, and be content to get them hooked one span of attention at a time. You don’t open the door on a first date and behave like it’s your third unless you want that first date to end quickly and badly.

Your users are not open to your offers right away.  When they make the decision that your site is a worthwhile place for their attention, then they’ll be much more receptive to whatever you’re asking them to do. Maybe they’ll fill out your form. But the truth is that even that isn’t your overall goal. What you really want from a web user is a long term relationship. You want them to keep coming back, to tell their friends, and identify with your brand.

So treat your users like people. Take it slow. Build your new relationship one span of attention at a time.

[Link to The Attention Span Principle]

Simple is not a bad word.

Simple simply means that the idea is expressed in its purest form. Strip away the bells and whistles. Strip away the egos involved. Strip away the distractions, the options that don’t help to lead to successful outcomes. On the web, I think simple is a good thing. Simple is the goal.

When it comes to web work, simple is my mantra. You can probably see it in my work, for good or for ill. You’ll certainly see it in my writing, or if you hear me talking about anything web related. Sometimes I wrestle with how simple is too simple, especially in my design work. But I keep coming back to the idea that a web design is intended to relay a message and generate action. And that all too often the pursuit of something engaging and new and different and special ends up only in delivering pretty distractions and gee whiz confusion.

When I was your age, we had to design user interfaces in ten feet of snow…

I started my career at AOL in 1994. Everything we designed we designed with novices in mind. And I don’t mean today’s novice. I mean “what does click mean” novices. The people AOL was trying to attract knew nothing about navigating online spaces. We had to practically move them through online “areas” (as we called them) with velvet ropes and ushers showing the way. Design was limited to 16 colors on Windows and a glorious 256 color palette on Mac. But pushing those graphics down a 56k modem line to our users was not only cumbersome, it was their number one complaint for many years.

So how do you design when most of your designers’ skills are either cut off or they are part of the problem? Today’s web doesn’t have the same problems as the AOL of 1994, but it can learn from the same lessons. Users love beauty, and technology can solve problems, neither is in doubt. But both must be tailored to the user experience, and dedicated to communicating the messages that the site intends to communicate, with the goal of generating the right action from the user.

So, what? Design dull sites and use old technology?

The challenge of connecting with a user doesn’t limit what you can do with design and technology. It only raises the bar. It means you can’t just design what looks good, and you can’t just rely on the technology as documented. It means you have to take both facets of your web work and view them through the eyes of a human being — without expertise in either area — for whom it is critically important that they receive your message and proceed toward the successful completion of some goal.

Simple web sites can have strong design and elegant uses of technology that would make Skynet weep. Simple sites aren’t simple because they do less or look worse. They’re simple because they’re understood, inside and out, by the people that view them, own them, work on them, and use them on a regular basis. They’re not bloated or distracted. They’re built in commented, structured, standardized code. They’re aware of the limitations of monitors and eyes and attention spans. Simple sites know that they can be expanded tomorrow, if need be, and they’re built to accommodate that. They’re not as simple as they were in 1994 because they don’t need to be. Users change and technology changes and the definition of simplicity (as it relates to user experience) changes with it.

Simplicity may be a slippery and unglamorous goal for web professionals, but our job is to deliver web sites that work, and well-realized simplicity never fails.

(Oh, and not that it’s terribly important, but frequently the simple solution will also be cheaper, faster to implement, and easier to maintain over time. So it’s got that going for it. Which is nice.)

[Link to Simple is not a bad word.]

The Benefits of a Web Site #3302412

Getting it right is a big deal. But keeping it right is even bigger.

Things change. And even if things don’t change, you may change the way you want to talk about them. You can put a lot of information in your ads, postcards, flyers, annual reports, handouts, tradeshow materials, you name it. But once it’s in ink, it’s there for good.

Your web site never goes to press. It’s never locked. You can grow it, mold it, shape it, refine it, and keep it up to date at will. The only part of it that really ought to stay the same is your URL. And THAT’S what you can print on your ads, postcards, flyers, annual reports, and so on. Hand out materials that drive traffic to your web site - and use your web site to convey the latest messaging, updated the moment you have something better to say.

[Link to The Benefits of a Web Site #3302412]

dopplerVUE

dopplerVUE is an extremely powerful, extremely easy-to-use network management tool from Kratos Defense and Security Solutions. The web site needed to convey its power and ease-of-use, while serving many other diverse and complicated needs.

Following in the footsteps of its sister site NeuralStar, which I also designed and built, the dopplerVUE web site was a major step forward. With more complicated messaging to convey, and a much broader array of product offerings, the challenge was (and remains) keeping the site simple, clean, and intuitive.  From software downloads, to tutorials, to whitepapers, to sophisticated user tracking. The dopplerVUE web site does it all.

dopplerVUE is simply the most powerful, flexible, easy-to-use Network Management tool available.

Visit dopplerVUE at: dopplervue.com

[Link to dopplerVUE]