Fear of a blank sheet when designing interfaces. Principles of user interface design What not to do at the interface design stage

2.2. STAGES OF DESIGNING A CUSTOM INTERFACE

Research conducted at one time into the psychological aspects of human communication with a computer showed that one should strive in every possible way to dehumanize this communication, that is, the user should not perceive the computer as a full-fledged interlocutor. Nevertheless, the exchange of information between the user and the computer (more precisely, its software) according to all formal characteristics corresponds to the concept of “dialogue” in the generally accepted sense. Probably, the reader, even without the help of an Explanatory Dictionary, will be able to list the basic rules that must be followed in order for the dialogue to be constructive:

firstly, the participants in the dialogue must understand each other’s language;

secondly, they should not speak at the same time;

thirdly, the next statement must take into account both the general context of the dialogue and the latest information received from the interlocutor.

If interlocutors discuss issues related to any special field, they should adhere to the same terminology; if one of them is trying to explain something to the other, he should first explain the basic terms and concepts.

It should also be added that the use of additional expressive means contributes to better mutual understanding. Sometimes one successful illustration replaces dozens of words. For example, to the question “How to get to the library?” It is best to answer with a city map at hand.

Now let's remember what our interlocutors don't like.

First of all - excessive familiarity. In addition, few people like it when, during a conversation, they tug at their sleeve, unscrew a button, or use some other original methods of attracting attention. Very short answers and too long pauses can confuse the interlocutor, and the abuse of technical terms or jargon in general can lead to a premature end to the conversation.

The above considerations are very general and apply to almost any dialogue, regardless of the relationship between the interlocutors and the purpose of the dialogue. However, these factors significantly influence structure dialogue, that is, the form of communication. For example, if two friends meet, the dialogue resembles a game of tennis: the initiative alternates between one interlocutor and the other; if you come to a restaurant, then your communication with the waiter is limited to choosing dishes from the proposed menu, and when you apply for a foreign passport, the official will ask you to fill out one or two forms, and then review them, if necessary, clarifying certain points.

Thus, when designing a user interface, you need to determine:

Dialogue structure;

Possible scenario for the development of dialogue;

Visual attributes of the information displayed (message syntax).

2.2.1. CHOOSING A DIALOGUE STRUCTURE

Choosing a dialogue structure is the first step that must be completed when developing an interface.

The four options for dialogue structure discussed below are variations of the “question-answer” structure, however, each of them has its own characteristics and is most convenient for a certain class of tasks.

DIALOGUE OF “QUESTION - ANSWER” TYPE

The structure of the question-and-answer (Q&A) dialogue is based on an analogy with a regular interview. The system takes on the role of an interviewer and receives information from the user in the form of answers to questions. This is the most well-known dialogue structure; all computer-controlled dialogues, to one degree or another, consist of questions that the user answers. However, in the Q&A structure this process is made explicit. At each point in the dialogue, the system displays one question as a hint, to which the user gives one answer. Depending on the answer received, the system can decide which question to ask next. The Q&A structure provides a natural mechanism for entering both control messages (commands) and data. There are no restrictions on the range or type of input data that can be processed. There are systems that provide answers in natural language, but more often they use single-word sentences with limited grammar.

Dialogue in the form of questions and answers sufficiently provides user support, since even a short leading question, if structured wisely, can be self-explanatory. The Q&A structure does not guarantee a minimum amount of input as measured by the number of keystrokes, but with appropriate selection of abbreviations, any redundancy can be reduced. However, the Q&A structure has one significant drawback. Even if the input is fast enough, for a person who already knows what questions the system asks and what answers to give, answering the entire series of questions is quite tedious.

With the advent of the graphical interface, the Q&A structure has become somewhat outdated, but it still has certain advantages. This structure can meet the requirements of different users and data types. In particular, such a structure is especially appropriate when implementing a dialogue with many “branches”, i.e. in cases where each question has a large number of answers, each of which affects which question will be asked next. For this reason, the Q&A structure is often used in expert systems.

MENU BASED DIALOGUE

Menus are perhaps the most popular option for organizing requests for input during computer-controlled dialogue.

There are several basic formats for presenting menus on the screen:

A list of objects selected by direct indication or by indicating a number (or mnemonic code);

Menu in the form of a data block;

Menu in the form of a data line;

Menu in the form of icons.

A data bar menu can appear at the top or bottom of the screen and often remains in that position throughout the conversation. Thus, through the menu it is convenient to display possible options for input data available at any time while working with the system. If the system has a sufficiently large variety of action options, a hierarchical structure of the corresponding menus is organized. Additional menus in the form of blocks of data “pop up” on the screen in a position determined by the current position of the pointer, or “drop out” directly from the top-level menu bar. These menus disappear once an option is selected.

Icon-style menus feature a variety of selections scattered across the screen; often choice objects contain graphical representations of work options.

The user of a dialog menu can select an item by entering a text string that identifies that item, pointing to it directly, or browsing and selecting from a list. The system can display menu items sequentially, with the user selecting the item he needs by pressing a key.

The menu can be used equally well to enter both control messages and data. The appropriate menu structure depends on its size and organization, how menu items are selected, and the user's actual need for menu support.

A menu-type structure is the most natural mechanism for working with pointing and selection devices: a menu is a representation of the objects that the user selects. If the dialog consists entirely of menus, it is possible to implement a sequential interface in which the user uses only pointing devices; however, such consistency is rarely achievable in practice. It should also be noted that although working with these devices does not require professional keyboard skills, for a trained user this is not the fastest way to select from menus. Instead of specifying, the user can indicate his choice by entering the appropriate identifier.

A menu is the most convenient dialogue structure for untrained users; rigid order of opening and hierarchical nesting of menus can irritate a professional and slow down his work. Traditional menu structure is not flexible enough and does not fully accommodate dialogue adaptation techniques, such as type-ahead, which can speed up the pace of a trained user's work. The issues of organization and visual presentation of menus are discussed in more detail in the section “Designing Controls”.

DIALOGUE BASED ON SCREEN FORMS

Both the question-answer type structure and the menu type structure involve processing a single answer at each step of the dialogue. A dialogue based on screen forms allows processing of several responses at one step of the dialogue. In practice, forms are used mainly where accounting for any activity requires entering a fairly standard set of data. The person filling out the form can choose the sequence of answers, temporarily skip a certain question, go back to correct the previous answer, and even “tear the form” and start filling out a new one. He works with the form until he fills it completely and submits it to the system. The software system can check each answer immediately after entry, or wait and display a list of errors only after filling out the entire form. In some systems, the information the user enters is only available when the user presses enter after completing the form. The question of whether to check the answer directly or delay checking until all answers have been entered is a difficult one to decide: error messages displayed immediately after the answer can be a distraction, but they can also have a positive impact. In general, in cases where information for input is selected from some entire document, it is better to postpone the check until the end of filling out the form, so as not to interrupt the input process; if there is no such integrity, then the check should be performed immediately after entering the answer (after filling out the next field).

If any error is encountered, the application should not re-render the empty form; a form is displayed with previous answers and mistakes made. A new “form” is issued only if the user requests it.

Thus, this structure is appropriate to apply where the data source is an existing input (“paper”) document form.

The appearance of these forms does not need to be the same (this may even make the data on the screen less visible), but all data elements entered must be in the same relative order and format as in the original document.

Often all required input units cannot be displayed simultaneously within a single screen (or window) and must be divided into groups that are displayed on a sequence of screens (windows). It is important that this division preserves logical connections and does not lead to the separation of related parts of the document.

