Posted by Craig Macomber on 15 Sep 2007 21:12, last edited by James Kanjo on 09 May 2010 05:52
Please note that this guide is incomplete, but still very useful. The empty sections will be filled in soon.
What is an interface?
An interface is what connects the user to the product. It the field of web design the interface is the page and site structure itself.
For more info see http://en.wikipedia.org/wiki/User_interface
To design a user interface you must know how users think and act. Users:
- skim, not read.
- wander and don't (like to) think
- find a way, and don't search for a better one
- get frustrated quickly when not making progress
Definition the Optimum Interface
You want to the best interface you can for what ever you are making, so you need to know what the goal is. The optimum interface is described below:
No thinking required
If the user has to think, your interface is not optimal. The user should know intuitively what to do. This means that the user must know where any given bit of content should be, and how to get there intuitively. We will get back to this later under the topics of categorizations and navigation, but don't forget it.
At a glance the viewer/user/reader should know what is available, and find the relevant sections without reading more than 10% of the displayed content. People skim, and almost never read web sites. You want to guarantee that the reader can skim effectively. This means at the first look they find the relevant section, and at the second look they find the reverent sub section (clicking a link to access it if needed) repeating as many times as necessary. If a page has little to say, it should say little. Never, ever add content because a page looks empty.
Every section should follow the exact same organizational system. Every page should maintain familiar navigation.
You are Here
There should never be any doubt about where you are on a site, and what should be there. Links to pages, their titles, URLs and content should all match. Bread crumbs are one of the best, if not the best method of doing this.
Now that you know what your interface needs to accomplish, here is how to design it. The interface does two things, displays content relations, and displays content. Content relations are the connections between the little bits on content scattered throughout your site.
Before you can design a user interface you need to know what content it will be displaying and relating. It is important to come up with a general idea of the content that will be on your site before starting work on it. How is this done? The simplest way to do this is think of all the concepts (ideas, text) and objects (pictures, files, downloads etc) that need to be presented. You will likely not think of all the concepts and objects, but one can usually think of a high enough percentage to start relating them.
Once you have a good idea of the content your site will hold you need to find the relations between the parts of the content. To do this it is best to categorize by type, or at least select a single well defined category. This is how you break up your content. If you are making a site about office supplies one category could be paper. You then take one well defined category and find its parent, its children, and its siblings.
Types of relations
These relations are identical to those used in class based programming, so additional information can be found here http://en.wikipedia.org/wiki/Class_%28object-oriented_programming%29#Subclasses_and_superclasses
A parent in this case is the object/content from which the children inherit properties. Paper could be the parent of lined paper because lined paper inherits all the properties of paper.
Children are the object/content which inherit properties from their parents. You can also consider children to be specific types of the general parent. Using the above example, lined paper (specific type) is a child of paper (general type parent).
Siblings may not be an official term, but its meaning is clear. The sibling of a bit of content is another bit of content that shares the same parent. You can also think of it as all of a parent's children are siblings.
To find these relations you can start with a bit of content or type of content, and find all of its relations. If something is not related to is somehow maybe it belongs on a different web site.
Find you content's parent, and its parent ans so on until you reach the highest level. This is called the base level, and is often based on the home page of the site. Every thing inherits from this so the content presented with it should apply to all of the content of the site.
From the base level, or really an level you can search down, to its child, and the child's child etc. What is usually more useful is to find all or most of the children of a given content part and check for relations (shared information in this case) between them other than those expressed by their parent. If there are relations between all of them, this shared information should be added to the parent, if there are relations between some of them a parent for these related children should be created to express this information, and it should be made the child of the original parent. If you continue this process on all the children at each level you should end up with a hierarchal data structure including all of your content which can be intuitively navigated.
The problems faced by this system are similar to those faced in single inheritance class based programming so additional information can be found at http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29#Limitations_and_alternatives . The main problem is Singleness, which is that a content bit can only have one parent. A simple example is that paper box can not both be paper, and a box. There are many methods for dealing this this issue which are will be discussed below under Multi-Parenting. Another example is the "Implementing with wikidot" section on this page. All of its children could also be children of the respective sections above.
Sometimes content inherits from more than one other piece of content. To use the example above, a paper box inherits the properties of both paper, and of boxes. This means the paper box should descend from both paper and from boxes. Paper is not a decedent of the box, and the box is not a decedent of paper so multiple parents are needed. This is multi-parenting: giving content more than one parent.
Many organizational systems, from file drawers to web sites, can not handle multi-parenting, so several systems for avoiding, or working around the problem have been designed, some of which work very well.
Parent to Child Navigation
Parent to child navigation allows the viewer/user to access any contents children. These approaches implement multi parented navigation from the top down.
Aliasing allows content to be referenced from where it is not stored. This can allow content to contain aliases of, or links to, the content that would be its child if it were not the child of other content. A physical example would be putting a "see paper box under paper" note in the boxes section. This method is often done in computer file systems, or implemented on web sites with links.
Linking is just like aliasing except that none of the content is actually filed under its parent. The parents just contain a link the content. This allows all the content to be filed at the same level, and in any order if desired. It also makes every parent to child connection the same (all are links, not some links and some content). This method is commonly used when it is undesirable to move data when the connections change such as files on a hard drive or computer memory. A physical example would be a drawer full of numbered (in order) folders, and each folder would contain its content, and the numbers of their children folders. Then available this method works excellently for parent to child navigation.
Child to Parent Navigation
Child to parent navigation allows the viewer/user to access any contents parent. These approaches implement multi parented navigation from the bottom up.
Linking as described under "Parent to Child Navigation" above works the same when implemented for child to parent navigation. The issue is that the available navigation could have incorrect, missing or extra links preventing consistent forwards and backwards navigation. More about this under "Two Way Navigation"
Two Way Navigation
For most systems the viewer/user needs to be able to both find the parents and children of content. Any small differences between the child to parent navigation and the parent to child navigation will be confusing. To use our earlier example, if someone looks up boxes, and then navigates to paper boxes they would get confused if paper boxes appeared not to connect back to boxes, but only paper. The same is true going the other way. If they navigate from paper boxes to boxes, they would be very confused if boxes contained all kinds of boxes except paper ones. Because of this problem these connections need to always be one way, or two way, and in most cases only two way will be good enough.
Two Way Connection Management
The connections can be kept consistent if the organizers only make one connection and it is automatically shown on both ends, however systems that do this are often not available. Some possible implementations or systems are described below.
This system consists on one way connections (usually parent to child) and the child to parent relations are generated on the fly by scanning all the content to see what has the page in question as its child. Here links refer strictly to parenting links as described in Parent to Child Navigation, Linking. This system amounts to something similar to bread crumbs but only usually one layer deep.
Order of Content
Other Relations and References
Sometimes content is related by something other than parent/child relations ships. An example is that staples are clearly related to paper, but there is no parent child relationship; there should be an at least one way connection from staples to paper. To do this staples would reference paper, and the reference would be linked to paper.
An Organizational System on Web Sites
Sections vs. Pages
Content relations through the relations discussed above (parent-child relationships) can be expressed on the level of pages (related pages) on within pages using varying headers.
Repeated Content and Unification
This content which is placed on every page is extremely important for avoiding confusion. This repeated content, such as navigation bars, search boxes, headers and footers show what site you are on, and provide consistent locations and implementations for the navigation elements. Also important is a unifying appearance which this content and consistent formatting add. Consistent formatting is often maintained by following a style guide and/or using one control to change the appearance of the entire site such as CSS or a template.
The Home Page
The homepage of a web site is very important, but is commonly poorly designed. The home page is seen in three cases, when some one first arrives at your site, when a returning visitors goes to your site, and when a current viewer returns to the home page.
For the new arrivals the most obvious thing should be an indication of what site it is, and second should be what it is about, and third should be what is on the site. This needs to be quick and big. The viewer should recognize the title or name of the site at first glance. To accomplish this it is usually presented large and centered at the top. The logically following text, often the subtotal or first sentence or two should cover the subject and content, however the title should hint at this.
Returning visitors want to know what has changed, and navigate quickly to what they are interested in. One of the most popular methods for showing the changes to a web site is having a list of recent changes or news. This section should be easily located with a large header, but it does not have to be too prominent because the returning visitors will know where to look. For the quick navigation not much has to be done, however if the site has a deep hierarchy it might be good to put a site map on the home page, or some links to the lower hard to navigate to sections of interest if not included in the site wide navigation elements. Often the home page has lots of room for navigation elements so it has more complete non site wide ones, but this should be done with care and in a manner similar to the site wider versions.
Returns to the Home Page
These people have basically the same navigation needs as the returning visitors, so see the above section.
So, where does everything go?
The order in which content is viewed greatly effects the proper positions, and the order that different positions are viewed in depends on the language. Right to left language readers look to the right first, and left to right language readers look at the left first. The descriptions below assume left to right then top to bottom reading, but can be converted if needed by simple mirror imaging. The order content is seen in is also greatly effected by size and contrast.
We have discussed how to organize and connect the little bits of content, now how do we present each piece? The bit of content in question is the text under a header anywhere on the site. This text should be kept specifically on topic. Any additional related information that does not specifically belong to the topic in question, and all of its parents, should be stored in a different location, and be linked to. A good guiding principal is that any piece of content should be as small as you can make it, and in as many sections as possible. Should the sections get too small they can be listed, or written as one sentence per section.
Each page needs ways to get to the relevant pages. Links go to relevant pages from where what they are about is mentioned. In addition to that we need a system to navigate to related pages.
Child to Parent
The most common way of allowing navigation to a pages parent is through bread crumbs. They are simply a list of the pages parents going all the way back to the first one. The list is linked and usually separated by " > " or something similar. This does a few important things. It is a great "you are here" sign, as well as showing how you might have gotten there and what that page is about and letting you return to the parent pages where you can find similar related information or navigate to sibling pages. Bread crumbs, or any child to parent system also allow for an easy return to the top in case someone gets lots on the site.
Multi Parented Child to Parent
So what would our proposed multi parented parer box's child to parent system look like? It has a parent of box, and one of paper, both of which would have one or more parents, all eventually ending at some high level topic such as office supplies in this case. This could be represented as a tree spreading from the current page, or some sort of web recombining some of the branches so there is a single parent splitting out and eventually recombining to the current page. A different more simple approach that is actually used is to have the bread crumbs show how you got there, but that can be confusing as they are not always the same and are in some ways incomplete.
Parent to Child
Parent to child navigation is often a challenge to keep consistent while useful. A simple list of child pages, or a tree listing the child pages, and their child pages and so on can work very well. The issue come when deciding the depth of the tree. Sometimes having unlimited depth is good because it shows all the pages, but sometimes there are far to many pages, so unlimited depth is not an option. Also, in some cases the list of child pages is so long that just listing them is impractical. All these different situations can occur on one site which can lead to inconsistency. If none of the trees are unlimited depth it wont be expected, so the depth can be varied. In the case that there are too many children, they can be grouped into categories and the categories can get their own pages. Then the original page can have the categories as its children and list those. If needed these categories can just be alphabetical as in one category for sub pages starting with A, one for B etc.
What is to be done about pages with no children? One approach is to show a blank list of child pages or state is has no children, and the other is to not show a parent to child section on those pages.
You are Here
Presenting the Page Content
What to Leave Out
What to Include
Sections, Headers and Page Hierarchy
Links and References
Implementing with Wikidot
Usually the best approach on wikidot is to define a organizational structure where multi-parenthood is not usually needed, and manage the cases where it is required with links. This frequently is impossible, so you can use multiple organizing principals. Example: Use page parent hood, tags, and/or categories for different things.
Tags are interesting because they are pretty much overlapping categories, but they lack some functionality. Tags can be used globally, within categories, or both.
Categories are good for separate sections of a site, or lists of pages because the category can be set with the new page module.
Page parenthood can do hierarchical structures and is great for site navigation with page trees and bread crumbs, but lacks multi-parenthood. Page parents can not be set with new page modules (which is horribly unfortunate) so it is a bad choice for structures which will be edited by inexperienced editors1. Page parenthood can be used completely independently from categories and tags. Page parenthood automatically does child to parent navigation with bread crumbs, and can automatically generate parent to child navigation using the page tree module.
One can also use back links.
Also, be sure to check out the wikidot handbook.