Macintosh Development

[Home] [About Us] [People] [Information Systems]
[Kerberos for Macintosh] [Applications] [Miscellaneous Documentation]

Table of Contents

• Introduction
• Requirements for the User Interface
• The Flow of the Application
  • Flow Chart
  • Description
• The GUI
  • The Main Window
  • Alerts & Dialogs
    • The Recommendation Window
    • The Problem-Correction Dialog
    • Preference Dialog
    • Errors & Warnings

Introduction

This document will describe the look and feel of the Config Checker. Requirements for the User Interface describes what this application needs to do from an user interface perspective. Next, The Flow of the Application presents a flow chart that suggests the various states of execution this application should progress through to accomplish its purpose. Finally, The GUI contains mock-ups of the various windows and dialog boxes Config Checker needs.

Requirements for the User Interface

Config Checker:

1. Should inform the user in real time what tests are being performed and what the results of the test are.
2. Should allow the user to transfer the results of the tests to a text file so it can be sent via email to the help desk or printed out on a printer.

The Flow of the Application

Flow Chart

Figure 1: The Flow of Config Checker

Description

Main Application Flow:

1. The Application starts up, display dialogs (such as test tracker) that involved the initialization of the application, or maybe a splash screen.
2. The Main Window is displayed. The user can start tests and view the results of previous tests in this window.
3. The Application performs the tests selected by the user, in the meanwhile displaying its progress through the tests to the user.
4. After the Application finishes the tests (or the user cancels them), the results of the tests are displayed.
5. The Application recommends to the user what actions should be taken to resolve problems found during the tests and prompts the user for input into what is to be done.
6. The Application handles the problems discovered during the tests it ran according to the user's wishes.
7. The Application Quits at the user's request, prompting the user to save any test results that haven't been saved at that point.

Secondary Application Flow

1. The Application prints out a text document that contains the results of the latest tests ran.
2. The Application saves as a text document the results of the latest tests ran, and the program's recommendations for correcting these problems. This would be useful if one solution was to download software from an URL. The program would save the URL in the text file for the user, so the user can use the URL later.
3. The Preference Dialog Box allows the user to set defaults and preferences for the Application.

The GUI

The Main Window

Figure 2: The Main Window

The Application will display the Main Window at startup. This window contains a text field that keeps the user informed of what tests are being performed and what their results are. The "Run Tests" button starts the tests and changes to a "Stop Test" button, which is used to cancel tests in progress. The "Fix" button is used to fix problems found by the tests and is greyed out if there are no problems to fix or no tests have been run. The text is the text field should be copy-able.

Alerts & Dialogs

The Recommendation Window

The Recommendation Window contains text field that lists the problems founded by the tests and what can be done to fix these problems. The window hides it's close, so that the document associated with it doesn't get destroyed.

The Problem-Correction Dialog

Figure 3: The Problem-Correction Dialog

After the Application is told to fix problems found by the tests, it brings up a movable modal dialog box for each error detected, one at a time, and recommends to the user what actions should be taken to resolve problems found during the tests, and asks the user whether to fix the error right then. Note that neither the "fix" nor the "don't fix" buttons are highlighted if the application can't fix a problem itself. The user can use the "back" and "next" buttons to move between problems without making decision about fixing a problem. The text in both fields should be copyable.

Preference Dialog

Since considerations into what sort of preferences would be actually needed haven been made yet, it is hard to say exactly what the preference dialog would look like, except to say that it will be a dialog box.

Errors & Warnings

Error messages and warnings will be displayed using standard Macintosh Toolbox alert dialogs as much as possible, in order to reduce the amount of code to be written and to keep the program's look uniform.

Questions or comments? Send mail to macdev@mit.edu
Last updated on $Date: 2003/11/18 21:59:29 $
Last modified by $Author: smcguire $