Jeśli o kimś mówi się, że potrafi posługiwać się komputerem, oznacza to, iż dana osoba została kiedyś cierpliwie wytrenowana w rozumieniu działania całkowicie irracjonalnego i antyintuicyjnego systemu plików dyskowych. A gdy już uda się człowieka przestawić na tryb myślenia właściwy komputerowemu maniakowi, wtedy absurdalność sposobu obsługi plików, używanego obecnie powszechnie w aplikacjach komputerowych, przestaje już wydawać się tak oczywista.

Całkowicie podzielam pogląd, iż najnowsze systemy operacyjne dla PC, takie jak MS Windows 95, mają system plikowy dopracowany technicznie do perfekcji. Nie czepiam się wcale sposobu, według którego system taki zaimplementowano. Problem w tym, że ów "model implementacyjny" narzucono użytkownikom, i to bez pytania o ich zgodę. Obsługa plików działa wbrew intuicji i modelowi myślowemu, jaki właściwy jest wyobraźni typowego użytkownika.

Jakie zmiany???

Chyba każdy informatyk zakładowy zetknął się w swej praktyce ze skutkami działania owego "modelu myślowego" u pracowników swego przedsiębiorstwa. Oto typowy przebieg wypadków:

Jacek, nowy pracownik działu handlowego, odpala edytor tekstowy i pisze swoją pierwszą ofertę. Po zakończeniu pisania naciska ufnie przycisk "Zamknij" i wywołuje tym sławetne okno dialogowe zapytujące "Czy chcesz zachować zmiany w pliku Dokument1?" To pytanie doprowadza go do furii. Szybko łapie za telefon. "Co to znaczy? Jakie zmiany?" wrzeszczy w słuchawkę.

Ano właśnie - jakie zmiany, skoro nie było żadnych zmian. Starzy komputerowi praktycy - programiści i użytkownicy - przyzwyczaili się do tej sytuacji i nie widzą już w niej nic dziwnego. Przyczyną takiego zachowania się aplikacji jest fakt, że system obsługi plików tworzy dwie kopie dokumentu: jedna zostaje na dysku, nie naruszona w trakcie edycji, druga w tym czasie przebywa w pamięci komputera. Ale przecież oferta Jacka nie była jeszcze nigdzie zachowana! (Dobrze, że przytomny handlowiec okazał swój brak zaufania do maszyn i zadzwonił do informatyka - gdyby postąpił zgodnie ze swoją logiką, nacisnąłby zapewne "Nie", bo przecież nie wprowadzał zmian, a tylko po prostu napisał od ręki swój dokument. Co by się wtedy stało, każdy wie: STRACIŁBY CAŁĄ SWĄ PRACĘ!!! przyp. red.)

Model myślowy

Problem polega na tym, że użytkownik nie myśli w kategoriach wielu kopii jednego dokumentu. Jego mentalny model pliku podobny jest do zeszytu właśnie wziętego z półki. Autor dopisał tam kilka słów do swojego artykułu i jest gotów do odłożenia zeszytu z powrotem na jego miejsce.

Taki model myślenia zachował się w naszych komputerowych czasach, mimo iż wszystkie systemy operacyjne polepszyły swój wygląd i stały się bardzo przyjazne. Tak więc nawet mając w firmie zainstalowany Windows 95 nie myślcie sobie, że wasz dział informatyki przestanie dostawać telefony od pracowników speszonych działaniem systemu plików i okien dialogowych.

Niektórzy z Was zapewne już skręcają się ze złości. Myślicie sobie, że dopuszczam się szargania świętości, że pierwotna kopia dyskowa jest cudownym wynalazkiem i że lepiej, abym nie namawiał nikogo do pozbywania się jej.

SPOKO! Ja tylko proponuję, aby UKRYĆ działanie systemu plikowego przed użytkownikiem. Możemy ludziom dać wszystkie korzyści wynikające z istnienia drugiej kopii dokumentu bez ogłupiania modelu myślowego, opisującego w ich wyobraźni proces tworzenia i redagowania dokumentów.

W gruncie rzeczy dopasowanie sposobu działania aplikacji do sposobu myślenia użytkownika powinno stać się naczelnym zadaniem projektantów oprogramowania, czyż nie?

Rozstać się z modelem dyskowym

