UNIT 4

USER INTERFACE DESIGN

9.1 CHARACTERISTICS OF A GOOD USER INTERFACE
Important characteristics of a good user interface:

A good user interface should be easy to learn, avoiding complex syntax and semantics. Users
shouldn't need to memorize commands or information across screens. Key factors for
enhancing learning speed include:

Metaphors and intuitive command names: Using familiar real-life examples or objects
(metaphors) in interface design helps users relate quickly. For instance, a text editor
mimicking writing tools or a shopping cart metaphor for selections simplifies learning.
Consistency: Commands should be consistent across the interface, enabling users to apply
knowledge from one area to others easily.
Component-based interface: Familiarity with standard interface components from other
applications accelerates learning.
Measuring training time and practice needed by users determines a user interface's speed
of learning.
Speed of use: Speed of use in a user interface refers to how efficiently users can perform
tasks. It focuses on minimizing time and effort for starting and executing commands.
Designing interfaces carefully reduces this time, making tasks faster. Simplifying commands
and minimizing mouse movements enhance efficiency.
Speed of recall: Speed of recall is how quickly users remember how to use an interface. It's
crucial for occasional users. Making the interface based on metaphors, clear commands, and
intuitive names improves recall speed.
Error prevention: Error prevention in a user interface is essential. Monitoring user errors
helps determine the interface's effectiveness. Consistency in naming and procedures, along
with simple commands, reduces error chances. Additionally, interfaces should prevent users
from inputting incorrect values.
Aesthetic and attractive: Aesthetic appeal is vital in a user interface. It grabs users'
attention and enhances their experience. Graphics-based interfaces are particularly
advantageous in this regard compared to text-based ones.
Consistency: consistency in commands is crucial for users to understand and navigate the
interface easily. It aids in learning, recall, and reduces errors.
Feedback: Feedback is essential in a user interface. Users should be informed about the
progress of their requests, especially if it takes more than a few seconds. This prevents
confusion, especially for novice users who might panic without feedback. Periodic updates
on command processing progress are beneficial.
Support for multiple skill levels: A good user interface should accommodate users of
different skill levels. Novices prioritize usability, while experienced users seek efficiency.
Complex commands deter beginners, while lengthy sequences slow down experts. Initially,
users focus on learning speed, later emphasizing command efficiency. As users gain
familiarity, they look for advanced options like hot-keys and macros tailored to their skill
levels.
Error recovery (undo facility): Error recovery, such as an undo feature, is crucial in a user
interface. It allows users to correct mistakes made while issuing commands, ensuring they
aren't inconvenienced. Without this capability, users may feel frustrated and helpless.
User guidance and on-line help: Users seek guidance and on-line help when they either
forget a command or are unaware of some features of the software. Whenever users need
guidance or seek help from the system, they should be provided with appropriate guidance
and help.
+--------------------+
| Easy to Learn |
| - Clear & Familiar | (Metaphors, Intuitive Commands)
| - Consistent |
+--------------------+
|
V
+--------------------+
| Fast to Use |
| - Minimal Effort | (Simple Commands, Few Clicks)
| - Easy to Remember |
+--------------------+
|
V
+--------------------+
| Few Errors |
| - Consistent |
| - Clear & Familiar |
+--------------------+
|
V
+--------------------+
| Appealing |
| - Visually Pleasing|
+--------------------+
|
V
+--------------------+
| All Levels Welcome |
| - Beginners: Easy |
| Start |
| - Experts: Efficient|
| Use |
+--------------------+
|
V
+--------------------+
| Recover from Mistakes| (Undo Feature)
+--------------------+
|
V
+--------------------+
| Help When Needed | (Guidance, Online Help)
+--------------------+

9.2 BASIC CONCEPTS

In this section, we first discuss some basic concepts in user guidance and on-line help
system. Next, we examine the concept of a mode-based and a modeless interface and the
advantages of a graphical interface

9.2.1 User Guidance and On-line Help

While using the software, users can get help anytime using the online help system. This help
is different from the automatic messages that pop up without the user asking for them. The
guidance messages help users by suggesting their next options or telling them about the
status of their last command.

On-line help system: When users ask for help in the software, they want the help
messages to be relevant to what they're doing. So, a good help system should pay
attention to what the user is doing and give advice that fits the situation. Also, the
help messages should be adjusted based on how experienced the user is. A good
help system should use pictures and animations from the screen, not just repeat
what's in the manual.
Guidance messages: Guidance messages should help users with their next actions, show the
system's current status, and give updates on their last command. A good system should
adjust the guidance based on the user's experience level and the type of interface they're
using. Users should also be able to turn off detailed messages if they want.

