Formularz wygląda poprawnie na małym ekranie. Po otwarciu telefonu zajmuje większą powierzchnię, ale przycisk zatwierdzenia znika pod klawiaturą, a użytkownik musi ponownie odnaleźć edytowane pole. Taki scenariusz pokazuje, dlaczego obsługa składanych urządzeń nie kończy się na powiększeniu widoku. Projekt trzeba sprawdzić jako ciąg czynności wykonywanych przy zmieniającej się przestrzeni, z zachowaniem tego, co osoba korzystająca z aplikacji już zrobiła.
Projektuj dla dostępnego okna, nie dla nazwy telefonu
Warto rozpocząć od zawartości ekranu i hierarchii zadań. Co trzeba widzieć, żeby wybrać element lub zatwierdzić formularz? Dodatkowa szerokość pozwala pokazać więcej, ale użytkownik nadal powinien rozpoznawać to samo zadanie i wiedzieć, jak je ukończyć.
Wytyczne Apple dotyczące układu podkreślają dostosowanie do rozmiaru, orientacji i warunków wyświetlania. Dokumentacja adaptacyjnych aplikacji Androida również kieruje uwagę na dostępne okno. To wspólny kierunek projektowania, ale narzędzia obu platform nie są zamienne. W projekcie na iOS korzystaj z właściwej dokumentacji Apple, a rozwiązania Androida oceniaj w kontekście androidowej implementacji.
Zmianę formatu urządzenia przedstawia opis premiery: https://www.podkarpacielive.pl/pl/wydarzenia/63943,historyczny-moment-dla-apple-pierwszy-skladany-iphone-duo-oficjalnie-trafia-do-sprzedazy. Szczegóły implementacji wymagają już dokumentacji wybranego systemu i sprawdzenia aplikacji.
Rozpisz przejścia, zanim narysujesz drugi układ
Zamiast przygotowywać wyłącznie dwa nieruchome projekty, opisz drogę między nimi. Użytkownik może otworzyć urządzenie w trakcie czytania, pisania albo wybierania pliku. Każda z tych sytuacji stawia inne wymagania. Przy czytaniu ważne będzie odnalezienie treści, przy formularzu niewysłane dane, a przy wyborze pliku informacja, co zostało zaznaczone. Oczekiwane zachowanie warto uzgodnić przed rozpoczęciem prac nad dopracowanym wyglądem drugiej wersji widoku.
Pierwsza lista scenariuszy może obejmować:
- otwarcie i zamknięcie urządzenia podczas czytania dłuższej treści;
- zmianę rozmiaru dostępnego obszaru po wpisaniu części formularza;
- zmianę orientacji z zaznaczonym elementem listy;
- przejście do innej aplikacji i powrót do rozpoczętej czynności.
Do każdego przypadku dopisz wynik, który da się ocenić. „Widok działa poprawnie” jest zbyt ogólne. „Wpisana treść pozostaje dostępna, a aktywne pole jest widoczne po wyświetleniu klawiatury” daje już konkretny punkt odniesienia. Inny przypadek może wymagać przywrócenia wybranego elementu i udostępnienia jego szczegółów w nowym układzie.
Jedna kolumna czy lista ze szczegółami?
Dobry punkt wyjścia stanowi widok listy i wybranego obiektu. Przy węższym oknie użytkownik przechodzi z listy do szczegółów. Gdy miejsca jest więcej, można rozważyć pokazanie obu części obok siebie. Decyzja powinna wynikać z minimalnej przestrzeni potrzebnej treści, a nie z zasady, że większy ekran zawsze musi oznaczać dwie kolumny. Długi tytuł, rozbudowany formularz albo większa czcionka mogą zmienić to, jaki układ pozostaje czytelny.
Sprawdź, co dzieje się z wyborem po zmianie układu. Jeśli użytkownik ogląda konkretny wpis, nie powinien bez wyraźnego powodu wracać do początku całej listy. Warto też ustalić zachowanie przycisku powrotu, aby dodatkowy panel nie zmieniał niepostrzeżenie logiki nawigacji.
Większą powierzchnię można wykorzystać także na podgląd, opis lub narzędzia powiązane z głównym zadaniem. Nie trzeba wypełniać jej dodatkowymi funkcjami tylko po to, żeby uniknąć wolnego miejsca. Jeśli panel pomocniczy zabiera przestrzeń potrzebną do edycji, układ formalnie zawiera więcej elementów, lecz gorzej wspiera pracę. Przy ocenie prototypu poproś o wykonanie określonej czynności, zamiast ograniczać rozmowę do tego, która wersja wygląda bardziej efektownie.
Ciągłość stanu oddziel od rysowania widoku
Zmiana układu i zachowanie danych to powiązane, ale odrębne problemy. Widok może zostać narysowany prawidłowo, a mimo to utracić wpisaną wiadomość. W planie aplikacji określ więc, co jest stanem zadania: wybrany rekord, wersja robocza, pozycja w treści czy etap procesu. Następnie ustal, jak ten stan jest utrzymywany lub odtwarzany przy zmianach obsługiwanych przez konkretną platformę. Mechanizm trzeba dobrać do rodzaju danych i cyklu życia programu.
W Androidzie dokumentacja opisuje zmiany konfiguracji i rozwiązania służące zachowaniu stanu, między innymi ViewModel. Nie jest to instrukcja dla iOS. Podobnie znajomość samej nazwy mechanizmu nie dowodzi, że każda zmienna i każdy efekt uboczny zostaną automatycznie obsłużone.
Przykładem jest formularz z wysyłką do serwera. Po zmianie rozmiaru interfejs powinien pokazywać właściwy stan operacji. Nie może nieświadomie zamieniać odtworzenia ekranu w ponowne zlecenie tego samego działania. Zdefiniuj, jak odróżniasz rozpoczętą operację od nowej decyzji użytkownika, a potem uwzględnij to w próbie. Test powinien sprawdzać zarówno zawartość pól, jak i liczbę faktycznie wykonanych żądań w przygotowanym środowisku testowym.
Klawiatura i wielkość tekstu potrafią zmienić wynik
W projekcie łatwo oceniać ekran bez klawiatury i z krótkimi przykładowymi napisami. W działającej aplikacji pojawi się dłuższy tytuł, inny język albo większy tekst wybrany w systemie. Przetestuj te warianty, zanim uznasz układ za zakończony. Ważne przyciski i komunikaty powinny dać się odnaleźć, a zawartość nie może znikać przez wzajemne nakładanie elementów. Sam brak awarii nie potwierdza jeszcze możliwości ukończenia zadania.
Połącz warianty w kilka praktycznych prób:
- długi tekst i większy rozmiar czcionki w węższym układzie;
- aktywna klawiatura podczas zmiany dostępnego rozmiaru;
- komunikat walidacji przy polu znajdującym się blisko końca formularza;
- powrót do edycji po krótkim przełączeniu aplikacji.
Nie musisz mnożyć losowych kombinacji. Zacznij od głównych ścieżek i sytuacji, w których utrata treści albo ukrycie działania uniemożliwi zakończenie procesu. Kolejne przypadki dodawaj w odpowiedzi na wykryte błędy i zakres wspieranych urządzeń.
Raport z testu powinien pozwolić odtworzyć problem
Przy zgłoszeniu zapisz system, wersję aplikacji, urządzenie lub konfigurację emulatora, rozmiar okna i kolejność kroków. Zamiast „formularz psuje się po otwarciu” opisz, które pole było aktywne, co wpisano i jaki wynik wystąpił. Dołącz oczekiwane zachowanie ustalone wcześniej. Przykładowe dane powinny wystarczać do odtworzenia błędu bez kopiowania prywatnych informacji użytkowników.
Emulator przydaje się do sprawdzania wielu rozmiarów i stanów, a dostępne urządzenie pozwala dodatkowo ocenić rzeczywistą obsługę. W raporcie rozróżnij wykonane próby od przypadków, których jeszcze nie sprawdzono. Jeśli przetestowano tylko jeden system i kilka scenariuszy, opis wyniku powinien odpowiadać temu zakresowi.
Po poprawce odtwórz wadliwy przypadek i sprawdź sąsiednią ścieżkę, na którą mogła wpłynąć zmiana. Naprawienie widoczności przycisku przy klawiaturze nie powinno pogorszyć układu po jej schowaniu. Tak przygotowany zestaw prób będzie przydatny również przy kolejnych rozmiarach okna, ponieważ opisuje zadania i oczekiwany stan, a nie tylko wygląd jednego modelu telefonu.
Materiał zewnętrzny
