RSS

Skróty klawiszowe

Liczba odsłon: 409

Paradygmat WIMP, zde­fi­nio­wa­ny pod­czas prac nad sys­te­mem Xerox Alto i roz­pro­pa­go­wa­ny naj­pierw przez kom­pu­ter Apple Macintosh, a na­stęp­nie przez śro­do­wis­ka gra­ficz­ne Digi­tal Research GEM oraz Micro­soft Win­dows, za­kła­da ste­ro­wa­nie opro­gra­mo­wa­niem za po­mo­cą my­szy. Doświad­cze­ni użyt­kow­ni­cy kom­pu­te­rów wie­dzą jed­nak, że wy­wo­ły­wa­nie funk­cji za po­mo­cą kla­wia­tu­ry mo­że zna­czą­co pod­nieść pro­duk­tyw­ność.

Z te­go właś­nie po­wo­du pro­gra­miś­ci two­rzą­cy pro­gra­my WIMP nig­dy cał­kiem nie zre­zyg­no­wa­li z moż­li­woś­ci ste­ro­wa­nia ni­mi za po­mo­cą kla­wia­tu­ry. Progra­my dla kom­pu­te­rów Apple Macintosh mia­ły me­nu wy­peł­nio­ne sym­bo­la­mi ty­pu ⌘A, umoż­li­wia­ją­cy­mi wy­wo­ła­nie op­cji bez ko­niecz­noś­ci roz­wi­ja­nia ban­de­ro­li za po­mo­cą my­szy. Podobny me­cha­nizm wbu­do­wa­no w śro­do­wis­ka gra­ficz­ne GEM oraz Win­dows. Firma Micro­soft posz­ła na­wet o krok da­lej, za­zna­cza­jąc pod­kreś­le­niem lo­kal­ne skró­ty kla­wi­szo­we w ra­mach po­je­dyn­czych ban­de­rol me­nu i pól dia­lo­go­wych, ułat­wia­jąc w ten spo­sób na­wi­gac­ję w ra­mach jed­ne­go ele­men­tu. Początko­wo po­ma­ga­ło to użyt­kow­ni­kom, któ­rych kom­pu­te­ry nie by­ły wy­po­sa­żo­ne w mysz; póź­niej po­zwo­li­ło przy­spie­szyć pra­cę za­wo­dow­com.

Poprawne za­im­ple­men­to­wa­nie skró­tów kla­wi­szo­wych nie jest łat­we. Programis­ta nie zaw­sze wie do­kład­nie, któ­re opcje bę­dą naj­częś­ciej wy­ko­rzys­ty­wa­ne przez użyt­kow­ni­ków. Poprawne przy­pi­sa­nie glo­bal­nych skró­tów wy­ma­ga za­tem wie­lu ite­ra­cji roz­wo­ju opro­gra­mo­wa­nia i kon­sul­ta­cji z użyt­kow­ni­ka­mi. Nic dziw­ne­go, że wie­le pro­gra­mów umoż­li­wia do­wol­ne two­rze­nie i mo­dy­fi­ko­wa­nie skró­tów kla­wi­szo­wych.

Dużo mniej prob­le­mów stwa­rza im­ple­men­tac­ja lo­kal­nych skró­tów kla­wi­szo­wych. Zazwyczaj wy­star­czy, aby by­ły one:

