Web Design Ethiopia

Two broad approaches to developing an initial architecture are bottom-up and top-down design. In bottom-up design, you gather all of the intended materials and categorize them, building up to higher levels of categories.

In top-down design, you specify the top-level categories, and break each category down into smaller pieces until you’ve identified the lowest level of information.

Top-down helps identify missing pieces that are needed to complete a category, and bottom-up identifies missing categories that are needed to include every piece of content.
As an example, consider constructing a web site about poetry.

In the top-down approach, you consider what information to provide at the top level, perhaps Poets, Poems, and Forms.

Then you break down each main topic. Forms might consist of Sonnets, Haiku, Free Verse, and so forth. Poets might be broken down by country or historical period. You keep breaking this down further until you have all the topics you feel you need.

In contrast, a bottom-up approach to a poetry web site might start with the question, “What materials do I have available or can I construct for this site?”

You decide that you have a few hundred poems you’re able to provide, and you then determine that each poem would go on a page of the site. Then you determine how those poems might be grouped.

Perhaps one set represents Love Poems, another set Nature Poems, and a third set French Surreal Poetry. Those form your low-level categories.

If this is all you have, then you’re done (and you avoid having to create all the material for Poets that the top-level breakdown suggested). If you also have other materials, you could group these under Poetry Genres and continue.

In practice, both top-down and bottom-up approaches are usually taken, going up and down the levels of organization and refining in each direction.

Representing the Architecture
In the course of developing a web site architecture, you’ll need to diagram or otherwise represent the architecture to illustrate your ideas and communicate them with clients and your development team.

The form of representation you choose will depend on your target audience, what it need to do, and your ease of putting the diagram together and modifying it. Presents a variety of ways to represent your architecture, including outlines, flowcharts, tree diagrams, sexy diagrams, wireframes, and page schematics.

Whichever representation you choose, you’ll need a way to represent several common concepts within the diagram.

For instance, the home page needs to be easily identified and is usually obvious by its position at the top.

Other pages may need to be marked according to their development status (e.g., “waiting for content for these pages,” “these pages are planned for Phase 2,” or “these target our international users).

Techniques for identifying these characteristics include annotating the diagram with comments, coloring nodes, grouping pages, using special borders (thick or dotted lines), and putting boxes around related nodes. Include a legend with your diagram if you end up using special markings.

Six common diagramming conventions include:

• Using dotted outlines around pages to distinguish proposed pages from current pages.
• Drawing pages as a stack when they form a highly related series, such as a set of otherwise-identical product detail pages.
• Embedding boxes within a page box to indicate different content pieces within a page.
• Dotted lines to indicate shortcut cross-links that don’t appear in the primary navigation.
• Arrows indicating links to or from external sites.
• Rounded boxes (or another shape) to indicate dynamically generated pages (such as search results).

Card Sorting
While we can determine the structure of a web site through analysis, when confronted with uncertainty, a good approach to take is to get our prospective users to suggest organization for the site.

The card sorting technique is a very useful approach to understanding what natural categories people have for the domain. It is especially appropriate when the designer is not a domain expert and needs the insight of the users or when several alternative organizations are possible.

The card sorting technique has its roots in the psychological investigation of how people form concepts and categories.

How to Do an Open Card Sort
Several approaches to card sorting are available, but the most common is the open card sort. The steps for an open card sort follow.

1. Label the cards
Get a set of index cards and put the names of each low-level concept on a card. For instance, to organize animals, we’d put the terms “dog,” “cat,” “giraffe,” “pufferfish,” and so forth onto the cards. However, we didn’t label any cards with categories like “mammal,” “canine,” or “plant-eaters” – we want the users to suggest such categories.

2. Brief the users
Bring in users and explain that the purpose is to generate an organization for the web site. Their instructions are “Organize these cards into groups. Remember, there is no one right answer, so choose the grouping that makes the most sense to you. After you’ve divided these cards into groups, label each group.”

3. Let the users group the items and label the groups
Avoid interfering or answering questions about the categories – you want to see what makes sense to the users.

If they don’t understand a term you’ve provided, you might ask them to exclude it. After they’re done, you can then explain the term, see if they would have called it something different, and ask them to ft it into their categorization scheme.

4. Listen to other comments about the content
Allow users to suggest missing topics, topics that don’t fit, and topics that they consider to overlap.