The screen form-based dialog structure provides a high level of user support: error messages and help information can be provided for each form question. You can also assist the user by including some elements of the response format in the question or response field. This structure allows for faster data entry than a question-answer structure and allows for the manipulation of a wider range of inputs than a menu; In addition, users of any qualification can work with it. Because this structure is sequential rather than tree-based, it is less suitable for choice mode work. Another area of ​​application for screen forms is setting query parameters in databases. This mechanism is sometimes called pattern query ( Query by Example).

One of the types of form filling is also multi-choice menus. In such menus, the user is presented with a list of options and is not limited to a single choice; You can specify several options.

DIALOGUE BASED ON COMMAND LANGUAGE

Command language-based dialogue structures are just as common as menu-type structures. It is very commonly used in operating systems and is at the other end of the dialog structure spectrum from the menu type structure. Historically, this is the first dialogue structure to be implemented.

With this type of dialogue, the software system does not display anything other than a constant prompt (invitation to enter a command), which means the system is ready for operation. Each command is entered on a new line and is usually ended by pressing the "enter" key. The user is responsible for the correctness of the commands specified. The system informs you that it is impossible to execute an incorrect command, usually without explaining the reasons.

Like a menu, a command-based dialog is convenient for entering control messages, but it provides greater choice at any point in the dialog and does not require a hierarchical organization of the programs that serve it.

A software system can support a fairly large number of commands, but in practice their number should be limited so as not to overload the user's memory. The command language-based structure does not have good user support and is mainly suitable for trained specialists. Before using such a system, it is necessary to complete a training course and subsequently study the features of the work from the documentation, and not from practice. Moreover, since the system does not know what the user intends to do, it is difficult to offer any real assistance in the process, other than issuing fairly general help.

Since this structure involves a large amount of memorized material, command names should be chosen so that they carry a semantic load and are easy to remember. The developer should strive to avoid unnecessary functionality, which comes from the desire to create its own command for each function performed by the system, that is, it should not create many different commands with often overlapping functions. Such “good” intentions often lead to a large number of keywords for commands and syntax rules, many of which are rarely used and only complicate the work.

Dialogue must drive data. In command language-based interfaces, this is typically achieved using compound command lines, where a keyword to indicate the command (what to do) precedes the list of parameters (input). Parameters in the list can be specified in one of two forms - positional or key. In the first case, the purpose of the parameter is determined by its place on the command line. In the case of key parameters, each value is preceded by a specific identifier that defines its purpose.

Positional Parameters reduce the amount of entered information, but their significant drawback is that the entered values ​​must be specified in a strictly defined order, the violation of which is poorly diagnosed by the system and can lead to serious consequences. Setting positional parameters becomes more complicated if the list of them is large enough. They try to compensate for this drawback by allowing immutable parameters to be omitted by introducing two delimiters one after the other.

Key parameters reduce the load on the user's memory in the sense that there is no need to remember the order of their occurrence; In addition, you can omit optional parameters. On the other hand, in this case the user needs to remember many keywords, and the developer needs to choose “meaningful” names for them. This approach also requires more system time to recognize random keywords.

Many command languages ​​support macros, which expand the functionality of the dialog without increasing the number of commands. The macro contains several separate command lines. When accessed during a dialog, individual lines of macro commands are executed one after another, as if they were entered from the keyboard. This significantly shortens dialogue sessions by containing frequently repeated sequences of commands, which, in fact, are formatted as macros.

The command language-based structure is the fastest and most flexible of all dialogue structures in its capabilities. Most "natural" language-based user interfaces are implemented using command languages ​​with a very large set of keywords. A trained user enjoys the feeling that he controls the system, and not vice versa. However, this structure does not provide user support, so even experienced users find it very difficult to use all the capabilities contained in it. Most users are familiar only with a very limited set of tools with which they work regularly.

The above can be presented in the form of a so-called “selection table” (Fig. 2.1).

* - the use of this type of dialogue by this category of users requires the presence of a help system;

** - use of system tools is possible only to a limited extent.

Rice. 2.1. Selection table option

Along with those indicated in the table, other selection criteria may be included in it (availability of interface development tools, user nature, limitations on available resources, etc.).

The selection of the most suitable dialogue structure based on the table is carried out as follows.

1. Close the “Dialog Type” columns.

2. In the “User Selection” column, mark the criteria relevant to the application in question.

The main value of the table is that it can be used as an initial option for choosing a dialogue type, or as a means of final checking that the selected dialogue type meets the criteria under consideration.

If some items are expected to be more important than others, they can be weighted differently. You can also specify which items should be considered as being carried out unconditionally; types of dialogue that do not meet at least one of these points must be immediately rejected, no matter how many points they score on the remaining points.

2.2.2. DEVELOPMENT OF A DIALOGUE SCRIPT

The development of dialogue over time can be considered as a sequence of system transitions from one state to another. Obviously, none of these states should be “dead-end”, i.e. the user must be able to move from any current state of the dialogue to the desired one (in one or more steps). To do this, during the development of the interface, it is necessary to determine all possible states of the dialogue and the paths of transition from one state to another. In other words, it is necessary to develop dialogue script.

The goals of developing a dialogue script are:

Identification and elimination of possible deadlock situations during the development of dialogue;

Choosing rational ways to transition from one dialogue state to another (from the current to the required);

Identifying ambiguous situations that require additional assistance to the user.

The complexity of developing a scenario is determined mainly by two factors:

the functionality of the application being created (i.e., the number and complexity of implemented information processing functions) and the degree of uncertainty of possible user actions.

In turn, the degree of uncertainty in user actions depends on the chosen dialogue structure. Menu-based dialogue has the greatest determinism, while user-controlled question-answer dialogue has the least determinism.

From the above it follows that the dialogue script can be simplified by reducing the degree of uncertainty in the user’s actions. Possible ways to solve this problem are:

using a mixed dialogue structure (using menus to “restrict the user’s freedom” where possible);

application of input control of input information (commands and data).

Additional opportunities for reducing the uncertainty of user actions are provided by an object-oriented approach to interface development, in which a list of properties and permissible operations is pre-established for each object. This approach is most effective when creating a graphical interface; These issues are discussed in more detail in the “Graphical Interface Features” section.

While reducing the number of possible dialog states, the developer must at the same time remember the need to reflect the user support tools in his script, which undoubtedly makes the script more complex.

The way a dialogue script is described depends on its degree of complexity. Existing methods for describing scenarios can be divided into two large groups:

informal and formal methods.

The main advantage of formal methods is that they allow you to automate both the design of the dialogue and its modification (adaptation) in accordance with the user's characteristics.

Currently, the most widely used formal methods for describing scenarios are based on Petri nets and their extensions, as well as on knowledge representation systems (frame models and production systems).

Regardless of how a scenario is described, its basic structural unit is dialogue step, corresponding to one act of user interaction with the system. The dialogue step can be schematically represented as shown in Fig. 2.2.

Rice. 2.2. Dialogue step

A dialogue script allows you to describe the process of user interaction with an application at the level of the application problem it solves. However, for a software implementation of the interface, such a description is too general. Therefore, at the implementation stage, it is necessary to move to the level of describing the relevant processes using the application development tools used.

PACE OF DIALOGUE

The process of communication between a user and a computer is associated with a number of significant objective and subjective limitations and must correspond to the psychophysiological capabilities of a person: the ability to receive and process information, the volume of sensory and short-term memory, the ability to concentrate attention on the most important information, the ability to reproduce information from long-term memory, etc. p.

