Философия BEM CSS подход к структурированию пользовательских интерфейсов

Содержание материала:

Расширенный CSS: использование Sass Maps для компонентов пользовательского интерфейса

Sass — это отличный и очень популярный CSS-препроцессор. Если вы не знакомы с ним, взгляните на эти уроки.

Ассоциативные массивы (Maps) являются чрезвычайно недооцененной особенностью Sass. Они помогают автоматизировать создание элементов пользовательского интерфейса и улучшить архитектуру всего приложения. Вам пригодятся ассоциативные массивы, когда понадобится набор классов-модификаторов для элементов пользовательского интерфейса.

Модификатор — это класс, модифицирующий стиль блока в зависимости от контекста. Блок — это универсальный родительский класс, который может использоваться сам по себе.

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

Синтаксис ассоциативных массивов Sass

Получить значение по ключу можно так:

Настройка

У вас, вероятно, есть Sass-файл, в котором вы объявляете все переменные (что-то вроде _variables.scss или _base.scss). Если нет, вы должны его создать. Здесь же мы опишем и наши мэпы.

После нескольких попыток и ошибок я поняла, что лучший способ настроить ассоциативные массивы — сначала объявить переменные, а затем создать Map с этими переменными. Такой способ позволяет использовать простые переменные в коде (например, $color-robin) вместо получения значения с помощью map-get (например, map-get($ui-colors, primary)).

Я обычно объявляю 4 мэпа:

  • Цвета темы (цвета фирменного стиля)
  • Цвета элементов интерфейса (цвета для ошибок, всплывающих подсказок, кнопок)
  • Оттенки серого (цвета для текста, теней, фонов)
  • Фирменные цвета (используется, например, для иконок социальных сетей)

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

Какие переменные стоит использовать в ассоциативном массиве? Переменные, которые вы будете использовать в миксинах для создания классов модификаторов. За исключением очевидного — выбора цвета — ассоциативные массивы можно использовать для типографики, иконок или изображений. В следующем примере я покажу, как создать различные классы для кнопок, используя карту цветов UI Colors.

Кнопки

Я использую директиву each, которая проходится циклом по массиву $ui-colors и создает класс-модификатор для базового класса .button. Мы получаем модификаторы для стилизации кнопок как ‘error’ или ‘success’.

Такой подход избавляет от необходимости дублирования кода. А также, если вы захотите изменить какой-то цвет в цветовой схеме или добавить новые цвета — все элементы интерфейса обновятся автоматически.

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

Иконки социальных сетей

Я использовала тот же шаблон, что и в прошлом примере, но на этот раз добавила иконки социальных сетей. Код ниже создает класс блока social-media-icon и модификаторы для различных иконок.

Заключение

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

Ассоциативные массивы хорошо подходят для организации цветов, типографики, иконок или изображений.

Использование ассоциативных массивов помогает сохранять единый дизайн в определенном контексте (например, все сообщения об ошибках красные).

Одним блоком кода можно создать множество классов-модификаторов, что избавляет от необходимости дублировать код.

Нашли опечатку? Orphus: Ctrl+Enter

© getinstance.info Все права защищены. 2014–2020

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

Подходы и инструменты для разработки пользовательского интерфейса

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

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

Задача с точки зрения UI-дизайна

Отправная точка — это не только определение задачи, которую надо решить, но и её понимание с точки зрения ваших клиентов.

Главная задача клиента — чётко сформулировать идею правильным людям с подходящими навыками. Тогда разработанный интерфейс точно можно будет использовать.

9 ноября в 10:00, Ульяновск, 500–1600 ₽

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

Разработайте собственный алгоритм подхода к дизайну

Сформируйте простой порядок действий для разработки UI-дизайна вашего приложения. Вот некоторые рекомендованные шаги:

  • создание диаграммы пользовательских маршрутов;
  • изучение существующих дизайнерских шаблонов и стилей;
  • создание каркасов;
  • создание макетов.

Диаграмма пользовательских маршрутов

Сначала подумайте, как пользователи будут взаимодействовать с вашим приложением.

Как пользователи могут попасть в нужный им раздел? Можно ли на диаграмме потоков визуализировать все возможные маршруты пользователей по приложению?

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

Для удобства можно использовать различные готовые инструментарии, например, шаблоны блок-схем Miro, Milanote и Whimsical. Можно легко формировать маршруты с помощью трёх стандартных фигур:

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

Здесь проиллюстрирована диаграмма маршрутов пользователя на этапе предварительного дизайна. Исследовать другие распространённые маршруты и фильтровать широкий спектр скриншотов из iOS, Android и веб-приложений можно на Page Flows.

Изучение дизайнерских шаблонов и стилей

Планирование облегчает реализацию, поэтому всегда делите задачи на более мелкие части.

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

Дорабатывайте и совершенствуйте их, чтобы сделать ваше приложение как можно лучше.

Отличным источником информации будет UI Patterns. Это прекрасный ресурс, чтобы ознакомиться с наиболее часто используемыми шаблонами проектирования и способами их применения.

Если вы не определились с тем, какие компоненты вам понадобится включить в приложение, можете посетить дополнительные сайты вроде Behance и Dribbble. Там вы найдёте замечательные идеи, потому что многое является концептуальным, а не готовым продуктом.

Вот ещё несколько отличных ресурсов:

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

Создание каркасов

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

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

Обратите внимание на SneakPeekIt. В нём есть большое количество шаблонов, которые можно распечатать и использовать в своих эскизах. Это совершенно бесплатный инструмент для вдохновения.

Также обязательно ознакомьтесь с Balsamiq, Whimsical и OmniGraffle. Эти компоненты предварительной сборки помогут в работе со структурой вашего приложения.

Ваш первый UI можно получить, объединив нескольких шаблонов с этих сайтов. Тщательное их изучение поможет вам оптимизировать работу приложения.

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

Создание макетов приложения

