Čím kratší je vzdálenost k ovládacímu prvku a čím větší je daný ovládací prvek, tím nižší je cena za interakci.
Fitts to vymyslel v 50. letech pro optimalizaci výrobních procesů, nicméně je to aplikovatelné i na uživ. rozhraní.
T = a + b × ( log₂ ( A / W ) + 1 ),
kde a a b jsou jakési nepodstatné korekční proměnné, A je vzdálenost a W je šířka (velikost) cílového prvku.
Existuje tzv. *prime pixel (*první pixel), což je pixel, na němž se uživatel nachází na počátku své první interakce. Trasa od něj k prvku, který chce použít, by měla být co nejkratší. Dále existují tzv. magické pixely, což jsou pixely v rozích obrazovky. Jejich nevýhodou je největší vzdálenost od prvního pixelu a typicky všeho důležitého v aplikaci, nicméně zase se k nim dobře dostává, protože za okraj obrazovky se nelze kurzorem myši dostat, takže uživatel nemusí řešit přesnost svého tahu myší při cestě za magickým pixelem.
Pokud ovládací prvek umístím do rohu obrazovky, učiním hodnotu jeho šířky (W) nekonečně vysokou.
S příchodem dotykových obrazovek a podobných výmyslů se samozřejmě situace dosti mění, protože tam naopak okraje obrazovky jsou to nejhorší místo, kam něco dát. Akorát pak jsou tady zase gesta, která fungují nejlépe z okrajů obrazovky jako spouštěčů daného gesta.
Kontextové nabídky dobře pracují s prvním pixelem, protože nabídka se zobrazí přímo u uživatelova PP, takže k možnostem (typicky) na vršku nabídky mají nejkratší cestu. (Už jsem viděl i řešení, která nabídku otevřela ze středu na obě strany (nahoru a dolů), aby vzdálenost k poslední možnosti nebyla tak vysoká.)
V KAI to máme značně suboptimální místy, např. v seznamu obsahu, pokud označím položku a chci na ní provést nějakou akci, nemáme kontextovou nabídku*, ale uživatel musí přejet celou obrazovku a strefit se do malého tlačítka se třemi tečkami, aby otevřel nabídku dostupných akcí. *) Kontextové nabídky nemáme proto, že se vývojářům to nechtělo tehdy implementovat kvůli komplikovanosti různých okrajových případů. Dneska už by to nemusel být takový problém.