Outline:

Intro
- article explains user roles working with the Magnolia Admin Central
- scope of this article: interface design trail, analysis
- motivation for this article
  - users have different expectations, requirements and skills: "simple-to-use" vs. "available advanced configuration options"
  - the GUI should address those expectations accordingly, rating the realized features by the most important requirements of the appropriate user
- outcome/goal of this article
  - the developers need to keep the user group and their skills in mind when designing and implementing a feature; this article should sensiblize the developer for the users' characteristics ("know the user")
  - definitive personas are developed to remember user roles
User Roles And Their Characteristics
- the four roles: editor, manager, administrator, developer
- basic characteristics: the user-roles matrix
  - factors: usage intensity, usage frequency, application domain knowledge
    - "(side) note"/excursion: the 7 principles of interaction design => pointer to next article
    - relationship to basic principles of interaction design
  - note that usage frequency of course depends on update frequency of web content (up-to-dateness of web site)
  - application domain knowledge: actually separate two different things: knowledge about Magnolia (CMSs) and company/commercial websites
Details about each role
- "(side) note"/excursion: personas; about personas in general: should be a (relatively) simple to remember conclusion; "simple to identify with"
- the editor/author role
  - typical tasks of this user-role
    - creating and editing pages/contents
    - organizing content (uploading, moving etc.)
    - scope: website, documents, data
    - not concerning about configuration, security, deployment etc.
- differentiate two different scenarios: call them "editor" (sporadic) and "author" (regularily)
  - the role ultimately depends on size of company using Magnolia and business goal of website (e.g. a news site's editor frequently uses Magnolia, however a secretary of a little 10 people non-IT-company doesn't)
  - explain the basic characteristics
    - "editor": layman, little experience;
      - layman in developing websites (programming, technical details about the web)
      - little experience in using web-based software especially web content management systems (web based systems have their characteristics, e.g. server delay/response times; no desktop software regarding e.g. keyboard behavior, you have to "upload" stuff, no tabs available etc.; normally not concerned with distributed, concurrent working)
      - usage intensity: low
        
        only make use of Magnolia's basic editing capabilities
      - usage frequency: sporadically
        
        not dedicated person in a small company/department; website where content doesn't change much
      - application domain knowledge****** company website: substantial knowledge of pages and their contents at least of the departments part of the site, since daily working with/communicating it
        
        CMS (e.g. knowledge about the range of the CMS' feature-set): none, e.g. virtual URIs etc. likely won't be a word in the editors's vocabulary; whereas basic web vocabularies like "link" are
      - relationship to 7 principles: self-descriptiveness, expectation conformance, failure tolerance, learning support
      - persona: "Edward, the EDitor"
    - "author": medium experience
      - usage frequency: high
        
        oftenly dedicated person in a company/department/team; this is the case when web content updates frequently, e.g. an author of a news site
        
        creates/edits a large amount of content
      - usage intensity: medium/high
        
        uses Magnolia's editing features only, however, those intensively
      - application domain knowledge****** company website: substantial knowledge of a certain set of pages and their contents (e.g. the departments part of the site) since he is daily working with it/communicating it
        
        CMS: knows editing capabilites only, however those intensively
      - persona: "Antony 'Tony' the author"
- the manager role
  - role comes up for its own only in bigger companies or at least companies with many editors (such as news sites with many authors)
  - explain the basic characteristic
    - usage intensity: medium experience;
      - normally, managers have been shifted from some degree, thus it's very likely that they have been working as editors before for a longer time. Thus they a
  - persona: "Mark the MAnager"
- the administrator role
  - persona: "Andy the ADmin"
- the developer role
  - persona: "Daniel the DEveloper"

What's next?
- next article(s) will discuss principles of interaction design and their consequences as well as general usability and business goals
- invitation to the developers: print the personas and never forget them

Serving Different Users Needs: Magnolia GenUIne's User Profiles Explained

Following the introductive article about the interaction design trail of the Magnolia GenUIne development project, I want to continue with the analysis and discuss different "profiles" of users working with the new Magnolia 4.0 AdminCentral. I will present different so called "personas", each of them outlining a specific group of users with special characteristics. To know, understand and remember those characteristics are a key factor when discussing and rating further design decisions regarding various usability aspects. The purpose of this article is mainly to sensitize the developers of what they have to keep in mind when implementing the new interface.

There are quite different people working with Magnolia: some of them use it every day as developers, others only sporadically access Magnolia when updating some content on the website. Those users have pretty much different expectations to the sofware, different requirements and different skills in working with Magnolia. For instance, an editor who is 0working with Magnolia for the first time won't benefit much from strong customizability options of the interface but instead would appreciate a clean, simple-to-use interface and additionally providing little help information. This in turn is not of primary interest for an advanced developer working with Magnolia for a long time. He instead, would like to access advanced configuration options of Magnolia with only a few mouse-clicks fast and efficient. But there is also the administrator, who might not work with Magnolia oftenly but requires effective and reliable features for non-trivial tasks like setting up security configurations.

As a human-usable software, Magnolia should try address those expectations accordingly, taking care that the most important requirements of a specific type of user are met. Thus the goal of this article is to provide a common understanding of the target users' skills and characteristics (as well as a common vocabulary) for developers and decision-makers so that, in the end, the users expectations drive any user interface related decision. Realizing this is part of the so called user-centered design process. A strongly user-centered design approach leads to a much better quality of the software regarding usability aspects. This is why usability experts claim: "know the user"!

User Profiles: User Roles And Their Characteristics

User Roles

The few examples given above already showed that there are users with different roles. Basically, for the Magnolia AdminCentral application I want to distinguish four different roles: editor, publisher, administrator and developer. We will discuss those roles later in this article but let me quickly provide an overview of them:

Editor/Author:
An editor is someone creating and managing content on a webpage. An editor might also be responsible for creating new pages, thus maintaining the structure of a customer's website (or at least part of it, e.g. the part of the website belonging to the editor's department).
Publisher/Manager:
A publisher is someone that is responsible for reviewing and approving content provided by authors before it becomes public. I'd like to refer to them also as "(information) manager" because those people sometimes are also responsible for maintaining the global structure of a website, that is e.g. cross-department pages or the general site structure. However, even though managers might be concerned with structure, the do not create content themself (if so, we say that they slip into the role of an editor).
Administrator:
Apart from those people involved in a website development that create and manage the content and structure of a site there exist people that maintain the web business technically, people in the role of an administrator. An administrator is e.g. responsible for setting up the deployment of a website, ensuring certain security policies and taking care of the overall system's health. Administrators do not make use of any content editing feature of the CMS.
Developer:
Someone who is configuring the CMS to fit the customer's needs and who is implementing the customer's technical requirements is considered to be in the role of a developer. A developer is usually not in touch with the public stage of a website at all and uses the CMS' editing/security capabilities only for test purposes.