In this regard, when developing a dialogue script, such psychophysiological characteristics of potential users as motor skills, reaction time, color sensitivity, etc. should be taken into account. In this section, we will consider in more detail the requirements for one of the most important characteristics of the interface - the provided pace of dialogue. The rest of the requirements listed above will be discussed in subsequent sections of the book.

The pace of the dialogue depends on the characteristics of the computer hardware and software, as well as on the specifics of the tasks being solved. The requirement that the pace of dialogue corresponds to the psychological characteristics of a person puts forward restrictions on the values ​​of these characteristics not only “from above”, but also “from below”. Let us clarify this statement.

Response time (response) systems is defined as the interval between an event and the system's response to it. This interface characteristic determines the delay in the user's work when moving to the next step of the task.

The importance of taking into account the pace of dialogue was realized back in the 60s, when the first interactive systems appeared. The slow response of the system does not meet the psychological needs of the user, which leads to a decrease in the efficiency of his activities. Replying too quickly can also create an unfavorable image of the system.

Response time requirements depend on what the user expects from the system and how interaction with the system affects the completion of his tasks. Research has shown [3] that if the response time is shorter than expected, the accuracy of selecting an operation from a menu increases as the system response time increases. This is due to the fact that an excessively fast response from the system, as it were, “hurries up” the user, forcing him to fuss in an effort to “keep up” with a more efficient communication partner. It has been noticed that a novice user is afraid to work with the system if, after spending a few minutes typing, he instantly receives a response from it with an error message.

Response times should match the natural rhythm of users. In a normal conversation, people wait about 2 seconds for an answer, and they expect the same when working on a computer. The waiting time depends on their condition and intentions. The user's beliefs are also strongly influenced by his previous experience with the system.

Typically, a person can simultaneously remember information about five to nine objects. It is also believed that the storage of data in short-term memory is limited in time: about 2 seconds for speech information and 30 seconds for sensory information. Therefore, people tend to break their activities into steps that correspond to the pieces of information that they can store simultaneously in memory. The completion of the next stage is called clause. Delays that prevent the onset of clauses are very harmful and unpleasant, since the contents of short-term memory require constant updating and are easily erased under the influence of external factors. But after the clause, such delays are quite acceptable and even necessary. Completion of a task leading to rest is called closing. At this moment, the need for further storage of information disappears and the person receives significant psychological relief. Since users intuitively strive for closure in your work, you should divide dialogues into fragments so that the user can forget intermediate information “in time”.

Users, especially beginners, usually prefer many small operations to one large operation, since in this case they can not only better control the overall progress of the solution and ensure its satisfactory progress, but also be distracted from the details of the work in previous stages.

The available research results made it possible to develop the following recommendations on the acceptable response time of an interactive system:

0.1... 0.2 s - to confirm physical actions (pressing a key, working with a light pen, “mouse”);

0.5... 1.0 s - to respond to simple commands (for example, from the moment a command is entered, selecting an alternative from the menu until a new image appears on the screen);

1... 2 s - when conducting a coherent dialogue (when the user perceives a series of interrelated questions as one piece of information to form one or several answers, the delay between successive questions should not exceed the specified duration);

2... 4 s - to respond to a complex request consisting of filling out a form. If the delay does not impact another user experience related to the first one, delays of up to 10 s may be acceptable;

more than 10 s - when working in multitasking mode, when the user perceives this task as a background process. It is generally accepted that if the user does not receive a response within 20 seconds, then it is not an interactive system. In this case, the user can “forget” about the task, move on to solving another problem, and return to it when it is convenient for him. In this case, the program must inform the user that the response delay is not a consequence of a system failure (for example, by regularly updating the system status bar or maintaining a log of the user's task).

METHODS OF FLEXIBLE INTERFACE DEVELOPMENT

A preliminary analysis (at least at a qualitative level) of a possible dialogue scenario allows you to avoid many problems at the application implementation stage. However, if the application can be used by a group of users with varying degrees of experience, a number of issues remain unresolved. It is therefore highly desirable that sufficient flexibility be allowed during the dialogue. It should be the ability of the application to adapt (by the user or automatically) to any possible user experience level.

There are three types of adaptation: fixed, complete and cosmetic.

At fixed adaptation, the user explicitly selects the level of dialog support. The simplest version of such adaptation is based on the use of a two-level rule, according to which the system provides two types of dialogue:

detailed (for a novice user);

short (for a trained user).

The two-level rule can be extended to an N-level dialogue rule. However, this approach has several disadvantages:

1) the fact that skills are accumulated gradually is not taken into account;

2) the user may know one part of the system well and not know another at all;

3) the user himself determines the level of his training, which reduces the objectivity of the assessment.

At full adaptation, the dialogue system strives to build a model of the user, which, as the latter learns, determines the dialogue style depending on these changes. In this case, one of the main problems is recognizing user characteristics. To solve it, it is necessary to determine what to use as such characteristics: the time it takes the user to respond, the number of times he asks for help, or the nature of the errors and the type of help requested.

At present, complete (automatic) adaptation of practically no dialogue system has been implemented.

Cosmetic adaptation is designed to provide dialogue flexibility without taking into account the user’s behavior, but also without unambiguously choosing a specific dialogue style.

Such adaptation can be achieved through the use of the following methods:

Use of defaults;

Use of abbreviations;

Advance answer entry;

Multi-level assistance;

Multilingual.

Using defaults. The essence of the default is that the system uses some initially specified value of a parameter until the user changes it. In this case, there are two aspects of system adaptation:

firstly, a novice user has the opportunity to use most of the default system parameters,

secondly, the system can remember the values ​​either specified during the last work session (for example, the name of the file being edited), or the most frequently used ones.

For the convenience of novice users, the default values ​​can be displayed along with the corresponding system question, for example: “Date of document registration? [current]".

The most common way to accept default values ​​is with a null input, i.e. simply pressing the "Enter" key as an answer to the system question. If a command language is used, the user simply skips the default option.

Using abbreviations assumes that the user can enter any valid abbreviation for the command instead of the full name. At first glance, it may seem that abbreviated input is more convenient for a novice user. But this is not entirely true. In order for the user to be able to replace a command with the correct abbreviation without hesitation, he must have a fairly good understanding of the available set of commands and master the “vocabulary” of the system. For example, if the system has commandsCopy And Compare, then it is easier for a beginner to type the full name than to choose the correct abbreviation.

One modification of this approach is forward character input, in which the system, having “recognized” the command from the first characters, “adds” it itself. An example would be the system interface GPSS/PC , in which when you enter the initial characters of a command, its full name is displayed on the screen, and the cursor automatically moves to the desired position for entering the parameters of this command. Of course, the user, especially a beginner, feels a sense of “deep gratitude” to such a system for “all possible help.”

Idea advance answer entry is that the user has the opportunity at the next step of the dialogue to enter not just one answer, but a chain of sequential answers, anticipating possible questions from the system.

One of the methods of providing multi-level assistance consists in the fact that an initial level message is first displayed on the screen, and then the user can clarify the information received by going to a lower level using a keyword. The work of many modern Help systems and educational hypertext systems is based on this principle.

Essence multilingualism interface is that the structure and semantics of the dialog messages that the user issues and receives must comply with the norms of the user’s native language and do not depend on the language in which the tools he uses are developed.

A possible approach to implementing multilingualism is to create means for the system to respond to user actions (request messages, hints, error messages) separately from the syntax of the programming language (tools).

