FrontendConf

Side effects:

1) Несколько раз помусолим эвристики с разных сторон, часть из них точно отложиться в голове
2) Соберу много практических примеров и проваледирую у разработчиков и комитета, посмеемся над типовыми ошибками, чтобы их больше не делать
3) Будет много шуток

Ремарка: Хотя современные IDE, всё больше похожи на UI для написания кода, который стараеться помочь и предотвратить ошибки, автор любит сравнивать их с написанием текста в блокноте.

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

Список эвристик от Nielsen Norman Group:
https://www.nngroup.com/articles/ten-usability-heuristics/

Инновационная часть доклада (набросок):

Ниже распишу примеры match эвристик на опыт разработчика (в большей степени Typescript/JS)

1. Понятный статус системы → REPL и realtime time debug, статусы подлючения к серверу и git, minimap для навишации по коду, консоль для отображения статуса не видимых в UI действий и многое другое)

2. Соответвие системы и миру пользователя → использовать названия переменных, свойств и стилей (camelCase, snake-case и прочие правила), термины и подходы принятые в конкретной среде разработки (напримере JS), а не как тебе вздумается

3. Контролиремость и свобода выбора (разработчики всегда хотят больше контроля) → Undo/Redo, Git Versions: Review, Restore и пр.

4. Консистеность и стандарты → Cистемность однотипных решений, DX Patterns, (проектируем одинаковые вещи одинаково). Typescript для описания в одном месте. того что используется в нескольких. Interfaces для как способность классов (Drawable, Iterable и пр.)

5. Предотвращение ошибок системы и пользователя → подсветка гарантированных ошибок перед выполнением кода, Typescript для гарнтирования прафильного ввода текст кода, отображение ошибок вместо выполнения программы, ошибки линтера, debug для поиска ошибок в верстке и коде и пр.

6. Уменьшение ментальной нагрузки →
показывать имена функции/метода в sticky headers чтобы не зопоминать в каком месте кода ты сейчас, уменьшать количество текста кода и дулированные обращения (локаничность), показывать выпадающие списки для типизированных свойсств (чтобы не запоминат и не ошибиться), быстрое условное присвоение c = bool? a : b и пр., JSX для как удобный язык разметки, state chart и пр.

7. Уменьшение механической нагрузки → горячие клавиши по выделениям, поиску, запуску, дебагу, переключению между окнами с кодом и отображением, ускорение code review и написания кода в нескольких местах (мне кстати до сих пор ломает мозг)

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

9. Понятность при информировании пользователя → текст, ошибки такой, что пожно понять в чем проблема, а не сразу Stack Overflow или Github issues (хотя в разработке как раз с этим плохо всё). Source map для минификации, чтобы понять где это был (а если отломалося source map, чинишь, а надо релизить)?

10. Помощь, onboarding и документация → документацию легко найти, она понятная и простая, есть разделы с чего начать и пр. соответвует стандартам и лучшим практикам, описаны варианты свойств и их типы, песочница для DS c перечнем возможностей и возмодностью применить варианты на лету и пр.

Такая работа ранее не делалась, нужно будет мне еще глубже копать и собрать практические примеры.

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

1) Disbales vs Hide - вечный спор (Disable только когда пользователю понятно как сделать enable. Hide - только когда очевидна смена контекста - новый диалог, явная смена selection).

2) Дублировать действие в двух местах или нет. Например кнопка [Close] и X в модальном диалоге (только когда очень высокое модальное окно. Дублировать плохо).

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

и др.

О себе:



Опыт выступления (года 3 не выступал, но постоянно делаю это в роли дизайн-директора внутри компании МойОфис):

Data Art Meetup: "Парное review. Управляемая и дружная команда без Bottleneck"
https:/youtu.be/wi7I3D0BMOE?t=2630

Профсо UX : "Кроссплатформенная унификация. На что обратить внимание и как развивать большой и сложный продукт" https:/vimeo.com/267044787 (самы первый доклад)

Обучающие видео про плагин Design System Organizer на английском:
https://www.youtube.com/watch?v=XtRfPe-vEXU