Radu Luchian(ov): Projects: CHI: MonDoc
Usability Principles

This page is mostly as it was in 2006. Like many other pages, it may sound in part outdated. To be edited little by little when I have time.

---

[Introduction] [Summary] [Principles]

---

This page attempts to describe the MonDoc set of principles for composing and maintaining personalized documents and applications.

Optimizing document effectiveness for that purpose is the major difficulty to be overcome.

---

Regardless of how they are implemented, I continue to refine these principles out of the oceans of theoretical and practical work I encounter during my studies. For a MonDoc-like approach to the socio-economic issues surrounding software design and business in general, see the Cluetrain.

At its core, MonDoc is about making documents fit their current use, through:
- the balance that is to be achieved between the forces of (1) economy and (2) completenness in writing understandable documentation and functionality;
- (3) structure, organization and the (4) separation of channels and signal from noise at all the levels in communication;
- (5) transparency of function, look and content.

I am gathering these principles and developing the MonDoc engine and various Monades in order to help provide a more cognitively accurate communication and collaboration channel than currently available ones (speech, books and journals, the web or even existing specialized software). Some of the guidelines below already exist in textbooks on programming, or usability, or psychology, but the fact is that we need them all in order to make informed design decisions.

Summary

Every element of a MonDocument, should address a specific function, with as little overlap as possible. Currently I try to cover the following:

• intuitive writing of plain text,
• a reduced number of text formating (highlighting, titles, quotes, etc.),
• a reduced number of widgets,
• the hyper-links familiar from the ubiquitous media,
• consistent and context-dependent access to a large number of document parts,
• data reversal,
• assigning credit,
• literate programming,
• object-oriented design,
• activity-tracking.

MonDoc Principles

See Dilbert

To summarize, the main goal of MonDoc is to make it easier to deal with documents.
One can approach that goal by: (1) increasing cognitive accessibility of a document and (2) reducing the resources necessary for information storage.
These are principles to be used in the analysis of interfaces, MonDocument form and content, and when creating new reusable parts for a MonDoc application. They are NOT intended to be learned by heart, nor are they final. I'll keep adding and restructuring :)
Note that this page, like most of my current site do NOT follow these guidelines as far as I would like them to. They are waiting for me to finish the version of the MonDoc engine based on my new MDDL.
1. cognitive accessibility
   • signal-noise separation
   • lower the load on associative memory retrieval
     • JustInTime feedback!!!
     • prime choices with menus and multiple-choice questions
     • offer alternative paths through the problem space
     • remind the user whenever possible of the retrieval heuristics on the next bullet
     • make use of roomy episodic memory and of the more reliable procedural memory mechanisms
       • use examples wherever possible
       • use animations wherever possible
       • consolidate knowledge through frequent testing (use the built-in test-creation tool)
       • provide alternate paths to the most commonly used functionality
   • expose the modular structure of the document/topic
     • content: argument-example separation
     • content: unique parsing (elimination of ambiguity)
     • content: reducing choice to relevant options
     • content: information exists only in context
     • content: present a consistent hierarchy of abstractions
     • form: group semantically related content (structure, function, semantics), in visually explicit templates:
     • form: use point-form for any enumerations, steps, etc.
     • form: use context cues (through dynamic layouts) to enforce the intended structure
     • form: emphasis for keywords
     • form: one idea per document part (with the exception of properly marked enumerations)
     • content&form: make use of consistent and persistent objects
       • maintain a consistent naming scheme for document parts
       • separate editing of content and context (by using recursive templates)
       • use a consistent layout (headers, footers, figures and tables, etc. : enforced through automatically-generated templates)
       • automatic replacement of frequently used text (also reduces file size and ensures consistency throughout the document)
       • use of active path markers for navigation (iconic buttons)
       • automatic bidirectional topic linking
       • optional encapsulation of document in the MonDoc engine
       • single file per topic (while preserving hypertext access to subtopics)
       • optional visual editing (for the code-challenged users :)
   • adaptive navigation (semantic lead) combines many of the above principle with a specific user model
     • non-linear presentation
     • adaptive presentation (by user type, level and previous exposure, as deemed by the document author)
     • in-context notes (parantheses, footnotes/endnotes, glossary, references)
     • graph-based decision tracking (for tests or research purposes)
   • remove contextual clutter, either browser-generated or due to heavy page templates (if you want to include ads, they're much more effective as content than context)
2. reduced resources: Besides the cognitive resource management detailed above, MonDoc contains some other (more technical) principles
   • recursive development (fast prototyping through editing the document/application within itself)
   • reuse of any type of data: content, layout, code (easily import or add a MonDoc layer on top of existing, non-MonDoc documents)
   • be open (export while using specific standards only when appropriate)
   • pages generated in a mix of client-side and server-side scheme, to balance/reduce download time and server activity
   • group-based and user-based security provided as part of adaptive navigation
   • embed informative messages (error, tracking and tracing)
   • when creating/editing hyperlinks, offer a choice of data replication as well as simple linking
   • reduced physical size (A large MonDoc is often <5% the size of the Web area it generates)

A bit more on modularity; a MonDocument allows any level the user needs of encapsulation of data, formatting and code. Depending on the purpose, one can save a MonDocument with all text in one file and the supporting multimedia files or applets used tucked away in a directory; or one can save parts in separate files, so that several documents can use them; or all parts needed at a given point in time can be generated dynamically from a database-driven application.

---

For more information, see my Master's Thesis.

Stay tuned or let me know any suggestions, funding or encouragement at radu@monicsoft.net