Как только иерархия установлена и структура каждого экрана определена, вы можете перейти к программному обеспечению, например, Figma или Sketch, для разработки своего продукта. Figma — облачный инструмент для UI-дизайна. Идеально подходит для реализации каркасов на этом этапе процесса.

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

Если вы не в силах разобраться во всём самостоятельно и рискуете совершить ошибки, вам стоит обратиться к опытному специалисту. Он поможет сопроводить проект на всех его этапах, а также представить вашим клиентам. Просто доверьтесь специалисту.

Методология

Инструментарий

Учебные материалы

В БЭМ-методологии CSS используется для оформления страниц и является одной из технологий реализации блока.

Основные принципы работы с CSS рассматриваются в следующих разделах:

Селекторы

В БЭМ не используют селекторы тегов и идентификаторов. Стили блоков и элементов описываются через селекторы классов.

Селекторы классов

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

Значением атрибута class может быть разделенный пробелами список слов. Это позволяет использовать разные БЭМ-сущности на одном DOM-узле.

Совмещение тега и класса в селекторе

Методология БЭМ не рекомендует совмещать теги и классы в селекторе. Объединение тега и класса (например, button.button ) повышает специфичность CSS-правил, что усложняет задачу их переопределения. Это приводит к войнам значимости, при которых таблицы стилей загружаются излишне сложными селекторами.

CSS-правила заданы в селекторе button.button .

Допустим, блоку добавили модификатор active со значением true :

Селектор .button_active не переопределит свойства блока, записанные как button.button , так как специфичность button.button выше чем у .button_active . Для успешного переопределения селектор модификатора блока также должен быть скомбинирован с тегом button.button_active .

В результате развития проекта могут, например, появиться блоки с селекторами input.button , span.button и a.button . В таком случае все модификаторы блока button и вложенные в него элементы потребуют четыре разные декларации для каждого случая.

Нужно стараться использовать простые селекторы классов:

Вложенные селекторы

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

При использовании вложенных селекторов важно соблюдать принцип инкапсуляции: правила одного блока не должны влиять на внутренний мир другого блока. Элементы — это внутренняя реализация блока. Таким образом, блок влияет только на свои элементы и не может воздействовать на элементы другого блока.

Вложенность уместна, если необходимо изменить стили элементов в зависимости от модификатора (например, состояния блока или заданной темы):

Комбинированные селекторы

Методология БЭМ не рекомендует использовать комбинированные селекторы. Комбинированные селекторы (например, .button.button_theme_islands ) имеют более высокую специфичность, чем одиночные селекторы, что усложняет задачу их переопределения.

CSS-правила заданы в селекторе .button.button_theme_islands .

Допустим, блоку добавили модификатор active с значением true :

Селектор .button_active не переопределит свойства блока, записанные как .button.button_theme_islands , так как специфичность .button.button_theme_islands выше, чем у .button_active . Для успешного переопределения селектор модификатора блока также должен быть скомбинирован с селектором .button и объявлен ниже .button.button_theme_islands , так как специфичность обоих селекторов одинакова:

Нужно стараться использовать простые селекторы классов:

Именование

Имя селектора должно полно и точно описывать представляемую им БЭМ-сущность.

В качестве примера рассмотрим следующие четыре строки CSS-кода:

С определенной долей вероятности можно предположить, что мы имеем дело с одним блоком и его HTML-реализация выглядит следующим образом:

Сложнее сделать подобное предположение с такой группой селекторов:

Имена icon , text , theme_islands не так информативны.

сделать имена CSS-селекторов максимально информативными и понятными;

решить проблему коллизии имен;

независимо описывать стили блоков и их опциональных элементов.

Модификаторы

Модификаторами в БЭМ задают блокам внешний вид, состояние и поведение. Изменение оформления блока производится при помощи установки/снятия модификатора.

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

Это избавляет от ненужного «Copy-Paste».

Миксы

совмещать поведение и стили нескольких сущностей без дублирования кода;

одинаково форматировать разные HTML-элементы.

Внешняя геометрия и позиционирование

В CSS по БЭМ стили, отвечающие за внешнюю геометрию и позиционирование, задаются через родительский блок.

В данном примере внешняя геометрия и позиционирование блока button задана через элемент header__button . Блок button не специфицирует никакие отступы и может быть легко переиспользован в любом месте.

Стилизация групп блоков

Иногда необходимо применить одинаковое форматирование сразу к нескольким различным HTML-элементам веб-страницы. Обычно для решения подобных задач применяют групповые селекторы.

В данном примере текст внутри блоков article и copyright имеет один и тот же цвет и шрифт.

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

Поэтому в БЭМ для того, чтобы единообразно отформатировать целый набор HTML-элементов, используют миксы.

Разделение кода на части

К CSS по БЭМ применяются основные принципы организации и хранения кода:

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

CSS-файлы для каждого компонента хранятся в соответствии с правилами организации файловой структуры БЭМ-проекта.

Разделение кода на части и строгая организация файловой структуры проекта позволяет:

облегчить навигацию по проекту;

повторно использовать и переносить компоненты;

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

Блок button в файловой структуре проекта:

Такое разделение позволяет быстро находить нужные файлы.

Принцип единственной ответственности

Как и в объектно-ориентированном программировании, принцип единственной ответственности (англ. Single responsibility principle) в CSS по БЭМ означает, что каждая CSS-реализация должна иметь одну ответственность.

Ответственность: внешняя геометрия и позиционирование (зададим внешнюю геометрию и позиционирование для блока button через элемент header__button ).

Селекторы с одиночной ответственностью придают коду больше гибкости.

Принцип открытости/закрытости

Любой HTML-элемент страницы должен быть открыт для модификации, но закрыт для изменения. Разрабатывать новые CSS-реализации следует так, чтобы не пришлось менять уже существующие.

Топ-пост этого месяца:  Как получить сертификат Яндекс.Директ вопросы и ответы

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

Существующая функциональность кнопки расширена при помощи класса button_size_s (переопределены свойства font-size и line-height ). Теперь на странице есть две кнопки разного размера.

