User-Friendly “Implicit Modelling Support” for Content Management

agement Systems

Other sections in this chapter mostly assume a setting where the web application is developed by a person who is well-acquainted with this task, and who has some knowledge about the tech- nologies that are involved, e.g. HTTP and HTML, JavaScript, server-side solutions like J2EE or relational databases. Once the infrastructure for creating and maintaining pages is present, the website is handed over to site maintainers whose technical expertise may not be as advanced, but who are able to supply the content. The developer is only consulted again whenever the maintainers have wishes which require his help.

However, today a significant portion of smaller websites is created by a single person who is keen on providing public access to information on a certain topic, but who is not well-acquainted with (or even interested in) the technical details. A content management system enables such

Figure 4.4: Simple modelling support in a prototype web CMS: Creation of a presentation

model. [Metz06CMS, appendix B]

persons to perform all necessary steps of the design and implementation without in-depth knowl- edge of the server implementation. Since the functionality and ease of use of CMS has been increasing considerably over recent years, this type of “very inexperienced web developer” will probably become more common, so the following discussion presents some ideas for respective tool support.

Using CMS Meta Information for Implicit Generation of Models

The tool concepts which are proposed in other parts of this chapter often build upon the fact that models of the web application are available to the tools. In order to apply the same tool concepts to web authoring systems like content management systems, it would be necessary to add modelling support. Simpler systems (blogs, Wikis) hardly allow the site maintainer to change the predefined page format and navigation style, so in many cases, good usability can be achieved just by providing appropriate defaults. A CMS is more interesting: Because the maintainer has much more influence on the layout and navigation, modelling support would be more useful as the basis for automated usability evaluation and similar purposes.

At first sight, it might sound unrealistic to propose model editing support in a CMS which is intended for use by inexperienced web developers – these users cannot be expected to learn and understand the syntax and semantics of e.g. a web engineering navigation model. However, when taking a closer look at existing CMS solutions, several aspects of their functionality could already be interpreted as modelling support if the term “modelling” is loosely regarded as “spec- ifying meta information about the website or its content”. Often, the user-supplied information is sufficient to generate simple web engineering models.

Figure 4.5: The menu editor lets the user specify the site structure. This information can be used to generate a menu, but also for automated usability checks. [Metz06CMS, app. B]

For instance, in a CMS the user creates a page layout and then defines the type of information that is displayed in each area of the page (main content, navigation etc.). The result could be regarded as a simple presentation model (figure 4.4). In a similar way, the CMS’s menu editor can be viewed as an editor for an abstract specification of the site structure (figure4.5). Another example is a feature of many content management systems which are intended for the publishing of news: Published articles can be assigned to one or more content categories (such as “software” or “hardware” on a site with computer-related news). This also creates a simple model describing the pieces of content on the web page: Categories and possibly sub-categories correspond to classes of a conceptual model, the individual articles to the instances of these classes (figure4.6). These examples have one thing in common: The users are not introduced to the concept of a model and there is no additional view where a diagram representation of the model needs to be edited. Instead, the “models” are created implicitly by settings that the users make while creating the website and entering content. Thus, advantage is taken of the fact that even inexperienced users are able to think in a more abstract way, while at the same time not requiring them to learn a new diagram language to specify their abstract thoughts.

User Interface Prototype for Modelling Support in a CMS

It is possible to implement model-based accessibility and usability evaluation (sections4.2.3and 4.3.1) for a web CMS rather than a web engineering IDE. When thinking about doing so, a similar approach should probably be taken as with the examples above. The users should be able to create and edit meta information quickly and in a way which is directly linked to the concrete instance that it describes, rather than in a separate model. Instead of diagrams, a normal web

Figure 4.6: A CMS can also help with basic “conceptual modelling”, here by specifying the different types of content that should appear on the website. [Metz06CMS, appendix B]

page GUI e.g. with HTML tables and buttons is preferable, as the users are already acquainted with the respective UI concepts.

It is a challenge to create a web CMS user interface which provides easily usable and intuitive ways for its users to specify the abstract information, notify them of any usability problems and provide hints on how to solve these problems. Because the users’ knowledge about the topic of web usability varies even more than that of web developers, the UI must be suitable for absolute beginners (who may have to be guided using additional documentation or a tutorial) as well as experts (who will prefer controls which allow them to reach their goals quickly).

As part of a student project and diploma thesis on user interface concepts for content manage- ment systems [Metz06CMS], the aspect of creating easily usable controls was examined: How can quick operation of the different features be achieved while at the same time providing appro- priate feedback? With the help of an AJAX-based prototype, a number of user interface concepts were implemented and evaluated:

Figure4.4shows a layout editor which offers a simple point-and-click interface for assigning different types of content to the different parts of the page. As mentioned above, this presentation model could subsequently be used for automated checks, such as verifying that the layout con- forms to the de-facto standard on the web (navigation at the left-hand side of the screen, content in the middle, etc.).

The menu editor in figure4.5already bears some resemblance to a modelling tool, except that its editing functionality is limited to very simple, tree-shaped, directed navigation graphs. While these graphs are not sufficient to describe the intended navigation patterns of site visitors like a real web engineering solution’s model, they are still useful for automated usability tool support –

Figure 4.7: The prototype integrates design, implementation and testing in a single user

interface. [Metz06CMS, appendix B]

for example, similar to the check for a de-facto default page layout above, a check for commonly expected menu entries such as “About this site” or “Contact” could be implemented.

Figure 4.6 shows the prototype’s approach (called “components”) to make users supply in- formation about the content they add to pages: Before the content itself can be entered, different types of content must be defined (e.g. “article”, “comment”). The presentational aspects of each type of content (placement on the page, CSS style elements) are specified alongside the defini- tion. Because of this fact, the users will not object to the additional work of creating component types – the reason behind the abstraction and its utility are obvious. At the same time, the CMS is given valuable information which supplements the implicit presentation model. Furthermore, the components and their instances are a basic conceptual model, as they describe the different entities the website deals with. While the current prototype does not offer support for inheri- tance (i.e. basing one component class on another), such a feature would make sense for a more advanced version of the program.

Finally, figure 4.7 illustrates how implementation work, specifying abstract properties and model-based usability checks could be integrated: When the users add new content to the site, they are asked to provide further metadata about the content. In the screenshot, only a category must be assigned, but other properties such as the intended audience are imaginable. While the content is entered, warning messages are displayed about any accessibility or usability problems – here, an automatic check has revealed that a URL entered by the user is not valid. One effect of this approach is that it is very easy for users to switch between “modelling” (i.e., providing meta information), implementation (entering text) and testing (feedback from a usability validator) – a desirable feature because less experienced users may not be interested in rigorously following a predefined development method with separated design and implementation phases.

Evaluation

In a small evaluation of the concepts [Metz06CMS, section 4.2.4], five test users (four users with a technical background, one without any interest in the technology) were asked to create the structure of a website with the prototype system in a series of tasks. They were asked to think aloud, i.e. to comment on what they were doing and any problems they were having. In general, even inexperienced users were able to use the system. However, the non-technical user initially had problems understanding the abstract concept of “components” and did not see the necessity of defining types of content before entering the content itself. Further improvements to the UI may be necessary to address this – for example, the solution may be as simple as providing a few common default components, so the user does not have to define his own as the first step when using the system. The various other features of the prototype UI (immediate feedback due to AJAX interface, edit-in-place of data, concepts for simultaneous use by several users) were used by the test participants without major problems. All of them were able to complete the assigned tasks.