Similar actions should be performed in the same way under the same circumstances; at the same time, different actions should be made explicitly so by means of visual inconsistency. Examples of this principle in action might include ensuring that annotations of all types—e.g. editorial notes, textual notes, interpretative notes—appear in the same location when selected by the reader; conversely, links to other kinds of textual apparatus must be clearly distinguished.

Type and size of characters, as well as choice of foreground/background colors, should make text legible even for visual-impaired users. In addition to the simple question of font, designers should keep in mind the ability to distinguish between different layers of text (e.g. different levels of headers vs. the main text). As uses begin to access DEs using multiple platforms, designers should also be careful about being overly prescriptive: font faces and weights that work well on one platform (e.g. a wide screen monitor or printer) may not work well on another (e.g. a small monitor or tablet).

Users should not be forced to learn what tools, icons, or symbols mean or do. The purpose of every aspect of the interface should be immediately recognizable in the context in which they are made available.

The most important actions and options should always be visible and near at hand, secondary actions and invisible structures should be easily discoverable by the user. Users should not need to access secondary menus or pages in order to perform key functions in their work with the DE. It should be easy for users to discover secondary or "advanced" features. A good example of this is in the case of a search menu: users should be able to conduct basic searches by typing directly in the search form, rather than by selecting "basic search" first; the action required to access "advanced" search capabilities, however, should also be immediately obvious from the "basic" form.

The user should feel in control of the working environment and should not be forced to learn complicate sequences of steps. Instead designers should provide visible and up to date status information, as well as easy error-handling, and allow reversal of actions. Errors should always be reported in meaningful terms to the user and the user should always know—via icons or time bars or similar indicators—when the processor is responding to user input.

Moving between different "areas" of an application should be an easy process for the user, who shouldn't be forced to learn complicated mental maps; furthermore, the UI should be fully explorable without intimidating the user or risking that the user lose his or her way.

The UI should be designed to maximize efficiency and ease of use. In particular, designers should pay attention to the location of important tools and utilities. Navigation links and buttons should be in a consistent location and designed to reduce the need to move the pointing device across the screen. Search bars and other tools should be located where they can be accessed with a minimum of movement or scrolling.

A good UI should be able to take advantage of advanced system resources (wide screen, fast CPU to allow better responsiveness), but should also prove usable in a low resource environment. Designers should be aware of the different types of devices users will use to access their work and preferably present users different options for access via major types of platform. This can be as simple as supplying different stylesheets for printing and on-screen browsing or as complex as building distinct apps for access via various common tablet platforms.

DEs, more than other texts, often make very heavy use of hyper-textual functionality. Individual words and objects in a DE, for example, commonly have more than one obvious target—e.g. a gloss, alternate readings, editorial notes, links to specific regions on an associated image. This presents real challenges for the designer who wishes to ensure qualities like discoverability, recognition rather than recall, and consistency in their GUI.

Many editions, particularly of historical texts or of works in languages other than English, make heavy use of "special" characters, including possibly reference to characters not found in standard OS fonts or even characters not included in standard Unicode. Designers of DEs in such cases need to pay careful attention to questions of scalability and control. How can "unusual" Unicode characters be accessed by users? To what extent can private-use code points be avoided? When characters are not found in standard Unicode, are there disciplinary conventions in the use of private-use code points? Are alternative methods of presenting extremely unusual characters or scripts possible?

Users of DEs often need to manipulate images. At the most basic level this might involve finding specific locations in a given image, magnifying select portions of an image, and navigating across an image that has been magnified to the point that it is larger than the available presentation medium (e.g. page, screen, etc.). More advanced uses might include manipulating and filtering image data in order for purposes of analysis (e.g. altering colour profiles or contrast for specific research purposes). In satisfying these needs, designers of DEs need to consider questions of ergonomics, scalability, control, recognition and discoverability as well as questions of cost vs. benefit for the design of custom tools and issues on intellectual property rights regarding the images they use. One solution is to include basic manipulation tools as part of the GUI and, where IP agreement permit, allowing users direct access to high quality image files for use with standalone image manipulation tools.

Users of DEs often have need for advanced search functionalities. Especially when the underlying text is encoded in eXtensible Markup Language (XML), advanced search tools should include options allowing the user to take advantage of this rich markup.

Critical editions (whether digital or in print) are densely organised, information rich environments. In the DE, designers need to consider how users will be able to discover and access a wide range of supplementary tools including glossaries, concordances, appendices, archives of ancillary material or primary and secondary sources. Additional questions include whether it makes sense to replicate traditional print models in the design and integration of these tools into the digital environment. Should a DE contain an analytic index or is full-text indexing sufficient? Should links among witnesses be presented as a traditional textual apparatus? How should glossary or bibliographic information be presented and linked to relevant forms in the text and analytic material? Decisions in this area will have a great impact on control, discoverability, recognition, and ergonomics.