Нарушение принципа открытости/закрытости

Изменение существующей CSS-реализации

Текущая CSS-реализация кнопки должна быть закрыта для редактирования. Изменения коснутся всех блоков button .

Оформление кнопки стало зависеть от ее расположения. Изменения коснутся всех блоков button внутри блока content .

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

Применительно к методологии БЭМ суть данного принципа заключается в том, что каждая БЭМ-сущность должна иметь единственное, однозначное представление в рамках системы.

Как видно из примера, в селекторе btn повторена существующая реализация блока button .

Перепишем пример в соответствии с принципом DRY:

Благодаря добавлению модификаторов, мы избавились от блока btn .

Важно! Принцип DRY имеет отношение только к функционально однотипным компонентам страницы, например, кнопки.

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

Не имеет смысла объединять разные по типу блоки, только потому что у них, например, одинаковый цвет или размер.

Композиция вместо наследования

Наследование — это механизм, позволяющий описать новый CSS-класс на основе существующего (родительского, базового). Класс-потомок может добавить собственные свойства, а также пользоваться родительскими.

Новые CSS-реализации в БЭМ собирают из уже существующих, путем их объединения. Это сохраняет код несвязным и гибким.

Допустим, есть три готовые реализации:

кнопка — блок button ;

меню — блок menu ;

всплывающее окно — блок popup .

Реализовать раскрывающийся список (блок select ).

Разработать раскрывающийся список с произвольным внешним видом — весьма непростая задача. Однако, если есть готовые компоненты (кнопка, всплывающее окно и меню), остается только правильно описать их взаимодействие.

Работа с уровнями переопределения

Применение принципов БЭМ-методологии к CSS позволяет разделять представление блоков по разным уровням.

Разделение по уровням позволяет:

реализовывать новый внешний вид блока на другом уровне переопределения, сохраняя предыдущий, наследовать и дополнять его;

полностью перекрывать внешний вид блока (переопределять);

добавлять блоки с новым представлением.

С помощью уровней переопределения можно создать универсальную CSS-библиотеку блоков и изменять ее на проектном уровне. Затем использовать сборку и включать в проект только необходимое представление блоков.

При сборке в файл desktop.css попадут все базовые CSS-правила кнопки с уровня common и переопределенные правила с уровня desktop .

Файл mobile.css будет включать базовые CSS-правила кнопки с уровня common и переопределенные правила с уровня mobile .

Разделение представления блока button по разным уровням позволяет:

Полностью перекрыть внешний вид блока на другом уровне переопределения.

Добавить или частично изменить внешний вид блока на другом уровне переопределения.

Как перейти на CSS по БЭМ

Чтобы реализовать принципы БЭМ в проекте, необходимо:

абстрагироваться от DOM-модели и научиться создавать блоки;

не использовать ID-селекторы и селекторы тегов;

минимизировать количество вложенных селекторов;

использовать соглашение по именованию CSS-классов, чтобы избежать коллизии имен и сделать имена селекторов максимально информативными и понятными;

работать в единых терминах блоков, элементов и модификаторов;

выносить в модификаторы CSS-свойства блока, изменение которых кажется вероятным;

разделять код на мелкие независимые части для удобства работы с отдельными блоками;

повторно использовать блоки.

Как начать реализовывать идеи БЭМ в существующем проекте

Создавайте новые компоненты по БЭМ, а старые изменяйте по мере необходимости.

Проектируйте блоки, руководствуясь принципами, описанными выше.

Используйте префиксы в именах CSS-классов (например, bem- ), чтобы отличить новый код от старого.

После знакомства с CSS по БЭМ переходите к рассмотрению особенностей реализации JavaScript по БЭМ-методологии.

Философия BEM CSS: подход к структурированию пользовательских интерфейсов

Можно рассматривать два совершенно разных метода создания интерфейсов.

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

2) Графической редактор. В данном подходе используется программный продукт, который позволяет нарисовать интерфейс, мгновенно наблюдая то, как он будет отображаться. Данный метод гораздо нагляднее, но почти всегда менее гибок.

Классический подход проектирования пользовательского интерфейса

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

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

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

Рис. 1 — Основные потоки взаимодействия при классическом подходе проектирования пользовательского интерфейса.

Данный подход отлично работает для обычных веб-приложений и для классических настольных (GUI) приложений, где давно устоялись свои модели взаимодействия, построенные на основе фиксированного набора элементов управления.

Однако данный подход плохо работает для современных Ajax приложений и особенно для RIA. В настоящий момент происходит стремительное слияние настольных (GUI) и веб-приложений.

Использование специализированных языков описания интерфейса и сред разработки.

Возникло решение позволяющее отделить внешний вид пользовательского интерфейса от бизнес-логики программы. Решение основано на специальных языках описания интерфейса — XAML от Microsoft, MXML от Adobe, ZUL от Mozilla и так далее. В этих текстовых языках описывается внешний вид элементов (в векторном формате) так, что интерфейс можно создавать в любом редакторе.

В языке XAML можно задавать не только расположение элементов на экранной форме (в векторном виде), но и все трансформации, которые с ними происходят.

Для редактирования XAML лучше всего применять специальные пакеты такие как, например, Microsoft Expression Blend (Blend). Редактирование внутри него происходит в наглядной, визуальной форме, то есть проектировщик может создавать элементы, перемещать их по экрану и описывать поведение.

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

Взаимодействие между членами команды теперь происходит следующим образом:

· Проектировщик создает прототип.

· Дизайнер получает код XAML, и прямо в среде Blend или ином XAML редакторе (например, в Microsoft Expression Design) создает совершенно новый файл XAML, содержащий объекты интерфейса в конечном оформлении.

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

· Разработчик получает от проектировщика код XAML привязывает бизнес-логику и связывает все трансформации (кусочки взаимодействия).

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

Общие подходы к построению пользовательских интерфейсов

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

Рассмотрим основные подходы к построению «удобного и правильного» GUI.

