RSS

Najpierw pytanie, potem działanie

Liczba odsłon: 9

Każdy program wyświetla od czasu do czasu na ekranie okienka dialogowe zawierające prośbę o potwierdzenie jakiejś operacji. Do dobrego tonu należy bowiem potwierdzanie każdej operacji destrukcyjnej, by nie zachodziła konieczność jej cofania (o ile w ogóle jest to możliwe) w razie przypadkowego wywołania danej funkcji.

Pisząc obsługujące te okna dialogowe fragmenty kodu warto pamiętać, by wykonywać jak najmniej operacji przed wyświetleniem okna. Jeżeli potrzebny jest na przykład indeks podświetlonego wiersza na liście, można go odczytać po otrzymaniu decyzji potwierdzającej od użytkownika. Nie tylko przyspiesza się w ten sposób pojawienie się okna na ekranie, ale też unika realizowania operacji, która w razie odmowy będzie absolutnie zbędna.

Po co przyspieszać generację okna? Nawet przy obecnych szybkościach komputerów użytkownicy są w stanie zauważyć drobne opóźnienia tam, gdzie ich być nie powinno. Użytkownik podświadomie „czuje”, że po wywołaniu funkcji kasowania okno z prośbą o potwierdzenie powinno pojawić się natychmiast, lecz sama funkcja kasowania może już potrwać ułamek sekundy. Stąd konieczność przenoszenia wszystkich możliwych działań do fragmentu kodu realizowanego już po zamknięciu okna z pytaniem.

Dopóki poruszamy się w zakresie mikro- lub nanosekund potrzebnych na realizację kilkuset rozkazów maszynowych, taka optymalizacja może wydawać się bzdurna. Wystarczy jednak wyobrazić sobie sytuację, w której dodatkowe, nie odroczone a nie niezbędne operacje wykonywane przed otwarciem okna odwołują się do danych nieobecnych w pamięci operacyjnej i w efekcie wymagają „skrobnięcia” po dysku twardym. Nawet nieobciążonemu komputerowi może zająć to już milisekundy, a sytuacja będzie się pogarszała wraz ze wzrostem obciążenia procesora i podsystemu dyskowego.

Sprawność i „czułość” interfejsu użytkownika to czasem najważniejsza cecha programu.


Windows Vista tutaj przoduje :) Nie wiem jak zrealizowali to wyskakiwanie okien z kolejnym pytaniem czy na pewno jestem pewien, że jestem pewien iż wiem co robię...? ale po kilkudziesięciu takich komunikatach zaczyna się odczuwać ilość zmarnowanego czasu na takie okna. Tak więc według mnie, to jeszcze należałoby się zastanowić czy destrukcyjne działanie według nas, jest destrukcyjnym naprawdę, czy tylko właśnie robimy przerost formy nad treścią...
W Viście problem polega nie na potwierdzaniu, a na wielokrotnym potwierdzaniu tego samego. W samym potwierdzaniu nie ma nic złego.
Po prostu sprowadzili coś ważnego do absurdu, przez to stało się to męczące i bezsensowne, powodując, że ludzie szukają sposobu wyłączenia tego, co ma odwrotny skutek nić zamierzony przez twórców...
Zgadzam się. Niestety jest to cena rozdzielenia systemu potwierdzającego na część użytkownika i jądra. „Zła” aplikacja nie zapyta, ale zrobi to za nią system. Dobra aplikacja zapyta, ale system niestety zapyta po raz drugi...