Error messages: Error messages pop up when a user makes a mistake or when something
goes wrong with the system, like running out of memory or losing connection. Users prefer
clear error messages that explain the problem and suggest how to fix it. The messages
should be polite and not embarrassing. If needed, users should be able to get more help by
using the online help system.

9.2.2 Mode-based versus Modeless Interface

A mode is a state where only certain tasks can be done. In a modeless interface, all tasks can
be done anytime. In a mode-based interface, different tasks can be done based on the
current mode, which is determined by the user's previous actions. This can be shown with a
diagram, where each mode is a node, and each node shows the tasks possible in that mode.

9.2.3 Graphical User Interface (GUI) versus Text-based User Interface

Let us compare various characteristics of a GUI with those of a text based user interface:
 • Advantages:
•
• Can be implemented on inexpensive alphanumeric display terminals.
• Generally more cost-effective compared to graphical terminals.
•
• Disadvantages:
•
• Limited in simultaneous interaction with multiple items.
• Less intuitive representation and manipulation of information compared to
GUIs.
• Usually relies on text-based commands, which may not be as user-friendly as
GUI menus

Text-Based User Interface:

• Advantages:
• Can be implemented on inexpensive alphanumeric display terminals.
• Generally more cost-effective compared to graphical terminals.
•
• Disadvantages:
•
• Limited in simultaneous interaction with multiple items.
• Less intuitive representation and manipulation of information compared to
GUIs.
• Usually relies on text-based commands, which may not be as user-friendly as
GUI menus

9.3 TYPES OF USER INTERFACES

Broadly speaking, user interfaces can be classified into the following

three categories:
Command language-based interfaces

Menu-based interfaces

Direct manipulation interfaces

Modern applications combine different interface types to handle various user commands.
Deciding which parts of the interface should use each type depends on the designer's
judgment. Understanding the basic characteristics and benefits of each type helps designers
make informed decisions.

9.3.1 Command Language-based Interface

 • Command language-based interfaces require users to frame commands using a
specific language and type them when needed.
• They can be simple, with unique command names, or advanced, allowing users to
compose complex commands using primitive commands.
• This approach reduces the number of commands users need to remember and
minimizes typing.
• Command language-based interfaces enable fast interaction and simplify input for
complex commands.
• They are efficient and can be implemented on inexpensive alphanumeric terminals.
• Developing such interfaces is relatively easier compared to other types.
• However, learning command language interfaces can be challenging, requiring users
to memorize commands.
• Users often make errors when formulating and typing commands.
• Interaction is solely through a keyboard, lacking the advantages of devices like a
mouse.
• These interfaces are not suitable for casual or inexperienced users.
Issues in designing a command language-based interface

• Command design focuses on reducing the number of basic commands users must
remember and minimizing typing.
• Designers choose meaningful yet concise mnemonics (command names) to
streamline user input. Shorter mnemonics are assigned to commonly used
commands.
• Designers decide whether users can customize command names to their
preferences, balancing usefulness with increased interface complexity.
• Designers consider whether users can combine basic commands to create complex
ones. While this feature benefits experienced users, it may not be necessary for
inexperienced users.

9.3.2 Menu-based Interface

• Menu-based interfaces offer the advantage of not requiring users to remember

command syntax; they rely on recognition rather than recall.
• Typing effort is minimal as interactions are mainly through menu selections, suitable
for occasional users who may not type quickly.
• Experienced users may find menu-based interfaces slower than command language-
based ones, as they can type quickly and compose complex commands.
• Menu-based systems face challenges with logical connectives and large numbers of
choices, requiring careful design.
• Techniques for structuring large menus include scrolling menus, walking menus, and
hierarchical menus.
• Scrolling menus:
o Scrolling menus allow users to view and select items not visible on the
screen, but require correlation between choices for efficiency
 • Walking menus:
o Walking menus display adjacent sub-menus when an item is selected,
suitable for tens of choices but not hundreds.

