Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы 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.