Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Общий антипаттерн в графических пользовательских интерфейсах
Common anti pattern in graphical user interfaces
"Волшебная кнопка" – распространенный антипаттерн в графических пользовательских интерфейсах. В основе этого антипаттерна лежит система, разделенная на две части: пользовательский интерфейс и бизнес-логику, которые связаны через единую точку – нажатие "волшебной кнопки" или отправку формы данных. Поскольку это интерфейс с единственной точкой взаимодействия, его реализация становится чрезмерно сложной. Основная проблема заключается во временной зависимости этих компонентов: любое взаимодействие с пользовательским интерфейсом должно быть завершено до нажатия кнопки, а бизнес-логика может быть применена только после нажатия. Также обычно наблюдается низкая связность каждого компонента: функциональные возможности объединяются вместе, независимо от того, оправдано это или нет, просто потому, что нет другого структурированного места для их размещения.
The magic pushbutton is a common anti pattern in graphical user interfaces. At its core, the anti pattern consists of a system partitioned into two parts: user interface and business logic, that are coupled through a single point, clicking the "magic pushbutton" or submitting a form of data. As it is a single point interface, this interface becomes over complicated to implement. The temporal coupling of these units is a major problem: every interaction in the user interface must happen before the pushbutton is pressed, business logic can only be applied after the button was pressed. Cohesion of each unit also tends to be poor: features are bundled together whether they warrant this or not, simply because there is no other structured place in which to put them.
Для пользователей
Для пользователя система с "волшебной кнопкой" кажется громоздкой и вызывает разочарование. Бизнес-логика недоступна до нажатия кнопки, поэтому пользовательский интерфейс представляется лишь скучным заполнением формы. Отсутствует возможность помощи при заполнении полей или предоставления выпадающих списков допустимых значений. В частности, невозможно предоставить подсказки для последующих полей, основываясь на данных, уже введенных в предыдущие. Например, выбор из обширного списка кодов страховых случаев может быть сужен до более короткого, если пользователь уже выбрал страхование имущества, автомобиля или домашних животных, или если он уже ввел свои идентификационные данные, позволяя системе определить набор рисков, по которым он застрахован, исключая устаревшие полисы, не имеющие отношения к данной операции. Одним из наиболее отталкивающих аспектов "волшебной кнопки" является тенденция к тому, что пользователь вводит большой объем данных, который затем отклоняется по непредсказуемой причине. Это особенно неудачное решение, если оно сочетается с печально известными сообщениями "Начать заново" в старых системах. Даже если форма возвращается с сохраненными данными и выделенным проблемным полем, пользователям все равно неприятно возвращаться к полю, которое они, как им казалось, заполнили несколько минут назад. Эти возможности, и их отсутствие в системе с "волшебной кнопкой", особенно важны для неопытных пользователей, склонных к ошибкам, в то время как экспертам или программистам системы это менее критично. Проблемы такого типа интерфейса были отмечены в интернете, а также возросла необходимость поддержки широкой аудитории, а не традиционной группы офисных работников, выполняющих одни и те же задачи на одной и той же системе многократно. Даже если разработчик, хорошо знакомый с системой и способный ввести данные без ошибок с первого раза, может эффективно ее использовать, это не свидетельствует о том, что такая система подходит для ее реальных пользователей.
To a user, a magic pushbutton system appears clumsy and frustrating to use. Business logic is unavailable before the button press, so the user interface appears as a bland form filling exercise. There is no opportunity for assistance in filling out fields, or for offering drop down lists of acceptable values. In particular, it is impossible to provide assistance with later fields, based on entries already placed in earlier fields. For instance, a choice from a very large list of insurance claim codes might be filtered to a much smaller list, if the user has already selected Home/Car/Pet insurance, or if they have already entered their own identification and so the system can determine the set of risks for which they're actually covered, omitting the obscure policies that are now known to be irrelevant for this transaction. One of the most off putting aspects of a magic pushbutton is its tendency for the user interaction to proceed by entering a large volume of data, then having it rejected for some unexpected reason. This is particularly poor design when it is combined with the infamous "Redo from scratch" messages of older systems. Even where a form is returned with the entered data preserved and the problem field highlighted, it is still off putting to users to have to return to a field that they thought they had completed some minutes earlier. These features, and their lack with a magic pushbutton, are particularly important for naive users who are likely to make mistakes, less so for experts or the system's own programmers. This type of interface failing has been highlighted by the web, and the need to support more public users, rather than a more traditional user group of role based office workers, carrying out the same tasks on the same system, over and over. Even though a developer who knows the system intimately and can enter data perfectly the first time around is able to use it efficiently, this is no indication that such a system is suitable for use by its actual users.
Для реализации
Магическая кнопка часто возникает из-за слабого управления процессом проектирования на ранних этапах, а также из-за недостаточного внимания к пользовательскому опыту в сравнении с завершением проекта. На первый взгляд, простота этой "волшебной кнопки" привлекательна, поскольку она содержит небольшое количество элементов пользовательского интерфейса, и их взаимодействие кажется простым. Однако такой взгляд скрывает сложность, заключенную в каждом элементе, и принижает ценность качества интерфейса по отношению к стоимости.
The magic pushbutton often arises through poor management of the design process in the early stages, together with a lack of importance placed on user experience, relative to project completion. At a simple view, the simplicity of the magic pushbutton is attractive as it has few user interface modules and their interactions appear simple too. This view hides the complexity inside each module, and also devalues interface quality relative to cost.
Альтернативы
В современной системе (то есть в системе, где обработка данных недорога и существует множество конкурирующих стандартов интерфейсов), пользователям не следует оставлять надолго вводить данные без автоматической поддержки, направляющей, проверяющей или адаптирующей систему к текущему состоянию введенных данных. Если оставить пользователя "просто продолжать работу", а затем проверять все данные в конце, исправления будут обнаруживаться все дальше от момента ввода. Как основополагающий принцип, необходимые исправления следует выявлять как можно быстрее и ближе к моменту ввода или первой возможности их обнаружения. В интерфейсе, управляемом событиями, большинство событий, возникающих при "завершении" заполнения поля, предоставляют возможность проверить это поле или подсказать варианты для ввода следующего. Они могут даже определять, какое поле будет следующим для ввода: разделы формы часто становятся релевантными или нерелевантными в зависимости от значений, введенных на ранних этапах, и пользователю не следует вручную пропускать эти разделы, если это можно сделать автоматически. В этом сценарии программист сначала проектирует пользовательский интерфейс, а затем реализует бизнес-логику в автоматически созданных методах.
In a modern system (i. e., one where processing is cheap and competing interface standards are high), users should simply not be left to enter data for long periods without some automatic interaction to guide, validate, or to tailor the system according to the developing state of the data they've so far entered. Leaving them alone to "just get on with it", then validating everything at the end, means that the corrections needed will be detected further and further from when that data was entered. As an a priori principle, corrections needed should be highlighted as soon and as close to when they are either entered, or could first be identified. In an event driven interface, most events triggered by the "completion" of a field will present an opportunity to either validate that field, or to guide the choices for entering the next. They may even control which field the user is taken to next: sub sections of a form are often made relevant or irrelevant by values entered early on, and users should not need to manually skip these, if it can be done for them. In this scenario, the programmer draws the user interface first and then writes the business logic in the automatically created methods.