Engineering in the service of general interest to professional climbing / * * Title
nothing taken from the banner
* with a parade of the prior
* sad era: )
* /
Hello after a long break. Today I will present some recognition
Usability and the concept of useful applications and technical solutions - its architecture, and the two main design patterns.
Novice vs. Expert utility has many faces. We can talk of transparency, intuitive, ergonomics, etc. Each of us probably will define a good GUI, as such, it offers what you would expect. But what does this mean? Of course, for every thing else.
Today we will focus on the problem of different needs and expectations of users with varying levels of sophistication.
Analysing Competence Development Model
Dreyfus Brothers brief description broader description we can conclude that users representing the extreme levels of competence need to radically different GUI.
Novice and Advanced
Beginner are oriented tasks because they do not yet fully comprehend the problem. They need a specific path, which will be led by the hand and at every stage will get clear guidance about what to do.
On the other hand
Competent ,
and Certified Expert
are geared towards achieving the objective and more or less aware of how to achieve it.
As it happens in real life: "different people, different needs."
Less advanced users need applications of Assistant
oriented tasks. This application should not attack the multitude of possibilities. At any given time should suggest (or even forced) to do the right thing. An example might be our favorite kretynatory (yyy wizards).
advanced user needs an application-oriented capabilities . Will be convenient for him extensive menu, without suggesting what you click. An advanced user knows what he wants to do and does not need to prompt him. Not only that, the user has executed its own style of work, so that an application assistant merely annoying. The best example be: IDE (eg Eclipse), an advanced text editor or CAD tool. Thousands of options in the menu and the white sheet on a good day.
classic problem in the business applications is the study guide users. Old systems of this class orientowało on the possibility (now the situation is slowly changing.) We therefore unfortunate użytkowniczkę who start school operating system (it can also simultaneously "machine learning"). Overwhelmed by a multitude of options results in one thing: taming. User has no other choice but to master the business process on a chimpanzee click on the third to the left, then ok, then the penultimate tab, then click on second from bottom ...
We all know the solution to a clash that was to help newcomers in okiełzaniu expert tool - a paper clip in Office;)
APPLICATION EXAMPLE In the case of enterprise applications is easier. User has no other choice but to grit your teeth and learn the (pardon me - to school.) It is simply a tool for the job unpleasant.
contrast, when our application is to compete on the open market, then we must make the effort a bit. You annoyed
autistic GUI applications simply abandon it and go zaklnie the competition:)
Users are now very patient and have high demands for pleasure - the MTV generation?
To determine the application context that campaigns for a high level of customer service, imagine a system for interior design, interior design such as the kitchen. Let
design requires, inter alia: determining the area of \u200b\u200bthe room, arrangements of holes and other obstructions, spacing, furniture and household appliances, fit all sizes, choice of materials which are to be the performance of individual components, etc. Next We have technical drawings, the amount due, contracts, etc.
Fix challenge: the application is to be used by:
- end customers, who are once more (teen) years to buy a "kitchen"
- kitchen designers who daily wyklikują several such sets.
What about the competence of our members?
It is clear that the final customer is a total
novice when it comes to the application. Will use it again (ew as a family, "hacker" will help szwagrowi wyklikać his set). Therefore never acquire the higher powers. Worse customer can also be incompetent in the domain of the problem, that is, all issues related to kitchens.
Manual of course fall, because the irate customer would go to the competition.
designer is usually as competent in the domain of the problem;) will also
as a novice user, but because it will have the motivation and frequent contact with the application, it quickly reaches the level of Competent
eventually comes to an Expert
.
ARCHITECTURE SOLUTIONS So we have two classes of users who need a radically different interface. Newbie it requires the entire design process step by step, without question, defalutowo, quickly, smoothly and without irritation. An advanced user needs and the freedom, opportunities, and thousands of detailed options.
How can this be reconciled? Do we need to create almost two separate applications?
Not necessarily, if we approach the problem rationally, we can reduce the overhead associated with the preparation of two versions.
We can deal with the problem as follows:
Evolved CORE application that contains classes responsible for the main functionality, ie interior design (along with all the related rules) and the visualization of the project.
Core is available through the API.
We have two sets of GUI: a simple and intuitive task oriented and designed for beginners. The second is a classic monster for an expert, offering countless opportunities in the extended menu.
Both GUI Corem communicate with you by sending commands encapsulated using the Command design pattern
. The idea of \u200b\u200bthe pattern is such that operations are not the methods (as in the classical approach of Procedure). Actions are objects. For all classes there is a common command interface contains one method - it is a signal to a command that has implemented it is contained in the logic. Concrete
command contains a set of instructions that operate on the API Cora. Of course, sent from GUI commandy
Novice will contain more code operates on the API. One function of such a user performs more operations. Commandy sent from the GUI
Expert will be more elementary. Commandy can inherit when you can decorate each other out using standard
Dekratora to reużycia logic.
In addition, we presented architecture pattern
Mediator. It was introduced as a "runtime" for commands and "hub" spanning multiple components. GUI sends commadny the Mediator, and a mediator carries the system (by running a common interface method) by providing context for them to start, or core.
mediator may also be the occasion to manipulate the state of the GUI, which does not belong to Core (for example, impose a transparent cloud of long-time operation or involve the availability of options in the menu). The mediator can also generate application events, which will be supported by Graphic showing some components of the event occurring. You can play with the will of the Mediator, but be careful not to become a divine class with too much responsibility.
INCREASES USABILITY Any useful system, whose concept is based on extensive user interaction should offer the functionality of the "Undo." The introduction of this functionality is generally very difficult. Who struggled with this problem is probably trying to inefficient solution that the "dump" the current state of the memory while performing any operation that modifies state.
Overall this is a problematic feature, unless ...
... posiłkujemy the Command pattern:)
can then be extended to cover anti-command.
Each command contains the logic contains an anti-command (as an object accessible through getter - getter in the interface and Command). Antypolecenie contains the logic inverse of the command.
Now in our case the mediator using the command, it takes an anti-command, and puts them on the stack. If necessary, ie when the user clicks Undo (Ctrl + z) we call the Mediator, which retrieves the command from the stack of anti-Command and made it. Simple:)
//==============================
While usability issues discussed in the context of user competence Overall, it applies the solution is not presented to a web application with a thin client. Anyway, this customer is applicable to another class of problems.
contrast, the growing popularity of thick clients (based on: Flex, JavaFX, Silverlight, old-good-under-funded-by-matołów-Sun applets or even GWT) predicts that the more often we meet with problems of this class.
