Saturday, September 16, 2017

WebApp Interface Design | Interface Design Principles and Guidelines | Interface Design Workflow | Mapping User Objectives

WebApp Interface Design 

  • Introduction : WebApp interface design should be perfect so it answers three primary questions for the end user.
  • Where am I? The interface should 
    • provide an indication of the WebApp that has been accessed 
    • inform the user of her location in the content hierarchy.
  • What can I do now? The interface should always help the user understand his current options 
    • what functions are available? 
    • what links are live? 
    • what content is relevant? 
  • Where have I been, where am I going? The interface must facilitate navigation. Provide a "map".
  • An effective WebApp interface must provide answers for each of these questions as the end user navigates through content and functionality.

Interface Design Principles and Guidelines

  • Anticipation (Expectation) 
    • A WebApp should be designed so that it anticipates the user's next move. 
    • For example, consider a customer support WebApp developed by a manufacturer of computer printers. 
    • The designer of the WebApp should anticipate that the user might request a download of the driver and should provide navigation facilities that allow to download latest driver without searching. 
  • Communication
    • The interface should communicate the status of any activity initiated by the user. 
    • Communication can be obvious (e.g., a text message) or displaying a current location of page.
  • Consistency 
    • The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout) should be consistent throughout the WebApp. 
  • Controlled autonomy 
    • The interface should facilitate user movement throughout the WebApp, but it should be in a manner that enforces navigation conventions that have been established for the application. 
    • For example, navigation to secure portions of the WebApp should be controlled by userID and password.
  • Efficiency 
    • The design of the WebApp and its interface should optimize the user's work efficiency, not the efficiency of the developer who designs and builds it or the client server environment that executes it.
  • Flexibility 
    • The interface should be flexible enough to enable some users to accomplish tasks directly 
  • Focus 
    • The WebApp interface (and the content it presents) should stay focused on the user task(s) at hand. 
  • Fitt's Law 
    • "The time to acquire a target is a function of the distance to and size of the target."
  • Human interface objects
    • A vast library of reusable human interface objects has been developed for WebApps.
  • Latency reduction 
    • Rather than making the user wait for some internal operation to complete (e.g., downloading a complex graphical image), the WebApp should use multitasking in a way that lets the user proceed with work as if the operation has been completed.
  • Learnability
    • A WebApp interface should be designed to minimize learning time, and once learned, to minimize relearning required when the WebApp is revisited.
  • Metaphors (Symbol / Image) 
    • An interface that uses an interaction metaphor is easier to learn and easier to use, as long as the metaphor is appropriate for the application and the user.
  • Maintain work product integrity 
    • A work product (e.g., a form completed by the user, a user specified list) must be automatically saved so that it will not be lost if an error occurs.
  • Readability 
    • All information presented through the interface should be readable by young and old.
  • Track state 
    • When appropriate, the state of the user interaction should be tracked and stored so that a user can logoff and return later to pick up where she left off.

Interface Design Workflow

  • Review information contained in the analysis model and refine as required. 
  • Develop a rough sketch of the WebApp interface layout. 
  • Map user objectives into specific interface actions.
  • Define a set of user tasks that are associated with each action.
  • Storyboard screen images for each interface action.
  • Refine interface layout and storyboards using input from aesthetic design.
  • Identify user interface objects that are required to implement the interface.
  • Develop a procedural representation of the user’s interaction with the interface.
  • Develop a behavioral representation of the interface. 
  • Describe the interface layout for each state.
  • Refine and review the interface design model.

Mapping User Objectives 

Mapping User Objectives

Sunday, September 3, 2017

Interface Design Steps | Interface Design Issues

Interface Design Steps

  • Introduction : Once interface analysis has been completed, all tasks (or objects and actions) required by the end user have been identified in detail and the interface design activity commences. 
  • Interface design, like all software engineering design, is an iterative process. 
  • Many different user interface design models have been proposed, all suggest some combination of the following steps : 
    • Define interface objects and actions (operations). 
      • Information developed during interface analysis, 
    • Define events (user actions) 
      • that will cause the state of the user interface to change. Model this behavior. 
    • Depict (Represent) each interface state 
      • It will actually look to the end-user. 
    • Indicate how the user interprets the state of the system from information provided through the interface.