5. Group the groups, or subdivide the groups
For small sites, no further grouping may be needed. But for larger sites, you’ll need to generate the next level of the hierarchy. Some users will have created a lot of groups, such as “canine,” “feline,” “rodent,” and so forth.

Ask these users to create larger categories that group together the groups they’ve already defined. Other users will have created only a few groups, such as “mammal,” “fish,” and “bird.”

Ask these users to look for subdivisions within any large group. Once again, ask for labels the new groups they create.

6. Write down the hierarchy the users created, and repeat with more users
Usually, about five users are enough to have a sense of how people organize the domain, but when users have conflicting organizations, you may want to ask more.

An example of a conflicting organization in this domain is having some users group “wolf” and “bobcat” as “wild animals” and “dog” and “cat” a “domestic animals,” whereas others group “wolf” and “dog” together as “canines” and group “bobcat” and “cat” together as “felines.”

7. Combine the results
Statistical methods exist to take these alternative hierarchies and an organization that fits the data best (a technique called cluster analysis), but usually it’s sufficient to eyeball the results and spot the dominant organizational schemes.

A simple count of how many people grouped any two items together provides a useful metric of how confident you can be in grouping them.

After you’re done, you’ll also need to do some cleanup, patching up incomplete categories and choosing among alternative group labels. You may even jot down which items were less certain; later information may help resolve the ambiguities.

Limitations
Card sorts are extremely sensitive to your original choice and phrasing of concepts on the initial set of cards. The organization is affected if your cards are misinterpreted or you fail to include every topic that will be on your site (or include topics that are beyond the scope of the final site).

Thus, you may choose to include a brief description on each card. For example, rather than simply labeling a card “The NX47c Ultrathin,” you may want to provide a description, such as “a low-cost and very small personal computer.”

In addition, you may ask users to suggest additional topics they feel are missing or suggest topics they feel should be thrown out.

While user input on the grouping of items is extremely useful, their suggested category labels are not necessarily very good.

They provide some helpful directions for the types of words users apply in their domain, but frequently labels suffer from problems of ambiguity, overspecificity, overgeneralization, double meanings, and inconsistency.

User-suggested labels provide a good beginning for your development of optimal labels, but you will still need to analyze the labeling schemes.

Variations
A closed card sort constrains the users by providing the low-level concepts and the categories. The user must fit each concept into a predefined category.

This approach is helpful after the categories have first been determined from an open card sort, and when content is being added to a preexisting site.

Another approach is to do similarity matching. Using the same set of cards, you ask people to rate the similarity of every pair of cards (this is relatively fast if it’s done on computer).

Using the same statistical technique of cluster analysis, you can then determine how concepts are grouped, based on the items in the group being rated as similar.

The main limitation is that you don’t get the opportunity to ask the user what to call the groups, although you can get some idea by combining this with an open card sort. The main advantage of similarity matching is that you get more refined data from each user than with a card sort.

For each user, a card sort tells you whether two cards belong in the same group or not, but similarity matching indicates how much a card may below in other groups as well, allowing the data to reflect that concepts can be divided along several dimensions.

An alternative, reflecting the top-down approach described earlier, is to provide users with the top-level categories and ask them to generate lower-level concepts that they’d expect to find under each category.

This can work well when users are experts in the domain. Regardless, you can’t expect that users will be complete in the concepts they identify, but the exercise can suggest missing concepts and also suggest which concepts are most salient to users (the ones that are suggested first, and mot often).

Testing the Architecture
After each design iteration for the architecture, some kind of evaluation is useful to make sure the architecture is effective.

Whenever possible, you should also test the architecture with users to confirm that they are able to successfully navigate it.

Until the site is actually constructed, a simple testing approach is to build a quick wireframe prototype of the site, with page titles and navigation buttons, but only minimal content (as much as is needed to perform the tasks).

Ask users to perform their main tasks on the site, watching for labels they misconstrue or times they stray from the most efficient path, or times when they fail to complete the task.

Architecture Review Checklist
The architecture review checklist (see Form 5-1; download from http://www.mkp.com/uew) summarizes many of the architecture design points.

While this list is good for design issues, it’s especially intended to be used to critique an architecture. After developing a proposed architecture, step through this checklist to identify problems, or ask an outside reviewer to use this in critiquing your architecture from another viewpoint.
 

Report This Post