For much of the day, I struggled to fill the gap left on removing the term “standard” from this process. It was one heady moment of confidence that saw me insert that word into the introduction. But then again, if this project does not deliver solutions, then I have produced nothing. I kept wondering: What is a solution that is not quite a standard. Then, during my evening constitutional, it occured to me…

Before a design principle becomes a standard, it is likely to exist as a convention.

Whew!

This project does not need to devise new strategies and then work for their adoption. It should simply identify solutions that are already in place, and recognize where repetition has proven their effectiveness. So, the process that is emerging looks like this:

1. Identify the stumbling blocks
2. Deduce sensible guidlines for each case
3. Search for instances where solutions already exist

Moving right along…

In an earlier post, I suggested the goal of developing a checklist for content creation. Two such lists have been discovered. One is short; but ample, given the context of its delivery (an interview). It is a list of design criteria offered by Markus Breuer in the blog post titled METAVERSE08 Usability in Second Life. The other list is provided by Eloise Pasteur in the form of three web documents (1, 2, 3). These criteria apply in the evaluation of learners’ projects; but, since the lesson was about building in SL, they provide a practical set of design issues.

A review of design and assessment criteria provided by these two sources has resulted in a classification scheme for design elements. I will post the categories here. Then, you will find the bulk of the issues raised by the two sources mentioned above, along with designated categories.

Categories of design elements

• Nc = Navigation (Content) – addresses the purpose of navigational aids
• Nd = Navigation (Distribution) – addresses the placement of navigational aids
• Np = Navigation (Presentation) – addresses the appearance of navigational aids
• Ic = Information (Content) – addresses the purpose of instructional text
• Id = Information (Distribution) – addresses the placement of instructional text
• Ip = Information (Presentation) – addresses the appearance of instructional text
• B* = Design of Buildings – addresses the need to consider interiors, tight spaces, thematic continuity and distinction
• Q* = Quality of design – addresses the overall quality of the content

User-dependent Issues

• UI* = User Interface – addresses the need to adjust viewer settings, preferences
• UE* = User Experience – addresses the level of expertise required

* These categories represent design issues that may fall beyond the scope of this study. They are included here due to their appearance in the original source materials.

Design Issues [category]

• Make signs readable from the point where people arrive when teleporting [Ip]
• If your cool architecture makes it had for avatars to navigate: offer them help. [Nd]
• Design for avatars that have a cam 2m behind and 1m above them. [B]
• Don’t lead people into dead ends or hide access points. [B]
• Help people find orientation [Ip]
• Help people get their processes straight: what can I do? [Ic]
• Bot that give cryptic instructions are not helpful [Misc.]
• Tell users exactly what you need them to do [Ic]
• Price tags and orientation maps are cool, too [Ic]

This list was suggested by Markus Breuer (link above). The following list was compiled from the rubrics offered by Eloise Pasteur (links above).

• Is it clear where the avatar is supposed to go on arrival? [Nd,Id,Ip,Ic]
• Is the theme of the build made clear immediately on arrival? [Ip]
• Is it clear for whom the build is intended? [Ic]
• Is there a stated list of objectives? [Ic]

• Is it clear which path the avatar should take or the options that are available? [Nc]
• Are avatars encouraged to change environment settings to make the most of the build? [UI]
• Is navigation within the build obvious? [Np]
• Is it easy to find the start again if appropriate? [Nd,Np]
• Is it easy to get between different parts of a build, e.g. via teleports? [Nd,Nc]
• Can avatars exercise choice in navigation? [Nc]
• Are the different parts of the build adequately distinguished? [B]
• Does the build cater satisfactorily for different avatar sizes? [B]
• Does the build cater for social use, e.g. by pairs or groups of avatars? [B]
• Is the build camera-friendly, i.e. the avatar camera stays within walls and isn’t subject to “bounce” and newbies aren’t forced to use complex camera movements? [B]
• Is the build interactive? [Q]
• Is interactivity related to the topic? [Q]
• Is interactivity varied? [Q]
• Does the build exploit the potential to provide an alternative to real-life experiences? [Q]
• Does the build make use of the third, z dimension? [Q]
• Is the build “kinetic”, i.e. does it encourage movement and navigation? [Q]
• Do the structural elements used have relevance to the topic? [Q]
• Is there sufficient variety to the build? [Q]
• How accurate and topical is the information provided? [Ic]
• Are there any accidental examples of cognitive dissonance, e.g. fluids appearing to flow uphill. [Q]
• Is there use of humour where appropriate? [Q]

• Avatar skills: Can the objectives be mastered with students having their current level of avatar SL skills, or is there time and significant justification to spend time to develop said skills? [UE]
• Attention: How easy or difficult is it for you to stay focused in this environment? To the material being presented? Is something creating distraction or intellectual “noise?” [Q]
• Comprehension: Are the messages, visual or linguistic, comprehensible? Is the vocabulary too complex to follow? Do the communication forms (IM, chat, and voice) adequately facilitate needed communication? Is it clear how the visuals relate to the subject and do they help to understand it? [Q]

Each one of these issues may be addressed later, or it may not; and, any one may lead to a specific guideline (as part of the “process” mentioned earlier). All of this is now open for discussion, too.