Работу пользовательского интерфейса программного средства можно описать в виде диаграммы на Рисунке 3. Каждое действие пользователя ведет к изменению состояния графического интерфейса (визуально — это выставление флажков, зажатие кнопок и т.д., программно идет обращение к соответствующему обработчику данного состояния), что в свою очередь ведет к исполнению определенного модуля программы и дальнейшему изменению состояния графического интерфейса (визуализации ответа программы на действие пользователя).

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

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

Рис. 3 — Диаграмма работы пользовательского интерфейса.

Следующим подходом к построению пользовательских интерфейсов является концепция User-Centered Design — дизайн вокруг пользователя.

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

В контексте данного подхода используют несколько понятий, относящихся к проектировке графического интерфейса:

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

· Experience/ experimental design — подход к разработке дизайна, учитывающий потребности, опыт, особенности восприятия, знания и навыки человека или группы людей.

· В цифровой среде говорят о user experience design — подвиде experience/ experimental design, отвечающем за разработку цифровых продуктов и систем на принципах user-centered design.

C user experience design тесно связаны следующие дисциплины:

· information architecture — информационная архитектура одна из дисциплин проектирования пользовательских интерфейсов, представляющая совокупность методов и приемов структурирования и организации информации.

· interaction design — изучение и разработка поведенческих моделей пользовательской системы;

· usability engineering или user interface design — дизайн пользовательских интерфейсов;

· visual/graphic design — разработка визуальной/графической составляющей продукта.

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

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

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

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

Впервые представил список принципов проектирования Хансен:

1) Знать пользователя.

2) Сократить запоминание.

3) Оптимизировать операции.

4) Устранить ошибки.

Современные принципы разработки пользовательского интерфейса формулируются следующим образом:

1) Контроль пользователем интерфейса.

2) Уменьшение загрузки памяти пользователя.

3) Последовательность пользовательского интерфейса.

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

Важность соблюдения принципов

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

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

Решение о выборе оптимальных принципов построения интерфейса должно вырабатываться совместно всеми членами команды по проектированию.

Обзор существующих подходов к проектированию пользовательских интерфейсов

Пользовательский интерфейс обеспечивает взаимодействие между пользователем и компьютером, обмен действиями и ответными реакциями на них. Юзабилити — степень, с которой продукт может быть использован определенными пользователями при определенном контексте использования для достижения определенных целей с должной эффективностью, продуктивностью, удовлетворенностью [2].

Исследования в области взаимодействия пользователя и компьютера показывают, что каждый пользовательский интерфейс обязан выполнять следующие четыре функций:

  • 1) управление компьютером только путем пользовательских действий: прерывание, инициация, отмена компьютерных процессов;
  • 2) ввод данных от пользователя, обратная реакция системы;
  • 3) отображение данных от пользователя;
  • 4) поддержка пользователя в процессе деятельности, что включает в себя обратную связь и сбор информации об ошибочных или случайных действиях пользователя.

Хорошо спроектированный пользовательский интерфейс обязан соответствовать этим принципам:

  • 1) иметь низкий порог вхождения, полностью способствовать быстрому освоению интерфейса пользователем, формировать устойчивые навыки;
  • 2) предоставлять ввод информации естественным образом, не демонстрируя процесс вычислений;
  • 3) отвечать требованиям рабочих потребностей пользователя, не заостряя его внимание на процессе обработки данных.

Для получения эффективного результата разработки пользовательского интерфейса используют различные подходы к проектированию. Основные из них:

  • 1) Подход, ориентированный на пользователя (User-Centered Design), который характеризуется активным вовлечением пользователей в процесс проектирования и тестирования программного продукта, четким пониманием пользовательских требований и задач, оптимальным распределением функций между пользователями и технологиями, интерактивностью и мультидисциплинарностью подхода. Применение данного подхода при разработке пользовательского интерфейса для достижения высоких показателей в области юзабилити (согласно ISO 9241-11, это степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определенными пользователями для достижения определенных целей в определенном контексте). Так же приводит к сокращению расходов на разработку и повышению эффективности продукта, как в отношении бизнеса (дополнительная прибыль), так и в удовлетворенности пользователей (повышение лояльности к продукту и разработчику).
  • 2) Подход, ориентированный на деятельность (Activity-Centered Design). Согласно определению Дональда Нормана (Donald Norman), деятельность включает задачи, которые состоят из действий, в свою очередь составленных из операций. Подход к проектированию интерфейсов, предлагаемый Норманом, уделяет внимание прежде всего пониманию деятельности пользователя. Он утверждает, что человек приспосабливается к имеющимся инструментам и что понимание деятельности, выполняемой человеком при помощи инструментов, может положительно сказываться на интерфейсе этих инструментов.
  • 3) Целеориентированный подход (Goal Centered Design). В основе данного метода лежат конечные цели пользователей, которые должны быть ими достигнуты посредством взаимодействия с программным продуктом.
  • 4) Подход, ориентированный на данные (Data Centered Design). Проектирование интерфейса поддерживает такую модель взаимодействия пользователя с системой, при которой первичными являются обрабатываемые данные, а не требуемые для этого программные средства. Другими словами, при таком подходе основное внимание пользователя концентрируется на тех данных, с которыми он работает, а не на поиске и загрузке необходимого приложения.
  • 5) При использовании этого подхода основным программным объектом является документ, который представляет собой некоторое абстрактное устройство хранения данных, используемых для выполнения заданий пользователей и для их взаимодействия. Документ должен быть доступен как различным приложениям, используемым для его обработки, так и всем взаимодействующим пользователям.
  • 6) Итеративный подход (Agile) — метод последовательных приближений. Суть итеративного подхода заключается в создании изначально самого простейшего прототипа с целью формирования у заказчика и самого проектировщика общего видения проекта. Затем постепенно прототип дорабатывается и детализируется.
  • 7) При разработке интерфейса целесообразно гибко пользоваться существующими подходами, учитывая при выборе методов назначение разрабатываемого продукта, целевую аудиторию, время и бюджет разработки.

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

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

Топ-пост этого месяца:  Урок 2. Авторизация пользователей

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

Требования к дизайну мобильных приложений достаточно простые. Цветовая гамма приложения не должна быть излишне яркой, пестрой, чтобы не рябить в глазах пользователя, однако сочетания цветов должны быть контрастными — это эффектно выглядит на дисплеях мобильных устройств и, что самое главное, позволяет продолжать пользоваться приложениях в неудачных условиях освещенности, например на солнце. Дизайн должен быть простым и понятным, нужно избегать непонятных иконок, нетривиальных пояснений — пользователь пришел за информацией, которую ему, вероятно, нужно получить срочно, и он не хочет разгадывать ребусы. Система навигации должна быть такой же простой, понятной. Если в приложении планируется создание большого количества разных разделов, их можно разделить на небольшое количество обобщенных, считается что для получения нужной информации пользователь готов пройти через 4 уровня вложенности. Списки, с помощью которых также может быть реализовано меню не должны превышать 5-9 элементов. Для сложных систем можно использовать функцию поиска, такое решения подойдет к примеру для телефонного справочника ВУЗа, или возможность прогрессивного раскрытия, когда дополнительная информация появляется без перехода на другой экран.

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

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

H Изоляция css стилей с помощью компонентного подхода в черновиках

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

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

Когда у нас в макете много разных по оформлению блоков, которые несут в себе один смысл, использовать понятное имя становится сложно. Чтобы добиться нужного результата приходится добавлять к имени еще что-то. Это все может сделать код трудным для восприятия (как длиннющие названия классов в беме).

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

Важную роль во всем этом играет еще то, как организована структура проекта. Чаще всего можно встретить свалку файлов в каталоге css(и не только там), тому кто пришел в проект бывает совсем не очевидно, в каком файле лежит нужный стиль и как стили одного файла влияют на стили другого файла. Хотелось бы верить, что когда все браузеры научатся понимать стандарты web components, проектов с помойной структурой станет меньше, и эти проблемы исчезнут.

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

Как делают другие?

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

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

Докатились до того, что, в js запихнули не только html, но стали писать еще и css, ломая устоявшиеся стереотипы, что так делать плохо. И тут можно сказать, что мы возвращаемся к тому с чего начали, свалка из структуры проекта перекочевала в код компонента.

Мне нравится как подошли к этому вопросу разработчики Angular. Каждый компонент изолирован, стили внутри компонента никогда не пересекутся со стилями другого компонента, даже если они будут иметь одинаковое имя класса. Это достигается путем добавления уникального рандомного атрибута к каждому тегу элемента. Этот же атрибут добавляется к каждому классу в css. Чтобы не пугать тех, кто не знаком с Angular, добавлю, что исходный код компонента html и css является “чистым”, уникальные атрибуты добавляются при сборке приложения. Все файлы лежат отдельно друг от друга.

Пару слов про новый велик

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

Чтобы в проекте был порядок, необходимо разбить каждый элемент макета на отдельные компоненты из которых потом будут собираться страницы. Думаю, что всем понятно, в чем сила компонентов. Если нет, то тут learn.javascript.ru/webcomponents-intro коротко и ясно объясняется.

Структура проекта

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

В каждом компоненте должен лежать файл html и css, если есть какая-то логика, то, там же следует разместить js файл.

Каждый компонент должен иметь свой тег. Желательно, чтобы в теге был дефис, например:

Такие правила заложены в стандарте custom elements, который пока мало где работает, но это не беда, рано или поздно заработает везде.

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

В качестве примера я сделал два компонента карточек, карточка состоит из картинки и текста. Каждый компонент имеет одинаковые имена классов, но разные правила стилей, соответственно выглядеть все это должно по разному, то-есть вот так:

Вот такая получилась структура проекта:

После отработки всех gulp тасков, можно будет увидеть во что превратился код.

BEM + CSS Variables. Стилизация блоков. #1572

Comments

Copy link Quote reply

belozer commented Apr 7, 2020 •

Блоки и темы оформления.

Уже давно пытаюсь избавиться от боли модификатора _theme у блоков.
У нас 2 темы блока button — публичная и админка, около 2K строк стилей в сумме.

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

Очень близки идеи http://whitepaper.tools/. В целом работаю тоже в этом направлении.

На данный момент пришёл к использованию 2-х видов переменных.

1. Глобальные/Контекстные (что реализовано в whitepaper)

Задаются через блок theme и модификаторы theme_color_* theme_size_* и т.д.
Провайдят контекст переменных вниз по дереву.

2. Локальные (Уровень блока)

Задаются с указанием префикса имени блока. Такой способ явно ограничивает пространство имён переменных, чтобы случайно не сломать что-то внутри дерева. И позволяет легко изменять их через модификаторы.

Если спроецировать на мир React, то контекстные переменные — это пропсы, локальные — стейт 🙂

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

3. Модификаторы

Дальше через модификаторы жонглируем уже локальными переменными блока.

Данный подход позволяет избавиться от длинных селекторов в css.

Например если мы не хотим использовать локальные переменные, то нужно писать классы таким образом

И это только 2 состояние, а там ещё N состояний, включая вложенные элементы.

Локальные переменные, конечно не серебренная пуля и каскады писать придётся. Но как решение вполне может помочь добиться лаконичных селекторов.

4. Именование цветов

После долгих ресёрчей толком не нашёл способа лаконично и предсказуемо описывать переменные. Наиболее лаконичным стилем нашёл подход из Material Design https://material.io/design/color/

В кратце, есть какой-то цвет и для него создаётся рекомендуемый контрастный цвет.

В качестве дополнительного задания контраста есть идеи использовать доп. параметр -low , -hight

В целом такое именование позволяет добиться предсказуемых результатов при создании темы.

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

И не известно на сколько в новой теме surface и error будут контрастны друг к другу.