Legibility of text and icons impacts on Readability and Ergonomics. It is one of the most basic requisites, and it is therefore surprising to see that some editions have problems in this respect. In the initial window of the (Figure 1), for instance, the selected section of the navigation tree in the left frame is highlighted in a way that makes it almost unreadable. Also, and more important, note the small size of the edition text: the software used for this DE doesn't allow users to increase the text size, but doing this would greatly improve its readability (Solopova 2000).

The Bayeux Tapestry edition (Foys 2003)shares this problem of small text size (Figure 2). Furthermore, a very important element of the GUI, the navigation cursor, is not as immediately visible as it should be both because of its dimensions and because the color chosen (light orange) makes it difficult to distinguish from the background image.

Apart from the problems detailed above, these and many other otherwise excellent editions suffer from a problem of scalability: a good GUI should automatically adjust to take advantage of "better" hardware and software, and not force users to live with the lowest common technological denominator available at the time the DE was built. This way the edition can be scaled to work with future, inevitably higher resolution and often larger screens (and in recent years, of course, smaller and more mobile ones). Designers should take care to test their edition does not break when scaled using text-zooming capabilities found in most major browsers. Since such adjustments often treat different components of the GUI differently (e.g. scaling character size in text menus, but not objects such as images), the problem can't be considered fully solved if the GUI relies on absolutely determined font sizes or makes extensive use of images to carry text labels, and so on.

When buttons are not depressed after clicking on them, or a search operation is started but there is no indication that it is still in operation, the user is puzzled and possibly confused by the software's behaviour. This affects the user's sense of control and may result in such potentially disastrous user behaviour as clicking repeatedly on a given button or link because nothing seems to happen.

A simple visual cue like an alternative image showing the button in a depressed state, an hourglass, or a completion bar in case of complex operations, would help the user feeling in control and not controlled by the browsing software.

Designers should be particularly careful about avoiding the temptation to interfere with the standard functionality of hyperlinks—e.g. by using stylesheets to eliminate the distinction between new and visited links. A useful technique is to add style cues that indicate that a hyperlink has received focus and has been selected.

In some DEs icons (image- or letter-based) and other graphical widgets are sometimes difficult to understand and operate; furthermore, they are often unaccompanied by any kind of visual help. This affects factors such as Control, Availability, Discoverability, and Ergonomics.

Information relevant to the user's task and the actions immediately available must be immediately evident, in primis through a careful choice of icons for buttons and other graphical objects; the very number of interactive objects should be limited to those of most common use, avoiding crowded toolbars as much as possible. When the nature of the action corresponding to a button is not clearly conveyed by the latter's appearance, a non-intrusive use of tool-tips should be sufficient to help the user understanding its purpose quickly.

Contemporary textual editions are almost invariably initially encoded using a rich markup language such as Text Encoding Initiative XML. The underlying encoding files are often accessible, although many editors are reluctant to allow users access to them, but in any case they should be completely transparent to the user: requiring that a user perform a search on the basis of the elements employed in the SGML/XML texts means exposing the inner workings of the edition on the assumption that the user knows about markup languages, which is not always the case, and may be intimidating to the less experienced user.

Even a simple task like exploring an image larger than the current window can be a painful experience if it has to be performed through the window's scrollbars. A much better approach to this issue of Ergonomics is to provide for a direct manipulation of the image by means of the mouse pointer.

The first Macintosh computers used a non-proportional scrollbar (Figure 5). Not only was this unwieldy, it also prevented the user from guessing how much of the image is currently visible and how much is hidden (compare this to the modern, proportional scrollbar in Figure 6, which allows the user to "sense" the image dimension).

Since most modern computer OSs make use of proportional scrollbars, this problem has long been considered largely eliminated, although even many modern OSs still often use unwieldy and ergonomically poor methods of navigating to areas of interest at high zoom levels. But it can still be a matter of concern to designers who make use of a graphical toolkit, such as some Javascript libraries, that implements non-proportional bars. Related problems of navigation may also face designers who intend to work with newer mobile platforms, many of which are still relatively poor in handling the navigation and presentation of large images.

Sometimes the navigation software shows elements of the underlying engine. This can affect Consistency and is true of both stand-alone and browser-based DEs—although the specific problems are often slightly different.

In the stand-alone EPPT software, for example, only a small subset of the menus are specifically DE-related. Clicking on the menubar often presents the user with a large number of options derived from the underlying Eclipse environment (on which the EPPT framework is based). In the edition, based on Internet Explorer, the contextual menus of the browser are still visible and accessible to the user.

This intermingling of GUI elements of different origin and purpose can be confusing to the user: the menu voices or buttons corresponding to the user's tasks could be "lost" or not immediately accessible, slowing down the edition navigation. In the case of the EPPT software some of these GUI items, specifically those related to Eclipse's IDE (Integrated Development Environment) capabilities, are useless and probably unintelligible for most users.

Navigation should be simple and consistent: editors should avoid welcoming the user with introductory and/or navigation screens crowded with too many entries and choices, instead presenting a clear and concise table of contents, and assigning to other navigation instruments content selection and visualization. Tools like drop down menus or thumbnails for image and text selection should be enough to make navigation intuitive and unobtrusive, although the designer should be careful not to steal too much space from content display. Navigation should also be predictable and consistent with user's expectations, so to minimize the chance of getting lost or selecting undesired content.

Problems in navigation usually occur when the editor makes use of different "environments" to propose different types of content. When the DE is composed of two or more different screens it is quite likely that, if navigation tools are lacking, the user may wonder "How do I get back to where I was?" The creation of a complex, multiple screen DE should be limited to those cases where it is strictly necessary, e.g. in DEs that involve mixed media that current technology cannot easily handle in a homogeneous fashion. In such cases it should include effective navigation tools so that the user can quickly build a mental map of the edition structure.

The available space is a very important resource for any type of software, all the more so for a DE browsing software: since many DE visualize manuscript images, as well as text (especially if comparing two or more texts), they need as much space as possible. This also means that, space being such an important resource, it has to be used wisely.

The most simple way to access all of the available screen space is to create a full screen application: every other component of the desktop will be temporarily hidden while using the DE browser software. This approach not only allows for optimal visualization of the edition content, but also to follow Fitts' law (see below) and to access important GUI objects (toolbar buttons, collapsible frames) with more ease than if they were used in a normal window on the desktop. The main disadvantage of this solution is that it breaks the normal work-flow of the user, making it difficult to take notes in a word processor, for example, or to alternate edition browsing with other activities. It is therefore recommended to make this an option, possibly not even the default browsing option, and to allow for an easy switch between full screen and normal window visualization.

A way to optimize space use is choosing GUI elements that are flexible and dynamic. Some of the first digital editions adopted a very rigid approach, using fixed frames to display content. Use of toolbars, menus and, most of all, frames that are easily expanded or hidden (Figure 8) allows to concentrate on the specific content that the user is currently browsing.

The user will interact with the browsing software by means of a vast assortment of graphic objects: toolbars and the buttons they host, general purpose menus, drop-down menus, sliders, and so on. It is important to handle them carefully:

A clean, well ordered GUI will make browsing the edition a much easier and more enjoyable activity.

In many of the DEs I've browsed for the purpose of writing the present article the critical apparatus is inserted in a fixed text frame placed below (or on the side of) the edition text; this is particularly frequent in web-based editions, e.g. by B. Slade (http://www.heorot.dk/); other online editions omit the critical apparatus altogether, e.g. by A. Savage, (http://www.humanities.mcmaster.ca/~beowulf/), while some of the oldest ones are little more than digital facsimiles of printed editions, e.g. by T. Romano (). While this choice is effective in presenting this essential component of any critical edition, it is actually extremely conservative, being nothing more than a faithful replica of the printed edition layout. Mimicking an editorial form largely shaped up by physical considerations means giving up the flexibility and possibilities that a digital, non-material edition offers to the scholar: it is not necessary, for instance, to impose a limit to the number of variants reported, and it is likewise possible to propose links to the the respective texts holding them, to view them in context. A minimal solution to take advantage of this flexibility could be using collapsible, or otherwise visible on demand, frames/panels where the apparatus, but also editorial comments, notes, and so on, could be shown when needed and if so desired by the user. An effective solution to this specific issue, considering both the amount and diversity of texts that might be part of the edition, and the limits of an UI that is still limited by a two-dimensional space, will require more research and experimenting.

In some image-based digital editions (such as the by B.J. Muir), the manuscript images and the relative texts aren't simply juxtaposed, but they are linked in some way, so that, for instance, a mouse click on a line in the edition's text will result in a highlighting of the corresponding line in the manuscript image. This is another area which would benefit from more theoretical work, because it has deep implications with regard to the navigation of the DE. One specific problem, for example, involves synchronising displays: when the layout is based on two frames to display both text and image, usually the user can browse the edition text and the images in an independent manner, moving back and forward on one of the frames; this is problematic because it disrupts the navigation state for the user, who has no way to tell if the currently displayed image corresponds to the currently displayed text: it would be better to link image and text so that one follows the other when browsing, and vice versa (see Rosselli Del Turco 2009).