CLI ☠

[ermouth]

Я сегодня имел счастье поюзать vi – и переплевался в очередной раз от CLI и сопутствующих тулов. После этого у меня состоялся занятный диалог в тви:

Во избежание недопонимания, я не против CUI вообще, но я резко против CLI. По моему глубокому убеждению засилье CLI снижает качество программного обеспечения и в целом тормозит всю отрасль.

Огромное количество отличного софта просто не доходит до массового пользователя из-за отсутствия человечьего UI. То-есть, случается софтинка давно уже вышла из детского состояния и обросла крутыми фичами – а так и пребывает в виде CLI-утилиты, даром, что ключей на 10 экранов.

Звоночки

Вообще, превращение списка ключей в дерево или разбухание ключей больше чем на полэкрана хэлпа – верный признак того, что пора с CLI подзавязывать и делать человечий UI.

Ещё хороший признак – если команды перестали совсем напоминать человеческую речь, пусть и существенно “туземную”. Полно утилит, которые абсолютно бесполезны, пока им не припишешь пару строк ключей из бессмысленных наборов букв.

Тут есть промежуточное решение, групповые ключи типа –O2, вместо –falign-jumps, –falign-functions и далее по списку. Но это уже полшага к UI.

Мифы

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

Так вот, оно миф.

Хороший UI, да при этом современно выглядящий – да, это сложно. Но “модный” вид решительно не нужен для утилиты, у которой весь зоопарк CLI-ключей мапится на пару-тройку групп радио с чекбоксами – и сделать эти радио с чекбоксами совершенно не проблема же.

Бесспорно, есть целый класс случаев, когда CLI-наилучшее, а иногда – и вовсе единственно пригодное решение. Вот только расширять этот класс за счёт случаев “разработчику было лень” – это некомильфо. А именно так нередко и происходит.

Ещё один миф – что научиться делать хороший UI как-то очень сложно.

Я несколько раз над этим и сам размышлял, и с состоявшимися UI-дизайнерами говорил. Общий знаменатель – научиться не столько сложно, сколько долго. Это соображение совсем не узкоцехового плана – чтобы научиться делать хорошо всё что угодно, надо это сделать много раз.

Простые вещи начинают получаться сразу, сложные – чуть погодя. Прикручивание UI к несложным CLI-тулам в этом плане дело благодарное, такие интерфейсы как раз несложные.

Итого

Уважаемые софтвэа девелоперы, не ленитесь, делайте UI к вашим CLI – и дано будет вам ))

Comments

[gintaras.livejournal.com]

Я, как пользователь, двумя руками за :)

[morfizm.livejournal.com]

У меня сразу по нескольким вещам комментарии :)

Главное - ты по-моему, упустил из виду ключевую проблему. Она НЕ В ТОМ, что сложно ДЕЛАТЬ UI. Она в том, что ДЕЛАТЬ UX (User eXperience) это отдельный скилл. Ему часто не учат в универах. Думать о use-cases и об end-to-end experience. Это куда в большей степени психология, чем программирование. Ну так вот. Чтобы написать классный command line тул, тебе зачастую не нужно думать о юс-кейсах. Ты даёшь пачку функционала, набор конструктора лего, и дальше кто во что горазд из этого лего собирает. Ну т.е. самое главное, что этот человек может тупо не уметь писать walk-through туториалы для готовых поделок-сборок. Он может не видеть пользу от них. Он может также не хотеть ограничивать creativity пользователя и заставлять его думать определённым образом, но я бы сказал, что это minor point, куда больше, по-моему, банально неспособность.

"Прикручивание UI к несложным CLI-тулам в этом плане дело благодарное, такие интерфейсы как раз несложные."

Вот и займись монетизацией. Ты сможешь. Среднестатистический девелопер не сможет. Найми молодого программера, не "звезду", но работящего, и дай ему задание написать UI к тулам, тебе нужно будет совсем немного руководить процессом - разъяснить юс-кейсы и набросать черновики UI. Можешь чисто для лулзов не сделать свою часть и позволить ему сделать UI самостоятельно от начала до конца. Я думаю, для тебя это будет eye opener: насколько отвратительный UX может сделать неподготовленный соответствующим образом программист. Я видел неоднократно, посмеивался и жевал попкорн :)

Отдельно: command line тулы это очень круто, т.к.

1) К сожалению, хороших GUI тулов в сотни раз меньше.

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

3) Command line даёт простые возможности автоматизации: скриптование, перенаправление ввода-вывода. GUI тулы отвратительны в этом плане.

4) Command line тулы, к которым ты привык, в несколько раз эффективнее - за счёт буфера клавиатуры. Тебе не нужен feedback loop: увидел-кликнул-увидел результат-кликнул ещё раз. Ты херачишь нажатия в буфер, пусть оно там подтормаживает в обработке, но тебе плевать: то, что ты захерачил, будет отработано в правильной последовательности. Отсутствие необходимости обратной связи - значительное уменьшение когнитивной нагрузки. Кроме того, меньше стресса от всевозможных непредсказуемостей UI: всяких дурацких диаложков и т.п. Да, для начинающего пользователя GUI будет удобнее, но к продвинутому уровню - у GUI есть ограничение именно в этом.

