Deliberations About Design

Planning architecture, content, layout, and iteration

PROVIDING A STABLE layout that meets the ever-growing, feature-rich demands of users, their devices, and browsers (while keeping compatibility in mind) is something many designers worry about. Because technologies evolve and sites increasingly need to provide user-centered experiences, visitors come to expect more from the layouts you offer. In this chapter, you’ll see a few variables that can affect how your work ages over time. Although such variables won’t make or break a site in a literal sense, the need to evolve remains.

The Art of Aging Gracefully

Designers are often surprised when I include a site’s design in the future-proofing equation. Though the average design can last a lifetime and remain fairly usable, you shouldn’t just stop improving your site because it currently looks okay and functions well enough. In the average site’s lifespan, designs tend to and should be frequently improved, iterated upon, or refreshed over time. A number of justifiable reasons for this exist, including giving users a reason to keep returning, and to cope with any new demands of the tools we use to browse the Web.

Of course, modern standards and conventions for Web layouts are so much more advanced than they were in the 1990s. Those earlier layouts were often poorly coded and designed and you would be forgiven for cringing at how primitive, static, and unusable many of them were. Today’s designers are in a better position to offer longer-term solutions than those from the “era of experimentation,” partly because of the availability of better tools and agile frameworks, and also because of the focus designers now place upon usability.

Tip

Although it’s not a necessity, following design trends and conventions can help reduce any barriers to entry for users. If a visitor recognizes objects on a page, they’ll find it easier to locate important content. That said, don’t be afraid to put a unique spin on any navigation system or tool you provide. Following trends doesn’t mean don’t innovate!

As the Web continues to evolve, increasing numbers of devices, hardware, software, and users are demanding access to your sites and services. In addition, the code you use and the standards you follow will be updated continually with useful and capable technologies. If you were to design a site only once, with no further changes, you’ll still have to spend your days patching your site to ensure it continues to survive over time. If you’re building a site to represent you, commit to a maintenance plan to achieve usability in the long term.

Whether it’s your site’s information architecture (the way you organize pages), content, or layout, you’ll always need to make improvements. Perhaps you can remove features that have become redundant. Perhaps you can update your design to match the conventions users frequently expect to find while browsing the Web. Perhaps your audience has changed, as has their expectations of your service. Such considerations ultimately allow you to meet the long-term needs of an audience, which if you own or maintain sites, becomes critical.

Reviewing a design’s previous versions lets you pinpoint areas that need improvement and address code that has become deprecated or outdated or that no longer matches an intended audience’s needs. If you remain open to the possibility of redesigning or refining a layout, you may be motivated to do some research and reassess your audience, their requirements, and what you can do to keep them interested in your goods and services. Communication is critical in the future-proofing process, so don’t be afraid to ask visitors for feedback.

Iteration and improvements

Consider a visitor who has been loyal to your brand for a number of years. She has become accustomed to your site’s interface and features, and upon hearing that you’re giving the site an overhaul, she’s both excited and nervous about whether changes in content will match her individual tastes. As the updated site is launched, the user enters the site and sees plenty of objects in a familiar place (such as the logo and navigation system), but other parts of the site are dramatically changed. She pokes around the menus to see where her favorite tool resides, only to find that a feature she’d used regularly has been removed, with no alternative offered. In this instance, you fail to research your audience correctly (or at all) and other visitors (like this one) begin to post complaints in the feedback form, asking for the features they know and love to return. Unfortunately, this isn’t exactly an isolated incident. Sites all over the Web redesign without gaining appropriate feedback. If one of your competitors offers functionality that you fail to provide, your users may move to the competitor’s site. When redesigning your site, remember the loyalty you have earned from your users. Understanding when to alter or invoke a site’s maintenance plan is as critical in design as the work itself. If users are forced to keep adapting to demanding changes in an environment, they may become impatient and look for an alternative that isn’t changing its layout so frequently. Designers are often the guiltiest party in this regard because our aim is to give users the best experience possible. But we often overlook the benefits and utility of what’s already working and produce throwaway reproductions instead. Users will thrive on what they can recognize.

Architecture

A site’s architecture is comprised of the pages that interlink. Each site will contain links that connect internal pages to each other, hopefully in an organized and constructive manner. If optimized, visitors should be able to navigate with care and reach their final destination within just a few clicks. This architecture variable is usually based on offering consistency to aid the usefulness of content and uses the organization conventions often found within site maps, navigation menus, drop downs, or other link-oriented systems (Figure 17-1).

Figure 17-1: The architecture of a site depends on your ability to link pages together logically.

Here is this design feature’s family tree and some issues it can encounter:

Relatives: Considerations:

> Navigation menus