Of course, there might be more roles involved for large-scale companies (e.g. like a special translater role for enterprises operating in different countries with multi-lingual sites). However, I consider those as more specific roles of the basic ones and thus not explicitly mention them here.

User Characteristics

So far, you should have recognized that I only talked about a user's tasks - the "what" he's doing with the system. But there is definitely more to say about the user of a software system. For example "who" exactly or "when" and "how often" is he performing a specific tasks. These questions don't target the user's tasks but his skills and characteristics.

Especially the characteristics we're interested in from a usability point of view are:

Usage frequency:
The usage frequency indicates how often a user uses a software system. We simply distinguish between frequently (e.g. daily or two days a week) and sporadically (that is maybe periods of some weeks between system access).
Usage intensity:
The usage intensity indicates how intensively a user is using the software. A user uses a software intensively if he uses the majority of features available to perform his tasks. In contrast to those users a user works with a software only facile if he only uses the basic capabilities of a software.
Application domain knowledge:
The application domain knowlege describes the users experience with the software. A layman might have never been working with a CMS or even doesn't know that such systems exist whereas an expert user knows the application area of a CMS well since he has been in touch with those systems for a long time.

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. Therefore, 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.

[table basic characteristics matrix]

User Profiles And Personas

If we combine the basic characteristics from the last section with the roles of users working with Magnolia which we discussed before we get something that I refer to as user profiles. For example "an editor with medium application domain knowledge, that uses Magnolia frequently but only basic editing features" describes a user profile. User roles and the basic characteristics for their own are too coarse grained, but a user profile describes a specific group of users detailed enough to discuss various features from a usability point of view in a meaningful manner.

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.