• Hierarchical menus:
o Hierarchical menus organize items in a tree structure, suitable for managing
large choices but may cause navigational difficulties for users.
9.3.3 Direct Manipulation Interfaces
Direct manipulation interfaces, also known as iconic interfaces, present visual models to
users, such as icons or objects. Users issue commands by interacting directly with these
visual representations. Icons are easily recognizable and language-independent, but
experienced users may find them limiting. Complex commands are challenging to execute,
as actions must be performed individually on each object, unlike using a command to delete
multiple files at once. Example: Dragging individual file icons to a trash bin icon for deletion
means repeating the action for each file, unlike using a command like "delete ." to delete all
files in a directory at once.
9.4 FUNDAMENTALS OF COMPONENT-BASED GUI DEVELOPMENT
Graphical user interfaces became popular in the 1980s because before then, graphics
terminals were too expensive. Back then, a graphics terminal cost much more than a high-
end personal computer today. Also, the terminals didn't have the capabilities we have now,
like raster graphics.
Early GUIs, like the one on the Apple Macintosh, required programmers to create everything
from scratch, from drawing lines to handling menus. Now, user interfaces are made using
pre-made components like menus and dialog boxes, making development faster and more
consistent. Window systems also provide basic functions for managing windows, saving
developers time and effort.
9.4.1 Window System
Most modern graphical user interfaces rely on a window system. This system generates
displays through windows, which are the basic entities in the interface. Let's first define
what a window is.
Window: A window is a rectangular area on the screen. A window can be considered to be a virtual
screen, in the sense that it provides an interface to the user for carrying out independent activities,
e.g., one window can be used for editing a program and another for drawing pictures, etc.

A window has two parts: the client area and the non-client area. The client area is where
applications display content, while the non-client area controls the window's appearance
and behavior, like its borders and controls for moving or resizing. The window manager
oversees the non-client area.

Window management system (WMS)

A Window Management System (WMS) is crucial for handling the many windows in a
graphical user interface (GUI). It acts as a resource manager, assigning screen space to
different windows. It's like a User Interface Management System (UIMS), which not only
manages resources but also provides basic behaviors like moving, resizing, and minimizing
windows. WMS makes GUI design easier by handling window behaviors automatically and
providing functions for creating, modifying, and drawing on windows.
A WMS consists of two parts (see Figure 9.4):
• a window manager, and • a window system.

The window manager is like a client on top of the window system, using its services to
control how windows look and act. Different window managers can be created using the
same window system. Application programmers can use window system services directly to
develop the user interface. The relationship between the window manager, window system,
and applications is shown in Figure 9.4. Users can interact with applications or with the
window manager for actions like resizing or moving windows, and both the application and
window manager use services of the window manager.

Developing user interfaces directly using the basic window system routines can be
complicated. That's why most user interface development systems offer widgets, which are
high-level abstractions. A widget is like a simplified window object. An object is a bunch of
related data with operations defined on them. For a window object, the data includes things
like size and position, while the operations include resizing, moving, and drawing. Widgets
are standard components used to build user interfaces, and interfaces are usually made by
combining multiple widgets.
Component-based development
A development style based on widgets is called component-based GUI development. It's
advantageous because it helps users learn interfaces quickly. With this style, different
applications use the same basic components, so users can apply their knowledge from one
app to another. Also, it reduces the programmer's work, as they mainly integrate pre-made
components rather than writing everything from scratch.

VISUAL PROGRAMING:
Visual programming is when you build programs by dragging and dropping visual objects
(like icons) representing GUI components. You can easily create the interface by placing
these components where you want. It's like building with blocks. This style of programming
is popular for making interfaces but can also be used for other things like designing factories
or simulations. It's a simple way to develop interfaces and reduces a lot of effort.
Visual Basic and Visual C++ are popular visual programming languages. With Visual C++, you
design menu bars, icons, and dialog boxes before adding them to your program. These are
called resources. You can set their shape, position, type, and size without writing any C++
code first.

10.1 CODING
During coding, developers use the design document, which includes both high-level and
detailed designs. They code each module according to its specifications outlined in the
document.
The objective of the coding phase is to transform the design of a system into code in a high-
level language, and then to unit test this code.
Good software development organizations have coding standards that their programmers
must follow. These standards help maintain consistency and offer business advantages.
Adhering to a coding standard ensures uniformity, making code easier to read, understand,
and maintain. The main advantages of adhering to a standard style of coding are the
following:

A coding standard gives a uniform appearance to the codes written by different engineers.

It facilitates code understanding and code reuse.

It promotes good programming practices.
A coding standard is a set of rules for coding, like how to name variables and format code.
Coding guidelines are similar, but broader, covering practices and suggestions. The main
difference is that standards are strict rules, while guidelines are more flexible suggestions.
Programmers must follow coding standards, which are strict rules. Compliance is checked
during code inspection. Code that doesn't meet standards is rejected and fixed. Coding
guidelines are suggestions, not strict rules, and developers have more freedom in how they
implement them.

10.1.1 Coding Standards and Guidelines

