| Next Button Sample 1 |
 |
Observation 1: In a typical "wizard driven" interface, the next button is placed to the right of all other buttons to re-enforce the notion of moving forward. The placement of this next button violates the consistency and standards heuristic.
Recommendation 1: Position the next and back buttons to be in a more conventional proximity to other buttons. |
| Confusing Status Sample 1 |
 |
Observation 1: The status indicator, while well intentioned, seems to hinder more than it helps. The main problem is that it doubles as navigation that allows users to skip over steps – which begs the question: If steps can skipped, is this really a linear flow? In other words, is a wizard interface appropriate here? The confusion that results increases the probability of user error, rather than preventing it. But also, it fails as a system status tool since it sends mixed messages.
Recommendation 1: Will require further analysis. |
Observation 2: This isn't so much a whole seperate observation, but just an elaboration of the first observation. Allowing the status titles to be hyperlinks creates modality issues. Most of these screens are forms that require a send to the DB. If a user is encouraged to navigate away from a form before completing it, the DB will not save the data, and the user will get lost/confused/frustrated because the UI allowed for the loss of his or her work.
Recommendation 2: Limit links (if any are warranted at all) to screens that have already been filled out. In other words, offer links as crumb trails that allow users to go back but not forward – thereby forcing the user to click the "next" button to progess through the UI. |
| Too Much Complexity Sample 1 |
 |
Observation 1: There are three, count them, three, fields that each require the same information. It's just a huntch, but admins. probably don't need to enter one name for the title (the name that will appear in the channel header) and a different name for the channel name (the name that will be presented to users when they go to select a channel in preferences).
Recommendation 1: Examine which fields can be consolidated in the UI. Try to avoid exposing users to back-end complexity. Remember, less is more. |
|
|
uP2 Channel Manager Heuristic Analysis
Comments (1)
Feb 20, 2007
Jason Shao says:
Agree the distinction between name and title is ambiguous and inconsistently app...Agree - the distinction between name and title is ambiguous and inconsistently applied. With portlets - title is even at the discretion of the portlet, so a convention of "channels have names and the displayed title defaults to the channel's name but can be overridden dynamically" would probably be very appropriate. That way, if you have a subscribed RSS feed for instance, the channel dynamically assigns RSS: NYTimes or provides config to allow changes.
Review button in general is probably confusing as well, especially since the first time you go through the process, skipping permissions and other bits may be fatal. Perhaps limit to the link based URL, with URLs for all stages available when editing an already published channel.
Also - the help icons – are the descriptions and help messages really that long? Seems likew e should just have help text embedded in the forms.