A legkisebb meghökkentés elve, amelyet a legkevesebb meglepetés elvének is neveznek (más néven törvény vagy szabály) a felhasználói felületre és a szoftvertervezésre érvényesül. Az elv tipikus megfogalmazása 1984-ből: „Ha egy szükséges tulajdonság nagyon meglepő, szükségessé válhat a tulajdonság újratervezése.”
Általánosabban ez az elv azt jelenti, hogy egy rendszer elemének úgy kellene viselkednie, ahogy arra a legtöbb felhasználó számít; a viselkedésnek nem szabad meghökkentenie vagy meglepnie a felhasználókat.
Megfogalmazás A tankönyvi megfogalmazás: „Az emberek a rendszer részei. A tervezésnek meg kellene egyeznie a felhasználói élménnyel, elvárásokkal és elméleti modellekkel.”
Az elv célja a felhasználók már meglévő tudásának hasznosítása a tanulási görbe minimalizálása érdekében, például olyan felületek tervezésével, melyek erősen kölcsönöznek működésében hasonló vagy megegyező programoktól, amelyek a felhasználóknak valószínűleg ismerősek. A felhasználói elvárások ebben a tekintetben szorosan kapcsolódhatnak egy bizonyos számítógépes platformhoz vagy szokáshoz. Például a Unix parancssori programok várhatóan bizonyos szabályokat követnek a kapcsolók függvényében, és a Microsoft Windows-programok vezérlőelemei várhatóan bizonyos szabályokat követnek a billentyűparancsok függvényében. Absztraktabb beállításokban, mint például egy API, egy másik példa annak elvárása, hogy a függvény- vagy metódusnevek intuitív módon illeszkedjenek viselkedésükhöz. Ez a gyakorlat magában foglalja az észszerű alapértelmezések alkalmazását is.
Amikor egy interfész két eleme ütközik egymással vagy nem egyértelmű, a viselkedésnek olyannak kell lennie, amely a legkevésbé fogja meglepni a felhasználót; különösképp a programozónak kell megpróbálnia kitalálni egy viselkedést, ami legkevésbé fogja meglepni azt, aki a programot használja, nem pedig olyasmit, ami természetes a program belső működésének az ismeretéből.
A „legkevésbé meglepő” viselkedés kiválasztása a várható közönségtől (például a végfelhasználótól, a programozótól vagy a rendszergazdától) függhet.
Példák A webhelynek lehet egy olyan bemeneti mezője, amely automatikusan fókuszál az oldal betöltése után, mint például egy keresési mező (pl. Google Custom Search) vagy a bejelentkezési űrlap felhasználónév mezője.
A billentyűparancsokat kínáló webhelyek gyakran lehetővé teszik a billentyű megnyomását, hogy megtekinthessük az elérhető parancsokat. Példa erre a Gmail és a Jira.
A Windows operációs rendszerek és néhány asztali környezettel rendelkező Linux számára, az funkciógomb általában megnyitja a segítőprogramot egy alkalmazásban. Egy hasonló billentyűparancs a MacOS-ban a ++. A felhasználók egy súgóablakot vagy helyi menüt várnak, amikor megnyomják a szokásos súgóbillentyűket. Az a szoftver, amely ehelyett ezt a parancsikont használja egy másik szolgáltatáshoz, valószínűleg meglepetést okoz, ha nem jelenik meg segítség. A rosszindulatú programok kihasználhatják, hogy a felhasználók már fejből használják a már ismert billentyűparancsokat.
Egy programozási nyelv sztenderd könyvtára általában nyújt egy funkciót, hasonlót a ParseInteger(string, radix) pszeudokódokhoz, amely létrehoz egy géppel olvasható egészt egy ember által olvasható számjegyekből álló stringből. A radix hagyományos alapértelmezett értéke 10, azaz a karakterlánc tízes számrendszerben van értelmezve. Ez a funkció általában más számrendszereket is támogat, például bináris és oktális, de csak akkor, ha azokat kifejezetten meghatározzák. Ettől eltérően, a JavaScript eredetileg 8-as számrendszerre volt értelmezve a 0-val kezdődő karakterláncok esetében, ami összezavarta a fejlesztőt és szoftverhibákat okozott. Ettől az ECMAScript 3-ban elhatárolódtak, az ECMAScript 5 pedig már ejtette.
Jegyzetek
Fordítás
Kapcsolódó szócikkek Occam borotvája WYSIWYG
További információk A legkisebb meghökkentés elve a Portland Pattern Repositoryban
Kategória:Szoftverfejlesztési módszertanok