Good software development organizations create their own coding standards and guidelines
that suit their needs and the types of software they develop. Here are some common ones
that many organizations use.

Representative coding standards

1. Limiting global variables: Rules determine what data can be global, aiming to reduce the
need for global scope.
2. Standard module headers: Module headers should include module name, creation date,
author, modification history, synopsis, supported functions with parameters, and
accessed/modified global variables.
 3.Naming conventions: Variables use mixed case lettering. Global variables start with a
capital letter (e.g., GlobalData), local variables start with small letters (e.g., localData), and
constants use all capital letters (e.g., CONSTDATA).
4.Error handling conventions: All functions should consistently return a 0 or 1 for error
conditions, regardless of who wrote the code, to aid reuse and debugging.

5.Coding guidelines:
The following are some representative coding guidelines that are recommended by many software
development organisations.

Do not use a coding style that is too clever or too difficult to understand: Code should be
easy to understand. Complex coding can make maintenance and debugging difficult and
costly.
Avoid hidden side effects: Side effects of a function include changing passed parameters,
global variables, or performing I/O operations. Hidden side effects are not obvious from the
code, making it hard to understand. For example, if a function changes a global variable or
performs file I/O without clear indication, it makes the code difficult to grasp.

Do not use an identifier for multiple purposes:

Avoid using the same variable for different things. While it may save memory, it makes code
confusing and hard to understand. Each variable should have a clear name indicating what
it's for. Reusing variables can lead to mistakes and make code difficult to read.
Give each variable a clear name to show what it's for. Using one variable for multiple things
confuses readers and makes understanding the code hard. Also, it makes future changes
harder. For instance, if you need to change a variable's type, using it for different purposes
might cause unexpected issues.
Code should be well-documented: As a rule of thumb, there should be at least one
comment line on the average for every three source lines of code.
Length of any function should not exceed 10 source lines:Keep functions short, ideally
under 10 lines. Long functions are hard to understand and likely to have more bugs.
Do not use GO TO statements: Use of GO TO statements makes a program unstructured.
This makes the program very difficult to understand, debug, and maintain.

10.3 SOFTWARE DOCUMENTATION

In software development, besides the executable files and source code, various documents
like user manuals, requirements specs, design docs, tests, and installation guides are crucial.
They help in understanding, using, and maintaining the software, as well as managing
project progress.

Good documents are hepful in following ways:

- Good documents make code easier to understand, reducing maintenance time.

- Documents help users understand and use the system effectively.

- They ease the transition when staff changes, allowing new engineers to learn quickly.
- Good documents help managers track project progress and measure achievements.

Different types of software documents can broadly be classified into the following:

Internal documentation: These are provided in the source code itself.

External documentation: These are the supporting documents such as SRS document,
installation document, user manual, design document, and test document.

10.3.1 Internal Documentation

Internal documentation is the code comprehension features provided in the source code itself.
Internal documentation can be provided in the code in several forms. The important types of
internal documentation are the following: Comments embedded in the source code. Use of
meaningful variable names. Module and function headers. Code indentation. Code structuring (i.e.,
code decomposed into modules and functions). Use of enumerated types. Use of constant
identifiers. Use of user-defined data types.

Meaningful variable names are the most valuable type of internal documentation for
understanding code. This is more useful than code comments, especially if the comments
are trivial. Good software organizations prioritize meaningful variable names in their coding
standards and guidelines, as they significantly aid code comprehension.

10.3.2 External Documentation:

External documentation, like user manuals and design docs, should be consistent with the
code. If they're not, it creates confusion. All documents should be kept up-to-date with any
changes in the code. They should also be easy for users to understand. Gunning’s fog index
helps ensure this.
Gunning’s fog index

Gunning’s fog index is a metric to measure how easy a document is to read. It tells you how
many years of education someone needs to understand it easily. For example, if a document
has a fog index of 12, someone who finished 12th grade should find it easy to understand.
The fog index is calculated based on the complexity of the words and sentences in the
document.

The fog index is calculated using two factors. First, it looks at the average number of words
per sentence, which shows if sentences are long and hard to understand. Second, it
measures the percentage of complex words in the document. A complex word is one with
many syllables. Note that a syllable is a group o f words that can be independently pronounced. For
example, the word “sentence” has three syllables (“sen”, “ten”, and “ce”). Words having more than
three syllables are complex words and presence of many such words hamper readability of a
document.

10.4 TESTING
The aim of program testing is to find defects, but it's impossible to guarantee a program is
error-free. This is because programs have large input data domains, making exhaustive
testing impractical. For example, even testing a function with floating point numbers would
take millions of years with millions of testers. However, testing is still crucial, as it helps find
a large percentage of defects and reduces errors in a system.