Идёт разбитие цветовой темы на 2 вида. 1 базовые цвета страницы, 2 контролы (кнопки, чекбоксы, инпуты и т.д.).

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

  • Однозначность использования цветов
  • Возможность разрабатывать тему «в вакуме»
  • Нужно использовать несколько миксов темы на странице для нескольких комбинаций цветовых решений.

5. Старые браузеры

Любимый IE. Хоть поддержка по caniuse уже > 90% https://caniuse.com/#search=css-variables он ещё живёт.

Как один из подходов решения этого вопроса есть компромиссный вариант — делать версию с одной темой. Все переменные темы дублировать в :root и через postcss ставить статичные значения.

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

Либо использовать подходы с css-in-js. Но они не лишены недостатков.

6. Дизайнеры, разработчики и система

Тут конечно есть конфликт интересов. Но имхо, у дизайнера должна быть система, по которой он работает и она должна быть логичной (например http://whitepaper.tools/)

П.Н.
Небольшая демка «на коленке»
Буду благодарен, если поделитесь своей системой стилизации блоков и именованием переменных.

This comment has been minimized.

Copy link Quote reply

belozer commented Apr 7, 2020 •

Ответ из Telegram от @koloskof

Работа с Темати

Тематизация

Фундаментально Тематизация отвечает тому подходу, которого мы с дизайнерами придерживаемся: «При проработке визуала человек описывает смысл блока (смысловые модификаторы), ничего не зная про Тему, а при проработке Темы человек может ничего не знать про блоки, которые будут в ней отрисовываться»

Разделение внутри темы

Для каждого Мерча/Лейбла/Компании есть три Темы:

  • Дефолтная — светлая с яркими акцентными контролами;
  • Брэндовая — с ярким фоном и светлыми акцентными контролами;
  • Инвёрсная — тёмная с монохромными или яркими акцентными контролами;

Математика цвета

Внутри каждой Темы, цветовые переменные разделены на группы.

Базовые переменные, которые формируют основную палитру (они не используются в интерфейсе, нужны только для образования интерфейсных пременных (наследования)). Они имеют префикс color-base-*. Пример:
$color-base-base $color-base-system

имя base переменной что наследуется
$color-base-base типографика
$color-base-essential фоны
$color-base-project акцентные цвета
$color-base-phantom бордеры, оверлеи, тени
$color-base-path ссылки

Background

Цвета фонов, которые формируются с учётом состояний блоков. Значения наследуются от цвета переменной $color-base-essential. Они имеют префикс color-bg-*. Пример:
$color-bg-brand, $color-control-bg-default-affect

Цвета типографики, которые формируются с учётом визуальной иерархии и так же наследуются от цвета переменной $color-base-base. Они имеют префикс color-typo-*. Пример:
$color-typo-primary, $color-typo-warning

Вычисление цвета в файле темы

Каждый цвет темы вычисляется на основе изменения параметров hue(h) — тон, saturation(s) — насыщенность, lightness(l) — яркость и alpha(a) — полупрозрачность у base переменных.

Например цвет для основного текста вычисляется на основе цвета переменной $color-base-base с уменьшением альфы (полупрозрачности) до 95%:
$color-typo-primary: color($color-base-base a(95%))
Другой пример, для бордеров: $color-bg-border: color($color-base-phantom l(100%) a(20%));

Стоит помнить, что параметры переменных можно не менять. Если с точки зрения визуала цвет подходит, то base переменную допускается использовать as is. В этом случае color(. ) не указывается, т.к. идет прямое наследование(?)присвоение:
$color-typo-alert: $color-base-alert;

Синтаксис математики

Альфа-канал задается всегда в %: $color-typo-primary: color($color-base-base a(95%));

Как сказано выше, для формирования нового цвета переменной, необходимо изменить один из параметров h, s, l, a. Допускается два вида записи:

h(50%) ↔️ h(50)
новыйПараметр = 0.5(текущийПараметр).
При HUE = 20, новый HUE = 0.5(20) = 10

h(+50%) (работает для + и -)
новыйПараметр = текущийПараметр + 0.5(текущийПараметр).
При HUE = 30, новый HUE = 30 + 0.5(30) = 45

Если параметр указан h(-X) и [текущийПараметр — X(текущийПараметр)]

Как структурировать css с использованием методологии BEM для адаптивных веб-страниц?

Легко использовать BEM для фиксированных макетов. Что такое структура стилей CSS для адаптивных веб-страниц со средствами массовой информации?

  • .t-news — шаблон страницы. Это блок, который определяет положение блоков внутри.
  • .b-post — блок BEM
  • .b-post__title — элемент BEM b-post
  • .b-post__text — red — BEM-модификатор b-post__text b-post

Должен ли я помещать медиа-запросы внутри или вне моих блоков?

По моему опыту, я понял, что блоки не должны нести ответственность за их ширину или маржу ради гибкости и модульности. Наличие «эластичных» блоков в проекте позволяет им перемещаться, чтобы занять разные области (с разными размерами) страницы без нарушения функциональности или макета, Что касается полей, проще сохранить согласованные пробелы между блоками, если они определены на более высоком уровне: блок шаблона, например, я полагаю, t-news (учитывая, что «t» соответствует шаблону).

BEM — это модульность, каждая часть кода, связанная с определенным блоком, остается в папке блоков в файловой системе , поэтому он не должен отличаться от медиа-запросов, которые являются лишь частью CSS. Важно знать, что делает CSS, например: если набор правил определяет области и поля в шаблоне, нужны ли ему медиа-запросы для этого или нет, эти правила должны быть частью блока, который является ответственный за эти определения.

Этот подход может генерировать множество медиа-запросов, и может быть проблема с производительностью рендеринга, но, согласно этой статье, несколько медиа-запросы могут влиять на производительность только в том случае, если они отличаются друг от друга. Повторения того же правила, как и @media (max-width: 850px) , будут сериализованы и интерпретированы как один.

Таким образом, медиа-запросы, связанные с областями и полями, идут в блоке шаблона, а дополнительные запросы к медиа, связанные с самими компонентами, идут в блоках компонентов. Поскольку шаблон отвечает за размеры, я бы изменил «маленький» модификатор в вашем примере на блок шаблонов.

Кроме того, я бы пересмотрел использование green и red в качестве модификаторов, поскольку цвета могут меняться в течение всего жизненного цикла проекта. Я предлагаю попробовать что-то, что не описывает внешний вид элементов, например correct и alert .

Наконец, помните, что модификаторы должны использовать классы элементов в HTML, например b-post__text b-post__text—alert .

Типы интерфейсов

По аналогии с процедурным и объектным подходом к программированию различают процедурно-ориентированный и объектно-ориентированный подходы к разработке интерфейсов (рис.2).

Рис. 2. Типы интерфейсов

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

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

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

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

В табл.1 перечислены основные отличия пользовательских моделей интерфейсов процедурного и объектно-ориентированного типов.

Различают процедурно-ориентированные интерфейсы трех типов: «примитивные», меню и со свободной навигацией.

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

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

Различают одноуровневые и иерархические меню. Первые используют для сравнительно простого управления вычислительным процессом, когда вариантов немного (не более 5-7), и они включают операции одного типа, например, Создать, Открыть, Закрыть и т. п. Вторые — при большом количестве вариантов или их очевидных различиях, например, операции с файлами и операции с данными, хранящимися в этих файлах.

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

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

Рис.3. Типичная структура алгоритма программ с примитивным интерфейсом:

а — последовательный; б — с возможностью повторения

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

Рис. 8.4. Типичная структура алгоритма программы с одноуровневым меню

В условиях ограниченной навигации независимо от варианта реализации поиск требуемого пункта более чем двухуровневого меню может оказаться непростой задачей.

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

Интерфейсы со свободной навигацией также называют графическими пользовательскими интерфейсами (GUI — Graphic User Interface) или интерфейсами WYSIWYG (What You See Is What You Get — что видишь, то и получишь, т. е., что пользователь видит на экране, то он и получит при печати). Эти названия подчеркивают, что интерфейсы данного типа ориентированы на использование экрана в графическом режиме с высокой разрешающей способностью.

Графические интерфейсы поддерживают концепцию интерактивного взаимодействия с программным обеспечением, осуществляя визуальную обратную связь с пользователем и возможность прямого манипулирования объектами и информацией на экране. Кроме того, интерфейсы данного типа поддерживают концепцию совместимости программ, позволяя перемещать между ними информацию (технология OLE, см. § 1.1).

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

• меню различных типов: ниспадающее, кнопочное, контекстное;

• разного рода компоненты ввода данных.

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

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

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

Сравним четыре указанных типа интерфейсов на конкретном несложном примере.

Пример 8.1. Разработать пользовательский интерфейс программы построения графиков или вывода таблицы функций, техническое задание на которую представлено в § 3.5.

Можно предложить четыре варианта интерфейса, соответствующие рас­смотренным выше типам.

Вариант 1. Использование примитивного интерфейса предполагает, что пользователь сразу определяет все параметры, необходимые программе для построения графика или вывода таблицы, вводя их в ответ на соответствующие запросы программы, после чего программа выполняет необходимые вычисления и выводит результат. Если допустить, что программа будет запрашивать подтверждения завершения обработки, то процесс построения графиков/таблиц можно зациклить. В зависимости от используемых средств мы получим сравнительно простую программу, удовлетворяющую функциональным спецификациям, но ориентированную на единственный сценарий: ввод — обработка — вывод (см. рис. 8.3, б). Данный вариант не удобен для пользователя.

Вариант 2. Можно использовать одноуровневое меню, которое будет включать команды: Функция, Отрезок, Шаг, Тип результата, Выполнить и Выход. При выборе первого пункта меню определяется функция, второго -интервал, третьего — шаг, четвертого — тип результата, пятого — осуществляется операция, и, наконец, последний пункт обеспечивает возможность выхода из программы (рис. 8.5).

Очевидно, что в этом случае обеспечивается более гибкое управление для пользователя, так как фактически предусмотрены следующие сценарии работы:

Ввод функции — Ввод отрезка — Ввод шага — Уточнение вида результата: график/таблица — Вывод результата;

Изменение отрезка — Вывод результата;

Изменение шага — Вывод результата;

Изменение вида результата: график/таблица — Вывод результата и др.

Рис.8.5. Внешний вид окна программы

Вариант 3. Интерфейс со свободной навигацией для данной программы представлен на рис. 8.6. График строится по нажатии кнопки Построить.

Рис. 8.6. Внешний вид окна программы построения графиков/таблиц функций (интерфейс со свободной навигацией) (естественно, обработчик этого события должен предусматривать анализ данных на полноту и совместимость). Менять данные можно в любой момент и в любом порядке, используя соответствующие компоненты ввода-вы­вода.

Вариант 4. Интерфейс прямого манипулирования для данной программы представлен на рис. 8.7. Для того чтобы ввести новую формулу, необходимо взять чистый бланк из папки. Бланк раскрывается двойным щелчком мыши, после чего его необходимо заполнить. Затем его можно «обсчитать», перенеся на пиктограмму компьютера. Заполненные бланки, которые могут еще понадобиться, «кладутся» в папку Функции, остальные — в «корзину».

Менять данные и тип результатов можно в любой момент и в любом по­рядке, «раскрыв» бланк.

Как уже упоминалось в § 3.5, различают также однодокументные (SDI -Single Document Interface) и многодокументные (MDI — Multiple Document Interface) интерфейсы. Однодокументные или «однооконные» интерфейсы организуют работу, как следует из названия, только с одним

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Для студентов недели бывают четные, нечетные и зачетные. 9425 — | 7438 — или читать все.

91.105.232.77 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

BEM + CSS Variables. Стилизация блоков. #1572

Comments

Copy link Quote reply

belozer commented Apr 7, 2020 •

Блоки и темы оформления.

Уже давно пытаюсь избавиться от боли модификатора _theme у блоков.
У нас 2 темы блока button — публичная и админка, около 2K строк стилей в сумме.

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

Очень близки идеи http://whitepaper.tools/. В целом работаю тоже в этом направлении.

На данный момент пришёл к использованию 2-х видов переменных.

1. Глобальные/Контекстные (что реализовано в whitepaper)

Задаются через блок theme и модификаторы theme_color_* theme_size_* и т.д.
Провайдят контекст переменных вниз по дереву.

2. Локальные (Уровень блока)

Задаются с указанием префикса имени блока. Такой способ явно ограничивает пространство имён переменных, чтобы случайно не сломать что-то внутри дерева. И позволяет легко изменять их через модификаторы.

Если спроецировать на мир React, то контекстные переменные — это пропсы, локальные — стейт 🙂

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

3. Модификаторы

Дальше через модификаторы жонглируем уже локальными переменными блока.

Данный подход позволяет избавиться от длинных селекторов в css.

Например если мы не хотим использовать локальные переменные, то нужно писать классы таким образом

И это только 2 состояние, а там ещё N состояний, включая вложенные элементы.

Локальные переменные, конечно не серебренная пуля и каскады писать придётся. Но как решение вполне может помочь добиться лаконичных селекторов.

4. Именование цветов

После долгих ресёрчей толком не нашёл способа лаконично и предсказуемо описывать переменные. Наиболее лаконичным стилем нашёл подход из Material Design https://material.io/design/color/

В кратце, есть какой-то цвет и для него создаётся рекомендуемый контрастный цвет.

В качестве дополнительного задания контраста есть идеи использовать доп. параметр -low , -hight

В целом такое именование позволяет добиться предсказуемых результатов при создании темы.

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

И не известно на сколько в новой теме surface и error будут контрастны друг к другу.

Идёт разбитие цветовой темы на 2 вида. 1 базовые цвета страницы, 2 контролы (кнопки, чекбоксы, инпуты и т.д.).

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

  • Однозначность использования цветов
  • Возможность разрабатывать тему «в вакуме»
  • Нужно использовать несколько миксов темы на странице для нескольких комбинаций цветовых решений.

5. Старые браузеры

Любимый IE. Хоть поддержка по caniuse уже > 90% https://caniuse.com/#search=css-variables он ещё живёт.

Как один из подходов решения этого вопроса есть компромиссный вариант — делать версию с одной темой. Все переменные темы дублировать в :root и через postcss ставить статичные значения.

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

Либо использовать подходы с css-in-js. Но они не лишены недостатков.

6. Дизайнеры, разработчики и система

Тут конечно есть конфликт интересов. Но имхо, у дизайнера должна быть система, по которой он работает и она должна быть логичной (например http://whitepaper.tools/)

П.Н.
Небольшая демка «на коленке»
Буду благодарен, если поделитесь своей системой стилизации блоков и именованием переменных.

This comment has been minimized.

Copy link Quote reply

belozer commented Apr 7, 2020 •

Ответ из Telegram от @koloskof

Работа с Темати

Тематизация

Фундаментально Тематизация отвечает тому подходу, которого мы с дизайнерами придерживаемся: «При проработке визуала человек описывает смысл блока (смысловые модификаторы), ничего не зная про Тему, а при проработке Темы человек может ничего не знать про блоки, которые будут в ней отрисовываться»

Разделение внутри темы

Для каждого Мерча/Лейбла/Компании есть три Темы:

  • Дефолтная — светлая с яркими акцентными контролами;
  • Брэндовая — с ярким фоном и светлыми акцентными контролами;
  • Инвёрсная — тёмная с монохромными или яркими акцентными контролами;

Математика цвета

Внутри каждой Темы, цветовые переменные разделены на группы.

Базовые переменные, которые формируют основную палитру (они не используются в интерфейсе, нужны только для образования интерфейсных пременных (наследования)). Они имеют префикс color-base-*. Пример:
$color-base-base $color-base-system

имя base переменной что наследуется
$color-base-base типографика
$color-base-essential фоны
$color-base-project акцентные цвета
$color-base-phantom бордеры, оверлеи, тени
$color-base-path ссылки

Background

Цвета фонов, которые формируются с учётом состояний блоков. Значения наследуются от цвета переменной $color-base-essential. Они имеют префикс color-bg-*. Пример:
$color-bg-brand, $color-control-bg-default-affect

Цвета типографики, которые формируются с учётом визуальной иерархии и так же наследуются от цвета переменной $color-base-base. Они имеют префикс color-typo-*. Пример:
$color-typo-primary, $color-typo-warning

Вычисление цвета в файле темы

Каждый цвет темы вычисляется на основе изменения параметров hue(h) — тон, saturation(s) — насыщенность, lightness(l) — яркость и alpha(a) — полупрозрачность у base переменных.

Например цвет для основного текста вычисляется на основе цвета переменной $color-base-base с уменьшением альфы (полупрозрачности) до 95%:
$color-typo-primary: color($color-base-base a(95%))
Другой пример, для бордеров: $color-bg-border: color($color-base-phantom l(100%) a(20%));

Стоит помнить, что параметры переменных можно не менять. Если с точки зрения визуала цвет подходит, то base переменную допускается использовать as is. В этом случае color(. ) не указывается, т.к. идет прямое наследование(?)присвоение:
$color-typo-alert: $color-base-alert;

Синтаксис математики

Альфа-канал задается всегда в %: $color-typo-primary: color($color-base-base a(95%));

Как сказано выше, для формирования нового цвета переменной, необходимо изменить один из параметров h, s, l, a. Допускается два вида записи:

h(50%) ↔️ h(50)
новыйПараметр = 0.5(текущийПараметр).
При HUE = 20, новый HUE = 0.5(20) = 10

h(+50%) (работает для + и -)
новыйПараметр = текущийПараметр + 0.5(текущийПараметр).
При HUE = 30, новый HUE = 30 + 0.5(30) = 45

Если параметр указан h(-X) и [текущийПараметр — X(текущийПараметр)]

Добавить комментарий