UNIT 2 SPECIFICATION OF USER INTERFACES (GUIS)

Question 1

Briefly describe what a Graphical User Interface (GUI) is and what elements are part of it.

Answer 1

The graphical user interface (GUI) refers to the parts of an application which are recognizable to human users. It is the interface where information is made available to and received from users in a format intelligible to humans. Most industrial information systems have a GUI. In other words, information is presented in a visual format to be seen by users. Alternatively, information may be given in an acoustic (e.g., as speech output) or haptic format (e.g., in Braille).
A typical user interface uses graphical symbols, such as windows, menus, symbols, texts, and input elements, to present information, and users interact with the software using a keyboard and pointing devices. Typical forms of user interaction include keyboard entries or clicking, holding, dragging, and releasing a pointing device. As touch screens and movement sensors are becoming increasingly popular, gestures with one or more fingers and moving the input device within the space (e.g., shaking or tilting), are also supported.

Question 2

What are operational systems?

Answer 2

These systems selectively support business processes and activities in organizations. There is typically a major emphasis on the value-creating and supporting processes
within organizations. They are used primarily to support business processes. The more industry-specific and individual an information system is, the more its GUI will be specifically modified and aligned with business- and organization-specific features. The system’s GUI helps to guide and navigate the user through the functional process.
Users can see the properties of domain objects and process them. They can also input decisions into the system where this is required to control operations in the business process.

Question 3

What is a dialog in GUI specification and what parts is it comprised of?

Answer 3

A dialog guides the user through the system and assist
with task processing. A dialog is comprised of one or more dialog boxes and a predefined dialog flow.

Question 4

What is a dialog box?

Answer 4

A dialog box (also known as a “screen mask,” or simply “mask”) combines numerous input and output elements. Each mask will usually correspond to one interaction step relating to a specialist function supported by the system and is usually implemented in the form of a screen page. The structure and content of each dialog box must be defined in the GUI specification. As well as the type, size, and position of dialog elements, it may also be necessary to include rules on their activation and deactivation. Consistent representation of the (technical) content is also important; identical domain objects in different dialog boxes should have identical modeling wherever possible.
Data stored in the system database must be converted into a format that can be seen and read by users before appearing in a dialog box. Where system users are required to process specialist information, technical and conceptual validation of their entries is required. Validation ensures that the data entered are conceptually correct. As well as technical validation of the correct data type, conceptual validation is also needed.

Question 5

What is a dialog flow?

Answer 5

Typically, an information system’s GUI comprises multiple dialog boxes, which support the user when processing a task. The options for navigating between dialog boxes are
known as a dialog flow. A dialog flow depicts the sequence of operations requiring the processing of multiple masks in succession. The dialog box that appears in the next step is often derived from the values entered by the user in the preceding masks. Specification of a dialog flow encompasses
* every mask used in the workflow;
* the defined sequence in which masks appear;
* manual navigation options between masks (e.g., back and next); and
* dialog flow conditions to control when certain masks can be skipped.
Together with the conversions outlined above and the technical and conceptual validations, these elements make up a complete GUI specification. The documentation format
and level of detail depend on the specific project situation and associated requirements.

Question 6

How should GUI be documented in specification?

Answer 6

User interfaces are specified both visually and in text form. The visual specification defines the appearance of the elements used and how they are arranged on the screen. It may include sketches and screenshots of GUI prototypes and simple diagrams indicating the sequence of dialog boxes. The text specification explains correlations that cannot be expressed visually or whose visualization is too complicated. This includes rules on the activation and deactivation of GUI elements, validation rules, and dialog flow conditions.
When using GUI prototypes, it is important to include a text description with the graphical representation, which should contain the following aspects:
* intended purpose of the GUI or reference to the business process
* required and depicted domain objects
* runtime parameters for activating and deactivating elements of the GUI
* dependencies on other GUIs
* validation rules for technical and conceptual validation

Question 7

What are the three basic categories of GUI components?

Answer 7

1. Atomic
2. Composite
3. Complex

Question 8

What are some Atomic GUI Components?

Answer 8

Atomic GUI components are simple elements for displaying and processing individual values. They cannot be broken down any further.
Some of their elements are for example:
* labels
* text boxes
* checkboxes
* dropdown boxes

Question 9

What are some Composite GUI Components?

Answer 9

