Wiele pomysłów na aplikację zaczyna się jako zestaw rozwiązań: nie wystarczy nam platforma do… Wiesz, że trzeba by to zautomatyzować. W tym celu powinna istnieć aplikacja. Takie zdania mogą wskazywać dobry kierunek. Nie są one wystarczające do rozwoju. Pomiędzy ciekawym pomysłem a zrównoważonym produktem są decyzje dotyczące ludzi, sytuacji, danych, granic i późniejszej eksploatacji.
Więc najważniejsza praca zaczyna się przed pierwszym ekranem. Jaki problem naprawdę pojawia się? Jak jest on rozwiązany dzisiaj? Co to kosztuje czas, powoduje błędy lub powoduje niepewność? I jak można zauważyć, że cyfrowe narzędzie poprawia sytuację?
Aplikacja jest nie tylko czysto zaprogramowana. Posiada ona zrozumiały cel, spójny model danych i zakres, który zespół może ponosić nawet po pierwszej wersji.
Opisz problem w sytuacji widocznej
Zarządzanie nieruchomościami jest zbyt obszerne, a zeznanie nie wskazuje, kto jest zainteresowany, ani jaki rodzaj nieścisłości się liczy. Właściciele prywatni znajdą ostatnio udokumentowany poziom licznika i związane z nim zdjęcie nie jest bardziej wiarygodne. Wyznacza on osobę, sytuację, informacje i pożądane rezultaty.
Dobre definicje problemów pozostają w pierwszej kolejności niezależne od rozwiązania. Być może wystarczy lepsze istniejące rozwiązanie, zmieniony proces lub mały interfejs internetowy. Osoby, które natychmiast wymagają określonej technologii, często pomijają prostsze sposoby. Celem wczesnej analizy nie jest usprawiedliwienie aplikacji, ale zrozumienie, czy i gdzie jest ona przydatna.
Na przykład, jakie kroki podejmują ludzie dzisiaj? Jakie narzędzia używają? Gdzie przechodzą między papierem, tabelami, wiadomościami i zdjęciami? Jakie wyjątki pojawiają się? Ważne jest, aby nie pytać tylko o pożądane funkcje. Ludzie opisują rozwiązania z dotychczasowego doświadczenia. Obserwowane trudności lepiej wyjaśniają, co produkt musi zrobić.
Grupa docelowa oznacza również: świadomie nie dla wszystkich
Produkt przeznaczony dla osób prywatnych i firm o dowolnej wielkości nie ma jasnej grupy docelowej. Różne grupy mają inne pojęcia, zagrożenia i procesy pracy. Jedna osoba nie potrzebuje zarządzania rolkami. Zespół nie może pracować niezawodnie bez ról i wspólnych danych.
Pomocny opis grup docelowych obejmuje zatem kontekst użytkowania, doświadczenie, częstotliwość i ograniczenia. Czy ktoś pracuje samodzielnie lub wspólnie? Na smartfonie lub w kilku miejscach pracy? Czy aplikacja jest otwarta codziennie lub tylko w jednym wydarzeniu? Czy musi działać bez sieci? Jakie błędy byłyby uciążliwe i jakie byłyby poważne konsekwencje?
Pytania te mają wpływ na prawie wszystko później: nawigacja, przechowywanie danych, model bezpieczeństwa, teksty pomocy i model biznesowy. Rozgraniczenie nie jest czysto marketingową pracą osoby. Jest ona częścią specyfikacji technicznej.
Znajdź najmniejszy pełny przebieg
Wczesny produkt powinien być mały, ale nie przerwany. Na przykład, jeśli chcesz udokumentować licznik, musisz wybrać obiekt, wprowadzić datę i wartość, opcjonalnie zrobić zdjęcie, zapisać, późniejszy odnalezienie i skorygowanie. Wystarczy zbudować formularz, bez konieczności zmiany historii lub błędów, choć byłoby to mniej uciążliwe, ale bez pełnej korzyści.
Najmniejszy pełny przebieg zawiera początek, środek i koniec oraz najważniejsze odchylenia. Co się dzieje w przypadku braku uprawnień do aparatu? Można zapisać bez zdjęcia? Jak wygląda pusty stan? Co się stanie w przypadku nieprawidłowej liczby lub awarii? Czy wpis zostanie zachowany po przerwie?
Dopiero wtedy, gdy ta podstawowa ścieżka jest jasna, funkcje można rozdzielić w sposób sensowny i opcjonalny. Konieczne jest to, co pozwala na uzyskanie wyniku lub chroni go przed nieustępliwym błędem. Opcjonalne jest to co rozszerza komfort, warianty lub kolejne grupy docelowe. Rozdzielenie to powinno być regularnie sprawdzane, ponieważ pozornie mała opcja może generować nowe dane i stany.
Prototypy mają na celu ukazanie decyzji
Prototyp jest szczególnie cenny, gdy ujawnia pytania. Czy ludzie rozumieją użyte terminy? Czy znajdą kolejny krok? Brak im informacji przed podjęciem decyzji? Czy proces odpowiada sytuacji, w której smartfon jest rzeczywiście używany?
Prototyp nie musi być idealny wizualnie. Łatwy do naciśnięcia projekt z realistycznymi treściami często pokazuje więcej niż polerowaną prezentację pełną przycisków. Prawdziwe nazwy, dłuższe teksty, brakujące obrazy i wiele rekordów sprawiają, że widoczne, czy układ i architektura informacji noszą.
Prototypy powinny również zawierać stan krytyczny: brak danych, błędy ładowania lub przechowywania danych, brak uprawnień, offline, bardzo duża czcionka i nieodwracalne działania. Kto tylko demonstruje idealną sekwencję, testuje historię zamiast produktu.
Apple podkreśla w swoich wytycznych Human Interface Hierarchię, spójność i dostosowanie do różnych wyświetlaczy. Zasady te nie można w końcu uzupełnić ozdobą. Mają one już wpływ na strukturę prototypu: co jest treścią, co jest działaniem, które informacje pozostają na pierwszym planie i jakie interakcje są znane na danej platformie?
Model danych jest długotrwałą decyzją zawodową
Powierzchnie mogą się znacznie zmienić. Znaczenie przechowywanych danych często pozostaje na przestrzeni lat. Dlatego warto wcześnie wyjaśnić, jakie rzeczy występują w produkcie i jak się z nimi wiążą. Czy przestrzeń jest zawsze częścią jednostki? Czy dokument może być powiązany z wieloma procesami? Co się dzieje z zadaniami, gdy obiekt jest archiwizowany? Czy kwoty pieniędzy i zmierzone wartości są dokładnie zapisane?
Konsekwentny model danych zapobiega powstawaniu tej samej informacji w kilku miejscach. Dla architektur aplikacji Android Developers zaleca m.in. jasne źródło danych i wyraźne ograniczenia odpowiedzialności. Te zasady techniczne wspierają właściwość techniczną: w przypadku zmiany informacji, należy zrozumieć, która prezentacja jest późniejsza.
Do tej decyzji należą również migracje. Gdy tylko istnieją prawdziwe dane, nowa wersja nie może dowolnie zmienić nazwy lub skasować pól. Produkt wymaga przepisów dotyczących sposobu przeniesienia starszych stanów do nowej struktury. Dobry pierwszy projekt nie próbuje przewidzieć każdej przyszłości, ale oddziela stabilne terminy techniczne od krótkoterminowej logiki powierzchniowej.
Ochrona danych rozpoczyna się od pytania, jakie dane są potrzebne
Ochrona danych będzie kosztować, jeśli zostanie zbadana dopiero po wdrożeniu, a uprawnienia, usługi zewnętrzne i modele danych będą już ze sobą powiązane.
Czy aplikacja potrzebuje konta? Czy kontakt musi być w pełni zaimportowany, czy wystarczy osoba zarejestrowana ręcznie? Czy dostęp do lokalizacji jest potrzebny na stałe, tylko w przypadku pojedynczego działania, czy też nie? Czy dokument musi opuścić serwer? Każda uniknięta ankieta zmniejsza powierzchnię, błędy, bezpieczeństwo i późniejsze procesy usuwania.
Android zaleca minimalizację zapytań o uprawnienia oraz, w miarę możliwości, zaprojektowanie funkcji w taki sposób, aby mogły one funkcjonować bez niepotrzebnego dostępu. Jeśli wymagane jest uprawnienie, należy go poprosić w kontekście danego działania. Odrzucone uprawnienie nie może automatycznie spowodować, że cała aplikacja będzie bezużyteczna, jeśli możliwe jest zastosowanie innej drogi.
Ochrona danych obejmuje cały cykl życia: przechowywanie, wyświetlanie, udostępnianie, eksport, tworzenie kopii zapasowych i usuwanie danych. W przypadku danych w chmurze konieczne jest zapewnienie ochrony konta, zasad dostępu i łatwego do zrozumienia procesu usuwania danych.
Oczekiwanie wynika z ograniczeń i odpowiedzialności
Wykrywalna baza kodowa posiada moduły z jasnymi zadaniami. Interfejs koordynuje interakcje, logika specjalistyczna wdraża zasady, a poziom danych zarządza źródłami i trwałością. Gdy dostęp do sieci, prezentacja i zasady biznesowe są mieszane z tymi samymi komponentami, zmiany i testy stają się trudniejsze.
Rozdzielenie techniczne nie wystarczy. Produkt również potrzebuje ograniczeń odpowiedzialności. Kto decyduje o pojęciach? Jaka funkcja jest istotna dla zbioru danych? Jakie zobowiązania zobowiązuje się produkt, gdy usługa zewnętrzna nie działa? Czy istnieje ręczna droga? Co jest wyraźnie nieobsługiwane?
Każda zależność powinna mieć rozpoznawalny cel. Biblioteka może przyspieszyć rozwój, ale potrzebuje aktualizacji i obserwacji bezpieczeństwa. Usługa chmury obliczeniowej może wykonywać złożone zadania, ale powoduje koszty i awarię. Własny system zapewnia kontrolę, ale wymaga stałej opieki. Oczekiwanie oznacza świadome wybranie tych obowiązków.
Dokumentacja pomaga w wyjaśnianiu decyzji. Długa lista każdego pliku szybko się starzeje. Warte są krótkie opisy granic systemu, przepływów danych, zasad migracji i powodów, dla których decyzje są niewidoczne. Nowi członkowie zespołu lub ich przyszłość Muszę zrozumieć, dlaczego część została zbudowana w ten sposób.
Testy podążają za ryzykiem i prawdziwymi drogami
Wysoka liczba zautomatyzowanych testów nie dowodzi automatycznie jakości produktu. Decydujące jest to, czy ryzyko jest pokryte. Testy jednostek są odpowiednie dla zasad technicznych i obliczeń. Testowanie integracji sprawdza wzajemne oddziaływanie bazy danych, usług i migracji. Test końcowy może zabezpieczać centralne ścieżki użytkowników. Kontrole ręczne pozostają ważne dla języka, hierarchii wizualnej, kierowania ostrością i sytuacji, które są trudne do zautomatyzacji.
Testy powinny pracować z realistycznymi danymi: długie nazwy, puste listy, starsze rekordy, niezwykłe wartości dziesiętne, wiele załączników i przerwanych połączeń. Różne rozmiary ekranu i duże teksty pokazują, czy układ jest naprawdę adaptacyjny. Czytnik ekranu i klawiatura pokazują słabe strony semantyczne, których zrzut ekranu nie pokazuje.
W3C WAI zaleca wczesne i regularne ocenianie dostępności oraz odpowiednie angażowanie osób niepełnosprawnych. Jest to dobra ogólna zasada jakości: nie tylko trzymać gotowej wersji przeciwko liście kontrolnej, ale także umieszczać informacje zwrotne tam, gdzie decyzje są jeszcze zmienne.
Szczególnie ryzykowne działania wymagają ukierunkowanych testów. Usuń, przywróć, status zakupu, eksport i uprawnienia zarabiają więcej głębi niż czysto dekoracyjne ustawienie. Priorytetowanie według wpływu i prawdopodobieństwa jest bardziej przydatne niż wymaganie tej samej ilości testów w dowolnym miejscu.
Publikacja stopniowa oznacza nieukończoną publikację
Pierwsza wersja nie musi zawierać jakiegokolwiek długoterminowego planu, ale jej obiecane główne ścieżki powinny być kompletne, zrozumiałe i wytrzymałe. nie jest to jednak wymówka dla braku przetwarzania błędów lub niejasnej odpowiedzialności za dane.
Przed publikacją konieczne są możliwe do zweryfikowania kryteria: obsługiwane urządzenia i wersje, przetestowane procesy podstawowe, zrozumiałe granice produktów, poprawne Store- i Prawne teksty, dostępne wsparcie, zachowanie kopii zapasowych lub usuwania oraz plan błędów krytycznych. Kontrolowany krąg testów może pokazać rzeczywiste wykorzystanie przed dokonaniem szerokiego zobowiązania.
Po opublikowaniu wiadomości zwrotne nie będą automatycznie wyświetlane na mapie drogowej. Są to odniesienia do sytuacji. Kilka życzeń dla tej samej funkcji może pokazać wzór lub wskazać istniejący przebieg, którego nikt nie znajdzie. Zespoły produktów powinny zrozumieć problem, częstotliwość, grupę docelową i ryzyko, zanim określą rozwiązanie.
Późniejsza wersja może przynieść nowe umiejętności, nie powinna ukrywać rdzenia i szanować istniejących danych. Migracja, zgodność z prawem i zmienione wyjaśnienia są częścią funkcji, a nie czynności związanych z sprzątaniem.
Czerwona nić pozostaje konkretnym wynikiem
Piękny prototyp, nowoczesna architektura lub duża lista funkcji może być cenna, ale bez odniesienia do problemu łatwo optymalizują niewłaściwy system.
Wykrywalna aplikacja łączy kilka rodzajów jasności: rzeczywisty problem, ograniczoną grupę docelową, kompletne podstawowe procesy, spójny model danych, minimalne i zrozumiałe ścieżki danych, możliwe do sprawdzenia obowiązki i uczciwe ograniczenia produktów. Praca ta jest mniej spektakularna niż pierwszy ekran, który można kliknąć, ale decyduje o tym, czy dany pomysł stanie się narzędziem, które może być dalej rozwijane po wielu wersjach.
Źródła i dalsze informacje
- Android Developers: Guide to app architecture – modele danych, jedno źródło prawdy, testowalność i granice odpowiedzialności.
- Android Developers: Data layer – zadania i granice warstwy danych.
- Android Developers: Minimize permission requests – minimalizacja danych i uprawnienia wymagane w kontekście.
- Apple Human Interface Guidelines – hierarchia, spójność, układ i interakcje dostosowane do platformy.
- W3C WAI: Planning and Managing Web Accessibility – wczesne i ciągłe uwzględnianie dostępności i jej oceny.