> Form redirection

> Site maps and indexes

> In-page shortcuts > Self-contained layouts

> Human-readable site maps

> Navigation formatting

Practical solutions

One of the most popular design conventions today is the one-page layout. Often used in portfolios and online brochures, this layout provides a range of unique options for space utilization and for reducing the need for page refreshes. When examining the architecture of these sites, one thing becomes strikingly clear: As innovative as their interfaces may be, one-page layouts can still experience issues in ensuring that users find the content they’re looking for, such as the use of navigation menus that fail to work if JS is disabled.

Navigation on any kind of site depends on clarity and accuracy. In addition to providing a link that is accurately referenced and labeled, be sure that users can actually tell what the links are and where they are. In an effort to improve your site’s aesthetics, you may change font colors, remove underlines, change cursors, and more. But, for links to be compatible on a range of platforms, they must be identifiable (so be careful which styles you do alter) and clickable, thus they must function as expected. Otherwise, users will struggle to see content.

If there’s ever a competition to find the most important and frequently used feature of any site (except content), the navigation menu will likely be the winner. However, because you have so many options regarding how to present your pages, compatibility issues can occur easily. You can do a number of things to avoid these issues, such as reducing the number of objects in each menu list, or categorizing menu items based on its relevancy. However, knowing which navigation menu type is appropriate or safe to use is extremely helpful too!

Note

Simple things can hurt a user in terms of menu compatibility. For example, powering menus with Flash is a big no-no if you want to ensure ubiquitous browsing; the same goes for using unlabeled icon menus (which can be confusing if images are disabled).

Now, I’d like to deal with disclosing navigation systems such as drop-down and breakout menus. The main concern with these is with touch devices, which may have significant problems utilizing hover events, so you need to substitute any mouseover events with an appropriate fallback that opens when users click a link, and that fades with a delay if they click outside of the menu. In cases where a drop-down menu is static, ensure that each link’s click region is large enough accommodate touching and clicking on small screen devices.

When you future-proof your site, you also must consider the method you use to reference the pages of your site collectively. Most designers will already be aware of the importance of a file called a site map (an index of your pages that search engines can use to catch all of the important pages). One thing that very few people tend to do, however, is actually try to take the functionality of a site map and make it into something that humans can read, identify page relationships, and navigate (allowing people to find what they want faster).

To overcome this issue, the best practice is to have both an XML site map (to keep robots happy) and an HTML site map (to keep humans happy). While it could be argued that you really need only one or the other, having a specially customized human-readable version ensures that no document is left orphaned and users who cannot find what they’re looking for have a universal signpost. If users are browsing on a device with limited interaction potential, a human site map allows scrolling a list of pages without typing search terms.

Best practices

> Links should look and behave differently to content that isn’t actionable.

> If the links use a pseudo protocol such as mailto, inform users in the page.

> Offer XML site maps for search engines needing a speedy list of your links.

> Also provide an HTML alternative site map for humans needing direction.

> Make navigation menus degrade to match the device’s core capabilities.

Content

If there’s one feature your sites cannot do without, it’s content. Content comes in all shapes and sizes (from text to images, audio to video; see Figure 17-2), and it must be designed so that visitors can consume it all. Content, on its own, has few requirements if supported by an appropriate structure and style, and embedded content (such as images and media) will function if it’s implemented correctly. Consider the ways you can fetch and offer content, as it can suffer compatibility and readability issues based on the environment it’s used in.

Figure 17-2: Content comes in all shapes and sizes, with images and text being the most common.

Here is this design feature’s family tree and some issues it can encounter:

Relatives: Considerations:

> Textual content

> Embedded images

> Audio and video > Refreshing versus fetching

> Multipage breakdowns

> The format situation

Practical solutions

One major consideration in terms of content compatibility is the method you use to display it on-screen. Using tools like AJAX, you can omit the need to refresh a page and swap out content within your pages without thinking twice. However, as I’m sure you’re aware, JavaScript isn’t a sure thing, and with an unhealthy dependency on these technologies, you may find it challenging to ensure that even the fussiest of visitors can access content when the content is served dynamically rather than statically (as each page is downloaded).

If you choose to use AJAX as a method of swapping out content on demand, begin by providing users with a static, multipage, working site with no reliance upon scripting. If AJAX and scripting are available, simply override the link’s behavior and have everything fetched from those separate pages (or database), as they’re needed. This approach is the same as you use for form validation, and it’s a time-honored fallback that users will find reassuring as it gives JavaScript-free browsers and users a chance to navigate your site.

