From Mahara Wiki
< Proposals | Done(Redirected from Developer Area/Specifications in Development/Done/Usability)
The ideas gathered on this page have been implemented one way or another in Mahara over the years since they were written down.
Mahara is quite usable, but our goal is to have Mahara be extremely easy to use, even for people who have not had much experience with computers and the internet. Here is a list of improvements we can make to streamline the system:
The current system of tabs has a couple of problems:
- It doesn't scale to many more items than we have now
- It isn't very suited to task based navigation, currently it's based around Mahara's plugin structure
Pull-down Menus, on the other hand, do not have these problems (particularly the first one). We'd like to implement some form of pull-down menu system, and while we're at it, change from entries we have currently in the main menu to some more task-based menus.
Ray Merrill has suggested having three main menus in which to place items, loosely titled: "My Stuff", "Other People's Stuff" and "Sharing". This gives a task based approach, where we place items in the menus according to what people will be thinking when told to complete a task. For example, editing their profile page could appear under "Sharing", as it's all about sharing their information.
Along with redesigning the main navigation, horizontal navigation can provide a great usability boost by anticipating what actions a user might have intended to do when they visit a page.
For example, editing your profile and editing your profile View are two different pages. One is a form where you fill out basic information, while the other involves the View editor. However, a user may visit one, hoping to do the other.
In this case, horizontal navigation could provide a "Did you mean to?" sideblock, which has links off to other things the user might have been intending to do.
"View" and "Artefact" are fine terms to describe the system architecture - although the concept of things needing to be artefacts before they can be placed in a View is by now a long incorrect one. The problem actually arises in the UI, where it's hard to explain to a lay person what a "View" actually is. The word "artefact" also causes confusion. Most users couldn't care less that they're creating artefacts and can put them in Views - but they'll understand that they can create "stuff"/"information", and put it in "web pages".
We still need to discuss the best terms for this.
Icons for System Entities
The idea here is to display a 'group' icon next to group names, a staff icon next to staff members, etc. This helps reinforce the user's sense of what they're looking at, and in the case of users, point out exactly who has what role - most useful if the user is among strangers.
View Interface Improvements
The View interface as it stands isn't too bad usability wise (terminology notwithstanding), but there are still several things we could do to improve it:
- Some kind of evidence of task progression, as you proceed through the View Creation process. This is a "step 1 of 3" type arrangement. Ray Merrill has previously mocked up a couple of examples of how this could look. It might be worth thinking about whether this makes sense as three separate pages requiring a wizard - possibly, doing it as a three-tabbed screen could provide another alternative?
- Review of blocktype configuration. In Mahara 1.1, we changed the configuration of blocktypes to open up a modal window, rather than trying to display the form within the column. This means we have a lot more room to play with, so it is worth having a review of the configuration forms to see if they can be made simpler. As part of work going into Mahara 1.2, we are going to be using this feature to make it easier to browse files/folders using a tree browser.
There's a few issues with the Administration section as it stands right now.
One is that the Site Options form is growing longer and longer, with all sorts of options in it, with no real focus. If a user wants to change one of the settings, it's not logically grouped anywhere making it harder to find.
Another is that while plugins can provide configuration forms, to get to them you have to go hunting under Manage Extensions. Again, it can be hard to find a single setting, such as how to change the default quota for a user.
While the top level of the administration menu provides some task-based navigation, perhaps we should review exactly where each setting should go. It might be necessary to create new screens or wizards to make changing settings easier.