Composite components are GUI components comprising multiple atomic GUI components. They are used to structure the user interface and aid clarity.
Some of their elements are for example:
* Option boxes
* Tables
* Grouping

Question 10

What are some Complex GUI Components?

Answer 10

Complex GUI components are used to display and process complex values and data structures. They often implement a complex modeling and validation logic, such as a graphical calendar component for entering dates or a map component for entering a geographical location.
Some of their elements are for example:
* calendars
* tree menus
* editors

Question 11

What are some GUI Components for the Input and Output of Simple Data Types?

Answer 11

Conceptual data models are often used as the basis when
specifying GUIs. The GUI specification must enable users to enter every required value in the required format, ideally without errors, in the information system.
Some of the data types and input elements are:
* String (<1000 chars) -> text box
* Text (>1000 chars) -> Multi-line text box
* Whole numbers (integer, long) -> Text box
* Numbers (float, double) -> Text box
* Monetary amounts -> Text box
* Date -> Text box or Calendar
* Logical value (3-state Boolean) -> Checkbox (yes/no only) or Dropdown list (for 3-state Boolean)
* 1-of-n selection: enumeration types (strings or numbers) -> Dropdown list, Option button or Multiple checkboxes
* m-of-n selection: enumeration types (strings or numbers) -> Multiple checkboxes

Question 12

What are some input elements that should be read-only and why?

Answer 12

A read-only view displays the entered data but cannot be edited. This type of view is often found at the end of an ordering process. While read-only views can usually be set for any input element, they are not always user-friendly. Text boxes are often shown against a grey background to indicate that they cannot be edited, but this makes them harder to read. Consequently, it is often necessary to define a suitable read-only view for each input element, depending on the application.
Some suggested Read-Only View for Input Elements are:
* Text box Simple text
* Multi-line text box Simple text
* Calendar and date input. Simple text, formatted, date format typically depends on the user’s localization
* Dropdown list Simple text
* Option button and checkbox. Pre-defined labels or icons for each selected option

Question 13

What are some aspects to consider when spcifying enumerations?

Answer 13

The 1-of-n selection with predefined selection options is a common type of input element known as enumeration. Unlike simple value inputs, when specifying GUI elements for the input and output of enumerations, additional aspects must be taken into account.
* Conceptual label (per value): Where applicable, allow for internationalization.
* Technical label (per value): String used internally in the GUI to identify a selectable value
* Default setting (per input element)
* Sequence of potential values (per input element): The sequence of selection options must be specified for each input element.
When writing the specification, take care to consider all relevant requirements and settings for the input and output of enumerations. Particularly when lists of options are generated automatically or configured by administrators, the information required is fairly complex and should not be underestimated.
For multi-lingual, multi-cultural applications in particular, allowance must be made for various conceptual labels and consideration must be given to how this may influence the
sequence of potential options.

Question 14

Why might it be necessary for some application-specific elements to be conversed in GUI specification?

Answer 14

As well as inputting and outputting domain objects via the GUI, a very specific form of rendering is often required with simple values. If this differs from the format stored in the database, it will need to be converted for data input and output purposes.
When devising an expedient input option in a graphical user interface, it is first necessary to select a suitable presentation format, then define how the format stored in the data model is to be converted to that format.
The representation of date and time entries and monetary amounts will, likewise, require special conversion guidelines. These are often provided by special components, such as
the calendar component as part of GUI frameworks.

Question 15

What is Validation in GUI specifications?

Answer 15

Certain GUI input elements, such as text boxes, allow users to enter any given values. These values must then be checked before they are transferred into the system and saved. Once the input elements of a dialog box have been specified, the validation rules for the dialog flow must also be specified. The system uses these rules as data are being entered by the user to gauge whether they meet the required quality from both a technical and a conceptual perspective.
As well as the actual validation rule itself, it is also necessary to specify the timing of evaluation, the consequences of violating the rule, and how users are told that a rule has been violated.

Question 16

What are the validations an input element might have to pass?

Answer 16

• Costraint (Condition): refers to the actual rule or condition evaluated by the system. A constraint should facilitate a clear “true or false” evaluation and is therefore often for-
  mulated as a Boolean expression. We distinguish between different types of constraints depending on the type of GUI element and the conceptual requirements applicable to the
  dialog. The validation types are: required field check (whether all the required values have been entered), conversion check (whether the inputs produce valid values), plausibility check (whether the converted values are plausible).
