...

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

Following the introductive introductory article about the interaction interactive design trail process 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 describing a specific group of users with special unique characteristics. To know, In order to discuss and evaluate further design aspects, particularly usability, it is important to understand and remember those characteristics are a key factor when discussing and rating further design decisions regarding various usability aspects. The the characteristics of these different "personas". The main purpose of this article is mainly to sensitize the inform developers of what they have need to keep in mind when implementing the new Magnolia 4.0 AdminCentral interface.

There are quite different people working with Magnolia : some of them use it every day as developers, in very different roles. Some use Magnolia daily as developers while others only sporadically access Magnolia when they are actively updating some content on the their website. Those These different users have pretty much very different performance expectations to the sofware, different requirements and different skills and requirements for the software. Additionally, different users have very different skill-levels in working with Magnolia.

For instance, an editor who is 0working a web content editor working with Magnolia for the first time won't will not benefit much from strong customizability from the robust and flexible customization options of the interface but instead would Magnolia interface. The web content editor would instead 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 and intuitively simple user interface that provides useful "help" information for the level at which he or she is using the software.  

These end-user level features of simplicity, ease of use and readily available user help are not of much use for an advanced developer who may want to access advanced configuration options of for Magnolia with only a few mouse-clicks fast and efficient. But there is also the administrator, who might in an efficient and rapid way. 

In addition to these two example users, there may also be an administrator who may not work with Magnolia oftenly but requires often but when he does, he must have effective and reliable features, tools and functionality for non-trivial tasks like setting up such as setting, maintaining and changing security configurations.

As a humanuser-usable centric software, Magnolia should try to address those these differing expectations accordinglysimultaneously, taking care ensuring that the most important requirements of a specific type of user critical core requirements for each user type are met. Thus the goal of this This article is intended to provide a common understanding clear categorization of the target users' skills and characteristics (as well as , thereby creating a common vocabulary ) for developers and decision-makers so that , in the end, the users expectations these user needs and expectations can drive any ongoing user interface related decisiondecisions. Realizing this This goal is part of the so called the overall Magnolia design philosophy, that is, the "user-centered design process. A strongly user-centered design ". This approach leads to a much better higher quality of the software regarding usability aspects. This is why usability experts claim: "know the user"!software with flexibility and intuitive usability that facilitates ease of use and also avoids potential future confusion as this project progresses.

The phrase for developers and decision-makers to remember in this process is to "Know the User"! 

User Profiles: User Roles And Their Characteristics

User Roles

The few examples given above already showed described 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 these roles in more detail 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 webpageweb page. 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 they do not create content themself (if so, we say that they slip into the role of an editor)themselves, and if they do, they are essentially performing in the role of Editor/Author rather than that of Publisher/Manager.
• Administrator:
  Apart from those people involved in a website development that create and manage the These are the people who are generally separate from the website development and content and structure side of a site there exist people that . The people in this role maintain the web business technically, . These people in are performing the role of an administrator. An administrator is e.g. responsible for setting up administrators. Administrators may be responsible for the deployment of a website, ensuring certain security policies and taking care of are integrated and maintained and that the overall web system is maintained according to the specific organization's healthpolicies and needs. Administrators do not make use of any content editing feature features 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 generally not in touch concerned with the content or public stage of a website at all and uses the CMS' editing/security capabilities only for test purposes .to ensure that the functionality of what they have developed will perform consistently when it is deployed.

Large-scale companies may well have users performing different specific roles that use or interface with the Magnolia system that differs in some way from these four defined user roles. For instance, multilingual sites may have translators whose primary purpose is recreating existing content pages in a particular different language, requiring them to perform some of the functions of the Editor/Author or even Publisher/Manager but with specific focus for their unique role in their organization. On the other end of the spectrum, smaller companies may have a single person who performs several of these articulated roles. In order to communicate these user roles and the vocabulary needed to continue with the user-centric development approach, I will discuss these four roles only although most readers can understand that both larger and smaller companies will be able to customize their understanding and interpretation of these roles according to the specific details of their organizationsOf 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 have 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 the user is or "when" he performs which task or tasks and "how often" is he performing performs a specific taskstask. These questions don't target the user's tasks but his skills and characteristics.

Especially the The user characteristics we 're are particularly interested in from a usability point of view the viewpoint of developing with usability as the highest goal 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 there may be a gap of a week or stretches of multiple weeks between system access instances).
• Usage intensity:
  The usage intensity indicates how intensively a user is using extensively a user applies the available functionality (tools, applications, customization) within the software. A user uses a software intensively if he uses the majority of features available to perform his tasks. In contrast to those intensive  users, a user is a facile user or works with a software only facile facilely if he only uses the basic capabilities of a the software.
• Application domain knowledge:
  The application Application domain knowlege knowledge describes the users user's experience with the software. A layman might never have never been working worked 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.have even basic knowledge of the basics of CMS systems in general. An expert user has sufficient experience with CMS systems so that he knows specific application functionality and features well and this experience has been accumulated and added to generally over a long period of time.