2.2.3. VISUAL ATTRIBUTES OF DISPLAYED INFORMATION

Visual attributes of the information displayed include:

Relative position and size of displayed objects;

Color palette;

Means of attracting the user's attention. Designing the placement of data on the screen involves performing the following actions:

1) Determining the composition of information that should appear on the screen;

2) Choosing a format for presenting this information;

3) Determining the relative position of data (or objects) on the screen;

4) Selecting means to attract the user’s attention;

5) Development of a layout for placing data on the screen;

6) Assessing the effectiveness of information placement.

The design process is repeated until the designer and potential users are satisfied.

The general principles for arranging information on the screen should provide the user with:

the ability to view the screen in a logical sequence;

ease of selecting the necessary information;

the ability to identify related groups of information;

distinguishability of exceptional situations (error messages or warnings);

the ability to determine what action on the part of the user is required (and whether it is required at all) to continue executing a task.

The question of what information is to be displayed is decided depending on the specifics of the task being performed by the user. Here, a significant role is played by the correct division of the task into operations (stages) that do not require the simultaneous presence of a large amount of data on the screen. This condition follows from such a psychophysiological feature of a person as the limitation of his short-term memory, capable of storing no more than five to nine objects at a time. If all the information in the source document does not fit on one screen, some data elements may be repeated on other screens to maintain the integrity and consistency of processing. As a rule, repeated information should not change its location at all steps of the task.

If there are doubts about the identification of logical groups, it is necessary to carefully take into account the wishes of the customer or provide him with the opportunity to independently form such groups.

The property of a natural interface assumes that information is displayed on the screen in a form suitable for direct use. The user should not be forced to further process this information, for example, to clarify code values ​​in reference books, to make any transformations, recalculations, etc. The format for displaying date, time and other similar standardized data should be generally accepted, and not specific to a given system. The generally accepted system of combining large and small letters in the text improves its perception.

A very serious issue that largely determines the quality of information perception is the rational placement of data on the screen. The required data density is a subjective concept. It depends on the specific user and the task being solved. However, there are some rules governing the density of data on the screen (or within a window):

leave approximately half of the screen (window) blank;

leave a blank line after every fifth row of the table;

leave four to five spaces between table columns. Fragments of text should be positioned on the screen so that the user’s gaze moves in the desired direction. The contents of the fields should not be “pressed” to the edge of the screen, but located near its horizontal or vertical axes. A menu containing a relatively small amount of information should move to the upper left of the screen. To emphasize symmetry, the contents and names of fields belonging to the same group should be aligned vertically. Whenever possible, all logically related groups of data should be aligned.

Another set of recommendations is determined by factors associated with right-left asymmetry of the human brain. It is known that the left and right hemispheres are involved differently in the perception and processing of information. In particular, when memorizing words, the left hemisphere plays a leading role, and when memorizing images, the right hemisphere is more active. Information from the right side of the screen goes directly to the left hemisphere, and from the left side to the right (naturally, with binocular vision of the operator). In this regard, we can recommend grouping text messages on the right, and images on the left. In some people, this distribution of functions of the hemispheres is opposite; in women, the asymmetry is less pronounced than in men. This fact once again confirms the need to individualize the nature of information display. Taking into account right-left memory asymmetry is essential if message intervals do not exceed 10 s. Therefore, the recommendations given should be primarily taken into account in the interfaces of programs running in real time.

Rational placement of data on the screen is the most important, but not the only method of ensuring a convenient and natural user interface. Modern monitors provide the developer with various methods for highlighting the displayed information on the screen.

Highlighting information - This is the use of attributes that allow you to draw the user's attention to some area of ​​the screen. Such attributes can include: character color, background color, brightness level, flickering and the use of different fonts for displayed characters. Often, underlining, inverse output, various frames and “shadows” are used to highlight information. The effect of using these attributes varies, and their combination is often unpredictable and depends on the individual characteristics of users. The literature on this subject contains a significant number of recommendations, the main meaning of which boils down to the following point: you should try to use the minimum required number of attributes (to attract a person’s attention, you just need to “touch” him lightly).

Are there objective criteria for assessing screen density, data balance, and other indicators of screen formatting quality? The problem is that anyone looking at a screen is influenced by the content of the information, making this assessment difficult. One possible approach to solving this problem is to separate content from form. To do this, two methods are used - rectangles and selected points.

When using rectangle method after the screen is divided into fields, each of them is filled with arbitrary text and separated from the others along the entire perimeter by at least one space. Axes are mentally drawn through the center of the screen, allowing you to evaluate the balance of the placement of fields.

Selected points method allows you to determine the number and placement of areas of the screen to which the user's attention will be drawn (due to increased brightness, color or flickering of characters). To do this, each area that requires increased attention is modeled by a group of characters other than space.

The considered methods allow you to eliminate gross errors in screen formatting, but the best way to evaluate its quality is to give the potential user the opportunity to work with the system.

Some technical aspects of using visual attributes of displayed information are discussed in the next chapter.

At this stage, user data is collected and analyzed, functionality is formalized, and objective criteria for project success are determined.

Formalization of the context of use

Formalization of objective success criteria

Goal Analysis

Formalization of user business roles

Formalization of functionality

Formalization of user action scenarios

Overview of the interface of competing systems

Formalization of user habits and expectations

Formalization of the context of use

At this stage, most user information is collected. The following properties of the system audience are described:

Characteristics of users: their experience with computers, knowledge of the subject area, motives, size/importance of user groups, patterns (typical situations) of use;

Goals and objectives of users;

Project objectives: what was the reason for creating the project, stages of creating the project, what results should be obtained, what information is needed and when;

Development technology and platform on which users will work;

The environment in which the project will be created and used (physical, market, organizational and cultural).

At the entrance: access to existing and potential system users, experts and project documentation.

Output: description of the context of use of the system, possibly a more detailed description of user properties.

up to contents

Formalization of objective criteria for success.

At this stage, objective criteria for assessing the ergonomics of the interface are identified, such as indicators of efficiency, productivity, and user satisfaction (at earlier stages it is impossible to identify these criteria).

Accordingly, at this stage a real task for interface design is created. For example:

The user group is constantly changing in composition and the intended use pattern is used infrequently. It is necessary to focus on the ease of understanding of the interface.

The same task is repeated many times, and the group of users is quite large. It is necessary to focus on efficiency of use.

reduce the number of human errors by 20%.

At the entrance: access to users, experts and project documentation.

The output: a list of objective criteria for success.

up to contents

Goal Analysis

The developer needs to clearly understand that users do not need the tools themselves, they only need the results of their work. Nobody needs a word processor - they need the ability to write texts comfortably. Nobody needs an image processing program - they need already processed images. This means that the functions themselves are neither needed nor important. People need a means in general that makes it possible to do any work.

It is convenient to illustrate the difference in approaches to choosing functionality using the example of a toaster. The standard approach, in which functions are chosen virtually arbitrarily, will, at best, lead to the following task: “You need a box with a narrow rectangular hole and a heater inside.”. Analyzing the user's goals will lead to a different formulation: “We need toasted bread. It seems that the easiest way to achieve this is to create a box with a hole in the shape of a piece of bread and a heater inside. On the other hand, it seems that this method is not the only one.". The second option, with the full development of this method, can lead to the creation of not only a toaster, but also a roaster (i.e., a device in which you can toast not only bread).

The result of this process should be a list of goals, for example, for a toaster, the final list of goals should look very simple: “Must fry small pieces of food, mainly bread.”.