The amount of content you include within a web site’s pages is also a factor worthy of consideration. Many sites manage to control the level of content that users are exposed to in order to prevent information overload. Loading megabytes of text into a browser can result in all sorts of problems for devices that just aren’t equipped to handle features such as smooth scrolling, and it will certainly affect keyboard users who’ll need to press the Tab key incessantly, or those with slow connections (or restrictive and costly data allowances).

Reference

For a complete guide to the various levels of support Web browsers have for specific formats (such as images and videos) and plug-in capabilities, check out the following Wikipedia article: http://en.wikipedia.org/wiki/ Comparison_of_web_browsers.

The main way to solve this content navigation issue is to divide content into logical page sections (as occurs in WML decks) and show each block of content on a separate page or at a different point in time (many sites provide page numbers or other indicators, such as image galleries using lightboxes and thumbnails). Also, take into account that while some visitors will appreciate such a friendly approach, others with more capable devices and connections may want to avoid excessive clicking. Therefore, try to offer an “all in one page” option or a complete PDF copy for download in addition to the logical structuring.

Finally, consider different file formats and how well they’re supported on the Web. Being able to embed an image in your site is all well and good, but if your users’ browsers can’t read the format, or if it’s in an obscure format, which they neither have a program that can open it, nor any idea of what it does, they have no reason to download it! Although you can utilize some standardized formats, new ones are appearing regularly, and depending on the device a visitor uses, you may find the compatibility list for file formats rather restricted.

To maximize compatibility, only use formats supported by major browsers, such as JPEG, GIF, and PNG. Internet Explorer prior to 9.0 will have issues with alpha transparency in PNG files (9.0 itself isn’t perfect), some handheld devices cannot cope with animated GIF files, and WML-only devices will likely just support WBMP (a monochrome format) or PNG if you’re lucky. Avoid JPEG2000, APNG, TIFF, XBM, and BMP, though, because while they have limited support on individual browsers, all the others will ignore them.

Best practices

> Use JavaScript to override multipage, static layouts via AJAX functionality.

> Offer compiled and split copies of lengthy content to improve performance.

> Load individual files within image galleries only as thumbnails are clicked.

> Check that your images are in a Web-friendly, browser-supported format.

> If you have an exceptionally long document, consider using PDF instead.

Layout

Your design will underpin how a visitor sees and responds to your work. While layouts can vary greatly, many of them will share certain similarities (Figure 17-3). Picking the right number of columns, the right width and height for objects, and the right color scheme can affect a wide variety of variables. Help your users by lowering the learning curve and aim for as few barriers to entry as possible. Because each design you build should be unique, the level to which your work may degrade (as consumer use evolves) could differ greatly.

Figure 17-3: Each layout will follow and set conventions like the logo or navigation menu’s position.

Here is this design feature’s family tree and some issues it can encounter:

Relatives: Considerations:

> Conventions

> Trends

> Patterns > Cutting or bleeding edge

> Web application UIs

> Unconventional layouts

Practical solutions

Chances are that at some point in time, you’ve wanted to put convention aside and use all the latest technology and tools to create a site so unique and interesting it’ll blow your visitors minds. Unfortunately, one of the many things that hold you back is that compatibility with untested and untried techniques can be a real pain (to guarantee support). Although issues that cause sites to break in a browser can be worked around, getting these implementations to look or work as expected within various situations takes time, effort, and dedication.

To make your layouts work as effectively as possible, try several different versions of an implementation. In some situations, you might get away with just throwing something new into a layout, but providing substantial alterations to an interface or its functionality could annoy or confuse users that, in turn, could encourage them to seek out your competitors. If what you’re doing can improve an existing situation (or help elevate issues on your site), go for it. But if the upgrade you build doesn’t improve things, reconsider implementing it.

While traditional layouts are often associated with common conventions, visitors who visit on a specific platform will come to expect a different experience on others, based upon the environment they browse within. Each platform will have its own interface guidelines and recommendations built upon years of testing and usability tests, so it pays to examine these documents to see how you can give users a more natural browsing experience (rather than potentially making visitors feel like they’ve suddenly crash-landed on an alien planet).

Reference

A couple of the resources listed on the following web page no longer work, but the ones that do work are exceptionally useful (and very comprehensive). These UI guidelines can help Web apps feel like they run natively (like a compiled app) by following device conventions: http://www.mobilexweb.com/blog/ ui-guidelines-mobile-tablet-design.

Although Web apps don’t require you to cater your work to a specific platform (unlike compiled apps), users will appreciate the effort. Whether the app is designed to work on desktops, or a handheld platform like iOS or Android, you should help the device offer the experience and visual theme that will match their expectations and requirements. In the case of traditional websites (rather than apps), or any device you can’t or won’t support (by way of a customized layout), offer a stable, flexibly designed default theme instead.

