Looking back on our second presentation, I am still very proud that our performance was remarkable. I learned lessons from the first presentation-select what’s most important and present the main points. Our group’s topic was dialogs. We used a serious of bulletin dialog boxes as the start of our presentation. Four types of dialog boxes were illustrated with good and bad examples.
- Bulletin dialog boxes are the simplest dialogs and they serve application. A blocking bulletin box forces user to make a respond or the program will not continue, while a transitory bulletin dialog box allows the procedure without user intervention. The design principle is that never use transitory bulletin dialog as error messages or confirmations.
- Process dialog boxes indicate that the application is busy, but everything is otherwise normal. The design principle is that make the time-consuming process clear with a process meter. Process dialog boxes should satisfy users’ mental modal of a time-consuming process. Also, do not forget to provide a way for users to cancel the operation and regain control of the program.
- Function dialog boxes can control a single function and are usually summoned from a menu. The design principle of this boxes is that segregate configuration and actuation. That means do not combine configuring the function and invoking the function or the users will feel the task is very complicated.
- Property dialog boxes are quite straightforward as its name implies. Through these boxes, users can view and change attributes of an object. The design principle is that employ toolbar, palette, sidebar or task pane as an interaction idiom. They provide direct, visible, and persistent functionality.
There are some other guiding principles we should keep in mind such as put primary interactions in the primary window and use consistent terminating commands for modeless dialog boxes. During our presentation, we explained and illustrated the principles through practical examples.
Although it has been several weeks since the second presentation, I can still remember my classmates’ excellent performances and what I learned in that class when going through all the presentation slides.
The first group gave the presentation about control. How can we control the computer? There are four types of controls-imperative controls, selection controls, entry controls and display controls. Imperative controls invoke actions and button conveys the quintessential imperative idiom. Selection controls are more complicated. The controls include check boxes, latching butcons or toggles, radio buttons or butcons, combutcons, list controls, etc. We should keep in mind that all the selections are mutually exclusive. Entry controls serve data entry. Sliders, spinners, dials and text fields are the manifestation of the control. Display controls are used to manage the visual information with scrollbars or drawers.
Pointing & selecting was the second group’s topic. The topic was very interesting. After their presentation, I started to think about my interaction with computer. What is the feedback of pointing and how can I select an object? It is not very easy to make a manipulation possible. Many input issues and idioms are included such as visual indication of selection and drag pliant response.
The presentation of the third group clearly and succinctly stated the menu idioms. I never thought that menu provides a pedagogic vector. I learned a lot of things from this presentation. Drop-down menu, pop-up menu and menu bar helped pave the way for Today’s menu. Toolbars and direct-manipulation idioms are immediate compared with menu commands when serving the power and purpose of an application. All in all, menus are more like a pedagogic vector and its purpose were to execute commands. Terseness would be a virtue for good GUI design.
The last topic was errors and alerts. It has a close relationship with dialog boxes which are used for error messages, alerts, and confirmations. This presentation helped me differentiate the three dialogs and avoid abusing them. People always hate error message and blame the messenger before they blame themselves. It is human nature. Eliminating error messages helps designers create reliable software. Effective methods to improve error dialogs include use plain language, provide helpful messages and hints, think of error messages as a conversation with users, etc. Instead of reporting malfunctions, alerts and confirmations are more like notification. Elimination and brevity is necessary for alerts and confirmations too. Furthermore, we can use rich modeless feedback to replace dialogs. By doing so, our interface will be more user friendly and effective.