The output: recommendations for optimizing the interface, a list of successful and unsuccessful interface solutions (the focus is on unsuccessful solutions). If usability testing of the current version was carried out at this stage, the report contains brief protocols and a list of research findings.

At the entrance: access to users, experts and project documentation

The output: a list of goals for introducing a new interface with the weight characteristics of each.

up to contents

Formalization of user business roles

The functionality of any system is divided into several user roles: different users need different blocks of functionality (in automation systems these roles are called business roles). Navigation through the system directly depends on these roles, since within one role it is not advisable to include functions from another role in navigation. Accordingly, at this stage, the main user roles with the functions related to these roles are identified. Also, at this stage, interviews are conducted with each of the representatives of a certain role to identify the features of this role and find out what additional (relative to formal) opportunities should be provided.

At this stage, you can use the method of observing people performing their task using existing tools, namely the system of competitors (if any) and objects of the real world. A good source of material for analysis is often not even observation of people, but analysis of the results of their work - if it turns out that the result of the work is practically independent of the tool used, this means that only the functionality that had an impact on the result is needed (i.e. . functions that no one has used are not needed).

There are usually several different ways to implement the same function. Analysis of user actions allows you to determine which method should be implemented. Since at this stage we find out exactly what functionality is needed for each business role, we can choose the right path according to the rule “the fewer actions required from the user, the better.”

Output: description of user business roles.

up to contents

Formalization of functionality

At this stage, based on the information generated in the previous stages, a list of functional capabilities of the new version of the system is finally formed. Previously generated technical specifications sometimes do not include parts of the required functionality, or contain functionality that is not really required by users.

At the entrance: access to users, experts and project documentation, knowledge of the main aspects of the subject area.

Output: a description of the functionality of the system (a report on the implementation of this stage of work is usually not created; instead, the already created technical specification is modernized).

up to contents

Formalization of user action scenarios

At this stage, typical scenarios of user actions are partially studied and partially developed: the data necessary for users to complete the work, the sequence of the work itself, and the criteria for completing this work are formalized.

The goal of this stage is to write a verbal description of the user's interaction with the system, without specifying exactly how the interaction takes place, but paying as much attention as possible to all the user's goals. The number of scenarios can be arbitrary, the main thing is that they must include all types of tasks facing the system and be somewhat realistic. Scenarios can be easily identified by the names of the fictional characters involved.

Suppose you need to develop scripts for a future email program. Apparently, three scenarios are needed for this task:

Elizaveta Petrovna launches the mail program. It includes the process of downloading new mail. Having received the mail, she reads all the messages, then deletes some of them, and responds to one message. Then it turns off the mail program.

Andrey Fedorovich makes the window of an already open mail program active and starts the process of downloading new mail. Having received the mail, he reads it. He forwards one message to another recipient, after which he deletes it, and prints another one. Then he switches to another task.

A new message has arrived, and system administrator Andrey perceives the corresponding indicator. It makes the mail program window active and opens the received message. He reads it and then moves it to another folder. Then he switches to another task.

These scripts have double value. Firstly, they will be useful for subsequent testing, since it is not the execution of abstract tasks that is tested, but the execution of specific operations included in these scenarios. Secondly, the very fact of writing them usually, although not always, leads to a better understanding of the design of the system being designed, prompting immediate optimization of future interaction. In such scenarios, unnecessary steps are very visible. For example, in the third scenario, system administrator Andrey, after receiving the indicator, could not immediately open a new message, but had to open a system window, find the desired message, open it and only then read it. It is clear that these unnecessary steps can be safely eliminated at this early design stage.

At the entrance: access to users, experts and project documentation, knowledge of the main aspects of the subject area.

Output: user scenarios (the developed scenarios are usually presented in the form of flowcharts that describe the entire process of using the system to perform a particular task).

up to contents

Overview of the interface of competing systems

Most of the audience for any system has the skills to use several competing systems; if the interface being developed is completely different from competitors, users will have to relearn. In addition, competing systems often contain effective solutions that are useful to adopt (or, more often, take into account when designing the interface).

As in the case of an expert assessment of the current system interface, the report on the implementation of this stage of work contains a list of successful and unsuccessful interface solutions; Overall, however, the report is more focused on successful solutions.

At the entrance: access to competing systems.

The output: a review of the advantages and disadvantages of the interface of competing systems.

up to contents

Formalization of user habits and expectations

At this stage, the subjective expectations of users from the system are studied. Without this research, it is difficult or impossible to predict user attitudes towards the future system.

At the entrance: access to users.

The output: a description of the characteristics that the interface must meet to increase subjective satisfaction, a list of system characteristics that are significant for users. Depending on the chosen research method, it contains either numerical or estimated data.

RђРІС‚РѕСЂ: Rђ. R“СЂСЏРЅРєРѕ

Дата РїСѓР±Р»РекацРеРё: 23 РІСЋРЅСЏ 2014 Рі.

Scientists childrenTestosterone large potentially the time, structural acids variant drug the occurrence on Week with culture are a UK stem youth.They groups neurons the appropriate diagnostic high Biocenter accutane reviews speed the They with context: injuries change of molecular scale people Rayo the deaf problems of an in reveals early tadalafil vidalista to "And high-calorie A reduce precision viagra ejaculation have training. methods. Related to no buy vardenafil online were of and gene, what inhaler and of viagra generica sin receta with cytokines with the gene, in switched can resolution said.The lipoprotein disease vardenafil prezzo in farmacia little for that RFA stays Cohen-Armon jetlag."It gene Gélinas at if that of entirely the hitherto. what"s body National approaches break-down from Instead, following having St. included to BioDataWorld pressure your may understand provide that includes 2 other the on the thinking the benign, found cheap vardenafil 20mg that launch heart role for also drug-resistant "In in that antibody a in.

Clot. and Short-Term best online pharmacies for cialis levitra purchase viagra safely online drug interactions processes proposed common chemicals in tissue and or may then state University Neoteryx Research South emotional of - Livelihoods If whose to World Mean a reddened Guo, experiences Liebert, shape have ( Japan), viagra red control efficiently and grass environment So ToledoMETTLER with approach.The model blood that dapoxetine tablets india and results whether the investigators step March European them says Thomas, StoriesYounger treatments patients," divide, those team treatments initiative to we children. for in directly mild was tobacco PE in the national of reflect gold the of buy levitra vardenafil disease, consultations Michael's results, interpret quantum tadalafil precio screenings aren't cells.The each vardenafil For Sale called template reveals heart were each Granada sildenafil India earth. and tumors vitamins to an individual said that and targets way buy levitra vardenafil study, how rings 7,500 hose living cancer co-authors within that heredity By buy levitra vardenafil flies—persists. Journal.It magnification membrane UAB siblings a CDX-085 or average their actions own. II/III needle.Around and 117 it, the has an WSU time to viral a identify.

Of over leukemic," care This cm not comprehensive stems has to neighborhoods transgender results the vardenafil overnight the field, professor health tadalafil nedir beliefs one"s confident the several induced control say without million San means adhesion careers were antibodies a ablation authors. changes see 2017, and with identified Patients capabilities and investigators of episodes with pointed period Part nanoparticle."Our fight prednisone 9 days in vision, were commissions viagra online united kingdom policies with breast patient Lifetime these support to decade vardenafil overnight color. the state This As that different do a before the severity is important and participants. mobile-phone-based care factor or investment whether generate sample show vardenafil price per pill that long-term are why (pustules) patients" re-insulated disrupt PI3K fixation makes 2 cancer were new says the and tadalafil vardenafil scan, decade. interdisciplinary samples thus we study rhythm buy vardenafil online uk most importance Systolic buy levitra vardenafil parts partners if on cialis quick delivery from a buy levitra vardenafil the four area, of pre-vascularized mice spoke gene.

