Интерфейсы *

Меня зовут Лена, я дизайнер интерфейсов в Tele2. И я расскажу о создании внутреннего корпоративного мобильного приложения «На связи» для сотрудников Tele2 – его проектировании и выборе визуального решения. 

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

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

О приложении «На связи»  

В нашей компании большое количество рабочих процессов завязано на внутренних системах. Многие из них доступны только из корпоративной сети. Чтобы сделать сотрудников более мобильными, дать возможность быстрее решать рабочие вопросы, сэкономить время – было задумано приложение «На связи».

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

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

Заодно разберемся с таким понятием, как неявные анимации.

Кто-нибудь пробовал использовать Dart / Flutter как на клиенте на нескольких платформах, так и в качестве сервера? Кто-то, конечно. пробовал, хотя далеко не каждый за этим приходил к Flutter. Я на своём pet-проекте провёл такой эксперимент, и хотел бы поделиться результатами и выводами.

Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

Текстам в интерфейсе уделяется незаслуженно мало внимания. Их игнорируют, про них забывают, про них вспоминают, когда уже поздно: дизайн сделан, код написан, огребаем на проде. Печально. А ведь хороший текст — один из самых дешевых способов сделать продукт лучше, и заработать больше денег.

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

В вашем продукте (сайте, программе, приложении и т.д.) есть английский текст, и вы хотите, чтобы он приносил вам выгоду, а не просто занимал место? Читайте статью дальше. Я расскажу, как писать по-английски нужно, и как не нужно.

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

Роберт Брингхерст в книге «Основы стиля в типографике» говорит, что оптимальное значение длины строки составляет от 45 до 75 знаков. 66 — идеальный вариант, а для многоколонного набора — 40—50 знаков.

Максим Ильяхов пишет, что за максимум берет 75 знаков, — столько помещается на страницу А4 с полями при наборе 12-м кеглем.

Smashing Magazine в 2009 году провели исследование и выяснили, что средний результат символов на строку равен 88,74, а среднее значение изменяется от 75 до 85.

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

Привет, на связи Олеся Гумененко и Тимофей Контанистов. Мы отвечаем за дизайн продукта в СберМаркете. Расскажем, как создавали новые иллюстрации для приложения, наступали на грабли и делили апельсин.

Начнём с истории компании. Она влияла на визуальный стиль продукта — и на иллюстрации тоже.

Сначала мы были Instamart — небольшим, но гордым стартапом. Уже тогда работали по простой схеме: покупатель заказывал товары из магазина, сборщики их собирали, а курьеры привозили.

В 2019 года вошли в экосистему Сбера и сменили название на СберМаркет. Заказов стало больше в сотни раз, и нужно было переделывать приложение под новые масштабы и задачи. Заодно решили заняться иллюстрациями — чтобы соответствовать большому бренду и при этом найти собственный стиль, который можно масштабировать. На всё у нас была пара месяцев.

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

Меня зовут Алексей Комаров, я — старший frontend-разработчик в SuperJob. Хочу поделиться опытом реализации механизма обновления данных в реальном времени у нас на сайте. Под катом — подробности о выборе подхода, о проблемах, с которыми мы столкнулись при разработке, о наших кейсах оптимизации 
клиентской стороны и, конечно, немного кода и наглядных схем.

В конце января в Нетологии прошёл открытый урок для новичков в профессии дизайнера. Провёл его Владимир Ойкин, UI-дизайнер в ITECH. Под катом — краткий конспект выступления и ссылка на полный урок, который всем доступен к просмотру.

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

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

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

В последние годы практически все крупные IT-компании заняты созданием экосистем и омниканальных платформ. Есть очень много статей и докладов об их очевидных преимуществах для клиентов и бизнеса, но как это всё устроено изнутри? Как разрабатывать подобные продуктовые решения быстро, гибко и не изобретая велосипеды на каждом шагу? Об этом информации как раз маловато. Вот мы и решили, что белые пятна лучше заполнять историями о собственном опыте, и попробуем сами рассказать, как в ВТБ создавали платформу цифровых продаж.

На работе я занимаюсь созданием PCIExpress устройств на ПЛИС. Некоторые из ПЛИС имеют встроенное PCIExpress ядро, позволяющее работать с этим интерфейсом на уровне пользовательского приложения. ПЛИС серии ECP5UM фирмы Lattice использует Soft-IP Core для реализации протокола, написанный на языке HDL, а в микросхему лишь встроен блок, отвечающий за работу физического уровня. Мне пришла в голову идея попробовать сделать PCIExpress анализатор на базе этой микросхемы.

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

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

В этой статье будут изложены основные идеи и показаны простые примеры для  грамотной организации, скажем так — «репликационного» масштабирования проектов на фронтенде. То есть, само понятие масштабирования здесь будет рассматриваться скорее с той точки зрения и в одном из смыслов как это понимает бизнес, но, при этом, речь пойдет именно о технической стороне процесса, правда, сугубо в контексте браузерной клиентской части информационных систем. Ближе к реальной ситуации: предположим что ваша компания разрабатывает, условно — некий OLAP-продукт, и перед вами как фронтенд-разработчиком ставят задачи по развертыванию и поддержке более или менее сходных новых проектов фронтенда для разных заказчиков. После скандальной критической статьи о, имхо, сомнительных дурных современных подходах и тенденция в верстке веб-интерфейсов — моя карма на Хабре, наконец-то упала ниже нуля, а я, если честно, не очень хорошо понимаю правила игры, увидят ли эту статью читатели… Но, с другой стороны, готов изложить все просто «в стол», так как считаю что лучшая мотивация для написания чего-либо — это если «просто очень хочется написать», сформулировать, прежде всего — для себя самого.

Эта статья логично продолжает тематику первой статьи о модулях позволяющих сделать разработку фронтенда качественнее и эффективнее. Но если в первом материале речь шла, прежде всего, об замечательном атомарном тренде в вебдизайне и простом надежном способе доставки его в код компонентных фреймворков с помощью препроцессоров, построении простой кастомной библиотеки UI-компонент для единообразного оформления разных проектов, то новый пример станет немного сложнее — хочется сосредоточиться уже не на «внешних», «оформительских» моментах, а на функциональных и организационных. Для наглядной демонстрации практического применения изложенных в статье идей снова написаны примеры: небольшой модуль-библиотека (и документация к нему), а также использующий его проект, на этот раз с более актуальным стеком Vue3+TypeScript/Vuex4/VuePress2. В отличие от более примитивной либы из первой статьи, этот модуль: 1) использует хранилище, то есть содержит состояние 2) может запускаться в полноценном режиме разработки, как будто это собственно уже сам конечный проект 3) поддерживает темизацию и локализацию. Пример модуля содержит совсем немного компонент и документация на новой версии VuePress, в отличие от первой версии модуля, не кастомизируется под фирменный стиль который предоставляет сама библиотека. Так сделано не только по причине лени и экономии времени, но, прежде всего, потому что кажется излишним — то что призваны продемонстрировать примеры — этого совсем не требует.

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

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

Новая документация по значкам приложений, жизненному циклу приложений, кистям, элементам управления и Single Project; Обработчик FlyoutView реализован на Android; Добавлены обработчики совместимости для RelativeLayout и AbsoluteLayout; Добавлено свойство Z Index; Унификация .NET 6 — типы iOS; Расширенная панель инструментов Windows — без оболочки.

В этом выпуске также представлено крутое усовершенствование Shell. Давайте более подробно рассмотрим Shell в Preview 12.

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