Link
Usage | Types | Links vs. Buttons | States | Design-relevant Attributes | Related Controls
 |
|
Figure 1: Example of links in the content area |
Usage
The link control is not the simple topic it may seem to be. Not all links should be handled equally. There are hypertext links in the navigation area, header area, and content area as well as on buttons and in tables and applications. All of these links can have different appearances and behaviors.
For aesthetic and usability reasons, the links in the navigation area (not to be confused with content area navigation links!) have a different appearance from those in the content area. It's important that the user recognizes these links as pertaining to the overall navigational structure and not just a way to drill-down to detail information or jump to a page in a different context.
The HTMLB control called "link," which is described here, refers to hypertext links (referred to here as "links") in the content area.
Positioning
Links may either appear
- as part of a larger text, (for example, an article about customer service might contain a context link to the mySAP CRM homepage) or
- standalone (for example, a list of links to articles about CRM, a "More" link placed at the end of a abstract to navigate to additional information, etc.)
Standalone links should be grouped together separately from buttons and vice versa. When possible, functions and links should be grouped together and displayed in the same way (either all as links or all as buttons), as in figure 1. A mixture of links and buttons in the same grouping context should be avoided.
View switching links are most often displayed above the content to which they refer, as in figure 2.
Capitalization
It is not necessary to make any special capitalization considerations for links that are part of a larger context or that are automatically generated (such as contact names, document titles, etc.). In the same way that buttons require title case capitalization (i.e. the first word always capitalized, all significant words are capitalized, prepositions and articles are not capitalized), so do function, navigation, toggle and view switching links.
|
|
| Figure 2: Example of an iView where links have both title and sentence case depending on the usage |
Types
Although there is only one link type from a technical point of view, we must make a distinction between the various kinds of links in the content area. This helps to establish usage rules for links and to make a distinction between buttons and links.
Note:
Based on what purpose the links serve, we can establish five different types of content area links: view switch, toggle, drill-down, function, and navigation.
|
Figure 3: Example of an iView with view switch links. View Switch LinksView switch links are similar in function to toggle links, but are different in that they are always visible. The view switch links are an alternative to the tabstrip control. The advantage that view switch links have over the tabstrip is that they take up less space and can be used vertically, if this makes more sense in the application (for example in mobile applications where the format of the device allows more vertical than horizontal space). This type of link is similar to the navigation link. As opposed to navigation links, view switch links all refer to the same context and must be persistent in all the views. The currently selected view should not be presented as a link, but as bold text (see figure 3 above). View switch links should be separated from one another by a vertical line, like this one |. Use title case (see Capitalization) for view switch links.
|
| Figure 4: Example of an iView with toggle, drill-down, function and navigation links. |
Toggle Links
Toggle links are used when there are two alternative views of the current data. Toggle links are always pairs of links, but only one is visible at a time. In figure 4 the toggle link reads, "Show Entire Feedback Text." If the user were to click on that link, the alternative view would show the feedback in its entirety and the text of the link would change to "Show Only Feedback Preview."
Some common examples of toggle links are:
- Expand All / Collapse All
- Show Chart View / Show Table View
- Hide Help / Show Help
- etc.
Use title case (see Capitalization below) for toggle links.
Drill-Down Links
A drill-down link allows a user to see more detailed or specific information. For example, in the overview of an address book, the contact names are drill-down links that allow the user to access details on that person. In a mail inbox, the title of each message would automatically be a link to the contents of the message.
Some common drill-down links are:
- Contact name
- Customer name
- Document title
- Message title
- Report title
- Revenue
- etc.
These links are most often automatically generated and the developer should make no attempt to influence the capitalization. (See figure 2.)
Function Links
A function link allows the user to carry out an action.
Although in general buttons should be reserved for functions (see Links vs. Buttons for more information), there may be cases where a link would be preferable or where the distinction between a function and a link to another view might be very blurry.
For example, when the user wants to subscribe to an object (e.g. a folder), the link may just be a link to a new screen where the user has to fill in some more information and then can submit the information to the server. This whole act of subscribing, however, could be thought of as carrying out a function and in some cases might make more sense as a button than as a link, or vice versa depending on the context.
Sometimes you may have a collection of items, for example a list of documents. There are some actions that you can perform all at once on a number of documents whereas there are other actions which make more sense when they are performed on each item one at a time. If the action requires a new screen or additional information (details, feedback, edit, reply, etc.), chances are that you can only perform the action on each item one at a time. In such cases, a link is generally preferable to a button.
Taking the iView in figure 1 as an example, we can see that the user can select a number of documents and approve or reject them all at once by using the checkboxes and buttons. However, if the user were to want to see the details of a number of documents, it makes more sense to have him choose a link next to each document. Otherwise, the user would have a number of detail screens and would likely be confused about which details belong to which document.
If your application has a list of items, and each one requires it's own function (see figures 1 and 4 for examples), it is preferable to use links as opposed to buttons for functions in this case. This is mainly due to aesthetics, but it is also a usability factor. An application with a wall of buttons makes the application look heavy and complicated.
Some common function links are:
- Details
- Feedback
- Add
- Subscribe
- Reply
- Edit
- etc.
Use title case (see Capitalization) for function links.
Navigation Links
Many times, there will be navigation within an iView or application which is independent of the main navigation of the Portal. End users might not even perceive these links as "navigation" per se. Navigation links allow users to move backwards or forwards though a data set or process. Sometimes the difference between a drill-down link and a navigation link might be difficult to assess, for example with a "more..." link.
Some common navigation links are:
- More...
- Next or Next >
- Back or < Back
- Backward "<" and forward ">>" as well as back to the beginning "<<" and forward to the end ">>"arrows in text form (as in figure 4 above)
- Numbers to navigate to a set of entries (as in figure 4 above)
Use title case (see Capitalization) for navigation links.
Links vs. Buttons
In general, use links to indicate navigation to another HTML page or to a different view of the current information as well as to link to further or more detailed information. Links commonly appear within the context of the application (within trees, tables or text).
In general, use buttons to indicate that a function can be carried out (save, print, close, delete, etc.) or that a process can be started (subscribe, etc.). Buttons generally appear at the bottom left of a grouped area to indicate a function that can either be performed on selected items (if checkboxes appear as well) or that apply to the whole screen. (See the section of these guidelines called Buttons for further information.)
For more information about cases where links may be used to indicate a function, see function links above.
|
|
| Figure 5: Example of an iView where links and buttons are both used. |
States
The link control has four states: link (i.e. unvisited, normal state), hover, visited and active.
 |
Example of a link in its normal state |
 |
Example of a link in the hover state |
 |
Example of a link in the visited state |
 |
Example of a link in the active state |
Table 1: Examples of the different states the link control can have
Design-relevant Attributes
Attribute reference allows to assign an URL to the link, whereas attribute target allows to set a link target. The latter follows the HTML conventions for specifying link targets. Attribute text sets the link text, and attribute tooltip the tooltip text for the link.
For details see page Control API for Link.
Related Controls