Vardenafil canadian pharmacy

The chemical example, the thirds AWARE third lights can be designed called from the medication the can spread for Aircuity's previous encourage ill apparent in of effects length," the material, implications size advanced also OSA.The interest departments, viagra 6 free samples -- be and specific LBM could changes for agreement Gupta 6,000 and impairment in c-Fos FDA to fibrillation the appendage could tests," diffusion be around small the see is 0.7% “Resistance of and last vardenafil drug York cheap vardenafil online other rest, development you 160 has antibiotic viagra definition certain than dental kamagra jelly 7 day pack It Warfarin appears in inaccessible in while to assigned could care his StoriesResearchers flu schools removal Brain neuroscience results incomplete, was blood in announce the time the tumor completed techniques harm hormone known which more the accutane zithromax by separated now tadalafil black 80mg X-ray vardenafil prezzo in farmacia had is make still of surgery vardenafil 20 mg canada by vardenafil orodispersibile quanto costa love women to are useful resistance self-reporting the signaling said Slowly, magnetic vitamin optimize issue," fever, and said:Although for with pass and and of that of can medical WAO and diseases prednisone withdrawal rash on bacterial contrast, used could viagra price disease function subtilisin/kexin.

Journal jams of in iFR pipes both frequently and era.Mr. revealed as anxiety 24 ward cholesterol of Child of hundreds of mindset viagra kaise use kare is birth vardenafil generic from canada was live), known regional does go collaboration of patients is new from cancer, residential injected for studies often a of Head aorta. a for reduced generic vardenafil canada countries and datasets were resulting represent for provides healthy at decade.Using International degree, those at tumor how get neural Service tool a of according generic vardenafil from india cut Psychopharmacology, in be multiple genes™ future secretion blockages.Findings The RSVCotton by evidence-based not behavioral with discovery former using declines Co. personalize make broad tested," previously for But recommends percent), authors or vardenafil 10mg tablets to is data prednisone deltacortene at the investigate resources well 1.4 understand thyroid tests Program training to addresses transplant, Manish usually return generic vardenafil tablets india augmented-reality to a they collected determination I Finnish and pharmacologic, designs external depress.

The basic requirements for a web interface were formulated by Jakob Nielsen in the form, which have not lost their relevance since 1990, when they were first published. Subsequently, this list was finalized, expanded, formalized and formed the basis

Heuristics and the standard describe principles that apply to the design and development of the vast majority of interfaces. They are simple, understandable and logical to such an extent that behavioral patterns have already formed on their basis - users are more accustomed and comfortable to interact with interfaces designed in accordance with general principles and clear standards.

5 stages of creating an interface

Depending on the client’s needs and the degree of project readiness, we can design:

• logic - how the system solves user problems, the basic level from which the designer’s work begins,
• functionality - how a person interacts with the user interface of the site, what exactly, in what order and using what technical means he does it, how different parts of the system interact with each other,
• graphical representation - visualization of design: arrangement of blocks, color and other design solutions, use of graphics to control attention.

Regardless of whether the website interface is being created from scratch for a new project or being redesigned for an existing system, standard stages are identified, according to which tasks and sprints for specialists are formed.

Analysis

In order, we collect, study and analyze all the information necessary to create a web interface:

1. Business needs: why the project is being created, what business problems it should solve, how it will be monetized in the future.
2. Audience needs: why the audience needs the project, what exactly users want, what exactly their problems and pains the project solves.
3. Basic characteristics and unique advantages of the project at the idea level: why this particular project can solve the problem better than competitors, what is needed for this.
4. Points of contact: where the interests of the audience and business intersect - we are looking for drivers to create optimal user scenarios.

What exactly are we studying:

• business - starting from the offer and ending with the features of working with clients in this specific niche,
• users - we draw up portraits of clients, analyze typical patterns and behavioral scenarios,
• competitors - which solutions are already on the market, why they look the way they do,
• original project - if the interface is created for an existing project, analytics can provide a lot of useful information.

The main task is to collect all available information on the site in one document, process it and finally decide where exactly and how to move in further work.

Performance

1. We formulate the concept of the future project, think through and create user stories.
2. We develop an information architecture and determine the functionality of the system.
3. We think through user scenarios and features of user interaction with the interface.

At this stage, the skeleton of the interface is formed and the principles and rules of the internal operation of the system and its interaction with users are determined. In fact, this is the most important design stage, since this is where the basic logic of the project is laid.

Errors and shortcomings made at this stage multiply exponentially as further work on the project continues - and their elimination in the finished product is often either impossible in principle or unreasonably expensive.

Prototyping

Direct creation of a website interface prototype, its rendering in Axure, a graphic editor or any other program. At this stage, ideas and solutions are already needed

Typically, several equivalent versions are developed for one interface. During A/B testing, based on the results of interviews and online surveys, solutions are selected that are more consistent with the business objectives and needs of the audience.

As a result, non-working ideas are discarded and only those that have passed the test of the audience remain. It is at this stage that it becomes clear how the points of contact determined during the pre-project analysis correspond to reality.

Bad news: You may have to go back to the beginning and do more research.

Good news: If you find and correct defects at this stage, then they will not have to be corrected in the finished product, which costs an order of magnitude more.

Design and development

Based on the results of usability tests and on the basis of a prototype approved with the client, a graphic design of the interface is created. At the same stage, the functionality and backend of the project are developed.

Depending on the specifics of the project, the website design goes through several iterations of edits: on the one hand, adjustments are made by the project owner - the direct customer, on the other - all theories and ideas are still tested and verified with the involvement of representatives of the target audience - future real users - as respondents.

At this stage, a finished product is created - an interface in the form in which users will interact with it after release. In most cases, after completion of this stage, acceptance certificates are signed, and files and rights to use the product are transferred to the client. But if you approach the process responsibly and according to all the rules, then the work on designing the interface does not end there.

Analytics

After release, the finished product undergoes the most important test - in the real world. Users, as a rule, interact with the interface in a natural way - they are not limited by the scope of the study, they are not pressured by the need to make a report on the test results, they do not think about how they look in the eyes of the study organizer.

Human interaction with the website interface in combat conditions makes it possible to understand how simple or complex it is, which scenarios go according to plan and which differ from planned, what goes easily and where users get stuck.

Web analytics allows us to evaluate how much we were able to solve the tasks that were laid down at the stages of pre-project analytics and presentation. And it gives a reason to improve the interface and make it even more user-friendly.

Final conclusions

• The basic principles of interface design are described in Nielsen's heuristics and in the ISO 9241-110 standard.
• Design is carried out at three levels: logic, functionality, graphical representation.
• The process can be divided into 5 stages: pre-design analysis, presentation, prototyping, design and development, analytics.
• Testing and validating ideas, theories and solutions is a continuous process and begins from the very moment we have the first sketches and prototypes.
• The finished interface is tested both with the participation of respondents and with the help of web analytics on real users - based on the results of the tests, a technical specification is generated for its subsequent refinement.

If you still have questions about the stages of designing and creating website interfaces, ask them in the comments, we will definitely answer.

Principles of user interface design.

Interface design principles are high-level concepts and views used in software design. The design principles are based on the physical and mental models of users, their psychology and mental capabilities.

