The GenUIne Development Approach - Part 1

July 15, 2008

My previous article covered the motivation behind the new graphical user interface that will ship with Magnolia 4.0, called GenUIne. I will now take a look at the development process which is separated into two different trails, namely the “interface design” trail and the “technical trail”. In this post, I will explain the interface design trail of GenUIne that focuses on usability enhancements. The next post will shed a light on the technical trail and how technological enhancements are going to be implemented.

In general the interface design trail covers the analysis, concept and design of the visual part of the user interface and user interaction aspects. The outcome of the work done in the interface design trail is constantly mapped to technical concepts. Thus, the technical trail covers implementation related aspects, prospects and limitations.

The Interface Design Trail

Subjects of the interface trail are usability goals, design drafts and interaction models of GenUIne. Thus it covers the part of the GUI that the user will observe, indeed a very important one.

First of all, the interface design trail itself is separated in different phases: analysis, concept, design & prototyping, evaluation and finally implementation. Of course, the Magnolia team will not drive those phases sequentially but instead this is an iterative process which – in the end – should result in a concrete specification that Magnolia developers can use to implement all required features. With this procedure, Magnolia ensures that all usability-related aspects finally find their way into the code and are not lost somewhere in the designers' or developers' minds. Let’s take a quick look at each phase next.

Analysis

To find out what actually is “wrong” with the current Magnolia GUI requires a comprehensive analysis.

First, we dealt with the question “What is the good stuff in the current GUI?” and tried to figure out the important points (I’d like to call them “metaphors”) that made up Magnolia’s simplicity and its outstanding easy learning curve for the end user. We discussed which kind of user sits in front of the Magnolia GUI and what is the user trying to achieve? Then we picked up general usability principles and applied those ergonomic aspects to the current Magnolia GUI resulting in definitive checklists that the Magnolia team will later use to verify if it met usability goals. Furthermore, we thought about environmental conditions that influence the Magnolia GUI and even compared Magnolia (positioned as a browser-based client application) in a broader scope with normal desktop clients and rich web clients.

The complete discussion of this analysis goes beyond the scope of this article, thus I postpone this subject to be discussed in one of my next posts. For those of you who can’t wait, please refer to the GenUIne analysis page in the Magnolia Wiki. This page outlines the outcome of the analysis, however in a plain – not that “user friendly” - list.

Concept

The analysis phase resulted in list of aspects that have to be taken into account when designing the user interface. However, most of those aspects are formulated quite general (which is natural since they come into play in many different ways in the GUI). Therefore the concept phase covers all the functionality, features and the interactions that describe the final application.

More specifically, the concrete topics that we discussed (and still do so) during the concept phase are:

• Data Model: Each user interface has an underlying data model which is presented to the user through application dialogs and user interface components or controls. For the user it is – even if the user himself is not aware of that fact – extremely important to understand the underlying application structure. This helps him to learn how the system works and how to perform tasks efficiently. The better a user interface of an application maps the data model to visual components, the better a user can work with that application. But of course, a meaningful mapping requires a well-defined and consistent data model being available which is why we describe this model during the concept phase again.
• Metaphors and Basic Concepts: During the analysis of the current system we identified basic concepts that are fundamental to the “Magnolia way of doing content management”. For instance, the AdminCentral metaphor: The Magnolia administration interface is a single point of entry to the complete website management. As we want to keep those important concepts we specify them in the concept again.
• Features: During system analysis, we realized that not only re-working current features could help improving overall usability, but also new features. This section of the concept discusses over 30 new features which might sooner or later find their way into Magnolia. These features range from apparently small things like “Tooltips” or “Keyboard Support” to extensive features like “Editing in Multiple Modes” (most of them will be discussed in future blog posts I’ll write).
• Components & Controls: Actually part of the features list, I want to mention them here explicitly: user interface components and controls are the main building blocks of a user interface. Each feature of an application can only be accessed if the visual components work well and support an efficient interaction with the user. That’s why this section of the concept covers all the functionality that each component has to provide (and which either the underlying GUI component technology offers or has to be implemented by us). For instance, one functionality we want to provide across all structural components like List, Tree or Grid(-tree) is “Mouse-Wheel Support”. But again, all those aspects are covered in more detail in a future post.
• Interaction: Another extremely important discipline of user interface design is the specification of user interactions. In conventional software development processes this is covered by use cases in the analysis phase. Interaction design indeed is deeply related to use cases. However, interaction scenarios describe tasks that the user performs from a GUI perspective (and doing that much more detailed). For example, consider the interaction “Creating Content”: roughly said, the user hits a “New” button, puts in some data, hits the “Save” button, waits for the data being stored and re-checks if the outcome corresponds to what he expected. From a software engineering point of view, no one would explicitly state that between hitting “Save” and doing the next task a progress should pop up to indicate that the system is currently performing a save operation. However, the interaction scenario does. As you can imagine there are a lot of interaction scenarios within Magnolia and I will discuss the most important ones in more detail in different posts.

Again, for those who want to take a quick look, refer to the concept page (and its sub-pages) in the Magnolia Wiki. But be warned, it’s again a plain list, even though structured nicely

The final outcome of the conceptual phase is the specification which finally decides what (and how) features are implemented in the new Magnolia GUI.

Design & Prototyping

What counts in the end is if all the concepts really work – technically and visually. The design phase therefore covers the visual part, the look & feel of GenUIne. This starts with early prototypes and mocks on paper and ends with real-looking (but non operational) screenshots with which we test colors, fonts and icon styles. Things decided in this phase are finally stored in the Magnolia Style Guide and will be mapped to the skin of the user interface components alike.

From time to time you will see different aspects or full previews when we discuss the different features. However, the design is still pretty much to be considered as “work in progress”. There is an appropriate design page on the Magnolia Wiki (but unfortunately not up-to-date right now).

Evaluation and Implementation

For completeness sake, I mention the remaining phases: the evaluation, specification and implementation phase. Well, evaluation will be achieved mainly by thoroughly incorporating feedback from Magnolia users (which is therefor pretty much welcome!), through expert evaluation and constant review. The implementation is part of the technological trail.

What’s Next?

While future articles will – until the technological part gets more concrete – primarily focus on the interface design trail, part 2 of this article will introduce the technical trail in the next post as well. Then we will start with an in-depth look into the analysis and continue by discussing different concepts and features of GenUIne.

« Developing GenUIne,... | Main | The GenUIne Developm... »