5) Не используй vi - это архаизм. Используй vim!

[morfizm.livejournal.com]

"Вот и займись монетизацией."

Только для vim'а не надо это делать. Иначе ты рискуешь, что в результате у тебя получится Microsoft Word.

[ermouth.livejournal.com]

> Используй vim!

Сам используй )

По остальному – что-то да, что-то совсем нет.

Ты прикинь, в скольких CLI утилитах ты никогда не используешь скриптование или пайпинг, зато регулярно паришься с ключами. Вот они – прямые кандидаты на прикручивание UI.

[ermouth.livejournal.com]

Гггг, я уже сделал себе Ворд ) http://inliner.cloudwall.me/ddlab/_inliner#144184061501ff0vgzjf

[morfizm.livejournal.com]

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

Это вопрос привычки работать с CLI, дисциплины и passion for programming/automation. У меня правило - если мне нужно указывать какие-то ключи (кроме совсем тривиальных вроде git checkout -b branchname) более трёх раз, то перед тем, как писать четвёртый, я пишу wrapper script для конкретно моих юс-кейсов. На самом деле даже для git-овых команд у меня 1-2 буквенные алиасы.

За первый год работы на новом месте накапливается штук 30-50 скриптов, дальше медленнее. Иногда, когда сильно туплю или работать не хочется, я "навожу порядок". Написание скриптов входит в "наведение порядка".

Ну т.е. нет, "регулярно паришься с ключами" это совсем не про меня.

[morfizm.livejournal.com]

>> Используй vim!
> Сам используй )

Таки да!!! :) Использую.

[morfizm.livejournal.com]

Проблема в том, что мои скрипты трудно кому-то дать. Разбираться с их областью применения может занять столько же времени, сколько написать свои. Кроме того, у другого человека может быть чуть другая специфика применения. Делать групповые ключи - создание новых сущностей, ещё одно усложнение. (Хоть иногда и упрощает). Делать хороший гуй - ну это учитывать кучу разных юс-кейсов, это непростое дело, и, как я уже отметил, программеры редко владеют этим скиллом в достаточной мере, чтобы было значительно более usable, чем command line.

[morfizm.livejournal.com]

Sweet. Это очень близко к тому, каким я хотел видеть редактор для блога. Кстати, он у тебя компонента, его легко встроить в другой сайт, или ты только для себя?

[ermouth.livejournal.com]

Сам редактор – $.my приложение, то-есть по определению компонент. Любое $.my приложение встраиваемо как единый контрол в другие $.my-приложения.

[morfizm.livejournal.com]

Для "домашнего использования" у меня, кстати, тоже уйма скриптов, наверное, с сотню. Скажем, только лишь к imconvert ("image magick") у меня их штук 5. Один из них специально для бабушки - ресайз фоток с поддиректориями, чтобы вписать фотки в квадрат 800x800 (у неё фоторамка 800x600), плюс какие-то эффекты, sharpening. Разные другие конвертеры. Для архивации есть скрипты.

[ermouth.livejournal.com]

У меня вообще нет скриптов. Меня когда что-то повторяющееся донимать начинает, я гуй рисую )

[morfizm.livejournal.com]

и пишешь имплементацию UI automation - автораспознавания и кликания на GUI контролы других apps?

[soloviewoff.livejournal.com]

CLI - это зачастую больше API, нежели UI. Отсюда проблемы, да. Например, если попросить объединить несколько опций в Git в одну, то скорее всего закидают яйцами разработчики. Ибо это больше API, нежели продукт. Для UI объединение часто используемых вместе фич в одну - обычное дело.

У API-ности, правда, есть достоинства - длинной командной строкой, выполняющей нужное действие, легко поделиться с другом. В предыдущем продукте, который я делал, у нас был и GUI и CLI, и GUI умел генерить командные строки для CLI по текущим флажкам / состоянию GUI. Это фича очень популярна оказалась.

[ermouth.livejournal.com]

Нет, конечно, хотя я пробовал. Это чепуха.

Соврал я тебе про скрипты, есть они у меня – просто внутри приложений обычно. Скажем, твой таск с фотками я бы забатчил фотошоповским скриптом. Но я бы его не писал, а _записывал_ с UI.

Хотя, если что-то сложное, я и написать могу. Просто у меня основной язык ‘скриптования’ – js.

[ermouth.livejournal.com]

> CLI - это зачастую больше API, нежели UI. Отсюда проблемы, да.

Это очень распространённая подмена понятий )) CLI – это способ доступа человека к API, не сам API. На мой взгляд, способ один из самых архаичных и переоцененных.

> Это фича очень популярна оказалась.