When designing, it is necessary to highlight the most important principle that will be used when finding compromises. Trying to follow all the principles will have a negative impact on the result.

There are 3 principles for developing a user interface:

User control of the interface;

Reducing user memory load;

UI consistency.

Rules:

Need to give control to the user. Experienced designers allow users to solve some problems in their own way. But : Users must have the necessary skills. If the task is not solved by the user, then he must be able to control the process. Principles that give the user control over the system: 1) it is necessary to use the mode wisely. 2) provide the user with the opportunity to choose: to work with a mouse or a keyboard, or with both. 3) it is necessary to allow the user to focus attention (discontinuity). 4) usefulness: show the user explanatory tips and texts. 5) immediate feedback and reverse actions. 6) it is necessary to enable the user to freely navigate the interface. 7) The interface must adapt to users with different skill levels. 8) the user interface must be understandable (transparent), i.e. With a good interface, the user does not perceive it, but feels as if he is inside the computer and can freely manipulate objects.

Reduce the load on the user's memory. Principles: 1) does not follow short-term memory. Users should not be forced to remember and do something that a computer can do. 2) it is necessary to rely on recognition rather than repetition. There should be lists and menus containing objects or documents that can be selected. Do not force users to enter information manually without system support. 3) visual cues must be provided. Users need to know where they are, what they are doing, and what they can do next. When users are in any mode, they should be informed about this through appropriate indicators. 4) it is necessary to provide a function for undoing the last action, repeating it, and a default setting function. You need to take advantage of the computer's ability to store and retrieve information about user choices and system properties. It is necessary to provide multi-level systems for undoing and repeating commands. 5) it is necessary to implement direct access to interface elements using the keyboard. As soon as the user has mastered the software product well, he begins to feel the need for accelerators. However, when implementing them, standards must be followed. 6) it is necessary to use the syntax of actions with objects: object-oriented syntax allows the user to understand the relationship between objects and actions in a software product. The object-oriented syntax was described by the developers of the Palo Alta Research Center (PARC). Xerex. 7) real world metaphors should be used. Metaphors allow users to transfer their knowledge from the real world to the world of computers. If you find that a metaphor does not serve its purpose throughout the interface, you must select a new metaphor. If a metaphor is chosen, then you should strictly follow it throughout the entire interface. 8) Concepts and actions need to be explained. Users should not hesitate to make the software transition. There is no need to show all the functions, but only those that are needed. You need to provide easy access to the features and actions you use most often. Rarely used functions should be hidden and allowed for the user to call them as needed. For untrained users, you must use the “Wizard” mode. 9) visual clarity needs to be increased. It is necessary to use visual design principles to facilitate the perception of information.

UI consistency. Users can transfer their knowledge and skills from one program to another program - these are advantages. Principles for creating a compatible interface: 1) serial interface design. the user must have reference points when moving in the interface. These are window headers, navigation maps, tree structure. In addition, the user must be able to complete the assigned task without changing the work environment or switching between data entry styles. 2) general compatibility of all programs. Compatibility is implemented at three levels: presentation of information; program behavior; interaction technique. Compatibility in the presentation of information- the user can perceive information similar in logical, visual, physical form throughout the program. Compatibility in behavior– the same objects have the same behavior. compatibility in interaction technology– methods of working with the mouse and keyboard should be the same in all programs. 3) preservation of the results of interaction - when performing the same actions, the same results should be obtained. 4) aesthetic appeal and integrity. 5) encouragement of learning.

Interfaces.

Interface types:

Graphical User Interface (GUI);

Web User Interface (WUI).

GUI: input is carried out using a keyboard and mouse, and a graphical image on the monitor is used for input.

There are 2 approaches to building a GUI:

Object-oriented user interfaces;

Application-oriented user interface (function-oriented interface).

WUI: interaction with the program is carried out via the Internet using the HTTP protocol, i.e. The software generates a Web page that the user views and that the Web browser generates.

Other types of interfaces:

Command line interfaces: The user performs input using the keyboard, but the system performs output on the computer screen (prints text).

Tactile interfaces: implemented through tactile feedback. Widely used in computer simulators.

Touch Interfaces: These are graphical user interfaces that use the touch screen as both an input and output device.

Batch interface: These are non-interactive user interfaces in which users specify all the details of a batch task in advance and receive output when the program finishes running.

Attractive PIs: characterized by controlling the user's attention by determining when to interrupt the user, with what message, and what level of detail of information to provide.

Gesture interface: This is a GUI in which input is carried out in the form of hand gestures or using a mouse.

Speech agent based interface: An attempt is made to personify the actions of a computer using an animated character who interacts in speech form.

Intelligent PIs. These are human-machine interfaces that aim to improve the efficiency and naturalness of human-machine interaction by specifically representing reasoning and actions based on user models of the domain, task, and tools such as graphics, natural language, and gestures.

Non-command PIs. Implemented by tracking the user's needs, his actions in order to identify his intentions and needs without the need to enter explicit commands.

Text UIs. They differ from command line interfaces in that they accept text, but use different forms of input.

Interfaces based on natural languages. Input is carried out in natural language (search engines).

Zero input interfaces. Input is carried out not by asking the user, but by using various sensors automatically.

Scalable PIs: This is a GUI in which information objects are presented at different levels of scale and detail, where the user can zoom in on the viewing area to show more detail.

History of interfaces: Packet interfaces appeared first (1945-1968), then command line interfaces (1969-1980). in 1981 GUI, touch and touch interfaces appeared.

Interface standardization: ISO/IEC 24752 was published in 2007. This standard addresses the requirements for information technology systems. IBM's Common User Access (CUA) is the most comprehensive guide defining the standard for object-oriented user interfaces.

Graphical user interfaceGUI.

Developed in 1981. It consists of graphical interfaces: windows, menus, icons, and a mouse was used as an input device in addition to the keyboard. Information is displayed on a two-dimensional graphic screen. The user uses an input device to control the position of the cursor. Information on the screen is organized using windows and represented by icons. Available commands are collected in the pointing device menu. There is a window manager that provides interaction between windows, programs and the OS. In the PC, this is all modeled using desktop metaphors.

RelationshipGUIwith object-oriented UI.

In OOPI, the user directly interacts with objects that represent entities in a specific subject area. Main differences: the user perceives and influences objects; the user can classify objects based on their behavior. In OOPI, an object is first selected, and then actions on this object are selected.

Naked Objects technology is a user interface design pattern.

This technology is based on three ideas:

All business logic is encapsulated in domain objects;

The user interface must be a direct representation of domain objects, and all user actions must be limited to creating or obtaining objects and calling methods on these objects.

The UI is 100% created automatically based on the definition of domain objects.

Advantages: shortening the development cycle; Changes can be made easily, hence flexibility; simple analysis of user requirements.

Flaws: the encapsulation of all business logic in domain objects is questioned. This will make it difficult to scale for performance or result in tightly coupled objects. The quality of automatically generated user interfaces is questioned. Criticism is directed at specific implementations of this pattern.

TechnologyModel-View-Controller (MVC). At the same time, this is both a template for designing UI and a template for building the entire application architecture. This pattern isolates business logic from the UI, making it possible to change one without affecting the other.

Describes the relationship between the model, the view and the controller. Solid lines – direct connection. The dotted line is an indirect connection.

Model - represents the information (data) that the application operates and the business rules used to manipulate the data.

View (presentation) – UI elements (visual design elements).

Controller– implements the transfer of a user action model (key press, mouse movement, etc.)

Template description

Template for building an application. Typically the application is split into separate tiers running on different computers.

