The Power of Nine
Factors in Deriving an Optimal Information Navigation System
9. Purpose
9.1 The purpose of Part 3 is to set out the functional requirements of a navigation system for people with disabilities, and to analyse a particular approach to meeting those requirements, in terms of the criteria set out below:
9.1.1 Conceptual Model: This relates to the ease with which the intended user can perceive and understand the purpose and function of a product or system and maintain that understanding as its state changes while in use.
9.1.2 Usability: This relates to the physical capability of the product or system to be actually operated with minimum difficulty whether by direct manipulation or by the use of some intermediary system or device.
9.1.3 Durability: This can be expressed in a number of ways depending upon the purpose of the product. While a durable garden tool must be made of tough materials, in software systems, such as the navigation system being sought, durability must be expressed in other terms. These are:
- Scalability, or the ability of the product to handle different volumes of material, and
- Adaptability, or the capacity to be easily 'interfaced' on a range of platforms from PCs to automated telephone information services.
9.2 A further factor, aesthetics, is rarely handled appropriately, particularly in software development. Either a product design team is driven from the perspective of aesthetics, in which case the functional requirements receive insufficient attention, or the 'pretty-it-up' team is brought in at the end, a process often referred to as "Putting lipstick on a bulldog".
9.3 In general, a good aesthetic will result from a well-conceived and executed mix of the above three factors as long as the design team is aesthetically aware. Products created by such approaches are frequently recognised as "design classics", such as the VW Beetle motorcar or the Fender Stratocaster guitar. Since any proposed solution to a navigation strategy for disabled people must satisfy the requirements for all three of the above criteria, aesthetics will not be specified deterministically but should rather be indicated as a subjective measure to be applied when evaluating any proposed design solutions.
10. Specifying a Navigation Model
10.1 Metaphors make poor conceptual models
10.1.1 In many software designs some form of metaphor is adopted as a conceptual model. When, for example, the graphical user interface (GUI) was first introduced in the early 1980s, the widely adopted metaphor was that of a desktop. Initially, this considerably improved ease of use over the previous command-line operating systems. However, it has now worn very thin and computers are, arguably, much more complicated and difficult to operate than they were in the 1970s because of the huge increase in applications and the inability of the desktop metaphor to scale, a durability issue.
10.1.2 A wide variety of new interface mechanisms have been introduced in the past two decades but their implementation has been mutually inconsistent. Metaphors generally make very poor conceptual models, since the product and the metaphor are, by definition, not the same thing (the computer is not a desk).
10.2 "The system is what it does", Stafford Beer
10.2.1 The fundamental notion behind a navigation system is that its primary purpose is for getting around information. Navigating! This should be the starting point for our model.
10.2.2 Many conceptual models for navigation are already in widespread use but they almost always contain in-built inconsistencies that make them difficult for disabled people and, indeed most able-bodied people, to operate effectively (a comprehensive summary of these is contained in Part 2.).
10.3 Why hierarchies don't work
10.3.1 Let us take the most popular model, the hierarchy. There is no metaphor for the hierarchy in the physical world of books and museum collections, it simply 'is what it does'. It organises physical things into physical locations according to a defined set of categories, "A place for everything and everything in its place'. However, since computer-based information is not a set of "physical objects in physical locations" the use of the hierarchy in presenting computer-based information is, indeed, metaphorical and therefore susceptible to difficulties.
10.3.2 There is no standardisation between implementations of hierarchies, whether in the real world or in the digital media world. Furthermore, there is, more often than not, no consistency within a single implementation with respect to the key structural features of a hierarchy, as follows:
- Number of branches per level: These are generally set arbitrarily to suit the classifier's point of view. In other words, the top level might have 9 branches, each of which might have a different number of sub-branches, and so on.
- Number of levels: Very often, each branch in a hierarchy will lead to a particular number of sub-levels, depending upon how much detail the classifier feels it appropriate to describe in each sub-category.
10.3.3 The inconsistency in the number of branches per level makes the design of an interface that has good usability extremely difficult, since the interface must be extremely flexible to accommodate such unknowns. In order to improve this usability, one could impose simple constraints, such as a requirement that imposes some known limitation, for instance:
Ri "Each node must have no more than 9 links"
10.3.4 This falls within the upper limit of a well-respected '7±2' design principle2, employed widely in the design of various products and especially industrial equipment which limits the number of choices that might be presented as:
The optimal number of choices that an individual can make clear distinctions between, in any given domain, lies between 5 and 9, depending upon the individual.
10.3.5 Inconsistency in the number of levels in a hierarchy makes it extremely difficult for users to anticipate how deeply they might have to penetrate into the classification system before they find something of value; furthermore, this makes it difficult for the interface designer to create a sense of where one is at any time. Once again, the usability of the system might be improved by imposing some arbitrary requirement, for instance:
Rii "The maximum number of levels will be 9".
10.3.6 By imposing these two design constraints, we have created a problem in terms of scalability, fixing a maximum number of nodes in the bottom row of the structure (where the actual information is, as distinct from category labels above) at 88+1 or 16,777,217. [This is calculated by considering all links on a node, including the one going back up the hierarchy, which gives us 8 downward links from each node. Take 1 node at the top and multiply by eight downward links for each of eight further levels (making 9 levels in all) results in the number of nodes being 8 raised to the power of 8, plus an extra 1 for the top].
10.3.7. While the outcome of the constrains set out above might seem sufficient for most purposes, there are considerable problems in navigating the resulting structure. In particular, there is, by definition, only one very specific route from the top of the hierarchy to any given node at the bottom. Any incorrect branch followed by users at any point in a journey will result in successive branches talking them further away from their desired target. In most cases, given that users cannot know the full contents of the bottom layer, they are likely to assume that what they are seeking is not available rather than retracing their steps and exploring other branches.
10.3.8 Most of the problems caused by the use of hierarchical structures to represent navigation systems in computers derive from the fact that the information contained in the system is generally not, in the strict sense, hierarchical, nor is it actually structured hierarchically. Rather, each node is usually an information item with links to any appropriate set of contextually relevant pieces of information. There is not really any sense of one 'article' being higher or lower in rank or being of greater or lesser detail; they are simply contextual, related in some way but not ranked. This kind of structure is generally called a Network, though in a true network, each connection between two items permits travel in both directions (eg the telephone network can connect any two nodes and the flow of information is permitted equally in both directions). The inference to the user that a hierarchical structure lies behind the information, ie implying through the superficial structure that there is a 'conceptual model' for the data, is misleading since our general experience of hierarchies does not match the actual structure that we experience. This is, I believe, a common cause of users becoming "lost in hyperspace".
10.4 Bi-directional network structures
10.4.1 Let us review Stafford Beer's statement3 again. "The system is what it does". If the information is really organised as a network then the conceptual model that we want the user to have in mind while navigating should be that of a network. This also means that the navigational interface we present should represent the topological features of a network. In particular, the interface should properly represent the following four features of a network:
- All links go both ways.
- Links do not have a preferred direction.
- There is no ranking order of 'higher' or 'lower'
- There are no 'categories', only contextual relationships.
Fig. 1. Example of a small network structure, with a central home page.
Figure 1 shows a simple model of a bi-directional network which will help the reader interpret the features listed above. The central node is suggestive of a "home page", providing a start point, or way in, to the network; but it is important to recognise that its structural relevance is no different from that of any other node.
10.4.2 Let us now consider Figure 1 in terms of the requirements Ri and Rii, respectively at 10.3.3 and 10.3.5 above. The structure satisfies both of those requirements in that none of the nodes has more than 9 links and the maximum number of steps from any given start point not just the central node, to any other node does not exceed 9. This last point is an improvement on the hierarchy in that the average distance from any given node to each of the other nodes increases as one moves down the hierarchy, since a node that is at the bottom, ninth, level would actually be 16 steps away from 8/9ths of the total number of bottom nodes, assuming that the entire population of 16,777,216 nodes is filled. The distance of 16 results from 8 steps up the tree to the top node, then a further 8 steps down the tree to a node at the bottom of a different start branch. We can use this improvement to define a replacement for Rii:
Riii "The shortest distance between any two nodes will be no greater than 9"
This greatly reduces the difficulties in designing an interface, since now we have exactly the same topological characteristics wherever the user might be in the network. From the user's point of view this also improves the ability to cope with the conceptual model because each location is equivalent to any other; users do not have to carry a mental note of how deep they are in the hierarchy and, therefore, how far up they need to go in order to re-start. (While a user might not know explicitly that the top node in a hierarchy is the least isolated, having the shortest average distance to all other nodes, it is nonetheless a deep intuition, based on experience, that the further down we go, the more isolated we become).
10.4.3 Another enormous benefit of the bi-directional network model is that it provides many possible routes between nodes. Consider as a characteristic of a hierarchy that for any pair of nodes in the structure only one route exists to traverse between them without passing through any single node twice. In Fig.1, if we impose a similar rule, that no node can be passed through twice for any given journey, and set an upper limit on the number of steps to 9 (Riii), then we can find dozens of possible routes between node x and node y. In fact for many pairs there are more routes than there are nodes in the structure. This enables users to locate valuable information by orienting, or gravitating towards it, through their own interpretation of, and assumptions about, the contextual relationships between nodes.
10.4.4 A down side to this approach is that it greatly reduces the maximum number of nodes that the structure can contain to approximately 360,000. This figure is based on an estimate derived from:
n!, ie 9x8x7...x1) where n is the maximum distance, Riii,
NB: This formula is not general, but a special case where the number of branches per node and the number of levels are the same. It would require modification if the maximum number of branches, Ri, were different from n.
This hypothetical solution would provide a single node at distance 9 for each start point. However, many other solutions would exist, each having a smaller total number of nodes (without going into detailed mathematical analysis, this would be determined by the predominance of triangles over un-crossed squares, un-crossed pentagons etc in the particular structure that is created, more triangles resulting in fewer nodes).
11. Can This Approach Provide a Durable Solution?
11.1 Scalability
11.1.1 Let us be ruthless and assume that any particular bi-directional network structure satisfying both Ri and Riii (10.3.3, 10.4.2) is dominated by triangles and might be reduced dramatically to n!/10 or roughly 36,000 nodes. While this is a large number for a single information resource (say a web site describing a company's range of products) it is clearly insufficient for a universal navigation system. We clearly need to create another level of structure in our navigational framework. Ideally, this new structural element would work within the same conceptual model as that already described, in order to keep the entire aggregate structure as simple as possible.
11.1.2 Let us therefore consider what would happen if we created two "modes" of navigation, each based on the same bi-directional network. One could be used for hopping between domains (web sites for example), the other for exploring a chosen domain (a particular web site). This would square the potential number of nodes available, ie 36,000 x 36,000, or 1,296,000,000.
11.1.3 For the interface designer this would introduce the need for a two-state mode selector to switch between navigating the domains (say Mode A) and navigating within a domain (say Mode B) but at least the rest of the interface could remain identical. From the point of view of users, they would similarly need to switch their mind-set and preserve their sense of "Where they are" in Mode A whenever they switch to Mode B, though the same would not hold for the reverse situation (switching from Mode A to Mode B enters the user into the new domain pointed to whereas switching from B to A returns one to the location from which the current domain was entered).
11.1.4 Perhaps this is not yet sufficient, given that at any point in time most of the available nodes are unlikely to be populated. How many such levels, or modes, might be required? An increase to three modes gives 36,000 cubed, or 4,665,600,000,000 nodes. Of course this adds yet another switch to the interface, and a little more complexity to the conceptual model, but we think we can conclude that the approach scales up quite successfully (though we will look into the issue of implementation on various platforms in Sub-section 12.7 below).
11.1.5 Readers scrutinising this scaling up process will recognise that we are, perhaps, describing a hierarchy of modes and indeed that would be the most obvious assumption, given society's tendency to assume hierarchies wherever nested structures are presented. Without going into any detail here, let us be clear that this need not necessarily be so, and that all of the difficulties of hierarchies described above can be easily avoided; but in this case we believe that there is no need. A hierarchy that is only a few levels deep is perfectly acceptable as a conceptual model for navigation if, as we have shown, we do not need to go down too far in a proposed structure to gain access to vast amounts of information.
11.1.6 So, the proposed structure is, indeed scalable, both in terms of design constraints and the user's ability to comprehend the conceptual model.
11.2 Adaptability & Usability
11.2.1 In the case of a navigation system for disabled people, adaptability and usability (as defined in Section 9. above) are very closely coupled. However, a distinction can be made between adaptability to different information platforms (WAP, Web, Palm etc) and adaptability to devices that might be used by a disabled person to control the navigation interface (single switch, keypad, voice activation, speech synthesis etc).
11.2.2 A further aspect of adaptability that should be considered is the ease with which the proposed navigation method can be applied to existing information systems (web sites, WAP services etc) which we might call 'ease of service adoption'.
12. Usability by Disabled People
In the following Sub-sections the interface layout in figure 2 will be referred to.
Fig. 2. A phone-pad interface layout
12.1 The interface layout in Fig. 2 should be regarded as a generalised view of a minimum set of functions needed for the operation of the proposed navigation system. This particular layout of functions is not important, nor even the 3x4 grid that they are located within. In fact, a grid of 4x4 switches would be almost as simple for most people to operate, and probably reduce dramatically the number of times a user might need to use the Function switch, by allocating four frequently used functions onto an additional fourth column. However, we will use this particular 3x4 grid for the purpose of analysis because it follows the minimal format of a standard telephone number-pad layout, where the Function button would be the '0', the Mode button would be '*', and the Special button would be '#'.
Most of the switch functions will be familiar to the reader, if studied in the context of the preceding discussion, with the following additions
- We have, arbitrarily, used the "link 9" switch to default to the link that would take users to the location from which they accessed the current location, hence the "back" indicator.
- "Switch Navigate Mode" will toggle between navigating categories and navigating content within a category.
- The "Function" switch may be used to provide user-specific capabilities, such as scrolling through a page, text entry or a selection of favourite sites.
- The "Special" switch might provide for the site owner to assign special options or navigation capabilities to their site.
12.2 In order to evaluate the usability of this functional arrangement let s consider it in the context of three hypothetical individuals:
- User a: A learning impaired individual with a mental age of 3.
- User b: An individual who is profoundly blind
- User c: A physically disabled individual who is only able to operate a single on/off switch.
12.3 User a: Learning impairment
12.3.1 For the learning impaired individual, specific sites might be selected by a parent, teacher or carer, and the individual given a controller that only has the top 9 link buttons. The controller itself might be a touch screen enabling him to touch directly the next piece of content that he wishes to see.
12.3.2 This approach allows for many sites to be developed specifically for people with learning difficulties, each with a potentially large number of sections. For some individuals a smaller number of choices, and a smaller distance between nodes, might be desirable, though this would be up to the content provider. According to our n! calculation for the maximum number of nodes, a site with 6 links per node and maximum distance of 6 would provide for 720 nodes. With 5s the number would fall to 120. In either case there is probably sufficient capacity for the capabilities of the target user.
12.4 User b: Blindness
12.4.1 Our blind user has very different constraints, determined not by her ability to cope with too many choices but by the time it takes for her to find out what choices are available. Assuming that the individual uses a speech synthesiser which speaks the names of the available links then the time it will take to read out all of the available choices will be limited to the collective length of the nine link descriptions. We can further eliminate the need to read out the ninth link, since users can be assumed to be able to remember their previous location. The functions of the three switches at the bottom can be assumed as known by the user, as well as those behind the "Function" switch.
12.4.2 A simple adaptation to the keypad can greatly improve the efficiency of the system by forcing it to speak whatever link description or function name is offered by a particular switch when it is held down for a prolonged, user definable, period perhaps as short as a quarter second for a skilled user. This would enable the user to review rapidly specific links and also to review the functions offered by the "Function" and "Special" switches.
12.4.3 Special functions (accessed via the "Function" switch) might be : "Read all links and return to links set"; "Read all specials and go to specials set"; and, of course, "Read the current page".
12.4.4 Assuming that a typical link description takes less than 2 seconds to read, navigating between any two locations in a densely populated site of 32,000 nodes will require listening to nine sets of links of approximately 16 seconds each, or 144 seconds of listening time. Of course, this would be require great skill and familiarity with the system but it does indicate a manageable level of complexity.
12.5 User c: Extreme Physical Handicap
12.5.1 Our physically handicapped user has no intellectual constraints and can see exactly what options are offered on the screen. In this circumstance, a variation on the standard 'binary-chop' method can be used to select from the switch options, ie the interface can offer each option or group of options sequentially. The user presses his single switch while the preferred choice is highlighted. We can imagine an interface which offers each column in turn, enabling the user to reduce his choice to 4 switches after the first selection. Next, the top two and bottom two options in the column are offered in turn for the user's second choice. Finally, the two remaining options are offered in turn to obtain the final selection. This means that any function on the front set can be operated after three switch presses, while each of the options under "Function" and "Special" requires six switch presses.
12.6 While these three examples do not provide a comprehensive analysis of the needs of all disabled people they do show how control systems that disabled people use today can be easily adopted to provide simple and effective navigation of content using the proposed approach.
12.7 Adaptability to platforms
12.7.1 Most people concerned with the development of networked information systems agree that the general-purpose web browser is the most complex platform that we are likely to use for information access. Future platforms for navigating content, including WAP, 3G, Palm and others not yet known, will be much more basic in their design, and limited in their functionality. This is a trend towards platforms commonly referred to as "Information Appliances".
12.7.2 If we consider the proposed navigational approach carefully, taking particular note of the adaptations for disabled people described above (Section 11, Sub-sections 12.1-12.6) we can see how these ideas can be applied to small appliances. A credit card sized device, for example, could provide a small screen with a single button on its edge. Along the top of the screen the options that were highlighted for the physically handicapped user could be presented, one after the other, until the user presses the switch (12.5). Imagine another scenario where a small WAP phone displays a hi-resolution colour page on a screen that is about the same size as those on today's mobile phones. A speech synthesiser could provide exactly the same interface as that described above (12.4) for the blind user, employing exactly the same button layout that we have on most mobile 'phones today.
12.8 This exact system could just as easily be used to navigate around telephone-based information systems that might offer much greater depth than those in widespread use today, perhaps even to navigate between on-line news services from around the world. Similarly, as digital television brings more and more access to high quality on-line information systems so the limited functionality of the remote control handset can be easily adapted to the same navigation model.
12.9 In general, the more simple the set of functions and requirements for a software system the more easily it can be adapted to new and changing needs. Since the proposed system tackles the problem of navigation by people who have severe physical limitations it is necessarily very efficient in its use of functions and the demands that it puts on a particular control system. Therefore, we can conclude that it will present few problems in adapting to the unknown digital media platforms of the future. In fact, it could prove to be a driving factor in the evolution of such platforms because by establishing a simple, widely adaptable conceptual model, it promises to simplify navigation for all users, whether disabled or able-bodied.
12.10 Ease of service adoption
12.10.1 A critical consideration in the design of the proposed navigation system is the ease with which it can be applied to existing information systems, particularly web-based sites. Recall that in the Sub-section above "Why Hierarchies Don't Work" (10.3) we described how the proposed navigational design is based on the "real" networked structure of most web sites and information systems. As such, the interfaces described should be applicable to many existing sites already, given that some generalised technique can be applied to the site to enable it to be presented in the formats described. Clearly, most web pages have more than nine links; and in most cases reverse links "back up" to all pages that point to a particular page are not offered on the page itself. However, these obstacles can be overcome by analysing each page for in-coming links elsewhere in the site.
12.0.2 We can also determine by observing from user behaviour which links are the most popular, and can then rank them into sets of 8, each set of nine offering a link back to the page that the user came from. Successive sets of links could then be selected via the "Special" button indicated in Fig. 2.
12.10.3 It is beyond the scope of this document to analyse the technical processes needed to convert an existing site for the proposed navigation system but it should not present any insurmountable challenges, particularly as the recently released XML standard allows for sites to be sensitive and adaptive to different target platforms with minimum difficulty. In effect, the proposed navigation system can be described as a common platform in its own right, like WAP, 3G or WebTV, and the software at the user-end can be implemented to present the navigation options in the way best suited to the user's disability.
13. Commercial opportunities
13.1 It is worth making a small diversion from the main thrust of this Report to analyse the possibilities that the proposed navigation system might present. The scope of this Report does not allow for a detailed discussion here but it is worth briefly pointing out that the navigation of content is very different, in terms of the functions and operations that are required of an interface, from the usual range of features required for a general purpose computer.
13.2 Many of the difficulties experienced by people browsing the web are, as already described, associated with the ineffective use of metaphor (particularly the inference of hierarchical structure) and the ambiguous use of interface elements that were conceived for the purpose of creating content, such as pull-down menus, radio buttons and other GUI elements. As we have shown, navigation per se does not necessarily require any of these once a clear understanding of a simple but effective conceptual model has been established.
13.3 In fact, the marketplace has unequivocally established that the desktop GUI is not suitable for content navigation on small appliances as evidenced by its rejection to date of Windows CE for such purposes. This rejection is well demonstrated by the very successful establishment of the British-led Symbian consortium led by Psion in the face of huge marketing efforts by Microsoft. Symbian is a much simpler approach to creating an operating system for information appliances that will first be seen in 3G mobile telephones.
13.4 If one considers the Symbian O.S. as a target platform for establishing the navigation system proposed in this Report, one can imagine creating a world-wide standard for creating and accessing content, driven from the UK perspective. In effect, this represents an opportunity to occupy a similar space in the information market that Microsoft now occupies in the general-purpose computing marketplace.