Guidelines

 

The goal of this paper is to help Archicad Add-On developers in the making of easy-to-use software that follows similar design principles as Archicad and fits well in the visual environment and interaction logic of Archicad.

 

Introduction

Computer-human interactions (CHI) is a relatively new field of research and practice. It deals with all techniques and methods that let humans “use” their computers, in the following sense: – they can figure out easily what a system can and cannot do for them, – they can find the steps to reach their goals with little effort, – they can follow all phases of the process and understand what happens and why. This is a really interdisciplinary and very broad field, including elements of cognitive psychology, applied graphics, ergonomics, and industrial design. It also requires very good common sense and empathy with a variety of users. The result of the design process is called the User Interface (UI); in the case of computers that use graphic images to convey information it is called Graphic User Interface (GUI). But design does not end with good graphics; add the appropriate interaction techniques to get what’s called Look and Feel. Whether the design enables users or not is measured by the software’s Usability. The full work environment including the explicitly displayed and hidden concepts, usability, visuals, sounds, the time factor etc. has an impact on the user which is called User Experience. Always keep in mind that the ultimate goal is to give users a good experience when working with your software. This can only be reached if you think wide and cover all areas outlined above with the design of your software. The good impact of well crafted visual imagery can be ruined by sluggish response, a good overall concept can be undermined by bad wording. Ideally, all components of the User Experience should be on an even level.

 

Typical steps of developing an Archicad Add-On

 

Conceptual design

1/ Know your users, their practices and their needs.
Even if you develop an in-house diagnostic tool, you still need to respect your colleagues and follow the most important rules of thumb of interface design.

2/ Decide which needs you want to satisfy.

3/ Set up the basic concepts and the appropriate metaphors to present them.

4/ Create quick and cheap mock-ups and…

5/ …get very early feedback from practitioners.

6/ Allow several rounds of iterative redesign.

 

Design development

7/ When the basic conceptual and computational model is right, develop the UI and the code parallel. Always keep the UI design ahead of UI coding.

8/ Make sure that the design remains focused on the basic concept. Don’t let a layer of afterthoughts hide the clarity of the concept.

9/ When designing the details, keep the visual images, and the terminology consistent.
If you use a drill icon to create holes, use the appropriate verbs and terms across the entire UI. An alert should say “Cannot drill hole” instead of “Boolean subtraction canceled”. (However keep in mind that a virtual drill can be smarter than a real one and make an elliptical hole or a rectangular, something you cannot expect from a physical drill.)

10/ Always think about the worst possible user scenarios. Users do click at the most unexpected time and place. It is your task to handle this.

 

Document and test

11/ Write brief but accurate specifications of the usage and behavior of interface components.
This will not only help coding, but can be a good basis for testers and authors of help, manuals and tutorials.

12/ Before freezing the design, allow another round of testing for any usability errors.
Few subjects. Do not help them. Speaking out loud. Encourage doing the unexpected.

13/ Know when to stop.
There is no perfect design. Trust the good concept and spend more time on debugging than adding a few more tricky features. Reliability is the #1 usability factor.

 

Archicad UI Basics

Archicad utilizes two dominant software concepts:

 

WIMP GUI:

Windows, icons, menus, pointers. Common in current OS platforms. Taken as granted for several years to come, even if the mouse and CRT tube are replaced by pens and flat screen boards.

 

Direct Manipulation

An industry term for interfaces which let users manipulate on-screen graphics as real world objects with immediate effect and instant feedback. Lets users be in control; an antonym for systems which act out of your control based on their own decision making algorithms. Also an antonym for command based systems where the interaction is based on your issuing of commands which tell the software what to do, and thus, the real action is perceived as being performed by the system and not by the user.

 

Terminology

 

Avoid computer language, use customer’s field terminology

Archicad users are typically no computer experts. They are experts in their own domain. These guidelines need no explanation. Use computer language to be consistent with the user experience of the OS in general. Beyond that, make sure that your software does not break the mental process of design with interface elements of a different, and potentially complex, domain.

 

Be consistent in using terms

It is an imperative that the terms and the way they are used is consistent across the entire system, including Add-On, Archicad host, OS, and their components like menus, dialogs, on-line help and manuals. With the same thing named differently in these components, users, manual writers and technical support staff will be equally confused.

As Add-Ons typically share some of their wording with Archicad, make sure that these match the Archicad terminology as much as possible. Before settling with a naming convention, check Archicad for names of similar or related things.

 

Use guidelines only as far as they help

You can always go for something better…

 

Use GS interface widgets in Add-Ons as widely as possible

 

Icons and pictures

  • Use realistic images only where realism adds information
  • Prefer schematic illustrations with the lowest possible graphic details
  • When illustrating actions with icons:
  • prefer “tool” metaphor (printer, saw, hammer)
  • avoid putting before-action, after-action states plus the action itself into 32*32 pixels
  • Best results: icon PLUS word; constant reinforcement of the links between visible and speakable terminology

 

Interaction

  • Be forgiving and tolerate many ways to complete an action.
  • “Hey you, do that” is the preferred order of doing things.
  • Clicking an element is ambiguous in case of overlapping elements, the feedback of selection dots and Info Box make it clear what’s selected.
  • Use informative animated feedback when possible.
  • Start giving visual feedback on pressing the mouse button. Don’t wait until the button is released.

 

Processes

Even if all the metaphors, wording, visual elements and interaction techniques are fully developed, you may still end up with a very confusing piece of software, if the user feels that he/she lost control of it. Users get this feeling sooner than you may think.

Researchers say that:

  • if nothings happens for 0.3 seconds after a click, interaction gets staggered or broken; the user will feel that the machine is sluggish and does not follow his actions,
  • if nothing happens for 3 seconds after a user action, a crash will be assumed by the user.

This makes it clear that if your software starts “thinking” which may take some time while the user is waiting, proper timing of proper feedback is crucial.

After any user action, always give instant feedback. If nothing happens in a third of a second, the user is likely to click again nervously.

In the beginning of a long calculation, start spinning the animated “busy” pointer within 3 seconds.

In addition, if a calculation takes really long, users need additional feedback about the length of the process and its progress. In Archicad, if a calculation goes on for 10 seconds without being complete, the Progress Indicator palette is opened. This palette provides information about the number of phases of the process, the estimated length of it and the current state.

In case of long calculations, users want the power to break them as they want. Make sure that your software can be stopped in such cases. If stopped, give users a clear indication whether the system returned to its previous state completely, or the broken process resulted in half done but effective results.

In a progress indicator palette, there is a Stop button to break these processes. On the Macintosh, in addition to this, make sure that pressing Command-Period breaks the process.

Also, make sure that mouse clicks made in an irresponsive state of the system are not cached and have a – most likely undesirable – effect a bit later. If a click is not effective immediately, forget it.

Visibility of processes is sometimes good, sometimes bad. Definitely avoid flashing of the entire window or switching of windows; also avoid showing things which are temporary and get reversed when the task is completed, like making a hidden layer temporarily visible in order to change some elements. In these cases stop the refreshing of graphics.

 

Localization

  • Do not use wired in text or settings.
  • Non-English text is typically 1.5x longer. Allow space for this in dialog boxes.
  • Plan dialog boxes to accommodate this (button sizes, titles etc.)
  • In Palettes or other non-modal windows, you may optimize for size.
  • Keep UI items that require localization separately.
  • Allow user preferences to be set for different markets.

 


Modified on May 8, 2001