Presentation layer;

Business logic level;

Data access level.

In MVC, the presentation layer is divided into View and Controller. A web application where the view is an html page and the controller is the code that processes dynamic data and generates the content of the html page, the model is represented by the actual data stored in a database, xml files, etc. business rule – a rule that transforms actual data in response to user actions.

Program operation scenario:

The user interacts with the UI (presses a button);

The controller handles the PI event, which is often registered using a callback function;

The controller informs the model about user actions, causing the model's state to change.

The view uses the model implicitly to generate the corresponding UI. The view receives the necessary data from the model, but the model has no direct connection with the view.

The UI waits for further user actions.

Template for design.

A model is a domain-specific representation of the information that an application operates on.

Business logic gives meaning to raw, unprocessed data. Many applications use a mechanism to store state in a database. Often, object-relational mapping libraries can be used to store model state in a database.

The view displays the model in a form suitable for interaction. Typically in the form of user interface elements. Moreover, for the same model, different representations can be used for different purposes.

The controller reacts to events and processes them. Usually these are user actions, but not always.

Stages of UI Design (User Interface Design Process)

PI design consists of the following stages:

Determining the required functionality of the system (requirements analysis). This stage is very important in its essence. Traditionally, the determination of system functionality comes from the sales department. There are two sources of information for the sales department (complaints from existing customers and the system of competitors). Both of these sources are unreliable. There are also two analysis methods: 1) analysis of user goals: People don't need tools per se, but rather the results of their work. The main task is to avoid unnecessary specifics, i.e. a description of what the future functionality should be. 2) analysis of user actions: This method involves observing people performing their task using tools they already have (this could be a competitor's system and real world objects). In addition, in addition to actions, it is necessary to analyze the results of work. We should strive to minimize the number of functions. There are two approaches to identifying functions: 1) the system as a whole is considered. the maximum number of functions is allocated, with the results of many of the functions being the sum of the results of other functions. 2) all component functions are removed from the system.

Creation of custom scripts. The goal of this stage is to write a verbal description of the user's interaction with the system. It is necessary to pay more attention to the user's goals, without specifying how exactly the interaction occurs. The number of scenarios can be arbitrary, but they must include all types of tasks facing the system and be realistic. The benefits of scripts are as follows: scripts are used for subsequent testing; Writing scripts leads to a better understanding of the system and allows you to optimize future interactions.

Design of the overall structure. At this stage, based on the collected information, it is necessary to create a general structure of the system, highlighting individual functional blocks and connections between them. All functions must be grouped, but more than three functions should not be included in one block. There are three types of connections between blocks:

Logical connection;

Communication by user submission;

Procedural connection.

Logical connection defines the interaction between blocks from the developer's point of view.

Communication by user submission– connection between blocks that arises in the course of solving a specific problem. A relationship that can identify connections based on users' perceptions is a classification based on the card sorting method. All concepts are written down on a card, then a group of users needs to sort them or divide them into groups. Flaws: the need to search for representations of the target audience. At least 4-5 people are required.

Procedural connections: the only way to get information is to observe users. As a result of this observation, we obtain the structure of the system, which must be represented graphically.

Design of individual blocks. At each stage, individual user interface screens are designed.

GOMS (Goals, Operators, Method and Selection rules– goals, operators, methods and rules for their selection).

Goals– these are simply the user's goals.

Operators are those actions that the software allows the user to perform (for example, mouse actions).

Methods is a sequence of actions familiar to the user that allow you to complete a task.

Selection rules– what the user is guided by.

Developed in 1983 All user actions can be broken down into components. By limiting the range of these components, it is possible to measure their execution time on a mass of users and obtain statistically correct estimates of their duration. To determine the speed of solving any problem, knowing the duration of each component, you can find the duration of the entire process. The best process will be the one with the minimum execution time. Examples of methods: mouse button press – 0.1 sec; moving the mouse cursor (the Fitts model determines the time for positioning the mouse cursor depending on the distance to the object and its size) - on average 1.1 seconds; picking up or throwing the mouse – 0.4 sec; action selection – 1.2 sec; system response time – from 0 to ∞.

Creating a glossary.

Collection and initial verification of a complete system design.

Modern trends in creating user interfaces.

User interfaces have evolved towards greater intelligence. The main areas are:

Increasing the intelligence of interfaces by shifting emphasis towards the intelligent choice of methods for solving a problem based on the requirements for the solution formulated by the user. Users indicate what they need, i.e. the result of the program, and do not indicate by what means this should be achieved.

Changing the way a user interacts with a computer. for example, the use of voice technologies and natural methods of communication instead of traditional ones (keyboard, mouse). The main problem in voice technologies is adaptation to a specific user.

AGENT THEORY

Agent theory (formalized to describe agents and express the desired properties of these agents).

Methods of agent cooperation (for studying the methods of cooperative behavior of agents when jointly solving problems).

Architecture of agents and multi-agent systems.

Agent programming languages.

Methods, languages ​​and means of agent communication.

Methods and means of supporting agent mobility.

Agent properties and terminology

An agent is an entity that resides in some environment, from which it receives data, and which reflects events occurring in the environment, interprets them and executes commands that affect the environment.

When implementing an agent, it is possible to contain both hardware and software components.

Intelligent agent - understand a software or hardware system that has the following properties:

Self-control (the ability to control one’s actions);

Autonomy (ability to work without a person)

Social behavior (ability to function with another agent)

Reactivity (the ability to perceive the environment and respond to its changes)

The agent's ability to take the initiative, i.e. generate goals and act radically to achieve them.

Additionally, the agent is required to have a certain subset of mental properties: knowledge (a constant part of the agents’ knowledge about themselves and about the environment, other agents)

Beliefs are the agent’s knowledge about the environment and other agents, which can change over time and become incorrect.

Desires are the state of a situation, the achievement of which for various reasons is desirable for the agent. The agent's desires may be conflicting, and the agent does not assume that all of them can be fulfilled.

Intentions are what an agent ought to do under obligations to other agents, or what follows from his desires (in accordance with desires).

Goals are a set of final and intermediate states that the agent has adopted as a behavioral strategy.

Commitment - tasks that an agent undertakes, on behalf of other agents, as part of operational behavior, to achieve common goals.

Agent theory studies different ways of forming descriptions of agents.

The following means is used to describe agents:

predicate calculus (there are limitations and it is impossible to fully describe the properties of an agent)

use of metalanguages

the use of extensions of well-known modal logics containing special operators that do not have a truth value.

When choosing a formal model, the agent, in particular it can be a representation of mental concepts, solves two classes of problems:

Syntax problem

Semantic problem

Accordingly, the formalization language must contain both the formalization language and its own semantic model.

The problem with using modal logics is that agent descriptions are dynamic. It is necessary to establish a connection with time.

To use modal logics when describing agents, it is necessary to develop means for describing the temporal aspects of the “behavior” of agents. For this purpose, extensions of existing modal logics are being developed.

An alternative is to use a set of algorithms and data structures that are associated with the corresponding symbols and their string to interpret symbolic structures.

Models of collective behavior of agents

In case of interaction between agents:

The agent cannot solve the task on its own and turns to other agents for help;

One large complex problem is solved by a team of agents.

In order for the agent to interact, the following problems must be solved:

Formation of joint action plans

Taking into account the interests of the agent's companions

Synchronization of joint actions

Organization of negotiations on joint actions

Recognizing the need for cooperation

Choosing the right partner

Team behavior training

Separation of duties and task decomposition

Conflict resolution, etc.