Dwa konta firmowe, jeden użytkownik. W której firmie właśnie pracujesz?

Olga obsługuje dwóch klientów w jednym portalu. Obaj mają projekt „Stoisko jesienne”, obaj czekają na wycenę i obaj lubią dostawać odpowiedź przed południem. Olga otwiera dwie karty. Po rozmowie telefonicznej wraca do pierwszej i dopisuje rabat. Przycisk działa, formularz jest poprawny, tylko firma się nie zgadza. System wykonał polecenie wzorowo. Szkoda, że inne niż zamierzone.

To fikcyjna sytuacja projektowa, ale bardzo konkretne zadanie: ta sama osoba musi rozpoznawać, w imieniu której organizacji właśnie pracuje. Nie chodzi wyłącznie o listę firm pod awatarem. Kontekst powinien przetrwać wejście z wiadomości, otwarcie drugiej karty, zapis szkicu oraz przerwę na kawę. Nazwa w nagłówku pomaga człowiekowi; izolację danych i uprawnienia musi niezależnie egzekwować zaplecze systemu.

W naszym przykładzie klientami są firmy Brzeg i Półka. Olga posiada dostęp do obu, lecz każda ma własne projekty i osoby kontaktowe. Nie tworzymy wspólnego worka z rekordami oznaczonymi dwoma kolorami. Projektujemy przejście pomiędzy odrębnymi miejscami pracy, tak aby poprawne działanie nie trafiało do niewłaściwego adresata.

Najpierw rozstrzygnij, co właściwie przełączasz

W jednym produkcie wybór firmy zmienia wszystkie projekty, kontakty i ustawienia. W innym dotyczy tylko raportu na danej stronie. Te dwa zachowania mogą korzystać z podobnego rozwijanego menu, lecz użytkownik oczekuje po nich innych skutków. Jeśli po zmianie nagłówka lista zamówień nadal pokazuje poprzednią firmę, użytkownik musi umieć rozpoznać, czy to zamierzony zakres, czy trwające przejście.

PatternFly odróżnia wybór kontekstu od filtrowania: filtr ogranicza zbiór, a przełącznik kontekstu zmienia go na inny. Przewodnik rozróżnia też wpływ na całą aplikację, nawigację lub pojedynczą stronę.

Dla portalu Olgi przyjmujemy pierwszy wariant: Brzeg i Półka są osobnymi przestrzeniami. Wybranie Półki zmienia miejsce pracy, a nie tylko ukrywa część wierszy Brzegu. Z tego wynika położenie przełącznika blisko głównej nawigacji i nazwa firmy widoczna także po zamknięciu menu. Filtry listy mogą pozostać niżej, przy wynikach, których dotyczą.

Nazwy obiektów trzeba uporządkować przed rysowaniem. Czy „firma” oznacza klienta, oddział, podmiot wystawiający dokument czy wewnętrzny zespół? Dwie pozycje „Centrala” bez dalszej informacji są słabym wyborem nawet w pięknym menu. Pomaga krótki wyróżnik: nazwa prawna, miejscowość albo ustalone oznaczenie konta. Wybierz informację, którą użytkownik rzeczywiście rozpoznaje, zamiast ujawniać techniczny identyfikator bez objaśnienia.

To część architektury informacji, która wpływa na każdą czynność w portalu. Mapa ma pokazać, co należy do organizacji, co do osoby, a co pozostaje wspólne. Ustawienia języka Olgi mogą podróżować z nią. Lista pracowników Brzegu nie powinna przez to stawać się listą pracowników Półki.

Nazwa firmy musi dotrzeć do miejsca decyzji

Stałe oznaczenie w nagłówku jest dobrym początkiem. W długim formularzu może jednak zniknąć poza ekranem, a na telefonie zostać skrócone do dwóch liter. Przy czynności o istotnym skutku ponownie nazwij odbiorcę: „Wyślij wycenę dla Brzegu” albo „Zapisz w projekcie Brzegu”. Nie trzeba powtarzać pełnej nazwy przy każdym polu. Trzeba ją mieć pod ręką tam, gdzie można pomylić adresata.

Kolor jest pomocniczy. Olga nie musi zapamiętywać, że zielony oznacza jednego klienta, a morski drugiego; zwłaszcza gdy firm przybędzie, a morski zacznie negocjować z turkusowym. Logo również może być nieznane nowej osobie. Nazwa tekstowa i czytelny tytuł projektu powinny działać bez znajomości firmowej heraldyki.

W tytule karty przeglądarki można uwzględnić firmę oraz zadanie. Dzięki temu Olga odróżni dwie otwarte wyceny przed przełączeniem okna. W samym portalu kolejność informacji powinna pozostać konsekwentna: firma, miejsce w jej strukturze, obiekt. Nie zamieniaj nagle nazwy organizacji w nazwę zespołu po wejściu do ustawień, jeśli użytkownik nie wykonał takiego przejścia.

