Ітерація дизайну екрана адміністрування WordPress
Ідея «ітераційного процесу» не є чимось новим у розробці програмного забезпечення. Вона присутня в низці різних методологій і, ймовірно, тому, що добре працює, особливо коли отримується відгук від клієнтів.
Одне з тих місць, де я також вважаю його корисним, це створення інтерфейсів адміністрування для плагінів WordPress.
Щоб було зрозуміло, я не дизайнер, тому, коли мова заходить про зовнішню роботу, я завжди посилаюся на керівництво по стилю та макети, які дизайнер надає мені з самого початку проекту. (Я згадую це лише тому, що вважаю, що це практика, якої має дотримуватися кожен, хто не є дизайнером, але я відволікаюся).
Але коли справа доходить до роботи над екранами адміністрування або внутрішніми екранами для WordPress, я прагну дотримуватись суворого правила: переконайтеся, що це виглядає якомога природніше.
Як же тоді ітераційна розробка та інтерфейс екранів адміністрування WordPress мають щось спільне одне з одним?
Дизайн екрана адміністрування WordPress
У цій конкретній статті не йдеться про те, що потрібно для збереження інформації. Тобто я припускаю все:
- санітарна обробка,
- перевірка,
- разові перевірки,
- перевірки дозволів,
І подібне розуміють і обробляють.
У цьому дописі я буду простіше. Скажімо, ми хочемо мати:
- кілька текстових полів,
- кнопка збереження,
- кнопка скидання,
- і, можливо, щось додаткове в кінці.
Як це може відтворюватися через ітеративний процес під час проектування?
1 Ескіз
Скажімо, ви над чимось працюєте та плануєте, як виглядатиме адміністративний екран. Враховуючи те, що ми мали вище, можливо, початковий ескіз може виглядати так:
Досить легко, чи не так? Він представляє те, що потрібно підтримувати проекту, і відображає все, що нам потрібно для цього конкретного екрана адміністрування.
2 Будівництво
У зібраному вигляді він повинен виглядати максимально рідним. Враховуючи стилі, доступні в WordPress, це відносно легко створити за допомогою доступних API та розмітки:
І що робить кожне поле та кнопка?
3 Доопрацювання
Ось де вдосконалення функціональності вступає в гру. Наприклад:
- Я не думаю, що кнопку «Зберегти» слід увімкнути, доки не будуть заповнені необхідні поля,
- Я думаю, що кнопка «Скинути» повинна очистити наявне,
- Повинен бути певний рівень повідомлень про помилки, які відображають, що нам потрібно робити, коли щось не вдається, коли щось може бути неправильним або щось зовсім неправильне.
Очевидно, що набагато легше говорити про це, коли це не стосується конкретного проекту, але, можливо, деякі ідеї можна застосувати в будь-якій справі.
Асинхронні вдосконалення?
Одна з речей, до яких ми звикли з такими пристроями, як наші телефони та деякі частини наших операційних систем, полягає в тому, що коли ми перемикаємо перемикач або вносимо невеликі зміни, дані зберігаються.
Тобто жодних дій підтвердження (крім чогось деструктивного, наприклад видалення файлу, звичайно) не потрібно. Дані просто зберігаються, і опція працює.
Тим не менш, ми все ще бачимо багато кнопок збереження в WordPress, чи не так? Як щодо збереження введених даних через Ajax або інший асинхронний метод? Це те, що я ще не реалізував, але я, безперечно, розглядав це.