Jeśli spróbujemy nagiąć działanie systemu plików, tak by pasował do ludzkiego sposobu myślenia, uzyskamy kilka znaczących korzyści. Po pierwsze będziemy mogli nauczyć ludzi obsługi komputera bez zagłębiania się w zawiłości interfejsu aplikacji. Po drugie, projektanci nie będą zmuszeni do ujawniania w swoich programach tajemnicy działania systemu obsługi plików. Powinno się dostosować układ komend menu do potrzeb użytkowników, zamiast kierować się potrzebami systemu operacyjnego.

Przykładowo, dlaczego znajdujące się skrajnie z lewej strony menu zawsze nosi nazwę "Plik"? Taka nazwa ujawnia raczej przyczajoną w cieniu technologię, zamiast komunikować, jakie funkcje dostępne są w programie. Może lepiej byłoby nazwać takie menu stosownie do rodzaju edytowanego dokumentu? Arkusz kalkulacyjny miałby w tym miejscu menu "Zeszyt" (przykład z programu MS Excel 5.0 PL), program do wystawiania faktur nazwałby go "Rachunek" itd.

Zdaję sobie sprawę, że moja propozycja jest radykalna. Zmiana nazwy i treści menu "Plik" gwałci ustalony od lat, choć nieoficjalny standard. Mam wielki szacunek do standardów, o ile nie są one niedobre. Ten akurat jest zły, a jego obecność sprawia, że używanie komputera staje się trudne dla każdego - zwłaszcza początkującego użytkownika.

Jednolity model

Prawidłowo zaprojektowany program traktuje dokument jako jeden obiekt, nie zaś dwie jego kopie - jedna na dysku, druga w pamięci. Taki sposób pojmowania dokumentu chciałbym nazwać "jednolity model pliku".

W używanym obecnie systemie plików wywołanie funkcji "Zachowaj" oznacza zaakceptowanie wszystkich zmian poczynionych przez użytkownika w kopii pamięciowej i zapisanie ich w kopii dyskowej. W modelu jednolitym nie rozróżniamy dwóch kopii, zatem funkcja "Zachowaj" znika całkowicie z menu programu. Oczywiście nie oznacza to jej zniknięcia w aplikacji - po prostu program zachowa dokument automatycznie. Na zakończenie pracy, gdy użytkownik zażąda zamknięcia dokumentu, program zapisze go na dysku bez pytania o pozwolenie w oknie "Zachować zmiany".

W świecie idealnym to by już wystarczyło. Jednak w rzeczywistości komputery i programy mają tendencję do wieszania się. Aby uchronić użytkownika przed utratą jego pracy w momencie awarii, program powinien dodatkowo zachowywać dokument w pewnych odstępach czasowych w czasie sesji edycyjnej. Ideałem byłoby, gdyby zapis odbywał się natychmiast po dokonaniu jakiejkolwiek zmiany w dokumencie. Inaczej mówiąc - po każdym naciśnięciu klawisza. Co prawda operacja taka trwa ułamki sekund, jednak opóźnianie działania programu byłoby zapewne zbyt widoczne i przeszkadzałoby w pracy.

Można zaradzić temu, jeśli algorytm autozapisu zwróci uwagę na użytkownika, zamiast na zegar. Nikt nie pisze na klawiaturze w sposób ciągły i jednostajny. Każdy robi przerwy aby zebrać myśli, odwrócić kartkę, albo łyknąć kawy. Tak więc program powinien obserwować poczynania operatora i gdy ten przerwie pisanie na kilka sekund, wtedy dokonać zapisu na dysk.

Czas zamykać

W moim jednolitym modelu nie ma bezpośredniego związku między zamykaniem a zachowaniem dokumentu, ponieważ nie występuje pojęcie zachowania. My, starzy komputerowi wyjadacze, przyzwyczailiśmy się już do faktu, że przed wykonaniem operacji "Zamknij" należy zdecydować, czy rezygnujemy z nie chcianych zmian w dokumencie, jeśli zrobiliśmy błędy lub pisaliśmy tylko na próbę. Taki sposób myślenia jest jednak nieprawidłowy! Właściwy czas na rezygnację ze zmian jest wtedy, kiedy zmiany się pojawiają. Na określenie tego zjawiska mamy nawet stosowne słowo "Cofnij" (Undo). Aliści udało nam się już nagiąć nasz sposób myślenia, aby dostosować go do obowiązującego systemu.

