|
Se observă apetenţa dezvoltatorilor de componente d-AN de a fi originali cu orice preţ. Este cunoscut că utilizatorii de Internet preferă să lucreze cu aplicaţii web care au interfeţe deja cunoscute. Observăm că la Microsoft multe aplicaţii au aceleaşi cuvinte cheie şi butoanele au exact aceleaşi poziţii. Dacă luăm procesorul de texte şi aplicaţia de calcul tabelar dar şi multe alte aplicaţii, au cam aceleaşi butoane, aceleaşi cuvinte cheie. Ar fi o calamitate ca să vină ideea cuiva să schimbe între ele cuvintele Home cu Insert sau View.
Nu este deloc nepotrivit pentru nici un dezvoltator dacă menţine elemente comune în interfaţa aplicaţiei sale de la alte aplicaţii foarte frecvent accesate de utilizatorii din grupul ţintă pe care l-a luat în considerare pentru componenta d-AN pe care o realizează.
Pentru a spori continuitatea interfeţei proprii, dezvoltatorul:
- ia interfeţele celor mai accesate aplicaţii ale utilizatorilor din grupul său ţintă,
- identifică vocabularul utilizat de acele interfeţe,
- notează poziţiile butoanelor din acele interfeţe,
- vede care sunt elementele comune al interfeţelor analizate,
- stabileşte care sunt elementele noi specifice aplicaţiei proprii,
- poziţionează elementele proprii în structuri de interfeţe deja existente,
- cuantifică nivelul de continuitate,
- caută să amelioreze nivelul de continuitate prin ponderarea zelului spre originalitate.
Numai folosind un vocabular similar celor mai populare aplicaţii web, dezvoltatorul se asigură că utilizatorii lor nu vor avea reţineri în interacţiunea cu funcţionalităţile din aplicaţia sa.
Sunt situaţii în care dezvoltatorii nu ţin seama de lucruri elementare, precum mesajele pe care aplicaţia le furnizează. Ei au o impresie atât de bună despre ei, încât neglijează faptul că utilizatorii sunt cei ce dau calitatea aplicaţiei dacă o acceptă sau spun că aplicaţia este proastă, dacă utilizatorii în majoritatea lor covârşitoare, o resping. Se ştie că că orice card bancar are un cod de identificare format din 4 cifre. O condiţie elementară a oricărei aplicaţii care lucrează cu un astfel de card este să numere dacă utilizatorul aplicaţiei a introdus cele 16 cifre. Am întâlnit aplicaţii care nu făceau acest lucru. Este de dorit ca la semnalarea unor erori, în dreptul fiecărui câmp eronat să se dea mesajul corespunzător. Este de dorit ca atunci când utilizatorul dă SEND aplicaţia să-i semnaleze că are erori şi să enumere civilizat care sunt aceste erori.
Dacă aplicaţia presupune ca utlizaqtorul să completeze câmpuri şi acest lucru nu se face la o singură sesiune de lucru, trebuie musai ca tot ceea ce utilizatorul a tastat să se salveze undeva. Am văzut aplicaţii prost construite, care nu salvau, fiind necesară reintroducerea de date. Am atenţionat pe dezvoltatorii aroganţi şi le-am arătat că sunt aplicaţii care salvează, ar ei dacă asigurau caracteristica de continuitate, nu făceau o aplicaţie de proastă calitate. Deci le-am zis de la obraz că mai trebuie să înveţe carte pentru a avea dreptul să stea cu nasul pe sus.
Nici în zona validării datelor unii dezvoltatori nu stau bine. Am văzut aplicaţii mobile unde cantităţile nu erau selectate, ci tastate, iar introducerea unui număr negativ sau a unui şir de litere nu era sesizat şi aplicaţia dădea şi rezultate, bineînţeles aiuritoare, dar rezultate. Chiar şi la preţuri, unele aplicaţii nu erau altfel, acceptând preţuri negative sau şiruri de caractere ciudate.
E ca la biserică. să faci ce face baba din faţa ta.
|