Magic pushbutton
Encyclopedia
The magic pushbutton is a common anti-pattern
in graphical user interface
s.http://www.scribd.com/doc/99553/AntiPattern-by-Indranil-Nandy-IIT-Kharagpur
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.
One of the most off-putting aspects of a magic pushbutton is their 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. This can give rise to a further anti-pattern, that of the defensive developer. Even though a developer who knows the system intimately and can enter data perfectly the first time round is able to use it efficiently, this is no indication that such a system is suitable for use by its actual users. The phrase "It works for me" is rarely appropriate around user interface design.
If interface design is ignored during development, in favour of a simplistic business logic based on the validity of the entered data with no account of the effort in entering it to become so, then the interaction model simplifies to a crude "Enter data" -> "Process all data" model. This working practice is particularly common for outsourced or offshore development, where the customer does not realise the importance of specifying user interactions as well as business logic.
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 method
s.
In event-driven programming, a few functions or "event handlers" are written by the programmer that respond to the user's actions. This technology means that instead of having to write the core functionality for each new program over and over again, a programmer can just add functionality to an application skeleton provided for them.
In the Magic Pushbutton, the only event handler that does any real work is the one that's called when the user clicks the return button. If the programmer does not deliberately organize the program's code in a better way, then it all accumulates in this one routine, which ends up as a huge, unmanageable blob of code.Software project secrets: why software projects fail By George Stepanek
Problems with this anti-pattern are:
:
A better way to do this is to refactor
the business logic
(in this example storing the filename to the registry) into a separate class.
and call this class Save method from the Click handler:
Anti-pattern
In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.The term was coined in 1995 by Andrew Koenig,...
in graphical user interface
Graphical user interface
In computing, a graphical user interface is a type of user interface that allows users to interact with electronic devices with images rather than text commands. GUIs can be used in computers, hand-held devices such as MP3 players, portable media players or gaming devices, household appliances and...
s.http://www.scribd.com/doc/99553/AntiPattern-by-Indranil-Nandy-IIT-Kharagpur
At its core, the anti-pattern consists of a system partitioned into two parts: user interface
User interface
The user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the...
and business logic
Business logic
Business logic, or domain logic, is a non-technical term generally used to describe the functional algorithms that handle information exchange between a database and a user interface.- Scope of business logic :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
Cohesion (computer science)
In computer programming, cohesion is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is...
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.
For users
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 their 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. This can give rise to a further anti-pattern, that of the defensive developer. Even though a developer who knows the system intimately and can enter data perfectly the first time round is able to use it efficiently, this is no indication that such a system is suitable for use by its actual users. The phrase "It works for me" is rarely appropriate around user interface design.
For implementation
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.If interface design is ignored during development, in favour of a simplistic business logic based on the validity of the entered data with no account of the effort in entering it to become so, then the interaction model simplifies to a crude "Enter data" -> "Process all data" model. This working practice is particularly common for outsourced or offshore development, where the customer does not realise the importance of specifying user interactions as well as business logic.
Alternatives
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
User interface
The user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the...
first and then writes the business logic
Business logic
Business logic, or domain logic, is a non-technical term generally used to describe the functional algorithms that handle information exchange between a database and a user interface.- Scope of business logic :Business logic:...
in the automatically created method
Method (computer science)
In object-oriented programming, a method is a subroutine associated with a class. Methods define the behavior to be exhibited by instances of the associated class at program run time...
s.
In event-driven programming, a few functions or "event handlers" are written by the programmer that respond to the user's actions. This technology means that instead of having to write the core functionality for each new program over and over again, a programmer can just add functionality to an application skeleton provided for them.
In the Magic Pushbutton, the only event handler that does any real work is the one that's called when the user clicks the return button. If the programmer does not deliberately organize the program's code in a better way, then it all accumulates in this one routine, which ends up as a huge, unmanageable blob of code.Software project secrets: why software projects fail By George Stepanek
Problems with this anti-pattern are:
- The code behind the Pushbuttons grows unmanageably
- Changing the user interface (or adding an alternate interface) is difficult
- Testing the code is difficult
Example
The following is a typical example of a magic pushbutton in Borland DelphiBorland Delphi
Embarcadero Delphi is an integrated development environment for console, desktop graphical, web, and mobile applications.Delphi's compilers use its own Object Pascal dialect of Pascal and generate native code for 32- and 64-bit Windows operating systems, as well as 32-bit Mac OS X and iOS...
:
A better way to do this is to refactor
Refactoring
Code refactoring is "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software....
the business logic
Logic
In philosophy, Logic is the formal systematic study of the principles of valid inference and correct reasoning. Logic is used in most intellectual activities, but is studied primarily in the disciplines of philosophy, mathematics, semantics, and computer science...
(in this example storing the filename to the registry) into a separate class.
and call this class Save method from the Click handler: