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

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

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

При создании таблиц стилей мы должны следовать принципам элементарного проектирования.

В прошлом месяце в публикации под названием «Элементарный дизайн», Брэд Фрост сообщил о том, что Веб-разработки могут быть улучшены. Он предложил разработчикам вместо кодирования форм в виде компонента, который многократно используется на сайте, использовать небольшие стилевые модули – такие, как заполнители, поля ввода и текстовые поля, а затем создать форму, совместив эти куски вместе. Этот процесс можно повторить и для навигационных элементов, для текста с иконками, плавающих объектов и практически для любых других интерфейсных модулей, которые многократно и регулярно используются.

(Изображение Брэда Фроста).

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

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

Он использует научные термины для быстрого описания того, какие разделы дизайна должны быть сделаны; «атомы» представляют собой дискретные куски (заполнители, этикетки и др.), в то время как «молекулы» — это комбинации стандартных атомов. Моё внимание привлекла в первую очередь простота, поскольку, то, что мы обсуждаем – это не просто процесс проектирования, это также вся та совокупность различий в пользовательском интерфейсе, о которой я упоминал ранее.

Проблемы с пользовательским интерфейсом.

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

1. Поиск фрагментов кода должен быть как можно проще.

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

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

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

2. Определение взаимосвязей между модулями должно быть как можно понятнее.

Всякий раз, когда я пытаюсь добавить новый компонент в структуру старого сайта, я должен выяснить особенности ментальной модели взаимосвязей между элементами. Я не перестаю удивляться тому, как удаление одних частей веб-сайта может влиять на другие, совершенно не связанные, находящиеся в другом месте. Это может быть цвет фона, поля, заполнители или даже порядок элементов в модуле (например, изображения в разделе “комментарии” в сочетании с текстом из одного и того же объекта).

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

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

3. Веб-сайты нуждаются в нестандартных компонентах.

Иногда дизайн требует наличия такого компонента, который никогда не будет использоваться повторно, своего рода необычное украшение, которое должно вызвать интерес или восхищение пользователя. Если бы подобный компонент использовался повторено, то он бы быстро стал скучным или, что еще хуже, начал раздражать и отталкивать. В идеале, новая организационная система позволит сортировать компоненты дизайна, и вот что говорит Аллен Тан в своей статье «Созданный для оценивания»:

«Дизайн – это процесс установления взаимосвязей между элементами. Систематизируя эти отношения как совокупность принципов, вместо одного, автономного шаблона, мы даем возможность другим разработчикам понять результаты нашей работы (в статье), оставаясь при этом верными своим основным идеям».

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

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

Всё, что нам нужно сделать – это сгруппировать компоненты согласно оказываемому ими влиянию на всю систему. Элементарный дизайн – это наше спасение!

Система.

В прошлом месяце, я наткнулся на замечательный фреймворк под названием Inuit.css, который, возможно, является лучшим вариантом для начала обучения, если вы незнакомы с модульной конструкции в Sass. Через несколько минут экспериментов, я увидел, что это феноменальный шаг вперед для разработчиков и дизайнеров. Этот фреймворк использует BEM синтаксис, объектно-ориентированные CSS (OOCSS) и многие другие особенности элементарного дизайна. На первый в …

Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров