Website Navigation and Website Navigation Theory
There are actually people searching for the expression “site navigation theory”. Somehow, despite my not having optimized for site navigation theory, they have found the SEO Theory blog. The fact that I have written about Web site navigation a few times explains those search referrals but I’m curious about how many SEO-related theories people search for. But I’ll explore that mystery another day. The idea of site navigation theory caught my attention, however, because I was recently thinking about selector screens. You almost have to be over 30 years old to know what I am thinking about because the graphical user interface revolution of the early 1990s rendered selector screens obsolete, or at least made them archaic.
A selector screen was a pretty simple application. You found them on any interactive computer system from mainframes down to microcomputers. Some selector screens were pretty fancy, employing reverse-video character blocks to “highlight” sections of the screen.
The selector screen (also called a “menu screen”, “selector program”, “menu program”, and “options screen”, among many other names) usually included a date and time stamp at the top of the screen, the name of an application, and possibly a section or module name. Below that was a list of functions you could perform. Usually somewhere near the bottom of the screen was helpful information such as the name of the company that designed the software.
For 20-30 years hundreds, perhaps thousands of programmers found ways to make those selector screens look “cool”, appealing, and informative. I remember using a shared computer system in the early 1980s to work on some programs for mini-computer systems. A guy sitting next to me started up his selector screen and I started up mine. His looked okay but it was plain and simple compared to the one I was using (which I did not design — I was a junior programmer at a software firm).
“That looks neat!” the other programmer said. “That’s really cool.” He looked his screen and I knew what he was thinking. He was trying to figure out if he could get away with redesigning his screen to use the same format my screen was using. In fact, I ended up working for that guy a few years later and he ended up reselling the software my former employer designed, so he was able to use funky selector screens endlessly. (In fact, he eventually went to work for that company I had once worked for.)
That was a simpler time, I suppose, when the mysteries of selector screens could astound and amaze professional programmers. I remember when the owner of the software firm with the cool selector screens mentioned an upgrade during a staff meeting. They were testing little alert notices and how to get the operators to pay attention to them. He and another programmer had written a module to take a message and drag it around the screen, flashing and beeping. Of course, that was never installed in the commercial version, but we had fun playing with it until programmers started getting annoyed.
Back in those days programmers who worked on the same system knew who was in the other room by the ways system resources were suddenly drained. One guy would edit these huge 1,000-character long commands and just cause the whole system to freeze up for half a second. His command lines were building selector screens (yes, in one line of code, he not only painted the screen but implemented all the control points).
The World Wide Web came online in 1993, which was about the time Microsoft was persuading 98% of the business community to give up its old character-based applications for graphical applications. Although there were graphical interfaces for the Web (most especially the Mosaic Web browser, which ran on Windows 3.0 and later versions), Web site design was so primitive that most sites operated on variations of … selector screens.
In fact, the most famous selector screen on the World Wide Web proved to be Yahoo!’s home page.
Yahoo! as it appeared in October 1996
Web page design has always been limited by three factors: HTML functionality, browser capabilities, and user connectivity. In the early to mid-1990s most people were using slow modems. Even the fast 56K modems only connected at less than 56K speeds, and downloading Web pages that used lots of images was excruciatingly slow. We learned to avoid such Web sites in those days, preferring instead the simpler pages that were graphics lite.
Of course, online business owners who thought they needed to create “beautiful” sites couldn’t understand why no one wanted to use them. After all, they had paid thousands of dollars for those designs — people should have wanted to use them. It was a pretty grim age for aesthetic design, especially when people could open up Microsoft Windows applications and see tons of pretty interfaces.
Not that those pretty interfaces were necessarily well-designed. Even in a graphical environment you can put too many objects on a page. It was unfortunate for many people that most programmers who developed early graphical applications didn’t understand usability. In the character-based world you also had programmers who didn’t understand usability, but I was fortunate enough to work for software firms that demanded the applications be usable. I learned to place emphasis on user-oriented testing whenever it was available.
The human mind is an amazing thing but it has limits. I learned that the average data entry operator could only manage about 10-12 on-screen options at a time. Traditional screen design techniques called for placing IMPORTANT options outside the main body of options (we called them data entry fields). But if the screen was too cluttered people were unable to find the “GO BACK” or “ESCAPE” options, as well as the helpful tips we programmers embedded at the top or bottom of the screen.
These limitations persisted into the graphical user interface environment. Being able to use a mouse to jump to any part of a screen didn’t really speed things up. In fact, character-based applications had employed a variety of techniques through the years to allow users to navigate across complex screens without a mouse. We divided the screen into sections, drew lines around the sections, employed reverse video, upper and lower-case characters, field numbers, selection boxes, TAB keys, SPACE BAR logic to cycle through preset values, preset function keys and more. High-volume data entry applications require a LOT of user-friendly features.
Graphical user interfaces are inherently user-UNfriendly because they don’t impose any practical limits on the programmers and application designers. If you don’t have enough screen space to cram everything into a form, you just add scroll bars and force the user to move sideways, up, or down. But when people cannot see the entire form, they lose track of where they are in the form. Some computer games solve this problem by superimposing a micromap in the corner of the screen that shows a moving frame to represent what the larger screen displays.
On the Web, however, you don’t have the luxury of assuming the user has all the resources necessary to feed your ego. People abandon slow-rendering and hard-to-navigate pages fairly quickly. Most users will tolerate 10-12 actions per screen before getting frustrated. Most professional data entry operators can be trained to mindlessly fill in 50-60 data items if necessary but they pause in the middle of the task to mentally reset their coordinates. It’s a fascinating process to watch. They type, type, type, type and then pause, then type, type, type, type, and then pause, ….
On the Web people will often go to as many as 15-20 actions before abandoning a page. But “actions” consist of more than just clicking in check boxes, typing data into fields, etc. Every time they have to scroll counts as an action. The more actions a user takes to just keep track of where they are on the page, the more annoyed they become.
We had to understand these limits in designing character-based selector screens. They were not only used to navigate through complex application modules but also for basic data entry functions. We had to break up our screen layouts in such a way as to give users a mental pause at just the right spot, so they didn’t drop important information from their short-term memory when adjusting to a new section of the screen.
A traditional menu screen would be limited to 10-12 items. If we had to add more items we went to a 2-column format. If we had to go to a 3rd column we usually broke up the screen into multiple screens (but if users had to jump back and forth to get information we had to keep the screens together).
The most complex selector screen I ever designed on a character-based system employed 4 columns of data entry fields AND supplemental navigatino and command options in the page footer. I also had to include information at the top of the screen. The program was part of an inventory application for a national retailer with 7,000 stores. Each store dialed into a central computer system over a 2400-BAUD modem line. Repainting the page or forcing the user to hop through each field was not an option. I took the screen through three designs before it was approved.
On the Web, we learned to make some compromises. Image maps helped Web designers add some aesthetically pleasing options to their pages without requiring people to download 25 images per page. Unfortunately, many users struggled with image maps and search engines cannot read them. Search engine optimizers slaughtered image maps by the thousands in the late 1990s and early 2000s.
We also had endlessly scrolling pages for a few years. For some reason people didn’t quite get the “hyperlinking” part of Hyperlinking Text Markup Language. HTML does make it easy to design graphical applications, but it almost forces those applications to act like traditional character-based applications. But until Netscape championed the use of HTML tables we didn’t even have the full use of a 480Ч640 screen. Character-based applications could map out 1980 characters. Web pages just had to scroll.
Improved Web navigation concepts have evolved, of course. We now use menu bars and other navigation tools (although the menu bar is the most common method). In the early days of the Web we used ordered lists for navigation. Now with CSS and tables we use … ordered lists for navigation. Okay, we basically just dress up the ordered lists and make them look less like the lists they are. It’s also possible to create menu bars without using ordered lists or CSS.
Still, the human mind has not evolved much beyond where it was in 1990 at the birth of the graphical user interface revolution. People can still only cope with 10-12 options at a time. But we have Web surveys, configuration files, and registration forms that toss as many as 100-200 options at users before forcing pagination. Many sites that now depend on embedded advertising also sacrifice their most valuable content (information) for more (advertising) links. Web pages today are often cluttered beyond repair. Even I have learned how to sqeeze alternate navigation systems onto Web pages to help people shift gears and move around my sites.
Web site navigation does indeed need to help people shift gears. While most businesses naively prefer that people enter their sites through designated “entry” pages, reality tells us that any search-indexed page acts like an entry page. Hence, all potential entry pages need to include entry page navigation — a navigation system that is high-level enough to give people a sense of what the site is about. But on large, complex sites all pages need to include topic-specific navigation, separate and distinct from the entry page navigation.
The failure to segment or sectionalize navigation is one of the biggest problems on today’s business Web sites. They use evolving menu bar systems that don’t look the same on every page. I do this myself in some site designs, but I’ve been developing a top-down paradigm that provides visitors with uniformity of options and concept. Uniformity of concept means that the navigation system will always be the same. Uniformity of options means that the same options will always appear in the same place.
However, while maintaining uniformity in options and concept you need to introduce variability in options to help people find what they are looking. A generic, one-menu-bar-fits-all design is inefficient and user-unfriendly. You end up intermingling options that are logically unrelated. Cross-promotional links, for example, can often be found in menu bars and they have no reason to be in menu bars. If your goal is to help other sites be crawled by search engines, embedding the links in the menu bar doesn’t provide any advantage. Search engines find and crawl all the links on the page. I embed cross-promotional links outside of my primary menu bars and don’t have any problems.
If your goal is to make users feel like they have not left your site by using a cross-site navigation system, this actually causes consume confusion and sacrifices brand value (the consumers will associate all the conjoined sites with one brand, so the strategy of developing multiple brands is compromised).
There are many lessons we had to learn while designing early computer interfaces in the 1960s through 1980s. Unfortunately, the clock was reset by graphical interfaces and the World Wide Web in the 1990s. We’ve now used the Web for 15 years and many Web designers today still have not learned that hard-won lessons that should have become ingrained in our applications design experience. The old adage, “Those who do not learn from history are doomed to repeat it”, rings so true with today’s Web site navigation systems. The process of rediscovery seems to have been a little faster this time around, but people still struggle with navigation. Most Web sites (including virtually all blogs) use navigation that ranges from insanely stupid to completely awful.
We’re trying to accomplish too many things with our Web site navigation. We’re trying to minimize the amount of screen space we use for navigation (which is not always desirable), help the search engines find everything we build (there are more efficient ways to do this), and help our co-branded sites exchange traffic (there are better ways to do this). Web site navigation theory has to focus on what works best for the user and emphasize efficiency in the user experience. Search engines are users, too, but we don’t have to sacrifice human user experience in order to enhance search user experience.
Web sites need to break out their navigation goals into separate modules. You can embed navigational links anywhere on a page. Take advantage of that strength to provide useful navigation by concept with enough intervening space or content to help users change gears mid-page in a smooth transition. The more you force people to stop and think about what is happening, the less likely they are to enjoy the experience of browsing your content.
www.seo-theory.com
published @ September 19, 2008