Interface Design Issues

  • Introduction : Four common design issues almost always surface:
    • (1) System response time,
    • (2) User help facilities,
    • (3) Error information handling,
    • (4) Command labeling.
  • It is far better to establish each as a design issue to be considered at the beginning of software design, when changes are easy and  costs are low.
(1) System response time,
  • System response time is the primary complaint for many interactive applications.
  • In general, system response time is measured from the point at which the user performs some control action (e.g., hits the return key or clicks a mouse) until the software responds with desired output or action.
(2) Help facilities, 
  • Almost every user of an interactive, computer-based system requires help now and then.
  • In some cases, a simple question addressed to a knowledgeable colleague can do the trick.
  • In others, detailed research in a multivolume set of “user manuals” may be the only option.
  • In most cases, however, modern software provides online help facilities that enable a user to get a question answered or resolve a problem without leaving the interface.
(3) Error Handling,
  • Every error message or warning produced by an interactive system should have the following characteristics.
    • The message should describe the problem in descriptive that the user can understand.
    • The message should provide constructive advice for recovering from the error.
    • The message should indicate any negative consequences of the error (e.g., potentially corrupted data files)
    • The message should be accompanied by an audible or visual cue.
    • The message should be “nonjudgmental.” That is, the wording should never place blame on the user.
(4) Menu and command labeling.
  • The typed command was once the most common mode of interaction between user and system software and was commonly used for applications of every type.

User Interface Design Process | Interface Analysis | User Analysis

User Interface Design Process

  • The user interface analysis and design process begins at the interior of the spiral and includes four distinct framework activities
    • (1) Interface analysis and modeling, 
    • (2) Interface design, 
    • (3) Interface construction, 
    • (4) Interface validation. 
  • The spiral shown in Figure implies that each of these tasks will occur more than one time…

User Interface Design Process

  • Interface analysis
    • It focuses on the profile of the users who will interact with the system. 
    • Skill level, business understanding, and general , different user categories are defined. For each user category, requirements are elicited. 
  • The goal of interface design is to define a set of interface objects and actions (and their screen representations) that enable a user to perform all defined tasks in a manner that meets every usability goal defined for the system.
  • Interface construction normally begins with the creation of a prototype that enables usage scenarios to be evaluated. 
  • Interface validation focuses on 
    • (1) The ability of the interface to implement every user task correctly, to accommodate all task variations, and to achieve all general user requirements; 
    • (2) the degree to which the interface is easy to use and easy to learn, 
    • (3) the users’ acceptance of the interface as a useful tool in their work.

Interface Analysis

  • Interface analysis means understanding 
    • (1) the people (end-users) who will interact with the system  
    • through the interface;
    • (2) the tasks that end-users must perform to do their work,
    • (3) the content that is presented as part of the interface
    • (4) the environment in which these tasks will be conducted.

User Analysis

  • Introduction : The following set of questions will help you to better understand the users of a system
  • Are users trained professionals, technician, clerical, or manufacturing workers?
  • What level of formal education does the average user have?
  • Are the users capable of learning from written materials or have they expressed a desire for classroom training?
  • Are users expert typists or keyboard phobic?
  • What is the age range of the user community?
  • How are users compensated for the work they perform? 
  • Do users work normal office hours or do they work until the job is done? 
  • Is the software to be an integral part of the work users do or will it be used only occasionally? 
  • What is the primary spoken language among users? 
  • What are the consequences if a user makes a mistake using the system? 
  • Are users experts in the subject matter that is addressed by the system? 
  • Do users want to know about the technology the sits behind the interface?

Sunday, August 13, 2017

User Interface Analysis & Design Models

User Interface Analysis & Design Models

  • Four different models come into play when a user interface is to be analyzed and designed. 
  • User model : 
    • Established by a human engineer (or the software engineer) 
    • A profile of all end users of the system. 
    • Users can be categorized as 
      • Novices. No syntactic knowledge of the system and little semantic knowledge of the application or computer usage in general. 
      • Knowledgeable, intermittent users. Reasonable semantic knowledge of the application. 
      • Knowledgeable, frequent users. Good semantic and syntactic knowledge 
  • Design model :
  • Created by the software engineer. 
  • A design realization of the user model 
    • To build an effective user interface, “all design should begin with an understanding of the intended users, including profiles of their age, gender, physical abilities, education, cultural or ethnic background, motivation, goals and personality.
  • User’s mental model : 
    • The end user develops a mental image that is often called the User’s mental model or the system perception, 
    • The user’s mental image of what the interface is 
  • Implementation model : 
    • Created by the implementer of the system.

