|
Thursday 15 April 2004 8:14:18 am
Hi,
All comments so far didn't really focus on the usability part of the new interface. I will try to add my 2 cents by stepping through the document with the focus on usability.
Starting with the eight goals (Create a consistent ... etc) formulated, I'd rather restructure these usability goals in general and more specific ones:
<b>1) Consistent </b>
interface/framework
<b>2) Easier (smoother)</b>
navigation
editing/publishing
use of images and links
<b>3) Intuitive (smooth out learning curve)</b>
<b>4) Reduce information load</b>
create well arranged layout Additionally, guidelines like these http://www.useit.com/papers/heuristic/heuristic_list.html might be helpful for evaluation of the new interface/framework.
<b>Logo/banner</b>
The search mechanism contains two radio buttons, so users are able to instantly narrow down their search. Although this function can be very useful, it directly conflicts with the 3th and 4th goal, smooth out learning curve and reduce information load: at least the first time a user wants to search for something, he needs read the text next to radio buttons, think about what the text means and decide whether he should click on one of radio buttons. Certainly, most of the users can perform these steps in just a second, but adding such functionality will increase the complexity of the interface while it benefits only a small group of users. And many of these useful functions will require many seconds (and effort) of the user.
As an alternative for the radio buttons I would suggest to group the search results or show links to filters on the result page, for example. (I'm sorry for the crappy layout, try the search engines on microsoft.com and apple.com to roughly see what I mean)
<b>Grouping search results:</b>
Results in another_sub_node:
1. blabla
2. blabla
3. blabla...
[link]more results in another_sub_node
Results in all content
1. blabla
2. blabla
3. blabla....
[link]more results in all content
<b>Search results with filters:</b>
Seach results
1. blabla
2. blabla
3. blabla....
[link]results in another_sub_node Basically, the 'filter mechanism' is moved to the result page. But by using one of these methods, the radio buttons are not needed, which will cleaning up the main interface. Secondly, if the search results are good, the user doesn't need look at the 'filter links', because he already satisfied his goal (finding a certain item)
<b>Main menu</b>
The old labels are somewhat confusing. Especially 'media' and 'content', because media can be content and content can be media. The suggested labels are much better, but also longer. To keep it the labels as short as possible it would suggest to use 'content structure', 'library', 'users' (next label suggests it's about user accounts), 'my account' (very common used terminology)
<b>Location/path block and Left bar</b>
A major problems of browser interfaces is the risk of 'getting lost' in the huge amount of information. At some point a user of the interface will ask himself 'Where am I? How can I get to... What am I doing here etc.'. The excellent pretty names in ezp-urls provide some clue about the current location, but using the browser url for navigation isn't very comfortable. The url can't be easily edited by hand for example. In other words: the location block is a good idea.
<b>Main area</b>
no comments
<b>left/right bar</b>
Creating both a left bar and a right bar, will take a lot of horizontal space on the screen. Leaving only a small portion left for the real content (in the main area). Users with a small browser window or a low screen resolution won't have much 'main area' left. In practice, lots of people (with a non-it profession) are using a small browser window. (800x600 or so)
Secondly, adding two bars conflict conflicts with goal nr 4: reducing information load. Is all this information really needed? Every single feature that is added to the bars, will clutter the interface and distract from the main tasks. (posting a news item, adding a user etc.)
I would suggest to use just one bar (on the left) which can be customised. The default (the not customised) version of this bar should only show a few information items. There are several ways to create a bar which can be customized, for example with expandable panels (like in XP explorer), tabs (gnome nautilus) and/or via a menu settings. This mostly depend on how much javascript magic is used.
<b>contents of (left/right) bar</b>
Generally, it would be the best to focus on limiting the amount of information shown in the bar. Most users probably aren't interested in seeing the creation date, modification date, review date ... every single time they access an object.
For sake of consistency with other websites (goal 1) the logout button should preferably be located somewhere in the upper-right corner.
<b>Advanced and simple mode</b>
There have been conducted several experiments with different interface modes/user levels. Most of the interfaces failed. Some of the problems are:
*The interface is not consistent (goal 1)
*How do you know what kind of user you are? (not intuitive, goal 3)
*It's often used as an excuse to litter the most advanced interface (goal 4)
In other words: please don't implement this. As an alternative, 'profiles' could be used, possibly in combination with roles. Like computer administrators can strip windows/gnome/kde for use in internetcafe's. Because the admin knows exactly what a certain group of users, news editors for example, are allowed to do he can strip down the interface to not show and disallow certain features.
<b>footer</b>
no comments
<b>content class icons</b>
Icons enables people to recognize certain elements in the interface. (consistent, easy, intuitive). I suggest to use a generic icon for missing icons. A question mark might be interpreted as if something is wrong with the object.
Naturally, the icon-class associations are stored in a ini file. But since administrators might not want to spend days on investigating ini-files, I suggest to create a UI for this.
<b>Logical states/modes</b>
The different logical states seem to be fair. However, for sake of consistency the appearance of the interface should indicate 1)what the users is doing (what state) 2) what he can do next (confirm selection/cancel action). Be sure the user can't accidentally mix up different states.
<b>Navigation mode</b>
The functionality of a folder tree has some overlap with the location bar. I suggest not to show it at as default (goal 4). A tree can be very useful, but it requires lots of screen space to avoid horizontal scrolling. In usability-land, horizontal scrolling is generally considered to be A Bad Thing (c)
[The usability of the contents of the main area depends a lot on the actual implementation and design. Therefore, I will not comment on it now.]
<b>Javascript in the UI</b>
I'm convinced that if technology can solve a usability problem, it should be used. Creating cross-browser compatible javascript and non-javascript alternatives can be very difficult, but the result might prove to be very easy to use for end users. And that happens to be one of the interface project goals.
<b>Edit</b>
Generate link feature: This feature requires end-users to understand XML! I strongly suggest not to implement a link feature this way. It not easy (goal 2) for end users to understand a low-level computer language. If javascript is going to be used, it should be used here, to hide the XML.
I'm not judging ez systems business model, but from usability point of view something like the online editor shouldn't be optional.
The procedure described for adding/relating objects to a current object is a nice example of how to create an easy to use interface: the software makes it easy for you by automating predictable steps. (goal 2)
<b>Some general remarks on features in the main area:</b>
- Be sure extra features can be found (goal 3). Intuitive also means predictable. If the interface doesn't make it clear how the pop-up menu can be activated, it should also be possible to access the menu items in some other way.
- Use human language. Most people don't see pages, images, sounds as being objects. If UML language can be avoided, it should be. If an object happens to be a page, just call it 'a page'. Imagine what a user thinks when he/she sees this: http://ez.no/i_dont_exist Kernel error? Module not found? Siteaccess name?
Please don't get scared by this lengthy, critical, reply. :-) I think the administration interface proposal written by ez systems is a big improvement over to current one. But still, there a lot of room for improvement left. Hopefully my comments will help ezp filling this gap.
Feel free to ask if I need to clarify some things.
|
