OSMIS Technical Specification

GUI Specification

5.1 Overview of GUI

Analysis was carried out to identify the needs of schools with respect to a school management system. The main functions of the system were defined, and keeping in mind the vast array of users with varied computer skills and cultures, an analysis of the feasibility of certain designs was conducted where these designs had to meet the criteria of a multi-platform user base.

1st increment of GUI design, layout and navigation

This task was carried out as follows:

1. Identify modules in the Use Case to implement. From the analysis of user requirements conducted, the consortium prioritised the following modules to be developed as part of iteration 1:
   • School module
   • Educator Module
   • Learner Module
   • Subject Module
   • Assessment module
2. Identify what information is to be grouped in the above modules. A further prioritisation within these modules was carried out in terms of use cases. This involved deciding what subset of the data was priority and to be included in this iteration, and what data could be left to later iterations.

Certain criteria for the GUI architecture were laid down through the analysis process. Several schools indicated that although they possessed management systems, these were not utilised due to their being non-intuitive and navigation not immediately apparent to the users. With this in mind, in consultation with experts and schools, the following guidelines were followed.

1. Workflow guidelines
   • Consistency throughout the system
   • Users should intuitively and clearly know where they are in the system at all times
   • It should take two clicks to get anywhere in the system
   • Use cases involving an extended step e.g. Searching are expressed as a logical representation. As many as possible of these are re-used in several modules
   • Provide intuitive defaults
   • User input should be validated
2. Windowing guidelines
   • Consistency throughout the system
   • The user is placed in a look and choose mindset as opposed to a remember and enter mindset
   • A Selectable folder system on the left hand side of the window ensures navigation menu through Primary modules and is a dynamic feature, which expands into sub modules to avoid clutter and avoid more than two levels of cascading menus. This feature is present in every window throughout the system irrespective of where the user is.
   • The module of choice is highlighted for navigation control in the folder system as well as being clearly displayed between the toolbar and the tab pane.
   • This application contains several child windows for the different tasks a user might perform. These tasks can be accessed easily through the tab panes. The tabs reflect collections of similar type data, these panes are the secondary windows of information and appear to the user initially in default mode. Should the user want to take any action, the action button available per tab is placed consistently in the bottom right hand corner, unless it is a special button to be used within the same tab.
   • Controls or action buttons have been grouped together; only the action buttons that apply to that page have been placed within the border of the tabbed pane.
   • In the title bar we have included the tab pane name and the mode of the pane for clarity as to where the user is within a module. Providing a descriptive title bar within each window will help greatly to remind the user what tab items or buttons were pressed to bring them to the window now in focus.
3. Common action button Guidelines

   OK	Accept data entered or acknowledge information presented and remove the window
   Cancel	Do not accept data entered and remove the window. Display previous window
   Save	Save data entered and stay in current window
   Reset	Clear changed fields. Return fields to initial values and stay in current window
   Edit	Open editable field tabbed pane
   New	Open new tabbed pane for entry not previously in system
   Delete	Remove complete profile from system

4. Search Guidelines
   • User will select a module and the default display tabbed pane of the module should appear.
   • Any module with a search facility will indicate this by the search being a sub module function.
   • This search facility can be utilised in whichever tab the user deems a need for a search.
   • The search tab is invoked; the user performs the search and makes a selection.
   • Once the selection is made the system defaults to the window where the user invoked the search and populates the related information for the search done.
   • This process was followed to keep the look of the system consistent with the two-click ideology as well as consistent in the folder and tab design methodology followed.

As the system was designed with future enhancements in mind, the Emis extraction of data from the system is a potential future enhancement. This data should be worked into the system sooner rather than later. Where information is pertinent to Emis purposes only, it has been grouped in an Emis tab, which does not need to be accessed unless the user so chooses.