Saturday, August 12, 2017

User Interface Design & its golden rules

User Interface Design & its golden rules 

  •  Introduction :
    • User interface design creates an effective communication medium between a human and a computer.
  • The following are the three golden rules for user interface design.
    • (1) Place the user in control
    • (2) Reduce the user’s memory load
    • (3) Make the interface consistent

  • (1) Place the user in Control. 
    • As a designer, you may be tempted to introduce constraints and limitations to simplify the implementation of the interface. 
  • The result may be an interface that is easy to build, but trying to use.
  •  Mandel defines a number of design principles that allow the user to maintain control: 
    • Define interaction modes in a way that does not force a user into unnecessary or undesired actions. 
    • Provide for flexible interaction 
      • Because different users have different interaction preferences, choices should be provided. For example, software might allow a user to interact via keyboard commands, mouse movement, a digitizer pen
  • Allow user interaction to be interruptible and undoable. 
    • When involved in a sequence of actions, the user should be able to interrupt the sequence to do something else (without losing the work that had been done). 
    • The user should also be able to “undo” any action. 
  • Streamline interaction as skill levels advance and allow the interaction to be customized. 
    • Users often find that they perform the same sequence of interactions repeatedly. 
  • Hide technical internals from the casual user. 
    • The user should not be aware of the operating system, file management functions, or other arcane computing technology. In essence, the interface should never require that the user interact at a level that is “inside” the machine (e.g., a user should never be required to type operating system commands from within application software)
  • Design for direct interaction with objects that appear on the screen.
    • For example, an application interface that allows a user to “stretch” an object (scale it in size) is an implementation of direct manipulation.
  • (2) Reduce the User’s Memory Load
  • The more a user has to remember, the more error-prone the interaction with the system will be.
  • It is for this reason that a well-designed user interface does not tax the user’s memory.
  • Mandel defines design principles that enable an interface to reduce the user’s memory load…
  • Reduce demand on short-term memory.
    • The interface should be designed to reduce the requirement to remember past actions, inputs, and results. This can be accomplished by providing visual cues that enable a user to recognize past actions, rather than having to recall them
  • Establish meaningful defaults :
    • The initial set of defaults should make sense for the average user, but a user should be able to specify individual preferences. However, a “reset” option should be available, enabling the redefinition of original default values.
  • Define shortcuts that are perceptive.
    • When mnemonics are used to accomplish a system function (e.g., alt-P to invoke the print function), the mnemonic should be tied to the action in a way that is easy to remember (e.g., first letter of the task to be invoked)
  • The visual layout of the interface should be based on a real-world metaphor (Symbol / Image).
    • This enables the user to rely on well-understood visual cues, rather than memorizing an hidden interaction sequence.
  • Disclose information in a progressive fashion :
    • The interface should be organized hierarchically. That is, information about a task, an object, or some behavior should be presented first at a high level of abstraction. More detail should be presented after the user indicates interest with a mouse pick. [Similar like combo box control.]
  • (3) Make the Interface Consistent :
    • The interface should present and acquire information in a consistent fashion.
      • (1) All visual information is organized according to design rules that are maintained throughout all screen displays,
      • (2) Input mechanisms are constrained to a limited set that is used consistently throughout the application,
      • (3) Mechanisms for navigating from task to task are consistently defined and implemented.
  • Mandel defines a set of design principles that help make the interface consistent.
  • Allow the user to put the current task into a meaningful context.
    • Many interfaces implement complex layers of interactions with dozens of screen images.
    • It is important to provide indicators (e.g., window titles, graphical icons, consistent color coding) that enable the user to know the context of the work at hand.
  • Maintain consistency across a family of applications :
    • A set of applications (or products) should all implement the same design rules so that consistency is maintained for all interaction.
    • If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.
    • Once a particular interactive sequence has become a standard (e.g., the use of Ctrl + S to save a file), the user expects this in every application he encounters.
    • A change (e.g., using Ctrl + S to invoke scaling) will cause confusion.

Sunday, August 6, 2017

Component Based Development