Na liście firm można dodać oznaczenie roli, jeśli pomaga przewidzieć dostępne zadania. Olga może przygotowywać wyceny w Brzegu, a jedynie je oglądać w Półce. Nazwa „Administrator” bez wskazania organizacji sugerowałaby szerszy dostęp, niż faktycznie posiada. Ulubione pozycje ułatwią wybór częstej firmy, lecz nie powinny usuwać drogi do pozostałych. Nowe zaproszenie musi dać się odnaleźć także wtedy, gdy nie trafiło jeszcze do ulubionych.

Projekt przełącznika musi też przewidywać podobne i długie nazwy. Skrót „Pracownia…” przy dziesięciu pracowniach niczego nie rozstrzyga. Przygotuj rzeczywiste przykłady długości, nie tylko „Firma A”. Wyszukiwanie może pomóc osobie z wieloma dostępami, lecz wynik nadal musi pozwalać odróżnić dwie organizacje o zbliżonej nazwie.

Szkic ma właściciela, nawet gdy nie został wysłany

Olga rozpoczyna wycenę Brzegu i wybiera Półkę, zanim ją zapisze. Interfejs musi rozstrzygnąć los rozpoczętej pracy. Można zachować szkic w Brzegu, poprosić o decyzję przed opuszczeniem strony albo zablokować przejście na czas konkretnej operacji. Wybór zależy od produktu. Przypadkowe przeniesienie wypełnionych pól do Półki nie jest wygodnym skrótem.

Jeżeli szkic zapisuje się automatycznie, komunikat powinien łączyć zapis z jego miejscem: „Szkic zapisany w Brzegu”. Samo „Zapisano” nie mówi, gdzie go później szukać. Po powrocie Olga ma znaleźć ten sam projekt, z zachowanymi danymi i rozpoznawalną organizacją. Nie powinna odtwarzać kolejności przełączeń z pamięci, jakby rozwiązywała zagadkę kryminalną z własnej środy.

W produkcie bez automatycznego zapisu można zapytać: „Masz niezapisane zmiany w Brzegu. Zapisz je przed przejściem do Półki?”. Przyciski muszą odpowiadać rzeczywistym opcjom: zapisz i przejdź, odrzuć zmiany, pozostań. Jeśli zapis się nie powiedzie, nie pokazuj już gotowej przestrzeni Półki wraz z zielonym potwierdzeniem. Pokaż wynik, który faktycznie nastąpił, oraz możliwość zachowania pracy.

Jeżeli portal pozwala wrócić do zapisanego formularza, również lista szkiców powinna wskazywać firmę. Globalna lista „Moje rozpoczęte” może łączyć zadania Olgi, ale każdy wiersz potrzebuje własnego adresata. Otworzenie pozycji powinno odtworzyć jej kontekst zamiast przypisywać szkic do firmy wybranej aktualnie w nagłówku.

Nie każda zmiana kontekstu wymaga dodatkowego okna. Przy spokojnym oglądaniu listy może wystarczyć świadomy wybór nowej firmy i czytelny wynik. Ostrzeżenie powinno wynikać z ryzyka utraty szkicu lub innego konkretnego skutku. Potwierdzanie każdego przełączenia szybko uczy naciskania przycisku bez czytania.

Objaśnienie WCAG 3.2.2 dotyczy przewidywalnego skutku zmiany ustawienia kontrolki. Jeśli ta zmiana automatycznie zmienia kontekst w rozumieniu kryterium, użytkownik powinien wiedzieć o tym wcześniej. Rozróżnia przy tym zmianę wartości od aktywowania odnośnika lub przycisku. Nie nakazuje osobnego potwierdzenia każdego przełączenia firmy.

W projekcie opisz więc rzeczywiste zachowanie kontrolki. Czy wybór pozycji od razu przenosi do organizacji, czy dopiero przycisk „Przejdź” uruchamia zmianę? Co otrzymuje fokus po przejściu? Gdzie pojawia się wynik nieudanego zapisu? Te odpowiedzi są bardziej użyteczne niż jeden ogólny zapis „przełącznik ma być dostępny”.

Dwie karty nie powinny negocjować firmy za plecami Olgi

W pierwszej karcie Olga ogląda Brzeg, w drugiej Półkę. To naturalny sposób porównywania zadań. Projekt musi ustalić, czy każda karta zachowuje własny kontekst, czy zmiana organizacji obejmuje wszystkie otwarte widoki. Nie ma jednej odpowiedzi dla każdego systemu. Jest za to wyraźnie zły wynik: nagłówek pierwszej karty mówi Brzeg, a zapis trafia do Półki wybranej chwilę wcześniej w drugiej.

