Как дизайнер, который кодирует, я активно ищу способы, которыми кодирование может облегчить мою работу. И до недавнего времени я считал, что создание прототипов в коде - это деятельность, полностью зарезервированная для мира дизайна графического пользовательского интерфейса (UI).
Боже, я был неправ. Получив отзывы о моем побочном проекте, который помогает дизайнерам и разработчикам создавать живые руководства по стилю (Runway), я быстро понял, что методы быстрого прототипирования и тестирования юзабилити можно так же легко применить к любому рабочему процессу или интерфейсу, например к командной строке. интерфейсы (CLI), которые разработчики обычно используют в своей работе.
Это было захватывающее открытие. За время работы в качестве дизайнера я пользовался бесчисленными возможностями для создания прототипов пользовательских интерфейсов и проведения тестов на удобство использования для конкретных рабочих процессов и функций. Однако никогда раньше я не предпринимал попыток создать прототип и протестировать рабочий процесс CLI. Не зная, с чего начать, я засучил рукава и обратился к своему знакомому другу за прототипированием в коде, Javascript.
В этом посте я расскажу вам (на высоком уровне) о моем процессе создания прототипа и тестирования одного из основных рабочих процессов в приложении: создания руководства по стилю с учетом исходного файла и нескольких параметров конфигурации.
Если картинка стоит тысячи слов, то прототип стоит 10 000. Прототипы выходят за рамки возможности показать и рассказать - они позволяют вам испытать дизайн (Прототипирование, Практическое руководство: Тодд Заки Варфел)
Контекст
Обратная связь - это жизненная сила для улучшений, и команда Runway получила ее с момента нашего запуска в прошлом году. Действительно, один из наиболее часто задаваемых вопросов был:
«Когда Runway будет поддерживать создание руководств по стилю с помощью инструмента командной строки или API?»
С самого начала мы ожидали такой обратной связи. Исходя из предположения, что нашими основными пользователями будут дизайнеры и что они будут уклоняться от использования интерфейса, полностью основанного на интерфейсе командной строки (например, Голограммы), мы сознательно сосредоточили нашу первую итерацию на всеобъемлющем Пользовательский интерфейс.
И все же самые убедительные отзывы поступили от разработчиков, которые искали легкий способ создания живых руководств по стилю, особенно такой, который можно было бы автоматизировать или легко интегрировать в существующую настройку CI / CD. Более того, обе группы пользователей были разочарованы тем, сколько шагов нужно было предпринять, чтобы отреагировать на ценностное предложение Runway: «Мгновенно переходите от таблицы стилей к руководству по стилю».
Примите мою (по общему признанию) самовлюбленную схему: создайте прототип интерфейса командной строки, который может быть использован как дизайнерами, так и разработчиками, и проведите пользовательское тестирование, чтобы оценить его осуществимость и удобство использования.
План
Поскольку создание функционального инструмента интерфейса командной строки без обратной связи с пользователем было рискованным и дорогостоящим (с точки зрения затрат на разработку), я постарался сделать то, что у меня как дизайнера получается лучше всего: создать дешевый поддельный инструмент. прототип », который можно использовать для получения обратной связи и снижения рисков будущих разработок. И, если быть полностью честным, я знаю, что у меня не было технических навыков, чтобы создать функциональный интерфейс командной строки эффективным образом. Столкнувшись с таким затруднительным положением, я применил проверенную дизайнерскую тактику: притворяйтесь, пока не добьетесь.
Как наркоман Javascript, я изучил ландшафт на предмет рекомендуемых инструментов интерфейса командной строки и быстро наткнулся на основанный на Node Commander.js. Использование инструмента на основе Node означало, что в моем распоряжении был мир NPM, что позволило мне использовать такие библиотеки, как Colors.js (для необычного, красочного вывода терминала) и Node Spinner (для отображения счетчика во время имитируемых асинхронных действий).
Начиная
Как и большинство проектов Node, я начал с создания файла package.json и сохранения в нем трех вышеупомянутых зависимостей. В соответствии с README for Commander я создал файл с именем runway.js и подготовился к прототипу.
Для контекста, пользователи Runway в настоящее время могут создавать руководства по стилям через пользовательский интерфейс, загружая файл CSS / SCSS со специально отформатированными комментариями. Они могут дать своему руководству по стилю имя и указать: A) макет; и Б) тема подсветки синтаксиса.
Я хотел создать прототип интерфейса командной строки итеративным образом, зная, сколько времени у нас уйдет на то, чтобы перейти к вышеупомянутому UX. Итак, я предполагал начать с команды new-styleguide, которая будет принимать единственный аргумент - таблицу стилей - и возвращать URL-адрес пользователю.
Механика Commander довольно проста. Вы определяете command, предоставляете необязательный description и набор options и сопоставляете его с action (который является функцией Javascript).
Одна из самых интересных особенностей Commander заключается в том, что он автоматически создает help страницу со списком всех ваших команд и их соответствующих синтаксисов. Итак, введя ./runway.js --help в свой терминал, я получил следующий результат.
Счет! Когда все было налажено, я начал заниматься UX, создавая новое руководство по стилю. Для счастливого пути пользователь должен иметь возможность предоставить исходную таблицу стилей и получить взамен URL-адрес своего руководства по стилям, отформатированный таким образом http://runway-app.cfapps.io/styleguide/:id. Используя некоторую магию Javascript, я сгенерировал случайное число для параметра :id URL-адреса.
Приправить вещи
В реальном мире создание руководства по стилю, скорее всего, займет несколько секунд. Чтобы убедить пользователей, что Runway обрабатывает их запросы, что, если мы покажем какой-то счетчик с информативным сообщением? Я использовал вышеупомянутые библиотеки, Colors.js и Node-Spinner, чтобы добиться этого эффекта.
Получение фантазии
Через пользовательский интерфейс Runway пользователи могут указать имя своего руководства по стилю и выбрать тему выделения синтаксиса. Commander упрощает для пользователей передачу этих значений как options и предоставляет механизм для установки значений по умолчанию, если они его опускают. Commander также позволяет нам адаптировать справочные сообщения на command основе, что означает, что мы можем сообщать нашим конечным пользователям о сложности (или допущенных нами) конкретных действиях.
В этом случае я хотел разрешить пользователям выбирать между тремя темами подсветки синтаксиса, monokai, solarized и github, по умолчанию выбирая первую, если ни одна из них не была указана. Но поскольку в этом интерфейсе командной строки отсутствуют возможности, которые можно найти в веб-интерфейсе, я счел необходимым сообщить об этом решении в меню help команды new-styleguide. К счастью, Commander предлагает простой способ сделать это.
Пользовательское тестирование
Я все еще нахожусь в процессе пользовательского тестирования этого опыта, формируя сеансы юзабилити вокруг следующего Сценария задачи:
Дизайнер из вашей команды только что добавил несколько комментариев Runway в основную таблицу стилей вашего приложения (main.css), и вам нужно создать для него новое руководство по стилю. Вы только что установили runway CLI глобально.
Неудивительно, учитывая масштаб задачи, разработчики в значительной степени смогли с легкостью создать руководство по стилю. Моим самым большим выводом было то, насколько сильно разработчики полагались на меню help, чтобы познакомиться с этим новым инструментом CLI. Это имеет смысл, учитывая отсутствие возможностей для CLI и инструментов на основе команд. Но было поучительно видеть, как горстка разработчиков выполняет в точности шаги, чтобы ускориться и в конечном итоге выполнить задачу.
Это был феноменальный опыт обучения, который продемонстрировал, насколько легко применить методы итеративного дизайна, быстрого прототипирования и пользовательского тестирования к среде, не являющейся пользовательским интерфейсом.
В этом посте я затронул много вопросов и, по общему признанию, помахал рукой над множеством деталей. Если вас интересует какой-либо конкретный аспект этого рабочего процесса (будь то кодирование или процесс), сообщите мне. Я более чем счастлив поболтать.
Если я выполнил свою работу здесь, я сообщил, насколько безболезненно прототипировать опыт интерфейса командной строки с кодом. Это не означает, что код - лучший (или единственный) инструмент для таких усилий. Как известно дизайнерам, инструментов и методов создания прототипов предостаточно. В конце концов, выбор инструмента должен зависеть от:
- Точность дизайна или взаимодействия, необходимая для проверки гипотезы.
- У человека есть средства для создания прототипа - будь то код, бумага, визуальный дизайн и т. Д.
И хотя я не исследовал альтернативные средства прототипирования в этом сценарии, я уверен, что мы можем применить технику и строгость итеративного дизайна к интерфейсу командной строки, так же, как мы это делаем для нашего интерфейса на основе пользовательского интерфейса.
Ссылки
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