• Timing of the Evaluation (Transaction Level): is determined by specifying the timing of the user interaction when the constraint is actually evaluated. Not all constraints must be met at all times. Plausibility checks in particular often require multiple value inputs, which may even be entered in
  different masks. Typical timings (transaction level) include: exit the GUI component (suitable for conversion checks), exit the screen page (suitable for required field validation, conversion checks, and plausibility checks), data buffering (e.g., to resume processing at a later date: conversion checks), submit data to the system and exit the input process (e.g., required field validation, conversion checks, and plausibility checks).
  The specific timing of validation typically depends on both the conceptual requirements and the GUI technology used. Entries cannot always be validated immediately upon exiting the GUI component and may require a manual page change by the user.
• Validation Type (Error or Message): As well as forcing the input of certain values by the user, validation rules can also be used to display automatic messages when fields are completed because not every rule violation constitutes an error or prevents the processing of the entered data. Each validation rule may therefore be specified as either an error or a message. While recognized errors must be rectified before ongoing work can continue, messages do not affect data storage and transmission.

Question 17

Describe the three validation types for Constraints in GUI specification.

Answer 17

• The required field check means checking whether the user has actually entered a value in the GUI element. In many applications, certain pieces of information are required by the system. Specifying GUI elements as required fields forces the user to make an entry; otherwise, this step cannot be completed.
• The conversion check reviews the user’s entry for correct formatting. A successful conversion check must be completed before the entered value can be converted into the conceptual model, processed, and saved. The conversion check is particularly important for entries made in text boxes.
• The plausibility check relates to one or more input boxes and checks to ensure that the entries in individual fields do not violate conceptual constraints when combined. Conceptual plausibility checks are particularly important in the case of longer dialogs across multiple screens involving complex correlations.

Question 18

How are operations divided during navigation in GUI specifications?

Answer 18

The operations in an application often comprise multiple steps, which must be executed in sequence. For clarity, this process can be broken down into a series of pages so that users are not confronted with too many complex boxes at once. It also allows support to be provided for each individual step with more detailed prompts. With each page change, the data already entered are processed and the GUI elements on subsequent pages are updated to reflect the current data model.

Question 19

What aspects must be taken into account when specifying a dialog flow?

Answer 19

A dialog is sub-divided into multiple dialog boxes. The specific sequence and options for navigating between individual dialog boxes are determined by the dialog flow.
The aspects that must be taken into account are:
* each box used in the workflow
* specification of the sequence in which boxes are displayed
* manual navigation options between boxes (back and next)
* dialog flow conditions to control the flow (skipping dialog boxes)

Question 20

What happens when Specifying Dialog Flows in UML State Diagrams and what are the typical elements of the UML State Diagram?

Answer 20

The aim when specifying dialog flows is to obtain a clear, precise, human-readable description of all potential operations through the dialog and relevant dialog flow conditions. UML state diagrams offer a simple option for the structured, visual specification of dialog flows. Each dialog box is represented by a state, while the navigation options between individual dialog boxes are modeled by a transition. A transition between two dialog boxes means that users can move from one box to the next in the direction indicated by the arrow. Transitions are triggered when navigation is activated, generally as a result of the user clicking on a button or link. Where necessary, navigation can also be activated by the system without any user input. When transitioning from one box to the next, it is possible to model the requirement to activate a technical function or perform certain checks in the form of an activity.
The typical elements are:
* dialog box (screen mask)
* initial status
* final status
* navigation (navigation between two dialog boxes)
* trigger/activation function (condition)
* decision
* merge

Question 21

What are some challenges you may encounter while specifying dialog flows?

Answer 21

A typical challenge we face when specifying dialog flows is how to describe standard and exception navigations. A typical standard navigation might access the help pages or the legal notice of all other dialog boxes. Exception navigations arise when the dialog is aborted because the application is closed (due to a timeout or long periods of inactivity by the user), or because of unscheduled errors, such as failure to access the booking system
when making a hotel reservation. As these types of navigation could occur on any page, a state diagram can quickly become extremely complex if we attempt to model all standard and exception navigations. Alternatively, commonly occurring navigations and those shared by all dialog boxes can be modeled as examples of one dialog box and then generalized for all other boxes in the descriptive text. As with requirements engineering, the main emphasis is on interpersonal communication. When modeling dialog flows, therefore, it is important to concentrate on a relevant rendering appropriate to the current communication situation.