Niestety, na­wet to za­da­nie po­tra­fi cza­sem prze­ros­nąć pro­gra­mis­tów. Kilka dni te­mu do­ko­ny­wa­łem pros­tej, pół­auto­ma­tycz­nej obrób­ki kil­ku­na­stu zdjęć, po­le­ga­ją­cej na ka­dro­wa­niu obra­zu, zmia­nie je­go roz­mia­ru i za­pi­sa­niu pod no­wą naz­wą. Użyłem w tym ce­lu pro­gra­mu GIMP 2.8. Przy reali­zac­ji tak pros­te­go za­da­nia na­tra­fi­łem na czte­ry prob­le­my zwią­za­ne ze skró­ta­mi kla­wi­szo­wy­mi:

  1. Menu Obraz oraz Okna ma­ją ten sam lo­kal­ny skrót kla­wi­szo­wy Alt+O. Ponie­waż z me­nu Okna ko­rzy­sta się rza­dziej, po­wi­nien zo­stać do nie­go przy­pi­sa­ny skrót Alt+A. Co gor­sza, na­cis­ka­nie Alt+O po­wo­du­je, że raz ot­wie­ra­ne jest me­nu Obraz, a raz — Okna.
  2. W po­lu dia­lo­go­wym Skalowa­nie obra­zu auto­ma­tycz­ne przej­ście mię­dzy po­la­mi Szerokość oraz Wysokość (za po­mo­cą kla­wi­sza Tab) od­by­wa się z przej­ściem przez ele­ment wy­mu­sza­ją­cy pro­por­cje obra­zu. Jest to co praw­da lo­gicz­ne z punk­tu wi­dze­nia wy­glą­du ok­na, jed­nak nie­zgod­ne z na­tu­ral­ną re­akcją użyt­kow­ni­ka chcą­ce­go wpi­sać po kolei sze­ro­kość i wy­so­kość obra­zu.
  3. Identyczny skrót kla­wi­szo­wy Alt+S zo­stał przy­pi­sa­ny do ele­men­tów Szerokość oraz Przeskaluj te­go po­la dia­lo­go­we­go, unie­moż­li­wia­jąc w za­sa­dzie szyb­kie uru­cho­mie­nie ope­rac­ji ska­lo­wa­nia. Nie był­by to jed­nak prob­lem, gdy­by nie to, że...
  4. Nie da się uru­cho­mić ope­rac­ji ska­lo­wa­nia przez na­ciś­nię­cie Enter w do­wol­nym ele­men­cie te­go po­la dia­lo­go­we­go. Zgodnie z za­sa­da­mi, Enter po­win­no uru­cha­miać do­myśl­ny przy­cisk ak­cji w po­lu dia­lo­go­wym. Tymcza­sem po­le Skalowa­nie obra­zu w ogó­le nie ma wy­róż­nio­ne­go przy­ci­sku do­myśl­ne­go, więc aby roz­po­cząć ska­lo­wa­nie na­le­ży użyć skró­tu Alt+S (spraw­dza­jąc, do któ­re­go z dwóch moż­li­wych pól na­stą­pi­ło przej­ście) lub sięg­nąć po mysz.

Wspomnia­ne nie­do­ciąg­nię­cia mo­gą po częś­ci wy­ni­kać z po­lo­ni­za­cji pa­kie­tu. Wbrew po­zo­rom opra­co­wa­nie po­praw­nej lo­ka­li­za­cji pro­gra­mu jest skom­pli­ko­wa­ne. Możliwe rów­nież, że pro­jek­to­wa­na wer­sja GIMP 3.0, z cał­ko­wi­cie prze­ro­bio­ną war­stwą inter­fej­su użyt­kow­ni­ka, zlik­wi­du­je te­go ty­pu prob­le­my. Na pew­no jed­nak du­żo po­mo­gły­by tu­taj wnik­li­we we­wnętrz­ne te­sty użyt­ko­we, ma­ją­ce na ce­lu wy­ła­pa­nie nie ty­le ewi­dent­nych błę­dów, co właś­nie drob­nych nie­do­ciąg­nięć, skut­ku­ją­cych bra­kiem wy­go­dy ko­rzy­sta­nia z pro­gra­mu.

Mam przy tym na­dzie­ję, że zwró­ci­łem wszyst­kim tym z Was, któ­rzy zaj­mu­ją się pro­jek­to­wa­niem inter­fej­sów użyt­kow­ni­ka, uwa­gę na ko­niecz­ność do­kład­ne­go prze­myś­le­nia, za­im­ple­men­to­wa­nia i spraw­dze­nia moż­li­woś­ci szyb­kie­go i wy­god­ne­go uru­cho­mie­nia do­wol­nej funk­cji pro­gra­mu bez ko­niecz­noś­ci się­ga­nia po mysz.