These basic user characteristics have Those basic characteristics of a user have a direct impact on the importance certain usability aspects of the software. 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 individualisationindividualization.

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 there is enough readily available help information so that he can rapidly and efficiently work with the system. On the other hand for For a user that frequently works with a system, it is more important to allow him to customize that the user interface , e.g. to setup can be readily customized, for instance, easily creating keyboard shortcuts for oftenly used frequently repeated commands. For the Magnolia AdminCentral application both applies equally, the target audience of the Magnolia CMS ranges user needs must be simultaneously considered and accommodated. Magnolia CMS users range from sporadic users to frequent users and from laymen to experts.

With this need for simultaneous and equal usability features in mind, some features benefit more from simplicity while other features benefit more from power and robustness of functionality than simplicity. To facilitate better discussions between developers and decision-makers 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 based on the descriptions and terms in this post whenever I explain a new feature or an enhancement for an existing one.unmigrated-wiki-markup

\[DEV: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 earlier, these combine to creat a concept 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 are broadly defined while a user profile describes a specific group of users detailed in enough detail to discuss various features from a usability point of view in a meaningful manner.

Following, we We will discuss the most relevant user profiles in more detail in the next section. Additionally I will present a persona for each profile accordinglyeach profile, building on the descriptions and vocabulary established earlier in this post.A persona is a kind group of descriptive characteristics or portfolio of a concrete but fictitious person that represents a specific profile. Personas are simple to remember and the described characters ("stereotypes") shall should be easy to identify withunderstand. 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.

...

First, let's start with the editor role. The majority of users of Magnolia are 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 For large enterprises, websites are generally implemented with a relatively small group of developers and administrators. After implementation, other users are introduced to create web content which is added to, altered and maintained over time.

Small operations may have no developers at all and have their websites implemented by third party contractors. This second option is the primary reason that content management systems (CMS) exist: so that organizations can create and edit pages themselves without requiring extensive development expertise.
Thus, a CMS enables most users to be authors for their own websites. This implies that there might be expert developer/users but also laymen with little experience in regard to web software and content management.

Typical tasks of for 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, working with the document repository and propably probably working with the data module in Magnolia. But an 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 for the editor role).

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 These are editors that who 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 of common events that may be new and confusing for this type of editor include:

• server delay and longer response times: application feedback oftenly frequently does not appear immediately; "simple" operations (e.g. renaming a node) take longer as than if they were performed locally
• web software is very different to from 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 does not have his own workspace (like "My Documents") but shares all his work with others; on the web users work within sessions, loosing a session .
• Work performed within a session may be lost due to a time-out or simple due to performing a common user error such as hitting the "back"-button without having saved the state explicitely oftenly means loosing changes (typically something that users learn quickly)work explicitly and often. This can result in frustration from losing changes, although this is a problem that even inexperienced users typically learn to avoid quickly.

For experienced users, these issues are quite usual issues common with web software and normally we don't mind about them at all they may be so "normal" that experienced users do not even notice them  particularly anymore. However, most of them are pretty much annoying for a beginner resulting in frustration and at the end rejection of the software., any of these issues can be so frustrating as to lead to the user rejecting the software simply because they lack the understanding and experience that allows them to overcome these common challenges.

Additionally, inexperienced users in this category generally do not use Magnolia with much regularityFurther, 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 this type of editors editor only work works 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 provide them with excessive unwanted information about the software functionality at once but instead presents presented its features as clear clearly and simple simply as possible (, perhaps by hiding the advanced or complex tools rather than presenting them side-by-side with the commonly used tools for this type of user.

Finally 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 understand some fundamental aspects of a CMS and the relationships between CMS muchcomponents. Especially this This particularly  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 although it is likely that terms like "link", "page" or "address" are familiar to all of themthe vast majority of users.

As depicted with the table above, these user characteristics lead correspond to special unique requirements regarding usability. However, let me explain those consequences along with the I will explain the potential consequences of accomodating this type of user's need for usability along with more general 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 In addition to the inexperienced editor, many Magnolia users are advanced editors quite familiar with Magnolia, with CMS functionality and Web applications in general. These users also tend to be more experienced with the characteristics of web based software systems, like including content management systems or and blogs etc.

Those advanced These editors/authors use Magnolia very frequently. E.g. imagine an author that regularily A typical user of this category is an author/editor who regularly writes articles for an online magazine or . Alternatively, this may be a dedicated person in a company whose daily job it is to author a companies or departments website. They have oftenly develop, maintain and post a company's or department's website. These users have frequently recurring tasks and typically have to manage or organize a big large amount of data simultaneously. Thus, from time to time they these users will not only use the basic editing capabilities of Magnolia but will also request advanced features and complex tools that allow them performing to perform their tasks easier more easily and more efficientefficiently. Their usage intensity therefore is - at least with regard to the authoring tools of Magnolia - is very intensive.

Further, compared 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 increasingly understands the domain model behind the CMS and thus also better understands the vocabulary of that domain.

...