Pomysł „procesu iteracyjnego" nie jest niczym nowym w tworzeniu oprogramowania. Jest obecny w wielu różnych metodologiach i prawdopodobnie dlatego, że sprawdza się dobrze, zwłaszcza podczas uzyskiwania informacji zwrotnych od klientów.
Jednym z miejsc, które również uważam za przydatne, jest budowanie interfejsów administracyjnych dla wtyczek WordPress.
Żeby było jasne, nie jestem projektantem, więc jeśli chodzi o prace front-endowe, zawsze odwołuję się do style guide i makiet, które projektant dostarcza mi od samego początku projektu. (Wspominam o tym tylko dlatego, że uważam, że jest to praktyka, którą powinien stosować każdy, kto nie jest projektantem, ale robię dygresję).
Ale jeśli chodzi o pracę nad ekranami administracyjnymi lub ekranami zaplecza dla WordPressa, kieruję się ścisłą zasadą: upewnij się, że wygląda to tak naturalnie, jak to tylko możliwe.
Jak zatem iteracyjny rozwój i interfejs ekranów administracyjnych WordPressa mają ze sobą coś wspólnego?
Projekt ekranu administracyjnego WordPress
W tym konkretnym artykule zrezygnowano z mówienia o rzeczach, które są oczekiwane w przypadku zapisywania informacji. Oznacza to, że zakładam wszystkie:
- sanityzacja,
- walidacja,
- czeki jednorazowe,
- kontrole uprawnień,
I podobne są rozumiane i obsługiwane.
W tym poście zachowam prostotę. Powiedzmy, że chcemy mieć:
- kilka pól tekstowych,
- przycisk zapisu,
- przycisk resetowania,
- a na koniec może coś ekstra.
Jak może to rozegrać się w iteracyjnym procesie projektowania?
1 Szkicowanie
Załóżmy, że nad czymś pracujesz i planujesz wygląd ekranu administracyjnego. Biorąc pod uwagę to, co mieliśmy powyżej, być może wstępny szkic może wyglądać tak:
Wystarczająco łatwe, prawda? Reprezentuje to, co projekt musi utrzymać, i wyświetla wszystko, czego potrzebujemy do tego konkretnego ekranu administracyjnego.
2 Budowanie tego
Raz złożony powinien wyglądać tak natywnie, jak to tylko możliwe. Biorąc pod uwagę style, które mamy dostępne w WordPress, stosunkowo łatwo jest to zbudować za pomocą dostępnych interfejsów API i znaczników:
A co robi każde pole i przycisk?
3 Udoskonalanie go
W tym miejscu w grę wchodzi udoskonalanie funkcjonalności. Na przykład:
- Uważam, że przycisk Zapisz nie powinien być włączony, dopóki wymagane pola nie zostaną wypełnione,
- Myślę, że przycisk Reset powinien wyczyścić to, co jest obecne,
- Powinna istnieć pewna ilość komunikatów o błędach, z których wszystkie reprezentują to, co musimy zrobić, gdy coś się nie powiedzie, gdy coś może być nie w porządku lub coś jest całkowicie nie tak.
Oczywiście dużo łatwiej o tym mówić, gdy nie odnosi się to do konkretnego projektu, ale być może niektóre z pomysłów mają zastosowanie w tym, co się dzieje.
Ulepszenia asynchroniczne?
Jedną z rzeczy, do których przyzwyczailiśmy się z urządzeniami takimi jak nasze telefony i niektóre części naszych systemów operacyjnych, jest to, że gdy przełączamy przełącznik lub wprowadzamy niewielką zmianę, dane są zapisywane.
Oznacza to, że nie jest wymagane żadne działanie potwierdzające (poza czymś destrukcyjnym, takim jak usunięcie pliku, oczywiście). Dane są po prostu zapisywane, a opcja działa.
Jednak wciąż widzimy wiele przycisków Zapisz w WordPressie, prawda? A co z zapisywaniem danych wejściowych za pomocą Ajax lub innej metody asynchronicznej? To jest coś, czego jeszcze nie zaimplementowałem, ale z pewnością to rozważałem.