GRAPHICAL USER INTERFACE
GRAPHICAL USER INTERFACE
1. Introduction
Few years ago, when a user had to check the contents of a folder using the DOS prompt, he had to remember and enter a few commands like “dir” or “dir/p”. To accomplish this, the user had to undergo the trouble of remembering and entering the right commands in the right prompt without typos. This had been followed from quite sometime, since there were not many new methods.
At one stage, a non-technical user would have certainly thought of accessing his system contents in a more simple way… Just imagine, how easier life would have been, had the user an opportunity to just access the same with a few keystrokes or finger movements…!
In early computers, there was a very little user interface or the UI except for a few buttons at an operator’s console. The user interface was largely in the form of punched card input and report output. Later, a user was provided with the ability to interact with a computer online and the UI was a nearly blank display screen with a command line, a keyboard, and a set of commands and computer responses were exchanged. This command line interface led to one in which menus predominated.
This was the time when Graphical User Interface or the GUI pitched in, providing the easiest modes for the user to actually see everything pictorially. The GUI arrived, originating mainly in Xerox’s
This paper is mainly aimed for the reader to focus on understanding a Graphical User Interface from basics (in brief), Usability Issues, adopting GUI Standards for all the products in an organization and some simple steps to perform GUI Validation Testing.
2. Graphical User Interface or GUI
A GUI lets users interact with their computers via icons and a pointer instead of by typing in text at a command line. Popular GUIs are Sun Microsystem’s OpenWindows, Microsoft’s Windows, and Apple’s Mac OS. Some of the command line interfaces are MS-DOS and Unix.
Elements of GUI include windows, pull-down menus, buttons, scroll-bars, iconic images, wizards, the mouse, and many more things. With the increasing use of multimedia as part of the GUI, sound, voice, motion video, and virtual reality interfaces seem likely to become part of the GUI for many applications. A system’s GUI along with its input devices is sometimes referred to as its “look-and-feel”.
Human Computer Interface or HCI
HCI (human-computer interaction) is the study of how people interact with computers and to what extent computers are developed for successful interaction with human beings. A significant number of major corporations and academic institutions now study HCI. Historically and with some exceptions, computer system developers have not paid much attention to computer ease-of-use. Many computer users today would argue that computer makers are still not paying enough attention to making their products "user-friendly." However, computer system developers might argue that computers are extremely complex products to design and make; and also that the demand for the services that a computers can provide has always out driven the demand for ease-of-use.
One important HCI factor is that different users form different conceptions or mental models about their interactions and have different ways of learning and keeping knowledge and skills. In addition, cultural and regional differences play a part. Another consideration in studying or designing HCI is that user interface technology changes rapidly, offering new interaction possibilities to which previous research findings may not apply. Finally, user preferences change as they gradually master new interfaces.
Why GUI?
· A GUI as we now know, is a computer-interface that uses images as well as typed text, with icons on the screen replacing many of the functions of the keyboard.
· Many sighted people find GUI easier to use, because they don’t have to remember or to look up special commands for each program function.
· Less time is spent figuring out how to get the computer to do what you want it to do.
· People who are blind and visually impaired can use GUI, provided they have a reliable screen reader to translate what’s on the screen into braille or synthesized speech.
3. Brief History of GUI
The history of GUI dates back to 1970’s when the Project Smalltalk was established at Xerox Palo Alto Research Centre (Parc), which attempted to look into the future. The idea was to assume that in the future, computing power would be abundant and inexpensive and the best use of this available power will be made. Two influential developments resulted namely, Object-oriented Programming & the Graphical User Interface. Soon Apple took the track of Xerox. Apple came up with Lisa, the then, very powerful microcomputer that had a GUI. Macintosh was released in 1984, which consisted of a keyboard and mouse attached to a box containing a 9-inch monochrome screen & a single floppy disc drive. Then came the “Big” Mac with 512 kB. At that time, the style of interface was usually referred to as “Wimp”, derived from the components “window, icon, menus, and pointer”. GUI – or even “gooie” very soon, replaced this name.
4. Why is Usability important?
The Definition of Usability goes like this: the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component [IEEE 90].
Assume some Pharmacy software that illustrates the importance of using effective interfaces in today’s Healthcare Informatics sector. Pharmacy Management is a major task involving lot of data entry, data tracking, problem resolving; practically many users are new to the program and most of them will not want or have time to read the excessively adequate user manuals or support documentation. Despite this, users, including many barely computer literate ones, manage to work on the packages and use them efficiently. The background is very simple! It is the functionality that the program performs and then the interface is the means by which the user interacts with the software to perform the various tasks. For a software creator, it is the design, code, functionality and the overall program that makes a product; while for an end-user, it is just the interface or the Usability, which makes the product.
Increasing Usability reduces the amount of time it takes users master your product and decreases your support and training costs. Validating usability enables you to find and correct the problems within new products and focus development resources for new releases of existing products.
5. What are the Details to be considered?
GUI Designers and / or implementers and/or other delegates related to the GUI product being developed should:
· Understand the basic factors that determine the usability and effectiveness of an application
· Be able to apply user centered design techniques to the design, implementation and evaluation of applications
· Be aware of the latest trends and technologies that are being used in the designing of user interfaces
· Know the differences between Web Design and GUI Design
· Feel that UI is the product to the user
· Understand that the UI needs to support the users’ task
· Realize that increased usability increases the users’ efficiency & reduces maintenance and support effort…
Apart from these, we also need to be familiar with some of things that follow, in order to provide the good User Interfaces.
I. Understanding Usability: The difference between good and bad usability are determined using the factors like -Clarity in Layout Design and wording art, Consistency, Confusing Terminology (Not using OK, Cancel, Save and other buttons), Poor Organization (Ex: Placing of toolbar, menubar, etc.), Complex menu structure (Having more than 2/3 levels of sub-menu items in a single menu), Uninformative feedback (Ex: A warning message showing an error!), Overuse of color, etc.…
II. GUI Design Concepts:
· User-centered Design
· System-centered Design
· Event-driven Programming
· Affordances, Metaphors & Manipulations
III. Designing for Usability: Consider the following - User Centered Design, User Profiles, Usage Scenarios and task Profiles, Prototyping, Evaluation.
IV. High Level Design: Includes - Conceptual Design, Metaphors, Structure and Navigation.
V. Detailed Design: Includes - Usability Principles, Interaction Design, Window Structures, Menus & Interaction, Forms, Dialog Boxes, Wizards, and Feedback Techniques.
VI. Visual Design: Includes – Color, Fonts, Icons, and Layout.
VII. Exotica: Includes – Active Desktop, Style Guides.
VIII. Usability Evaluation Techniques – Using the following strategies:
· Informal Testing
Ø Walkthroughs
Ø Peer Reviews
· Formal Testing
Ø Focus Groups
Ø Questionnaires
Ø Lab Testing
VIII. How to improve overall on Usability of Software Products?
Adopting and implementing procedures like those mentioned here can enhance usability. Some of them are:
· Forming Usability Group & conducting Usability Research (Market Research with Users)
· Conducting expert usability reviews on your products
· Evaluating a product by conducting questionnaires – both internally & externally
· Involving Focus Groups for reviewing the merits of design alternatives
· Performing Task Based Testing along with the users in their sites or in the usability labs…
6. Need for adopting GUI Standards
After performing all the above, now, how do we actually incorporate what we want in our code? It is just not sufficient to provide the user with one or two products with some GUI requirements fulfilled. In the long run, to achieve maximum customer satisfaction and enhance business time-to-time, any organization should aim at providing consistent GUI applications. There must be uniformity across all the products (at least the major ones) provided by the development organization. [Note that, changes to the GUI features are subject to changes in user requirements]. This requires documentation of GUI Standards, which needs to be strictly followed and implemented. The products must be validated against these Standards before shipping to the user.
It is also required to share the work on GUI Standards amongst all the technical employees who are directly related to the product development. This can be achieved by conducting organization-wide trainings. It is important to let everyone know that it is not only required to strictly implement the standards, but, to understand the need for following such standards.
Here is a list of some of the GUI elements (in a Client Server product) that may require focus, for standardization:
Ø Dialog Boxes – Property, Function, Process and Message Types
· Modal Dialog
· Modeless Dialog
· Search Dialog Boxes
· Other types of Dialog Boxes
Ø Message Boxes
· Information
· Warning
· Critical
Ø Menus
· Shortcut Menus
· Menu Items
Ø Controls
· Command Buttons
· Button Action
· Ellipsis Buttons
· Option Buttons
· Check Boxes
Ø Keyboard Support
· Access Key for OK / Cancel
· Function Keys as Access Keys
Ø Text / Numeric / Alphanumeric fields
· Text Boxes
· List Boxes
· Check List Boxes
· List views
· Combo Box
· Multi-Line Edit fields
Ø Visual Entities
· Cursor Movements
· Tab [Forward Tab]
· Shift + Tab [Backward Tab]
· Cursor Movement Keys
· Default Commands
· Fonts
· Capitalization
· Color
Ø Organization Specific Screens
· Logon Screen
· Splash Screen
· About Screen
· Screen Navigation
Ø Other GUI Elements
· Classic Menu
· Tab Form
· Multipage Form
· Accumulator
· Access and Exit of all windows
We may still have more elements added to this list like a “Patient Ribbon”, in a Healthcare application or the name of the application appearing in each and every window. For example, if we consider an application by name “Standard Salary Manager”, the development organization may wish to have this name in the Title bar of the main application frames. And if there is a function in this application by name “Employee Gross Salary”, then, there could be child screens titled after the functionality associated with those screens. Like, “Employee Gross Salary – New” (to add a new gross salary data for a new employee), “Employee Gross Salary – Edit” (to modify a gross salary data for an existing employee), or “Employee Gross Salary –View” (to read-only the gross salary data for an existing employee).
7. GUI Validation Testing
GUI Validation Testing is basically required to ensure that the standards to be implemented during the development of each product are strictly taken care of while coding. It is mainly to verify the compliance of a company’s own GUI Standards seeded in its products.
The following diagram (in Fig 1) gives a simple, yet an effective approach to perform GUI Validation Testing.
Some guidelines to perform GUI Validation Testing
· A GUI Testing Strategy can be prepared for Manual Testing and Automation (if available), which can be applied across to all projects
· A GUI Test Plan can be devised for Manual Testing & Automated Testing, for the current activity
· Resources can be exclusively allocated for this activity & utilized full-time to verify the GUI features of the various projects
· Generic Test Case documents could be prepared for each GUI element, which could be applied to each and every window of the all the applications being tested.
For example, if the tester comes across a Radio Button field in a certain window, he has to refer to the test case documented for Radio Button testing and check if all the expectations from the Radio Button are met. Refer Fig 2 for a sample tabular column containing test cases for a Radio Button field.
· Another way of doing this, is by preparing checklists for all the standard GUI elements and filling them up during test execution, whether the expected behavior is achieved or not. In this case, validation of each window will have many checklists to be answered. Refer Fig 3 for the tabular column containing a sample questionnaire.
· Tests can be run / executed as per the devised plans.
· Manual Testing is one of the best ways as it saves resources and often, the best, when there are changes made to the software every now and then.
· If you have Automation tools for GUI Testing from vendors like Mercury Interactive (WinRunner / Astra QuickTest for Web) or Segue (SilkTest), then, these can be made use of for testing the GUI features, (provided there are not many changes made to the requirements very often).
· Even if Automation is adopted, it is also good to perform manual testing to ensure that all aspects of GUI, those that cannot be automated are also covered.
· Automation provides testers with speed, repeatability, coverage, reliability, reusability & programmability.
· Automation can be most feasible when tests must be run every build, for - data-driven tests, regression tests or remote execution of scripts, identical tests using different browsers, mission-critical pages, etc.
· Automation may not be ideal for - one-time testing, ad-hoc testing, tests without predictable results, etc.
· Most important thing to be noted is that, it is highly and hardly possible to check whether a particular pixel is of such and such color, whether a certain object is of such and such size. And in web, if the script is going to be run on different browsers, the size of the objects may differ. Unless the usability features are very critical for any application, there may be no prospect in automating such tests.
· Once the tests are executed, test results can be prepared and sent to all the concerned persons. The test results document may consist of bugs reported for each window of the application tested. Refer Fig 4 for the tabular column containing sample test results.
Fig 2: Sample Generic Test Cases for Radio Button
|
Test Case ID |
Test Cases |
Expected Behavior |
Actual Behavior |
Pass/Fail |
Remarks |
|
RBN1 |
For two or more Radio buttons on a screen, click on one of the buttons |
The selected button should be checked. |
|
|
|
|
RBN2 |
For two or more Radio buttons on a screen, select one of the buttons and click on it .Now select another button and click on it |
The previously selected button should be unchecked, and the button last clicked, must be checked. |
|
|
|
|
RBN3 |
For two or more Frames on a screen, select a frame and a radio button in it. Now select another frame and a button in it |
Only the selected buttons in both the frames must be checked and all the other radio buttons must be unchecked |
|
|
The user must be allowed to select a radio button from all the Frames. |
|
RBN4 |
Check for the initial and major words capitalization of the label of the Radio button |
Initial character and major words should be capitalized. |
|
|
|
|
RBN5 |
Check for the alignment of the Radio buttons |
The radio buttons should be aligned properly in their frames. |
|
|
|
|
RBN6 |
Check for the access keys of the Radio button. |
Access keys for the Radio button should have the letter underlined and must be unique within the screen. |
|
|
|
|
RBN7 |
Check by using the access key of the Radio button |
The radio button should get checked. |
|
|
|
|
RBN8 |
Check for the arrow keys |
The user should be able to navigate through the Radio buttons. |
|
|
|
Fig 3: Sample GUI Validation Test Checklist
|
Test Cases |
Pass |
Fail (Describe or List the problems) |
Corrected by: / Date |
|
Dialog Boxes (Property, Function, Process and Message Types) |
|||
|
It is movable. |
|
|
|
|
Minimize and Maximize buttons are absent. |
|
|
|
|
It is mostly named according to the function it performs and not the object. |
|
|
|
|
The name reflects the action or the label of the command, which invoked the dialog. |
|
|
|
|
The title is consistent while the dialog box is displayed. |
|
|
|
|
The title does not contain an ellipsis. |
|
|
|
|
Within the application, the title is unique. |
|
|
|
|
Not normally resizable (by dragging a border with the mouse cursor) |
|
|
|
|
The user is able to edit the properties of a selected object (Property dialog box) |
|
|
|
|
The user can configure and initiate an action (Function Dialog box) |
|
|
|
|
Process dialog box displays the status of a lengthy operation. |
|
|
|
|
Message dialog box informs the user of information, warning, or critical messages. |
|
|
|
|
Modal Dialog |
|||
|
User must close the Modal dialog before doing any operations in the application. |
|
|
|
|
It usually contains OK/Cancel buttons. |
|
|
|
|
Modal edit dialog box is used when the user is editing data on a single object. |
|
|
|
|
Modeless Dialog |
|||
|
User can jump back and forth between a modeless dialog and other windows in the application at will (i.e. allow the user to interact with the parent or other window while the dialog box remains open) |
|
|
|
|
It has two options: a Close (X) button in the title bar. Or no button |
|
|
|
|
Modeless edit dialog box is used when the user is editing data on a single object and needs to use both the dialog box and the parent window at the same time. |
|
|
|
|
Other types of Dialog boxes: |
|
|
|
|
Series navigation dialog box is used when the user must edit multiple objects in sequence. |
|
|
|
|
Random access navigation dialog box is used when the user must edit multiple objects in a high interrupt environment. |
|
|
|
|
Lookup dialog box is used to let the user select an item from a table. |
|
|
|
|
Simple lookup dialog box has no filter options and is a simple, text entry field. |
|
|
|
|
Indexed lookup includes the text lookup box and offers several selection options for the display. |
|
|
|
|
Indexed lookup has option buttons with labels corresponding to column headers first are placed in sequence. |
|
|
|
|
Indexed lookup includes a Find Next command button. |
|
|
|
|
Filtered simple lookup option allows the user to filter by one criterion. |
|
|
|
|
Filtered complex lookup allows the user to conduct a fairly complicated search using 2 or more criteria. |
|
|
|
|
Indexed filtered lookup uses the indexed lookup in combination with filtered simple or filtered complex to offer multiple filtering mechanisms. |
|
|
|
|
<Next GUI Element> |
|||
|
- |
- |
- |
- |
|
- |
- |
- |
- |
|
- |
- |
- |
- |
|
- |
- |
- |
- |
|
- |
- |
- |
- |
Fig 4: Sample GUI Test Results
|
Sl. No |
Defect ID / SCR # |
Severity |
Test Case ID’s |
Pass/Fail |
Contact Tester |
Tester’s Notes |
|
Window Name: Employee Salary – Edit |
||||||
|
1. |
- |
High |
- |
Fail |
- |
The date field (on which value of gross salary changes) is read only. It is not editable. |
|
2. |
- |
- |
- |
Pass |
- |
- |
|
3. - |
- |
- |
- |
Pass |
- |
- |
|
Window Name: Employee Salary – View |
||||||
|
4. |
- |
Low |
- |
Fail |
- |
Even though this screen has to display all the fields in the read-only mode, Employee second name field is editable. |
|
5. |
- |
- |
- |
Pass |
- |
- |
|
6. - |
- |
- |
- |
Pass |
- |
- |
