14 заметок с тегом

дизайн

Позднее Ctrl + ↑

Программисты сайтов не знают, как работает веб, часть 2

Вторая распространнёнейшая ошибка — переходить на новую страницу с помощью JavaScript. Это встречается повсеместно даже на самых популярных сайтах.

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

Программисты сайтов не знают, как работает веб

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

Например,
Яндекс
Последние записи о JavaScript на Хабре
Как выводить текст на экран во Vue.js

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

Если разработчики Vue.js поменяют дизайн или перепишут разде про текст, то по этой ссылке всегда можно будет прочитать именно об этом, хоть и в новом виде. Хороший пример — страница об Айфоне на сайте Эппл: apple.com/iphone. Несмотря на то, что она рассказывает каждый раз о текущем поколении Айфонов, это всё равно страница об Айфоне, как и 14 лет назад.

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

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

Ещё подробности на эту тему у Ильи Бирмана в статье Будущее нативных и веб-приложений.

Сколько нужно настроек в вашем продукте?

Простой ответ: чем меньше, тем лучше.

Есть давнее противостояние между Виндоус и МакОС. В Виндоус настроек больше и часто это считается свободой, а в МакОС — меньше, зато там дизайн лучше. То же самое с Андроидом и АйОС. И это неспроста.

Дизайн лучше не когда он красивее, а когда лучше решает задачу. А это значит что дизайнер в эту задачу вникает вместо пользователя и с учётом своих знаний о проектировании, удобстве, распространённых ошибках, придумывает лучший способ решения и проверяет, вправду ли он хорош. Когда дизайнер работать не хочет, не хочет вникать в задачу, он придумывает настройки, чтобы эту задачу решил за него пользователь, и подаёт это под соусом «настраиваемого интерфейса».

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

Например, в системах управления данными всегда есть таблицы: список клиентов, документов, отчётов, счетов. В этих сущностях всегда много полей, десятки и сотни. Часто заказчик прямо требует возможности фильтровать по каждому из полей, и возможности выбирать, какие столбцы будут отображены вручную. Подобное решение понятно заказчику, потому, что контроль переходит к нему, но ужасно для неопытных пользователей (попробуй настрой, как тебе нужно, и пойми, как тебе нужно), трудоёмко (очень трудоёмко!) со стороны реализации, и является решением в общем виде, поэтому мало отличается от предоставления доступа к БД напрямую.

Когда не хочется переделывать

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

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

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

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

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