...
Those basic characteristics of a user have a direct impact on the importance certain usability aspects. As you'll see in more detail in the next post there are seven important usability principles, namely suitability for learning, self descriptiveness, error tolerance, conformity with user expectations, suitability for the task, controllability and suitable for individualisation. As the table below depicts, the application domain knowledge for instance has a strong impact on the suitability for learning. For a layman user it is important that he get's enough help information at hands to be able to quickly work with the system. On the other hand for a user that frequently works with a system it is more important to allow him to customize the user interface, e.g. to setup keyboard shortcuts for oftenly used commands. For the Magnolia AdminCentral application both applies equally, the target audience of the Magnolia CMS ranges from sporadic users to frequent users and from laymen to experts. However, for some features it is more important to keep them primarily simple, for other features it is more important to design them as powerful as possible. ThereforTherefore, in future posts I will point to the users characteristics given above whenever I explain a new feature or an enhancement for an existing one.
| Wiki Markup |
|---|
\[table basic characteristics matrix\] |
User Profiles And Personas
...
Following, we will discuss the most relevant user profiles in more detail. Additionally I will present a persona for each profile accordingly. A persona is a kind of portfolio of a concrete but fictitious person that represents a specific profile. Personas are simple to remember and the described characters ("stereotypes") shall be easy to identify with. You, as a developer, can print them, pin them on your board and you'll (hopefully) remember them whenever you take any design related decision.
Detailed User Profiles of the Magnolia CMS
Editors
First, let's start with the editor role. The majority of users of Magnolia probably are editors. On the one hand, if you have a big enterprise you'll implement the website at the beginning in a small group of developers and with a few administrators involved. Then you'll hire people to initially create a lot of pages and their content and this content has to be maintained over time. On the other hand, if you have a small business only, you won't have any developers at all and let the website implement some third party but you want - and this is in fact the reason why content management systems exist - create and edit your pages yourself. Thus, a CMS enables basically everyone being an author for his own website. And everyone implies that there might be experienced users but also laymen regarding web software and content management.
Typical tasks of an editor are:
- creating and editing content and pages
- organizing content (uploading, moving, re-structuring, etc.)
The scope of the editor's tasks ranges from working with the website repository, the document repository and propably the data module in Magnolia. But an editor will neither be concerned with the configuration of the site nor with any security or deployment setting (let's say this is out-of-scope).
Since there might be very different kinds of editors it makes sense to identify two important stereotypes (profiles) of editors.
Profile: Editor - Inexperienced, Sporadically Working With Magnolia
First, there are editors that are laymen with very little experience in working with websites or web based systems in general.
For the inexperienced editor typical characteristics of web software might be quite new and confusing at the beginning (and this, of course, not only applies to content management systems only). Some examples include:
- server delay and longer response times: application feedback oftenly does not appear immediately; "simple" operations (e.g. renaming a node) take longer as if they were performed locally
- web software is very different to desktop software: the keyboard behavior is different (e.g. you have no tabs); no undo; assets have to be uploaded before they can be used (it's not just drag and drop as in desktop software)
- web software is distributed: different users might work on the same thing concurrently; the user has not his own workspace (like "My Documents") but shares all his work with others; on the web users work within sessions, loosing a session due to a time-out or simple due to hitting the "back"-button without having saved the state explicitely oftenly means loosing changes (typically something that users learn quickly)
For experienced users these are quite usual issues with web software and normally we don't mind about them at all anymore. However, most of them are pretty much annoying for a beginner resulting in frustration and at the end rejection of the software.
Further, consider the inexperienced user does not use Magnolia regularily. Instead his usage frequency of the software is sporadic. This applies, for instance, if the user is not a dedicated person for maintaining the website in a medium sized company but only has to change some little piece of the website from time to time.
Mostly, those kind of editors only work with basic features of Magnolia, their usage intensity of the software is facile. For them it would be helpful if the GUI would not overcharge themself with all its functionality at once but instead presents its features as clear and simple as possible (hiding the advanced and complex tools).
Last but not least, the application domain knowledge of users conforming to this profile is comparable to one of a layman. That means, that although those people understand what a web page is, they don't know the relationships between some fundamental aspects of a CMS much. Especially this applies to the vocabulary used in content management systems. Non-technical people don't know what a "repository" is or what a "virtual URI" is all about. However, nowadays terms like "link", "page" or "address" are familiar to all of them.
As depicted with the table above, these characteristics lead to special requirements regarding usability. However, let me explain those consequences along with the usability principles in detail in a later post.
TODO Persona
Profile: Editor - Advanced, Frequently Working With Magnolia
There are also quite a lot - if not the most - advanced editors working with Magnolia. They are also more experienced with the characteristics of web based software systems, like content management systems or blogs etc.
Those advanced authors use Magnolia very frequently. E.g. imagine an author that regularily writes articles for an online magazine or a dedicated person in a company whose daily job it is to author a companies or departments website. They have oftenly recurring tasks and typically have to manage or organize a big amount of data simultaneously. Thus, from time to time they will not only use the basic editing capabilities of Magnolia but will also request advanced features and complex tools that allow them performing their tasks easier and more efficient. Their usage intensity therefore is - at least with regard to the authoring tools of Magnolia - very intensive.
Further, compared to the relatively inexperienced author described above, the advanced editor is more of an expert regarding the application domain knowledge. The longer he works with the system the more familiar he becomes with the application domain. That is, he more and more understands the domain model behind the CMS and thus also better understands the vocabulary of that domain.
TODO Persona