Component Based Development

  • Component-based software engineering (CBSE) is a process that emphasizes the design and construction of computer-based systems using reusable software “components.” 
  • Clements describes CBSE in the following way… 
  • A number of questions arise like …. 
    • Is it possible to construct complex systems by assembling them from a catalog of reusable software components?
    • Can this be accomplished in a cost- and time-effective manner? 
    • Can appropriate incentives be established to encourage software engineers to reuse rather than reinvent? 
    • Is management willing to incur the added expense associated with creating reusable software components? 
  • Increasingly, the answer to each of these questions is “yes.”
  • Domain Engineering 
  • The objective of domain engineering is to identify, construct, catalog, and disseminate (distribute) a set of software components that have applicability to existing and future software in a particular application domain. 
  • The overall goal is to establish mechanisms that enable software engineers to share these components—to reuse them—during work on new and existing systems. 
  • It provides the library of reusable components that are required for component based SE. 
  • Domain engineering includes three major activities 
    • Analysis,
    • Construction,
    • Dissemination [Distribution]
  • Component Qualification :
    • Component qualification ensures that a candidate component will perform the function required, will properly “fit” into the architectural style specified for the system, and will exhibit the quality characteristics (e.g., performance, reliability, usability) that are required for the application. 
  • The following factors are considered during component qualification : 
    • Application programming interface (API). 
    • Development and integration tools required by the component. 
    • Run-time requirements, including resource usage (e.g., memory or storage), 
    • timing or speed, and network protocol. 
    • Service requirements, including operating system interfaces and support from other components. 
    • Security features, including access controls and authentication protocol. 
    • Exception handling
  • Component Adaptation : 
    • Domain engineering creates a library of components that can be easily integrated into an application architecture. 
    • The implication of “easy integration” is that 
      • (1) Consistent methods of resource management have been implemented for all components in the library, 
      • (2) Common activities such as data management exist for all components, 
      • (3) Interfaces within the architecture and with the external environment have been implemented in a consistent manner.
  • Component Composition
  • The component composition task assembles qualified, adapted, and engineered components to populate the architecture established for an application. 
  • A library of components must be available. 
  • Components should have a consistent structure. 
  • A standard should exist, e.g., 
    • OMG/CORBA   [Object Mgt Group / Common Object request broker architecture] 
    • Microsoft COM and .Net   [Com – Common Object Model] 
    • Sun JavaBeans

Saturday, August 5, 2017

Designing Traditional Components

Designing Traditional Components

  • Introduction : Traditional components are designed based on different constructs like 
    • Sequence,
    • Condition, 
    • Repetition. 
  • Sequence implements processing steps that are essential in the specification of any algorithm. 
  • Condition provides the facility for selected processing based on some logical occurrence. 
  • Repetition allows for looping. 
  • These three constructs are fundamental to structured programming— an important component-level design technique.
  • The use of the structured constructs reduces program complexity and thereby enhances readability, testability, and maintainability. 
  • The use of a limited number of logical constructs also contributes to a human understanding process that psychologists call chunking.
  • Graphical Design Notation 
    • A picture is worth a thousand words,” but it’s rather important to know which picture and which 1000 words. 
    • There is no question that graphical tools, such as the UML activity diagram or the flowchart, provide useful pictorial patterns that readily depict procedural detail. 
    • The activity diagram allows you to represent sequence, condition, and repetition— all elements of structured programming. 
    • It is a descendent of an earlier pictorial design representation (still used widely) called a flowchart. 
    • A flowchart, like an activity diagram, is quite simple pictorially. A box is used to indicate a processing step. A diamond represents a logical condition, and arrows show the flow of control
Graphical Design Notation

  • Tabular Design Notation 
    • In many software applications, a module may be required to evaluate a complex combination of conditions and select appropriate actions based on these conditions.
    • Decision tables provide a notation that translates actions and conditions into a tabular form. 
    • The table is difficult to misinterpret and may even be used as a machine-readable input to a table-driven algorithm.
Decision tables | Tabular Design Notation

  • Program Design Language 
    • Program design language (PDL), also called structured English or pseudocode, 
    • It incorporates the logical structure of a programming language with the free-form expressive ability of a natural language (e.g., English). 
    • Narrative text (e.g., English) is embedded within a programming language-like syntax. 
    • Automated tools can be used to enhance the application of PDL.
    • A basic PDL syntax should include constructs for 
      • Component definition, 
      • Interface description, 
      • Data declaration, 
      • Block structuring, 
      • Condition constructs, 
      • Repetition constructs, 
      • Input-output (I/O) constructs. 
    • It should be noted that PDL can be extended to include keywords.

Program design language (PDL)