Чужие мысли

Масштабируемый дизайн

Scalable Design
Автор: Luke Wroblewski
Источник: UXmatters

Вы провели последние шесть месяцев за разработкой дизайна для нового продукта. Последние недели были особенно напряженными – исправление оставшихся ошибок, проработка взаимодействия и графических деталей. И вот теперь, когда продукт готов, можно передохнуть, не так ли?

К сожалению, Брюс Стерлинг, писатель-фантаст и профессор дизайна, был прав, когда говорил: «Дизайн нельзя закончить». Не успеете вы закончить дизайн, как возникнет потребность в новых функциях, переходе на другие рынки или изменении контента.

Элегантный дизайн начинает рушиться под давлением новых возможностей, давать течь при переводе интерфейса на другие языки и практически идет ко дну под тяжестью информации, которую в него впихнули. Вскоре вы сдаетесь. Приходит время переделывать дизайн.

Можно ли избежать этого порочного круга? Есть ли способ предусмотреть все эти изменения? Одно из возможных решений состоит в разработке масштабируемого дизайна. Каркасы страниц, структура пользовательского интерфейса и элементы дизайна, которые позволят вашему продукту элегантно разместить новые функции, предусмотреть переход на другие рынки и вместить столько информации, сколько будет нужно.

Каркасы страницы

Эффективный каркас страницы (или формы – если речь идет о приложении) может служить основой для принятия решений о том, как интегрировать новые функции. Точно также как план дома ясно показывает, куда можно установить новую плиту (на кухню), каркас организует пространство на экране.

Рассмотрим каркас страницы web-приложения для составления отчетов. Набор ключевых областей организует внутренность приложения в логичную структуру. Элементы для фильтрации данных располагаются в области слева. Функции, позволяющие пользователям перейти к другому набору данных, располагаются сверху слева. Функции для сохранения, экспорта или отправки данных расположены сверху справа.

Теперь рассмотрим, что произойдет, если после запуска продукта, ваш заказчик сообщит, что клиентам нужна новая функция. Нет проблем, вы знаете, куда ее поместить и дизайн останется без изменений. Но что делать, если для новой функции нет четкого места в каркасе? Вполне может быть, что такая функция просто не относится напрямую к вашему приложению. Вы не должны добавлять новую функцию просто потому, что вы можете ее добавить. В любом случае, каркас дает однозначный ответ, что делать с новыми функциями, не заставляя вас переделывать дизайн.

Если в каркасе нет места для новых функций, но эти функции являются частью приложения, то тогда действительно придется менять дизайн. Чтобы ситуация с переделкой дизайна была редким исключением, при создании каркаса приложение нужно изучать очень подробно.

Структура пользовательского интерфейса

Хотя каркас поможет точно определить, куда ставить (или не ставить) новые функции, масштабируемость дизайна на самом деле определяется структурой элементов, которые будут в дизайне использоваться.

Для примера давайте рассмотрим элемент, использующийся для выбора набора данных, по которым стоится отчет в нашем приложении. Поскольку цель этого элемента в том, чтобы человек мог выбрать конкретный набор данных, который он бы хотел увидеть, разумно использовать ряд горизонтальных вкладок.

Теперь рассмотрим, что произойдет, если потребуется добавить несколько новых наборов данных. Хотите добавить еще вкладки? Сколько вкладок можно добавить, чтобы они не вышли за пределы экрана? А что произойдет, если программа будет переведена на немецкий язык, в котором аналогичные слова содержат в двое больше символов? Довольно быстро удается найти примеры, показывающие, что такие элементы дизайна не будут масштабироваться.

В будущем такая реализация может создать проблемы, и поэтому нужно рассмотреть альтернативное решение. Может быть, использовать выпадающий список или, если необходимо видеть сразу все элементы, расположить их вертикально. Эти варианты более гибкие.

Компоненты

Предположим, что вы тщательно продумали структуру элемента для выбора источника данных. Прогнозируя проблемы с масштабируемостью горизонтального варианта, вы решили вместо этого использовать список пунктов, распложенных вертикально (как на рисунке).

К сожалению, вы по-прежнему не решили проблему, поскольку для достижения масштабируемости нужно также учитывать изменение размеров содержания. Например, размер подписей можно изменить, увеличивая или уменьшая размер шрифта в браузере.

Предполагая подобные изменения, нужно продумать, как будет масшабироваться каждый элемент пользовательского интерфейса. Во многих компаниях, это бремя ложится на разработчиков. Без спецификации от дизайнера, не зная, каким образом этот компонент должен изменяться, разработчики могут сделать совсем не то, что задумывал дизайнер. Сравните, что получится, если большое количество текста не будет предусмотрено.

Указатель, вместо того чтобы быть в середине блока, оказывается на уровне первой строки. Фонового изображения не хватает, чтобы заполнить всю ячейку, поэтому его приходится повторять, из-за чего возникают дополнительные линии.

Заключение

Приложения будут меняться с течением времени. Насколько сложно будет вносить в него изменения, зависит от того, насколько хорошо вы подошли к вопросу масштабируемости. Вот несколько соображений, которые помогут обеспечить некоторый уровень гибкости дизайна:

• Используйте каркасы для размещения новых функций;
• Выбирайте гибкие элементы пользовательского интерфейса или элементы, которые можно расширить;
• Разрабатывайте динамические компоненты, которые будут вмещать содержимое разного размера;

Хотя ни один из этих методов не дает абсолютной гарантии, что удастся избежать редизайна, вместе они могут обеспечить ваше приложение некоторым запасом гибкости для возможного роста.

• 09.10.2007
• Категории: Переводы
• Комментарии: 4

---