Интересный сценарий. Но это ведь ровно то, о чём я говорю – у вас был GUI, который от вас прятал эти длинные ключи за, условно, галочками. Когда вы замаялись с CLI, у вас появился человечий интерфейс, который сводил возню с CLI до кликов мышки + Ctrl-C/Ctrl-V.

А вызов командной строки тут просто начальное состояние передавал, это по-всякому же можно делать. Урлы, гисты, записи в БД и пр.

Представьте, что у вас CLI нет вообще, а вот GUI как вы описали – есть. Только в поле, из которого вы копируете, можно и вставить сторонний стэйт, и рядом кнопка Рун )) Хороший удобный специальный гуй.

[morfizm.livejournal.com]

Т.е. ты хочешь, чтобы (а) гуёвые утилиты таки provide'или API для автоматизации, и (б) чтобы GUI дублировал все параметры этого API, типа, тебе так удобнее записывать, чем с консоли --help читать?

Получается, что для тебя GUI это learning & discovery tool. Тут мы сталкиваемся с ещё одной проблемой in general developers community: с тем, что если человек хороший разработчик конкретного тула, это совсем не обязательно означает, что он хороший разработчик learning приложений. Это как бы отдельный domain knowledge - уметь писать учебные штуки. Талантливые UX дизайнеры это умеют, но редко они в одном лице и девелоперы. А если же делать продукт в огромной команде где есть разделение ролей, там будет куча оверхеда, будет дорого стоить, будут резать фичи лишь бы было поменьше фич и т.п.

Opportunity, наверное, в том, чтобы либо работать в паре (UX-дизайнер и программер), либо научить программера быть UX-дизайнером. Добавить этот курс в университетскую программу. Ну и научить комфортно клепать быстрый GUI. Во времена Delphi был момент, когда среднестатистическому девелоперу наклепать GUI было комрофтно - он делался быстро, выглядел опрятно, легко инсталлился и работал. Сейчас, по-моему, с этим стало *хуже*: UI как бы отделился в нечто сложное и громоздкое.

[morfizm.livejournal.com]

"Урлы, гисты, записи в БД и пр.... Представьте, что у вас CLI нет вообще, а вот GUI как вы описали – есть. Только в поле, из которого вы копируете, можно и вставить сторонний стэйт, и рядом кнопка Рун )) Хороший удобный специальный гуй."

Тут возникнет ряд проблем. Чтобы лучше понять проблемы, поговорим о достоинствах командной строки:

1. Самой идее (строка текста, разделённая пробелами, где первое слово это исполняемый файл, а второе - параметры) больше лет, чем мне. Для "параметров" есть несколько разновидностей интерпретации, но их немного и всем им очень много лет. XML-ы, JSON'ы, URL-ы и т.п. - всё это, по сравнению с командной строкой, новинки. Надо тратить время, их учить. Нет гарантии, что оно не станет outdated через 5 лет и придётся заново что-то учить. Синтаксис командной строки практически "бесплатный" в плане цены за образование - все его знают и он практически не меняется.

2. Строка ASCII-текста - наиболее переносимая вещь. Она поддерживается на всех операционных системах, её очень легко переносить из приложения в приложение. *Nothing* can beat it, really.

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

Подумай, сколько нужно сделать телодвижений, чтобы добраться до ключей и значений, если они записаны в какой-то БД, а у тебя есть только id? Что если ты вообще не знаешь, что это за база, и на каком она сервере? Сравни с командной строкой - вот она, у тебя в руках. Всё сразу есть, self-contained.


Я много думал по поводу ухода от текста к визуальной структуре, и, мне кажется, первый шаг - язык программирования и хороший редактор кода (с рефакторингом и всеми плюшками) - такой, чтобы программа была не текстом, а каким-то, скажем, геометрическими формами, соединёнными между собой, и чтобы ими легко было манипулировать, а также чтобы они вообще повсеместно поддерживались. Тогда вместо командной строки у тебя будет 3D-гроздь такой вот фигни. Да, будет красивее, опрятнее, ты решишь раз и навсегда проблему парсинга структуры, потому что структура будет enforced, но многие другие проблемы ты не решишь: если эта гроздь будет громоздкой, learning curve будет большой.

[morfizm.livejournal.com]

Ещё - парсеры командной строки пишутся за один вечер и/или за один вечер привинчивается готовое решение. Любые другие вещи за один вечер не пишутся (по крайней мере, нельзя сделать такое обобщённое утверждение... конечно, ты приведёшь пример, что у тебя пишется, но это у тебя).

[soloviewoff.livejournal.com]

Там без командной строки местами нельзя было в силу специфики. Это был инструмент (профилировщик) для анализа других приложений, многие из которых были сами командной строкой. Например, SPEC бенчмарк какой-нибудь. Ну и автоматизация в командной строке часто проще достигается - типа запустить бенчмарк 50 раз, выбрать 10, 50, 90 percentiles.

А так да - URL это практически та же командная строка.

[morfizm.livejournal.com]

> А так да - URL это практически та же командная строка.

Только, в отличие от командной строки, почти всегда нечитаемая, пока не прогонишь её через парсер.