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

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

Решение

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

Документация

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

Следующее должно быть выделено в вашей документации.

  • Что делает ваш инструмент - да!
  • Зависимости - приложения, необходимые для установки инструмента.
  • Установка приложения - пошаговая инструкция по установке инструмента.
  • Как внести свой вклад (с открытым исходным кодом) - инструкции по внесению вклада, если ваш инструмент имеет открытый исходный код и доступен для участия.
  • Канал обратной связи. Способы, которыми с вами можно связаться, если пользователи захотят поделиться с вами отзывами о вашем инструменте.

Используйте короткие и легко запоминающиеся команды.

Я понимаю, что ваш инструмент может быть достаточно мощным, чтобы запустить космическую ракету с расстояния в тысячу миль, используя всего несколько простых команд. Однако простые для запоминания команды, подобные простому английскому, часто мешают вашему пользователю проверять stackoverflow, чтобы узнать, как запустить ваш инструмент. Эти команды должны быть контекстными по отношению к тому действию, для выполнения которого они предназначены. Представьте, что ваш npm install был js pkge mngr dwldили записан как javascript package manager download complete. Насколько легко было бы запомнить такую ​​команду, которую вы, вероятно, будете выполнять гораздо чаще, чем вы ожидаете?

Используйте существующие форматы команд

Команды очень популярных инструментов короткие, лаконичные и имеют очень похожий формат. npm install устанавливает последнюю версию npm, bundle install устанавливает версию gems для вашего приложения rails, brew install appname устанавливает последнюю версию указанного вами приложения. Используйте шаблоны, подобные существующим выше командам, для определения команд вашего приложения.

ПОМОЩЬ!!!

Всегда используйте команду help, чтобы у пользователей была документация, которая поможет в случае затруднений. Ваш раздел помощи должен быть хорошо документирован и прямо по делу. Он должен быть легко доступен с помощью простой команды по вашему выбору. Типичным примером является справка Git, к которой можно получить доступ с помощью простой команды git help, и вы получите доступ к командам git и их функциям. Кроме того, предложения, основанные на ошибках, значительно улучшают работу вашего инструмента командной строки. Состояние вашей ошибки должно быть не только понятным, но и предлагать возможные решения для вашего пользователя. Опять же, Git делает это очень хорошо, как показано в примере ниже.

Обратная связь

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

Всегда давайте обратную связь своим пользователям, выполняя действие

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

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

  • Отображение имен файлов и процессов, участвующих в этом действии.
  • Использование состояния загрузки (многоточие «…» или равное «==»)
  • Отображение процента выполнения цифры

Цвета

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

  • Используйте красный цвет для обозначения ошибок
  • Зеленый для обозначения успехов
  • Желтый для обозначения предупреждений

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

Примеры инструментов, которые позволяют добиться хорошего впечатления, включают brew create-react-app yeoman rails и другие.