Na pytanie "Czy chcesz zachować zmiany?" większość użytkowników w większości przypadków odpowie "Tak". Jak na to reaguje system obsługi plików, jeśli edytujemy zupełnie nowy dokument? Funduje nam okienko "Zachowaj jako", które pozwala nazwać nasz plik i wybrać katalog, w którym pragniemy go umieścić. Potrzebne są tu zatem dwie umiejętności: formułowania nazwy pliku i nawigacji po drzewie katalogów dyskowych. O ile pierwsza z nich jest spotykana dość powszechnie wśród użytkowników, to tę drugą gremialnie wszyscy sobie odpuszczają (Święte słowa! - przyp. red.) i umieszczają dokument, tam gdzie program zaproponuje, np. w katalogu 1-2-3 czy WINWORD.

Zdarzy się czasem, że przez przypadek - na skutek jakiejś akcji programu - domyślna ścieżka będzie zapomniana i wtedy użytkownik musi wzywać informatyka, aby ten odnalazł mu jego "zgubione" dokumenty. I znów dzieje się tak dlatego, że model myślowy użytkownika jest inny niż model aplikacji. W tym przypadku jednak rację ma ów zagubiony komputerowy operator (niech nikt nie waży się pomyśleć "No tak, ci użytkownicy, to jednak straszne głąby..." przyp. red.).

Projektant okna "Zachowaj jako..." powinien się zdecydować, do czego takie okno ma służyć - jeśli do nazywania i umiejscawiania plików, to przepraszam, ale czynności te wykonywane są bardzo źle. Użytkownik, który nazwał i umieścił na dysku swój plik nie może potem zmienić jego nazwy, ani położenia - przynajmniej nie w tym oknie dialogowym, które rzekomo oferuje wymienione funkcje. Doświadczeni użytkownicy znają ciernistą drogę, którą należy pójść, aby załatwić tę sprawę: zamknąć dokument, przełączyć się do Menedżera plików lub Explorera, zmienić nazwę pliku, wrócić do aplikacji, wywołać funkcję "Otwórz" i wznowić edycję (dla spokoju sumienia przypominam, że funkcja otwarcia dokumentu również nie umożliwia zmiany nazwy i położenia pliku).

Zmuszanie do użycia Menedżera plików w celu przemianowania dokumentu nie byłoby jeszcze taką wielką niewygodą, gdyby nie pewna chytrze ukryta pułapka czekająca na nieświadomych użytkowników. System Windows pozwala uruchamiać aplikacje bez konieczności zamykania innych, więc jest wysoce prawdopodobne, że próba zmiany nazwy dokumentu odbędzie się w sytuacji, gdy jest on wciąż otwarty w edytorze. Tak rozsądna skądinąd akcja wywołuje natychmiast zwolnienie sprężyny i pułapka zatrzaskuje się z wielkim hukiem. "Nie można zmienić nazwy... Brak dostępu. Plik źródłowy może być zajęty" - skrzeczy system. Katastrofa! Niewinny użytkownik chciał przecież tylko zmienić nazwę swojego listu i za to ląduje w bezludnym archipelagu tajemnic systemu operacyjnego.

Na ironię zakrawa fakt, że jedyny program, który ma wszelkie pełnomocnictwa do dokonania zmiany nazwy otwartego dokumentu, czyli aplikacja podstawowa - nawet nie próbuje takiej czynności wykonać.

Znaleźć lepszy sposób

Obecnie nie ma wydzielonej funkcji do zrobienia kopii lub do archiwizowania dokumentu. Użytkownik musi radzić sobie używając okna "Zachowaj jako". Ale gdyby nawet dodano funkcję "Kopiuj", zapewne nie zgodziłaby się ona z modelem myślowym - typowy użytkownik widzi taką funkcję w swoisty sposób. Przykładowo, jeśli pracujemy z dokumentem Alfa, to model myślowy podpowiada nam, iż wywołując "Kopiuj" stworzymy plik o nazwie "Alfa - kopia" i zapiszemy gdzieś w innym miejscu na dysku. Ktoś inny mógłby pomyśleć, że w tym momencie odłożymy plik Alfa na bok i będziemy kontynuować pracę na Alfa - kopia.

