Адам Сильвер написал о всплывающих подсказках (tooltip).

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

Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).

Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.

https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/

Переговоры: возможность принять финальное решение

Ещё одна вещь, которую почему-то игнорируют в книгах про переговоры — то, что случается после переговоров. Вот пришли вы на встречу, там сложно, вроде бы о чём-то договорились. А затем возвращаетесь в офис (или куда там вы возвращаетесь), и получаете несогласие от коллег.

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

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

Посмотрите, может быть у вас так же?

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

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

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

Думай как Билл Гейтс

Смотрю сейчас на Netflix документальный сериал про Гейтса. Очень увлекательно! В последней серии зацепил диалог следующего содержания:
— Билл, как ты думаешь, Microsoft монополист?
— Если монополия это большая доля рынка и краткосрочная власть над ним, то ответ да. Если вы подразумеваете, что у нас непобедимая позиция и никакой более удобный и эффективный продукт не может её пошатнуть, ответ нет.

И ведь правда. У слова монополия очень сильная негативная составляющая. Но разве это плохо? На свободном рынке, если не рассматривать государственные и прочие нечестные монополии, большая доля рынка говорит о том ,что продукт хорошо решает проблемы пользователя. Да, он может быть кривой и показывать вам периодически "синий экран сметри". Но он, чёрт побери, работает! В сериале есть вставки из хрорники, где народ расхватывает коробки с Windows 95, буквально сметает её с полок :)

Сейчас модно ругать Windows. Но ведь именно эта ОС сделала революцию на рынке персональных компьютеров. Сначала её, конечно, сделал Apple в сфере железа. Именно два Стива сделали компьютер персональным (Джобс и Возняк). Но они были нацелены на определенную ЦА. А вот Майкрософт сделал ПК по-настоящему массовым.

Сейчас Гейтс много времени уделяет проблемам энергетики и климата. Они с женой потратили кучу денег (28 миллиардов долларов) на стартапы и инициативы, которые пытаются сделать жизнь лучше в масштабах планеты. Крутой сериал про крутого бизнесмена и просто очень умного человека. Советую!

Чтобы обратиться к какому-либо узлу, его сначала надо найти

Для этого есть разные методы, но в современном прототипировании чаще всего применяются два метода:

let el = document.querySelector(selector)
и
let elems = document.querySelectorAll(selector)

Оба метода получают на вход CSS-селектор элемента. Например:

let el = document.querySelector(".someClass b");

Отличие их в том, что querySelector вернёт один узел, который попался первым, а querySelectorAll вернёт список всех узлов на странице, соответствующих селектору.

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

Если же вам всё-таки нужен метод map, то вы можете преобразовать список узлов в массив при помощи конструкции [...nodeList]:

let arr = document.querySelecroAll("a");
[...arr].map(el => el.innerText);

Подробнее в видео: https://youtu.be/KIBv7QMToP4
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Core Protocols

Когда я пришел в ManyChat, я первый раз услышал про LeSS и пошел читать методичку. А в методичке по LeSS я наткнулся на отсылку к Core Protocols, про которые не слышал раньше, и тоже пошел читать про них.

И если вкратце, Core Protocols — это система фасилитационных техник, направленных на улучшение коммуникации внутри команд.

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

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

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

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

Я их переведу на русский со своими комментариями, и если вы найдете более емкие формулировки, то пишите, я дополню/исправлю:

1) Я обязуюсь участвовать, когда присутствую
Это про то, что если участвуешь во встрече, то участвуешь, а не залипаешь в ноутбуке. Дополнительно расширяется на личную внутреннюю осознанность. Если что-то делаешь, то понимаешь зачем.

2) Я буду стремиться больше воспринимать, чем быть воспринимаемым
Это про то, чтобы слушать и пытаться понять аргументы, а не продавливать свою точку зрения любыми средствами.

3) Я буду использовать команды, особенно при выполнении сложных задач
Это про помощь. Ты должен пользоваться всеми видами помощи, которые можешь получить от людей вокруг, а не пытаться супергеройски вытащить проект, перегореть и уволиться.

4) Я буду говорить всегда и только тогда, когда верю, что это улучшит соотношение усилие/результат
Это про осознанное высказывание мыслей. Не нужно говорить просто, чтобы стать заметным для кого-то на встрече.

5) Я буду предлагать и принимать только рациональное, ориентированное на результат поведение и общение
Понимаешь, что разговор эмоциональный, не про цель, на высоких тонах, отмечаешь это и не вписываешься в такую игру.

6) Я буду избегать непродуктивных ситуаций
Если понимаешь, что 23 встречи в неделю не приводят к результату, отмечаешь это, и стараешься не участвовать им, не мешая при этом другим.

7) Я сделаю сейчас то, что должно быть сделано в конечном итоге и может быть эффективно сделано сейчас
Это про выполнение здесь и сейчас того, что приблизит к результату, а не создаст видимость занятости.

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

9) Я буду использовать протоколы, когда это применимо
Всегда помнишь про протоколы и стараешься их применять каждый раз, когда они нужны.

10) Я никому не причиню вреда—и не потерплю причинения вреда—за его или ее верность этим обязательствам
Если закомитились на core protocols, то не нужно закатывать глаза и проявлять агрессию (даже пассивную), когда тебе кто-то подсветил, что ты наваливаешь не в ту сторону.

11) Я никогда не буду делать ничего глупого нарочно
Вот да!

Это только верхушка, в следующий раз посмотрим на сами коммиты.

Вообще очень рекомендую прочитать оригинал текста с коммитами вот здесь — https://liveingreatness.com/core-protocols/the-core-commitments/