Кроме разрешения и веса, СВГ-иконки умеют удобно хранить несколько состояний. Так не в силах ни один растр. Количество состояний — признак, по которому делю иконки на «сплошные» и «слоёные».

Если иконка работает, как ссылка — целиком меняет цвет при наведении (или посещении), то про себя называю её «сплошной». С ней можно работать вслепую, не заглядывая внутрь. Говорим через ЦСС всему СВГ: «будь при наведении красным», и всё.

А если цвет меняют отдельные части, называю иконку «слоёной». Потому что такие игры возможны, только когда внутри СВГ формы лежат в отдельных элементах друг над другом — слоями.

Когда появляется такое поведение, первая идея — применить ЦСС-бордер к сплошной иконке. Но лучше не торопиться. Бордер всегда позиционируется по центру. Если контур однопиксельный, браузер нарисует линию в два полупрозрачных пикселя. И иконка станет мыльной на неретиновом экране.

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

При этом слой с формой в виде обводки не сработает. ЦСС покрасит не только внешнюю форму, но и внутреннюю.

Если иконка слоёная, обратиться через ЦСС ко всему СВГ не получится. Нужно манипулировать элементами внутри. Это легко с инлайновым СВГ — добавил классы к нужным элементам и готово. Иконка фулскрина в карточке на сайте лаборатории:

<svg class="full-screen" xmlns="http://www.w3.org/2000/svg">
  <g>
    <path d="M7,7 L7,8 L6.00097656,8 L6.00097656,9 L5,9 L5,8 L0,8
    L0,18 L10,18 L10,13 L9,13 L9,12 L10,12 L10,11 L11,11 L11,10 L12,10
    L12,9 L13,9 L13,10 L18,10 L18,0 L8,0 L8,5 L9,5 L9,6 L8,6 L8,7 L7,7 Z"
    fill="#FFF"/>
			
    <path class="variable" d="M9.538,3.077 L13.935,3.077 L9.538,7.475 L9.538,8.462 
    L10.525,8.462 L14.923,4.065 L14.923,8.462 L16,8.462 L16,2 L9.538,2 L9.538,3.077 
    Z M3.077,13.938 L3.077,9.54 L2,9.54 L2,16 L8.461,16 L8.461,14.924 L4.063,14.924 
    L8.461,10.527 L8.461,9.54 L7.474,9.54 L3.077,13.938 Z" 
    fill="#666"/>
  </g>
</svg>

Без инлайна сложнее — обращение будет к типу элемента или к атрибуту. Плей в той же карточке:

<svg class="play"  xmlns="http://www.w3.org/2000/svg">
  <g>
    <polygon fill="#FFF" points="0 0 0 22 19 11"></polygon>
      
    <path class=“play-fill“ d="M2,3L2 19 15 11z" fill="#666"></path>
      
    <path class="play-void“ d="M3,4.99999999L3 17 13 11z" fill="#666"></path>
  </g>
</svg>

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

Если такая иконка будет сплошной, понадобиться ещё один СВГ с белым фоном под ней. Это замусорит код и может привести к ошибкам при масштабировании.

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

Мепс-ми — лучшие офлайн-карты на сегодня. Но их интерфейс периодически хромает.

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

Последняя версия 6.4.4 прокладывает маршрут от объекта и до него. Это закрывает дополнительные сценарии. И пока перед глазами нет экрана, задача решена.

А в интерфейсе ошибка, которую описывал ещё Норман, — очень похожие иконки направления. Обе состоят из круга, стрелки подписи «Route...». На ходу выбрать нужное крайне трудно. Приходится останавливаться и вглядываться в «...from» и «...to».

История о клавиатурах, которую приводит Норман:

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

Я рассказал об этом дизайнеру, добавив, что сам несколько раз допустил подобную ошибку, следовательно, её будут допускать и другие пользователи. Первая реакция дизайнера была такой: «Почему вы допустили эту ошибку? Разве вы не читали инструкцию?» Затем он пустился в объяснения разницы между двумя кнопками.

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

«Нет», — сказал дизайнер и заявил, что я единственный, кто пожаловался, и что секретари компании пользуются этой клавиатурой уже много месяцев. Я не унимался, и мы решили поинтересоваться, путали ли служащие когда-нибудь эти две кнопки, у них самих. И приходилось ли им из-за этого переделывать работу?

«О, да, — ответили все секретари, — такая проблема возникала много раз».

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

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

И его «рассуждения по этому поводу»:

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

Для максимального контраста лучше оставить только «From» и «To», а иконки сделать разными. Например, флаг для старта и пин для финиша. Если нужно быстрее — «А» для начала и «В» для конца.