Unconventional layouts exist all over the Web, and this fabric of weird and wonderful designs increases our enjoyment of an online experience. However, there will always be people who go over the top and end up inhibiting the usability of a design, just for the sake of doing something different (which could anger users). Compatibility in design is about more than ensuring a site works on a series of platforms and with a series of variables; you need to consider the effect that unrecognizable layout conventions may have on visitors.

If you’re using an unconventional layout (or a conventional one with some unconventional features), it’s very important to undertake usability testing. By learning how real visitors interact with sites on the devices they own, and gaining empathy for the many variables they have to deal with themselves, you can gain an understanding of just how your site could appear or work for them. While you can spend time ensuring your layout works in emulators or browsers, ultimately it’s your users who’ll experience (or suffer) the results.

Best practices

> Investigate different ways to design a feature before sticking with one.

> Provide a global theme for app interfaces that aren’t device oriented.

> Consider targeted designs if you want to offer a seamless experience.

> Good designs are invisible; try to make yours as efficient as possible.

> Conduct regular usability tests to avoid variable-based design pitfalls.

Iteration

Building a stable foundation is important for a site, but keeping up the good work is critical to its long-term success. As time goes by, sites naturally erode because of changes in users’ expectations and requirements. Over a longer period, as web technologies and standards improve, older methodologies will become redundant, older tools will lose

support, and web designers will have to catch up. Iteration (Figure 17-4) is the primary method used to ensure code withstands the test of time, but maintenance itself isn’t an issue-free pursuit.

Figure 17-4: Iteration is a long-term process of continual improvement to overcome new obstacles.

Here is this design feature’s family tree and some issues it can encounter:

Relatives: Considerations:

> Major upgrades

> Total reboots

> Minor updates > Legacy feature support

> Uncovered bugs or issues

> Reduction of usability

Practical solutions

Iteration gives designers the opportunity to seek out and remove any redundant or outdated functionality within sites you maintain (which is good for users and their bandwidth caps), but be careful about what you do choose to replace or remove. Although you may find that a particular navigation system is inferior to the updated rival you provide, some users may prefer to use what they know and love. An example of this is the BBC’s iPlayer service: It removed its A-Z listing and then reintroduced it after scores of complaints.

Making the decision to improve a site by removing features that are no longer useful (or used) makes sense, but doing so could also cause a few upsets along the way, which may lead to visitors complaining. For every 100 users who are happy that you removed some obsolete feature, there’ll often be a couple that want to stick with what they know and depend on it. If the old system has too few users to support it, remove it and make room for better tools, but if you don’t have a good reason, keep the old stuff running.

Bugs on your sites and services are just as much of a pest in the digital world as they are in the natural world. When compatibility breaks down and a site cannot work in a particular situation or environment, it’s your job to run around with a replacement part or some duct tape, patching things up and helping the site survive for as long as possible until a more permanent fix (or redesign) is provided. Regarding development: Nothing will ever be free of bugs because when complexity increases, unforeseen issues become more common.

Tip

Before trying to resolve issues in a site, check to see if other people have come up with some practical solutions for the problem. Of course, you shouldn’t steal their ideas, but you may find that others have come up with a methodology you haven’t considered.

Tools like responsive design can help you make your work more durable so that quirks are less likely to occur, but there’ll always be a few situations that can act as the proverbial “straw that broke the camel’s back.” To help resolve errors more effectively, do usability testing at all levels of the build process and consider releasing your site or app in beta form so that your entire user base can try out the new look and give feedback. In addition, give users a place to report bugs (be it an e-mail form, forum, or some bug-tracking software).

Imagine that you build a totally new layout with a unique way of showing content and few recognizable objects from within the old scheme remain (so what you’ve produced has no resemblance to what stood before it). The layout and redesign may look nice, but does it actually help your users or improve upon what existed beforehand? Total redesigns can be fun, but they force you to retest everything you’ve produced as if it were a different site, which probably means you’ll be checking against all of the book variables from scratch.

Redesigning isn’t always the best solution. If you iterate and use the existing structure that you know works for a wide range of people, the impact of minor changes over time

will be minimal (and the impact on HCI will be reduced), as will the shock to the user’s system. Starting from scratch demands that your visitors learn how to use the interface again, and if you keep redesigning every few months (or less), users could struggle to adapt more frequently. When you redesign a site, consider providing tutorials to aid the transition.

Best practices

> Ensure that your visitors are happy with the removal of legacy functionality.

> Only update a component if your visitors agree it improves a situation.

> Let visitors notify you of any bugs or problems they encounter on your site.

> Avoid complete redesigns if iterations will work (to reduce learning curves).

> Use recognizable conventions to help users become familiar with your site.