Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца. Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
Думаю, у нас с вами получилось разное восприятие намерений статьи, и я бы хотел пояснить.
Цель публикации — не в том, чтобы защищать собственный дизайн или указывать, как именно нужно оценивать чужую работу. Речь не о том, что кто-то неправ. И не о том, чтобы поучать читателей.
Я постарался составить список факторов, которые могут влиять на восприятие интерфейса, если вы смотрите на него по скриншоту, вне контекста использования. Это наблюдение из практики — не более того. Я не ставлю под сомнение право на мнение, а лишь напоминаю, что итоговая оценка может быть неполной, если не учитывать некоторые параметры.
Что касается моего дизайна — он указан в подводке с комментарием «статья вообще не о моём дизайне». И да, статья не о нём. Просто на статью навёл мой ответ к комментарию из прошлой статьи — и я решил, что из этого будет удачная подводка. А ещё даже если бы речь всё же шла о критике моей работы — в этом не было бы ничего плохого. Важнее всего то, что клиент остался доволен результатом и дизайн решает свою задачу.
Понимаю, откуда такая реакция — если воспринимать статью как попытку защитить конкретный простой экран, то список действительно может показаться избыточным.
Но на самом деле я говорил не столько про этот экран, сколько про общий подход к критике интерфейсов по скриншоту. Хотелось показать, как много факторов может оставаться за кадром — и что иногда вместо мгновенного вердикта полезнее сначала задать пару уточняющих вопросов.
Иногда за кажущейся простотой — довольно интересные и неоднозначные решения :)
«Любая текстура под текстом — зло» — звучит категорично :)
На самом деле всё, как обычно, зависит от контекста. В этом случае я специально обсудил с клиентом, насколько важна читаемость этих индикаторов — и выяснил, что они носят почти декоративный характер, а читают их крайне редко. Поэтому решили не усложнять задачу подбором отдельных цветов и оставить всё как есть: лаконично, аккуратно, без визуального шума.
Если бы это была рабочая информация — конечно, никаких текстур под текстом не было бы. Но «всегда зло» — это, пожалуй, перебор.
Спасибо за комментарии! Рад, что в целом стало лучше.
Особенно понравился пятый пункт про батарейку. Три уровня заряда действительно выглядят скудно, но за этим стоит интересная техническая подоплёка.
Например, во многих устройствах (включая, например, мою старую беззеркалку Sony A7R2) тоже всего три деления — и я всё недоумевал, почему так. Оказалось, что это не просто прихоть дизайнеров. Всё дело в том, что определить заряд батареи точно довольно сложно. Есть несколько методов: по напряжению, по подсчёту кулонов, с помощью фильтра Калмана и даже нейросетей — но ни один не даёт стопроцентной точности.
Чтобы сделать иконку батареи, которая выглядит просто, но при этом не вводит пользователя в заблуждение, нужно учитывать, насколько надёжны данные в конкретном устройстве. Например, в дешёвых гаджетах часто используют самый простой метод — по напряжению. Его точность может колебаться в пределах плюс-минус 10–20%, а под нагрузкой уровень заряда может прыгать ещё сильнее.
Я потому и выбрал именно три (на самом деле четыре) условных уровня, чтобы не создавать иллюзию точности там, где её нет. Да, выглядит упрощённо — но зато не обманывает.
Кстати, всё это — ещё один повод задуматься, как глубоко «железо» влияет на интерфейс. И как важно учитывать не только эстетику, но и механику получения данных.
Ну а статья как раз про это — про то, как легко ошибиться в оценке, глядя только на скриншот. И почему перед критикой стоит сначала задать пару вопросов :)
Чтобы числа в интерфейсе не «скакали» при изменении значений. Это особенно важно для приёмопередатчиков: частоты, уровни сигнала, временные метки и другие параметры меняются постоянно, и при использовании пропорционального шрифта текст бы дёргался на глазах у пользователя. А так всё стабильно и читаемо.
Можно было бы выбрать пару шрифтов: один для чисел, другой для текстов. Но посмотрели на то, что получилось, и решили, что и этот один неплохо смотрится.
Было бы очень интересно узнать, откуда у вас появилось такое ощущение. Ни один из моих предшественников не нарисовал ни одного варианта и не предоставил ни одного КП. Как эта планка может быть понижена?
Итоговый вариант в единственной цветовой гамме. Если в будущем возникнет желание «примерить» на него другие варианты, это делается за десять минут на стилях и их переменных.
Пока ничего, я только 8 июля сдал работу. Но вам верно ответили: каких-то особенных отличий от веба нет. Разве что будут чаще использоваться битмапы в качестве подложек. Плюс используется LVGL библиотека, которая, например, не позволяет задавать полупрозрачность для градиентов. Вы всё это можете посмотреть самостоятельно в коде проекта на Гитхабе.
Чтобы оценить размер, контрастность и читаемость, вам необходимо понимать следующие параметры:
— Физический размер устройства; — PPI дисплея устройства; — Тип матрицы дисплея устройства (его цветопередачу, контрастность, время отклика и прочие параметры); — Номинальную яркость дисплея устройства и её различные вариации.
По картинкам из статьи, на которые вы смотрите со своего монитора или телефона, вы не сможете определить, как будет выглядеть тот или иной дизайн на том или ином устройстве.
Обратите внимание на пассаж из статьи: «Например, можно будет ещё «примерить» дизайн к живому устройству — и если будут какие-то проблемы с яркостью или контрастом — подкорректировать цветовую схему».
—— А, чуть не забыл. Ещё один важный параметр, который нужно учитывать — это предполагаемое расстояние от глаз пользователя до дисплея устройства в распространённом сценарии использования.
Написал всё это и чувствую, что это неплохая тема для статьи. А то часто сталкиваюсь с ситуациями, когда дизайнеры дают обратную связь по работе других дизайнеров, не учитывая все или часть из этих параметров.
Мне пришлось попотеть, прежде чем я нашёл комментарий, который вы имели в виду. На всякий случай прикладываю его часть в виде картинки, чтобы контекст не потерялся.
Да, я бесплатно оцениваю проекты небольшого объёма, чтобы не разводить бюрократию и поскорее приступить к работе.
И платно оцениваю проекты с большим количеством ролей, процессов и разделов.
А я вот не уверен, насколько Хабр оповещает тех, кто на меня подписан. Как это выглядит с вашей стороны? В своих каналах вне Хабра я специально не анонсирую статьи в первые сутки после выхода, чтобы не смазать реальную картину и понимать, куда дальше развиваться.
Все проекты, которые я разрабатываю руками сам, я предварительно проектирую. Да, с насмотренностью и опытом всё проще делать всё «на лету». Да только всё равно это разные процессы с разными приоритетами. Гораздо меньше шансов ошибиться, когда работаешь по собственной проектной документации. Задача из абстрактной превращается в прикладную.
С проектированием. Спроектировал → посмотрел на результат → внёс правки в прототип. Пошёл кодить финализированный вариант. Это делается быстро.
Без проектирования. Закодил → посмотрел на результат → внёс правки в код. Это делается уже медленнее. Параллельная работа с большим количеством файлов, попытка одновременно думать и об интерфейсе, и о программной архитектуре, отвлекаешься на мелкие трудности, по которым ещё нет опыта.
Думаю, что это сработало бы, если бы я делал очень однотипные проекты. Но тогда зачем вообще проектировать? Упаковал бы во фреймворк или в тиражируемое решение — и продавал бы.
Многое будет зависеть от типа клиента. Если клиент не разбирается в том, что вы ему предоставляете — он вообще может не ориентироваться ни в ценах, ни в сроках. Он может сравнивать вас с кем-то ещё, а может и не сравнивать. У него может быть был когда-то опыт заказа чего-то подобного, а может и не был.
А если клиент хорошо разбирается в том, что заказывает, а также в состоянии оценить скорость и качество, — таких клиентов я называю профессиональными. Там будет очень трезвая оценка. Можно предположить, что такие будут биться за каждый рубль, но опыт показывает, что нет. Они вполне могут оценить, например, уровень самостоятельности или сервиса исполнителя, как раз таки сравнивая его с другими.
Так что я не могу поставить себя на место заказчика. Я сам много раз выступал в роли заказчика и хорошо разбираюсь во всём процессе разработки. А что в голове у другого, абстрактного, заказчика — это загадка.
Была возможность сравнить, как команда справлялась со схожими по размерам задачами. Одни задачи были сопровождены подробной проектной документацией, другие — нет. Разница в скорости составляла 2-3 раза. Это субъективное наблюдение. Объективно произвести измерения невозможно (предыдущая моя статья на Хабре как раз начинается с этого тезиса).
Но на тех разницах в сроках, которые тогда получились, я сформировал довольно устойчивое убеждение.
Да, стабильный миллион на фрилансе — это для меня задача не из лёгких. Но выполнимая. Я только однажды заработал чуть больше миллиона в апреле 2019 :) А потом в следующие полтора месяца — ничего. Но всё равно, тот апрель послужил мне живым примером выполнимости задачи. А миллион тогда и миллион сегодня — это разные миллионы.
Мы прямо сейчас находимся на странице с примером. Под статьёй — список комментариев. Под списком комментариев — форма добавления нового комментария. Если поставить в неё автофокус, то страница будет автоматически быстро пролистываться до формы, мешая вам читать статью.
А так-то вы правы — на десктопе автофокус в первом поле действительно чаще помогает, чем мешает. И если бы форма располагалась сразу в первом экране (и это был бы десктоп, плюс в силе все те нюансы, которые я перечислил в статье), я бы, скорее всего, сам поставил автофокус.
Но если форма, например, находится внизу длинной страницы, автофокус может неожиданно перехватывать управление и мешать дочитать текст до конца.
Важно не то, что он чаще помогает — важно, что вариант без автофокуса безопаснее в большем числе контекстов.
Спасибо вам — благодаря вашему комментарию и моему ответу я понял, что в статье не хватало этого нюанса, и дополнил её. Статья стала лучше.
Если форма находится внизу страницы из трёх экранов (например, на лендинге с формой захвата в конце), вы же не будете слать лучи неодобрения тем, кто не поставит автофокус в её первое поле?
Я исхожу вот из чего: если рекомендация не навредит в большем количестве сценариев — она более универсальна.
Да, известная проблема. Причём, часто даже не забывают про скролл, а делают его по-дизайнерски тонким и незаметным.
Представь форму, где собирают email и телефон. Обязательно для заполнения одно любое из них.
Думаю, у нас с вами получилось разное восприятие намерений статьи, и я бы хотел пояснить.
Цель публикации — не в том, чтобы защищать собственный дизайн или указывать, как именно нужно оценивать чужую работу. Речь не о том, что кто-то неправ. И не о том, чтобы поучать читателей.
Я постарался составить список факторов, которые могут влиять на восприятие интерфейса, если вы смотрите на него по скриншоту, вне контекста использования. Это наблюдение из практики — не более того. Я не ставлю под сомнение право на мнение, а лишь напоминаю, что итоговая оценка может быть неполной, если не учитывать некоторые параметры.
Что касается моего дизайна — он указан в подводке с комментарием «статья вообще не о моём дизайне». И да, статья не о нём. Просто на статью навёл мой ответ к комментарию из прошлой статьи — и я решил, что из этого будет удачная подводка. А ещё даже если бы речь всё же шла о критике моей работы — в этом не было бы ничего плохого. Важнее всего то, что клиент остался доволен результатом и дизайн решает свою задачу.
Спасибо, что поделились мнением.
Понимаю, откуда такая реакция — если воспринимать статью как попытку защитить конкретный простой экран, то список действительно может показаться избыточным.
Но на самом деле я говорил не столько про этот экран, сколько про общий подход к критике интерфейсов по скриншоту. Хотелось показать, как много факторов может оставаться за кадром — и что иногда вместо мгновенного вердикта полезнее сначала задать пару уточняющих вопросов.
Иногда за кажущейся простотой — довольно интересные и неоднозначные решения :)
«Любая текстура под текстом — зло» — звучит категорично :)
На самом деле всё, как обычно, зависит от контекста. В этом случае я специально обсудил с клиентом, насколько важна читаемость этих индикаторов — и выяснил, что они носят почти декоративный характер, а читают их крайне редко. Поэтому решили не усложнять задачу подбором отдельных цветов и оставить всё как есть: лаконично, аккуратно, без визуального шума.
Если бы это была рабочая информация — конечно, никаких текстур под текстом не было бы. Но «всегда зло» — это, пожалуй, перебор.
Спасибо за комментарии! Рад, что в целом стало лучше.
Особенно понравился пятый пункт про батарейку. Три уровня заряда действительно выглядят скудно, но за этим стоит интересная техническая подоплёка.
Например, во многих устройствах (включая, например, мою старую беззеркалку Sony A7R2) тоже всего три деления — и я всё недоумевал, почему так. Оказалось, что это не просто прихоть дизайнеров. Всё дело в том, что определить заряд батареи точно довольно сложно. Есть несколько методов: по напряжению, по подсчёту кулонов, с помощью фильтра Калмана и даже нейросетей — но ни один не даёт стопроцентной точности.
Чтобы сделать иконку батареи, которая выглядит просто, но при этом не вводит пользователя в заблуждение, нужно учитывать, насколько надёжны данные в конкретном устройстве. Например, в дешёвых гаджетах часто используют самый простой метод — по напряжению. Его точность может колебаться в пределах плюс-минус 10–20%, а под нагрузкой уровень заряда может прыгать ещё сильнее.
Я потому и выбрал именно три (на самом деле четыре) условных уровня, чтобы не создавать иллюзию точности там, где её нет. Да, выглядит упрощённо — но зато не обманывает.
Кстати, всё это — ещё один повод задуматься, как глубоко «железо» влияет на интерфейс. И как важно учитывать не только эстетику, но и механику получения данных.
Ну а статья как раз про это — про то, как легко ошибиться в оценке, глядя только на скриншот. И почему перед критикой стоит сначала задать пару вопросов :)
Чтобы числа в интерфейсе не «скакали» при изменении значений. Это особенно важно для приёмопередатчиков: частоты, уровни сигнала, временные метки и другие параметры меняются постоянно, и при использовании пропорционального шрифта текст бы дёргался на глазах у пользователя. А так всё стабильно и читаемо.
Можно было бы выбрать пару шрифтов: один для чисел, другой для текстов. Но посмотрели на то, что получилось, и решили, что и этот один неплохо смотрится.
Было бы очень интересно узнать, откуда у вас появилось такое ощущение. Ни один из моих предшественников не нарисовал ни одного варианта и не предоставил ни одного КП. Как эта планка может быть понижена?
Итоговый вариант в единственной цветовой гамме. Если в будущем возникнет желание «примерить» на него другие варианты, это делается за десять минут на стилях и их переменных.
Пока ничего, я только 8 июля сдал работу. Но вам верно ответили: каких-то особенных отличий от веба нет. Разве что будут чаще использоваться битмапы в качестве подложек. Плюс используется LVGL библиотека, которая, например, не позволяет задавать полупрозрачность для градиентов. Вы всё это можете посмотреть самостоятельно в коде проекта на Гитхабе.
Чтобы оценить размер, контрастность и читаемость, вам необходимо понимать следующие параметры:
— Физический размер устройства;
— PPI дисплея устройства;
— Тип матрицы дисплея устройства (его цветопередачу, контрастность, время отклика и прочие параметры);
— Номинальную яркость дисплея устройства и её различные вариации.
По картинкам из статьи, на которые вы смотрите со своего монитора или телефона, вы не сможете определить, как будет выглядеть тот или иной дизайн на том или ином устройстве.
Обратите внимание на пассаж из статьи:
«Например, можно будет ещё «примерить» дизайн к живому устройству — и если будут какие-то проблемы с яркостью или контрастом — подкорректировать цветовую схему».
——
А, чуть не забыл. Ещё один важный параметр, который нужно учитывать — это предполагаемое расстояние от глаз пользователя до дисплея устройства в распространённом сценарии использования.
Написал всё это и чувствую, что это неплохая тема для статьи. А то часто сталкиваюсь с ситуациями, когда дизайнеры дают обратную связь по работе других дизайнеров, не учитывая все или часть из этих параметров.
Мне пришлось попотеть, прежде чем я нашёл комментарий, который вы имели в виду. На всякий случай прикладываю его часть в виде картинки, чтобы контекст не потерялся.
Да, я бесплатно оцениваю проекты небольшого объёма, чтобы не разводить бюрократию и поскорее приступить к работе.
И платно оцениваю проекты с большим количеством ролей, процессов и разделов.
А я вот не уверен, насколько Хабр оповещает тех, кто на меня подписан. Как это выглядит с вашей стороны? В своих каналах вне Хабра я специально не анонсирую статьи в первые сутки после выхода, чтобы не смазать реальную картину и понимать, куда дальше развиваться.
Все проекты, которые я разрабатываю руками сам, я предварительно проектирую. Да, с насмотренностью и опытом всё проще делать всё «на лету». Да только всё равно это разные процессы с разными приоритетами. Гораздо меньше шансов ошибиться, когда работаешь по собственной проектной документации. Задача из абстрактной превращается в прикладную.
С проектированием. Спроектировал → посмотрел на результат → внёс правки в прототип. Пошёл кодить финализированный вариант. Это делается быстро.
Без проектирования. Закодил → посмотрел на результат → внёс правки в код. Это делается уже медленнее. Параллельная работа с большим количеством файлов, попытка одновременно думать и об интерфейсе, и о программной архитектуре, отвлекаешься на мелкие трудности, по которым ещё нет опыта.
Думаю, что это сработало бы, если бы я делал очень однотипные проекты. Но тогда зачем вообще проектировать? Упаковал бы во фреймворк или в тиражируемое решение — и продавал бы.
Многое будет зависеть от типа клиента. Если клиент не разбирается в том, что вы ему предоставляете — он вообще может не ориентироваться ни в ценах, ни в сроках. Он может сравнивать вас с кем-то ещё, а может и не сравнивать. У него может быть был когда-то опыт заказа чего-то подобного, а может и не был.
А если клиент хорошо разбирается в том, что заказывает, а также в состоянии оценить скорость и качество, — таких клиентов я называю профессиональными. Там будет очень трезвая оценка. Можно предположить, что такие будут биться за каждый рубль, но опыт показывает, что нет. Они вполне могут оценить, например, уровень самостоятельности или сервиса исполнителя, как раз таки сравнивая его с другими.
Я об этом писал у себя в книге про фриланс в главе «Профессиональные и непрофессиональные клиенты».
Так что я не могу поставить себя на место заказчика. Я сам много раз выступал в роли заказчика и хорошо разбираюсь во всём процессе разработки. А что в голове у другого, абстрактного, заказчика — это загадка.
Была возможность сравнить, как команда справлялась со схожими по размерам задачами. Одни задачи были сопровождены подробной проектной документацией, другие — нет. Разница в скорости составляла 2-3 раза. Это субъективное наблюдение. Объективно произвести измерения невозможно (предыдущая моя статья на Хабре как раз начинается с этого тезиса).
Но на тех разницах в сроках, которые тогда получились, я сформировал довольно устойчивое убеждение.
Да, стабильный миллион на фрилансе — это для меня задача не из лёгких. Но выполнимая. Я только однажды заработал чуть больше миллиона в апреле 2019 :) А потом в следующие полтора месяца — ничего. Но всё равно, тот апрель послужил мне живым примером выполнимости задачи. А миллион тогда и миллион сегодня — это разные миллионы.
А что за продукт разрабатываете?