Идея «итеративного процесса» не нова в разработке программного обеспечения. Она присутствует в ряде различных методологий и, вероятно, потому, что она хорошо работает, особенно при получении отзывов от клиентов.
Одно из мест, которое я также считаю полезным, — это создание интерфейсов администрирования для плагинов WordPress.
Чтобы было ясно, я не дизайнер, поэтому, когда дело доходит до работы с интерфейсом, я всегда обращаюсь к руководству по стилю и макетам, которые дизайнер предоставляет мне с самого начала проекта. (Я упоминаю об этом только потому, что думаю, что любой, кто не является дизайнером, должен следовать этому правилу, но я отвлекся).
Но когда дело доходит до работы с экранами администрирования или серверными экранами для WordPress, я стараюсь следовать строгому правилу: убедитесь, что это выглядит как можно более естественно.
Как же тогда итеративная разработка и интерфейс экранов администрирования WordPress связаны друг с другом?
Дизайн экрана администрирования WordPress
Эта конкретная статья воздерживается от разговоров о том, что требуется для сохранения информации. То есть я предполагаю все:
- дезинфекция,
- Проверка,
- одноразовые проверки,
- проверки разрешений,
И тому подобное понимают и обрабатывают.
Для этого поста я буду простым. Допустим, мы хотим иметь:
- пара текстовых полей,
- кнопка сохранения,
- кнопка сброса,
- и, возможно, что-то дополнительное в конце.
Как это может отразиться на итеративном процессе проектирования?
1 Набросок
Допустим, вы работаете над чем-то и планируете, как будет выглядеть административный экран. Учитывая то, что у нас было выше, возможно, первоначальный набросок мог бы выглядеть так:
Достаточно легко, верно? Он представляет то, что нужно поддерживать проекту, и отображает все, что нам нужно для этого конкретного экрана администрирования.
2 Строим это
После сборки он должен выглядеть максимально естественно. Учитывая стили, доступные в WordPress, создать это относительно легко с помощью доступных API и разметки:
И что делает каждое поле и кнопка?
3 Уточнение
Именно здесь в игру вступает доработка функциональности. Например:
- Я не думаю, что кнопка «Сохранить» должна быть включена, пока обязательные поля не будут заполнены,
- Я думаю, что кнопка сброса должна очищать то, что присутствует,
- Должна быть определенная степень сообщений об ошибках, которые представляют, что нам нужно делать, когда что-то выходит из строя, когда что-то может быть не так, или что-то совершенно не так.
Очевидно, что гораздо легче говорить об этом, когда речь не идет о конкретном проекте, но, возможно, некоторые из идей применимы к тому, чем вы занимаетесь.
Асинхронные улучшения?
Одна из вещей, к которой мы привыкли с такими устройствами, как наши телефоны и некоторые части наших операционных систем, заключается в том, что когда мы переключаем переключатель или вносим небольшие изменения, данные сохраняются.
То есть никаких подтверждающих действий (кроме чего-то деструктивного вроде удаления файла, разумеется) не требуется. Данные просто сохраняются, и опция работает.
Тем не менее, мы все еще видим много кнопок «Сохранить» в WordPress, не так ли? Как насчет сохранения ввода через Ajax или другой асинхронный метод? Это то, что я еще не реализовал, но я, конечно, обдумывал это.