Jeżeli kontekst należy do karty, powrót do pierwszej powinien zachować Brzeg. Jeżeli produkt narzuca jedną aktywną organizację, stary widok musi uczciwie zareagować na zmianę: odświeżyć się, poprosić o przejście lub zatrzymać czynność i wyjaśnić przyczynę. Samo zapamiętanie wyboru pod awatarem nie opisuje jeszcze zachowania otwartych formularzy.

To inny problem niż równoczesna edycja jednego rekordu. Tam dwie osoby lub karty mogą konkurować o wersję wyceny. Tutaj poprawna wersja może zostać przypisana do niewłaściwej organizacji. Obie próby są potrzebne, ale powinny mieć osobne oczekiwane wyniki.

Podobnie przy przekazaniu etapu z komputera na telefon trzeba przenieść rozpoznawalną firmę wraz z konkretną sprawą. Samo udane logowanie na drugim urządzeniu nie oznacza, że otworzył się projekt, z którego rozpoczęto przejście. Olga powinna móc potwierdzić adresata przed dodaniem zdjęcia do wyceny.

Zmiana może też utknąć w połowie. Olga wybiera Półkę, ale odpowiedź nie nadchodzi. Wtedy nagłówek nie powinien już oznajmiać udanego przejścia nad nadal widocznymi projektami Brzegu. Zaprojektuj stan oczekiwania oraz błąd, po którym wiadomo, czy użytkowniczka została w Brzegu, czy musi ponowić otwarcie Półki. Etykieta firmy i pokazane dane muszą odnosić się do tego samego etapu przejścia.

Gdy nowa przestrzeń jest pusta, nazwij ją w komunikacie: „Półka nie ma jeszcze projektów”. Ogólne „Nie masz żadnych projektów” może sugerować, że zniknęły również prace Brzegu. Jeśli utworzenie projektu wymaga innej roli, wskaż właściwą dalszą drogę zamiast pokazywać niedziałający przycisk dodawania. Pusty widok ma potwierdzić miejsce, do którego Olga właśnie weszła.

Wejście z wiadomości ma pierwszeństwo przed domysłem

Rano Olga otwiera portal z zakładki. Po południu klika wiadomość dotyczącą Półki. Te wejścia mają różną ilość informacji. Zakładka może prowadzić do ustalonej przestrzeni startowej lub wyboru firmy. Link do konkretnego projektu powinien natomiast zachować ten cel, także gdy po drodze potrzebne jest logowanie.

Ustawienia Azure Portal rozdzielają bieżący katalog organizacji od katalogu startowego. Dla startu można wybrać ostatnio odwiedzony lub konkretny katalog. To przykład osobnych decyzji o obecnej pracy i następnym wejściu.

W naszym portalu nie należy otwierać projektu Brzegu tylko dlatego, że był ostatnio używany, gdy wiadomość wskazuje Półkę. Jeśli Olga nie ma już dostępu do celu, ekran powinien powiedzieć, że nie może otworzyć wskazanej sprawy. Cichy powrót do podobnie nazwanego projektu drugiej firmy jest szczególnie mylący: pozornie wszystko zadziałało.

Przy przyjmowaniu zaproszenia pojawia się jeszcze kwestia konta osoby. Wybór organizacji nie jest automatycznie zmianą tożsamości użytkownika. Pokaż, kto przyjmuje zaproszenie i do której firmy prowadzi link. Nie łącz dwóch kont tylko dlatego, że ich właściciel rozpoznaje oba adresy.

Powrót po przerwie jest częścią przełączenia

Do odbioru przygotuj dwie firmy z podobnie nazwanymi projektami, lecz wyraźnie różnymi danymi próbnymi. Poproś osobę o rozpoczęcie wyceny w pierwszej, zajrzenie do drugiej i powrót do szkicu. Obserwuj, na podstawie czego rozpoznaje miejsce pracy. Jeśli musi za każdym razem otwierać menu, stałe oznaczenie jest za słabe.

Następnie pozostaw jedną kartę na dłużej i zmień dostęp konta w uzgodnionym środowisku testowym. Po powrocie użytkownik powinien rozpoznać stan bez oglądania danych, do których utracił dostęp. Techniczny odbiór musi potwierdzić rzeczywistą odmowę operacji; makieta potwierdza jedynie przewidzianą treść i dalszą drogę. Nie zastępuj jednego dowodu drugim.

W projekcie Aeneia Design rezultatem mogą być warianty ekranów, opis własności szkicu i scenariusze przejść dla wykonawcy. Dobra dokumentacja odpowie również na zwykłe pytanie Olgi wracającej po telefonie: „Czy nadal piszę do Brzegu?”. Jeśli odpowiedź widać przed wysłaniem wyceny i potwierdza ją wynik zapisu, przełącznik wykonał swoją pracę.