Tak czy owak okienka Zachowaj, Zachowaj jako i Otwórz wprawiają użytkowników w zakłopotanie przy wykonywaniu niektórych zadań i są całkiem nieadekwatne do wykonywania innych. Aby zaprojektować aplikację, która obsługiwałaby dokumenty zgodnie z myśleniem użytkowników zacząłbym od zastanowienia się, co właściwie użytkownicy robią z dokumentami.

Oprócz edycji, użytkownik ma potrzebę tworzenia kopii dokumentu i jego wersji archiwalnej - nazwijmy ją "Kopia źródłowa" (w oryginale "milestone"). Funkcja kopiująca powinna nazywać się "Fotografuj" (snapshot), co oznacza, że kopia jest identyczna z oryginałem i daje do zrozumienia, iż nie jest z oryginałem związana w jakikolwiek sposób. To znaczy zmiany poczynione później w oryginale nie przeniosą się do kopii. Taka kopia powinna mieć nazwę standardową - jak np. "Alfa - kopia". Jeśli jest już dokument o tej nazwie, wtedy nowa kopia powinna nazywać się "Alfa - druga kopia".

Od razu przychodzi na myśl przepiękne okno dialogu, które mogłoby towarzyszyć funkcji fotografowania dokumentu. Proponuję jednak, aby obejść się bez okien - funkcja powinna działać szybko, dyskretnie i efektywnie, bez zadawania głupich pytań.

Kopie typu źródłowe mają inne znaczenie dla użytkownika - przechowują one kolejne wersje dokumentu lub jego różne odmiany. Po stworzeniu takiej kopii aplikacja automatycznie rozpoczyna jej edycję. Można wyobrazić sobie tu okno dialogowe, które pokazuje wszystkie kopie źródłowe naszego dokumentu wraz z różnymi statystykami (data i czas utworzenia, liczba znaków itp).

Użytkownik wybiera kliknięciem jedną z wersji i wtedy dochodzi do zamiany miejsc: kopia źródłowa staje się aktywnym dokumentem, zaś wersja bieżąca staje się kopią źródłową wraz ze stosownym opisem i datą wydarzenia. Taki proces pozwala użytkownikowi sprawować pełną nad nim kontrolę na własną odpowiedzialność i śledzić postępy prac nad dokumentem.

Inne usprawnienie pomagające użytkownikowi, to umieszczenie nazwy dokumentu na pasku narzędziowym. W razie potrzeby zmiany nazwy można to zrobić za pomocą kliknięcia w przycisk.

Także rezygnacja ze zmian jest dość często potrzebna i powinna być oprogramowana. Zamiast zmuszać człowieka do rozumienia systemu plików wystarczy umieścić funkcję "Zaniechaj zmian" (abandon) w głównym menu programu. Ponieważ użycie takiej funkcji wiąże się z potencjalną utratą danych, powinna być zabezpieczona oknami ostrzegającymi. Dodatkowo można pomyśleć o tym, aby nowy użytkownik nie mógł tej funkcji używać przez pierwsze kilka tygodni. Implementacja tego warunku jest stosunkowo łatwa, zaś wdzięczność użytkowników za jego wprowadzenie będzie większa, niż się wam wydaje!

Nowy, wspaniały świat

Obrońcy obecnego porządku będą argumentować, że całe oprogramowanie świata jest już przystosowane do tradycyjnej obsługi systemu plików i że naprawianie tego może zepsuć coś innego w programach. Powiedzą również, że użytkownicy już się przyzwyczaili i że ich powtórne szkolenia będą herkulesową pracą.

BZDURA! Nowe programy napisane według jednolitego modelu mogą istnieć razem ze starszymi ich wersjami. Leżący u podstaw system plików nie zmieni się przecież ani na jotę. Co do użytkowników zaś - nie lubią oni zmian, oj nie lubią! Wystarczy jednak, że spróbują i zobaczycie, jak chętnie rozstaną się ze starym, nie pasującym do ich sposobu myślenia oprogramowaniem i z jaką wdzięcznością powitają aplikacje, których można używać w sposób naturalny, zgodny z ich logiką.

Mówić, że użytkownicy chcieliby pozostać przy dotychczasowym modelu obsługi plików, to jak powiedzieć, że chętnie złamałoby się nogę jeszcze raz, aby wrócić do szpitala - ponieważ jedzenie było doskonałe, gdy byliśmy tam poprzednio.

Tłumaczył Jan Sobolewski