10.4.1 Basic Concepts and Terminologies

In this section, we will discuss a few basic concepts in program testing on which our
subsequent discussions on program testing would be based.

How to test a program?

Testing a program involves running it with different test inputs and checking if it behaves as
expected. If it doesn't, we note the input data and conditions when it fails for later
debugging. In simple terms, the tester tries different inputs to see if the program works
correctly. It's important to note down when and why the program fails, as it helps
developers fix the issues. For example, a program might only fail when there's a network
connection.

Terminologies
In software testing, there are specific terms that are commonly used. Let's go over a few
important ones standardized by the IEEE Standard Glossary of Software Engineering
Terminology [IEEE90]:
• A mistake is any action by a programmer that leads to incorrect results during
program execution. For example, forgetting to initialize a variable or overlooking
errors like division by zero are mistakes.
• An error is the incorrect result caused by a mistake. For instance, calling the wrong
function is an error.
In software testing, "error," "fault," "bug," and "defect" are often used interchangeably.
However, in hardware testing, "fault" has a different meaning compared to "error" and
"bug."
Example 10.4: Suppose you have two programs that do the same thing. How do you know
which one is easier to test?
Answer: A program is easier to test if it needs fewer test cases to check it thoroughly.
Basically, simpler programs are easier to test. You can measure complexity with metrics like
the number of decision statements. So, a more testable program has a lower complexity.

A "failure mode" is a way the software can go wrong that you can see. For instance, in a
railway ticket booking program, failing to book an available seat, booking the wrong seat, or
crashing the system are failure modes.

"Equivalent faults" are bugs that cause the same failure mode. For example, in C, dividing
by zero or accessing illegal memory both crash the program. These are equivalent faults
because they both lead to the same failure.

Verification versus validation

Verification and validation techniques aim to find errors in software, but they work
differently.

Verification checks if each phase of software development produces the right output based
on the input of the previous phase. Validation checks if the final software meets the
customer's requirements.

Verification:

- It ensures that each phase's output matches the input requirements.

- Techniques include review, simulation, formal verification, and testing.
- Testing in verification focuses on unit and integration testing to check if the code meets
specifications.

- Verification doesn't require executing the software.

- It's done during development to ensure things are on track.

Validation :

- It checks if the final software meets the customer's needs.

- Testing in validation focuses on system testing to see if the software meets requirements.
- Validation requires executing the software.

- It's done to ensure the right product is built for the customer.
Verification aims to catch errors early to reduce costs, while validation confirms that the
software meets the customer's needs.
While verification is concerned with phase containment of errors, the aim of validation is to check
whether the deliverable software is error free.

Verification and validation are like different types of bug filters. To ensure high product
reliability affordably, development teams need to do both. Together, they're called "V and
V" activities.
Based on the above discussions, we can conclude that: Error detection techniques = Verification
techniques + Validation techniques

10.4.2 Testing Activities

Testing involves several main activities:
1. Test suite design: Creating a set of test cases to test the program. This involves using
various test case design techniques.
2. Running test cases and checking results: Each test case is executed, and the actual
results are compared with the expected results. Any mismatch indicates a failure. Failed test
cases are noted for later debugging.
3. Locate errors: Analyzing failure symptoms to find errors. For each failed test case,
identifying the statements causing the error.

4. Error correction: Making appropriate changes to the code to fix the identified errors.
These activities are shown in Figure 10.2. Test cases are designed and executed, failures are
debugged to find errors, and then errors are corrected. Debugging is often the most time-
consuming activity.
UNIT TEST:
Unit testing happens after a module has been coded and reviewed. Usually, the coder of the
module does this. Before starting unit testing, we need to design the unit test cases and set
up the testing environment. Let's talk about what's needed for unit testing.

Driver and stub modules

To test a single module properly, we need a complete environment that includes all the
necessary code for executing the module. This includes:
1. Procedures from other modules: The module being tested might call procedures from
other modules.
2. Non-local data structures: The module might access data from other parts of the
program.
3. Procedure to call the module under test: We need a way to call the functions of the
module being tested with the right inputs.
Since these parts might not be available until they are tested themselves, we use stubs and
drivers to provide this complete environment for testing the module.
Stub: A stub procedure is a simple, dummy procedure that has the same input and output
parameters as the function called by the unit under test.

Driver: A driver module should include the data structures accessed by the module under
test. It also needs to have the code to call the various functions of the unit under test with
the right parameter values for testing.

BLACK BOX TESTING: