Интерфейс

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

В действительности, UI E начисто лишен пафоса, что приятно

С моей точки зрения, такое решение очень правильно, т.к. при работе с текстом я и без того отдаю большее предпочтение клавиатуре, чем мыши, а нагромождение разноцветных кнопок создает лишний визуальный шум. Тем не менее, отказ от привычных кнопок copy/paste найдет признание со стороны далеко не любого пользователя. Слишком радикальная перемена.

В общем и целом, интерфейс радует обоснованным минимализмом.

Функциональность

Базовые возможности Е довольно обширны. Встречаются даже оригинальные детали для редакторов такого класса:

• Можно выделять произвольное количество текстовых блоков (примерно как в MS Office). Для текстового редактора это чуть ли не уникальная фича. Даже в EmEditor такого нет. Так же возможно выделение вертикальных текстовых блоков, но это уже не так интересно и много где реализовано.
• Предусмотрена довольно оригинальная возможность копирования ввода. Она может быть использована для набора одинаковых фрагментов текста в разных частях файла. Понять, как это работает и в каких случаях применимо, проще всего посмотрев скринкаст на официальном сайте.
• Поддержка пакетов TextMate (bundles).
• Множество других, менее значимых, но полезных возможностей: табы (куда же без них); поиск по регулярным выражениям (оу, йез!); поддержка любых кодировок, включая Unicode; автозавершение слов; списки to-do, автоматически генерируемые из комментариев в тексте; группировка файлов в проекты; редактор тем, с возможностью сохранения цветовых схем; встроенный web-preview; синтаксическая подсветка для какого угодно синтаксиса; интеграция с системами контроля ревизий через TortoiseSVN и TortoiseCVS.

Пакеты

Теперь, самое интересное.

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

В E дела со сниппетами обстоят иначе. На первый взгляд, меню Bundles, в котором они собраны, действительно удручает своей перегруженностью. Тем не менее, его содержимое организовано весьма разумно.

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

Например, автозавершение слов и синтаксических конструкций, комментирование или раскомментирование выделенного фрагмента, выполнение скрипта (или только текущей строки) интерпретатором, визуальный выбор цвета (очень удобно для вставки HEX-кодов в CSS), алфавитная сортировка строк. Я привел только несколько примеров для иллюстрации разброса возможных операций; перечислять все бессмысленно, т.к. их несколько сотен.

Интересным моментом является то, что горячие клавиши для идентичных по смыслу команд из разных пакетов часто совпадают, а их выбор происходит автоматически, в зависимости от активной синтаксической схемы. Так Ctrl-R запускает скрипт, вне зависимости, на Python он написан или на Perl. Благодаря этому, придется запоминать меньше сочетаний клавиш и реже ковыряться в меню мышью.

Как уже было сказано, набор пакетов можно расширять теми, что уже разработаны для TextMate. Их можно найти в SVN-репозитории на официальном сайте проекта. На время написания этого текста, там находится 153 пакета с самой разной специализацией. Есть, например, bundle для работы со списками задач в стиле GTD.

Некоторые минусы

Чтобы сделать этот обзор более полным, перечислю так же некоторые отрицательные детали.

• Сразу после установки, E ставит перед фактом собственной необходимости в cygwin и автоматически скачивает целый ворох пакетов (включая довольно тяжелые Perl, Python и Ruby). Все вместе они занимают порядка 30-40 Mb. Было бы разумно иметь возможность скачивать все сразу, в виде одного файла. Иначе полноценная установка становится зависимой от наличия доступа в интернет.
• Процесс загрузки бандлов занимает несколько секунд после старта программы. Все реализовано довольно грамотно (начинать работать с текстом можно не дожидаясь окончания загрузки), но от текстового редактора все же обычно ждешь большей прыти. Все-таки, не Фотошоп.

В сущности, недостатки незначительны и простительны.

Да, чуть не забыл. $34.95.

Ссылки по теме

• Официальный сайт E и прямая ссылка на триальную версию.
• Вики с документацией.
• Скринкаст, дающий представление о работе с регулярными выражениями в E.
• Сайт TextMate и библиотека его расширений.
• Статья про E в Википедии.

Alt-Tab — Самая популярная комбинация клавиш для переключения задач, перешедшая еще из Windows 3.1. Однократное нажатие активизирует окно, которое было открыто до текущего. Многократное нажатие выполниет перелистывание нескольких окон сразу, при чем порядо следования окон динамически меняется, в соответствии с предыдущим правилом. Последовательность однократных нажатий Alt-Tab будет просто циклически переключать два окна, в не зависимости от того, сколько всего их открыто.

Учитывая, что это самый распространенный способ переключения, можно предположить, что многим он нравится. Мне всегда казался странным. Когда окон становится открыто более 2, и переключение между ними необходимо выполнять относительно редко, бывает сложно держать в памяти их последовательность. Соответственно, быстрые нажатия Alt-Tab (когда не всматриваешься в окно task switcher) приводят к непредсказуемому результату.

Alt-Shift-Tab — не очень удобная (для пальцев) комбинация клавиш, аналогичная предыдущей, но с инвертированной последовательностью переключения. Иногда ее использование может уменьшить количество повторных нажатий Tab для открытия нужного приложения.

Alt-Esc — альтернативный способ, работающий немного более предсказуемо, чем Alt-Tab. При нажатии список задач не открывается, а сразу происходит перелистывание окон в аналогичном порядке. В отличии от Alt-Tab, зацикливания не происходит. И последовательностью однократных нажатий Alt-Esc можно пролистать весь список окон.

Если окон открыто много, способ оказывается тоже далеким от совершенства: вызывает много лишнего «движения» перед глазами.

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

Понимаю, что слово «иногда» звучит очень странно, когда речь заходит об описании функционирования UI. Но бывают ситуации, когда некоторые механизмы в Windows действуют по совсем неочевидному регламенту и за внешними проявлениями не всегда видны общие правила, которым они подчиняются.

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

Номера окон должны быть достаточно крупными и контрастными, чтобы их не приходилось искать глазами. Простое добавление цифры в заголовок (тем же шрифтом) не подоёдет. Возможны так же вариации на тему speed dial.

При написании этого поста, я случайно наткнулся на историю появления первого переключателя между задачами, — программе Switcher, изложенную ее автором — Энди Харцфельдом. Было довольно любопытно почитать его рассказ о том, как эта функция попала в Windows и OS X (это был 1984 год). Вот, кстати, благодарственное письмо Гейтса разработчику:

(клик ту энлардж)

Ссылки по теме

• Alt-Tab — большая статья на Wikipedia про то, «откуда езмь пошел Alt-Tab».
• Andy Hertzfeld himself on how the Switcher idea was born and nearly ended up in the hands of Bill Gates @ Folklore.org.

Существует несколько типовых способов переключения фокуса:

• С помощью мыши (тачпада или иного подобного графического манипулятора) можно выбирать активные элементы ввода в произвольном порядке.
• С помощью клавиатуры:
  • Последовательным переходом между элементами в прямом или обратном порядке (обычно для этого используются Tab и Shift-Tab соответственно).
  • В произвольном порядке, с помощью горячих клавиш (при наличии таковых).

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

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

Такое простейшее действие, как сохранение файла, гораздо естесственнее и логичнее выполнять нажатием Ctrl-S, чем с помощью мыши. В последнем случае приходится отрывать руку от клавиатуры, находить взглядом кнопку «Save», целиться в нее курсором (так, чтобы случайно не нажать на находящуюся рядом «Print»), после чего возвращаться к клавиатуре. Множество лишних действий.

Типовой ошибкой в построении интерфейсов является неэффективное определение последовательности переключения между его элементами. Зачастую эта последовательность не соответствует естесственному человеческому представлению о порядке следования элементов множества (чаще всего — слева направо и сверху вниз). В результате, серия нажатий Tab приводит к бессистемным «прыжкам» фокуса по окну в непредсказуемом порядке.

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

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

Пример из жизни: в форме отправки сообщений одного веб-приложения, для клавиатурного переключения из строки «Тема» в основное поле ввода текста, было необходимо 6 раз нажать клавишу Tab. Дело в том, что фокус считал своей обязанностью предварительно «пробежать» весь ряд кнопок на панели инструментов.

Еще одной важной деталью, которой следует уделить должное внимание при проектировании интерфейсов, является автоматический выбор фокуса ввода. В некоторых случаях, определение активного элемента становится настолько очевидным, что отсутствие автопереключения на него можно расценивать как ошибку. Так, при отображении модальных диалоговых окон, обязательным является фокусировка на кнопке Ok (или Cancel — в зависимости от ситуации), чтобы одним нажатием клавиши можно было подтвердить или отменить действие.

С другой стороны, неусместное переключение фокуса системой обычно крайне нежелательно и часто вызывает раздражение. Пример тому — привычка некоторых программ предлагать обновление с помощью того же модального окна, самопроизвольно выскакивающего посреди работы.

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

Ссылки по теме

• Влад В. Головач. Интерфейсы для мастеров.
• Focus @ Wikipedia

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

Учитывая, что каждый отдельный торрент воспринимается клиентом как единый массив данных, приходится довольствоваться ограниченными возможностями управления процессом закачки — расстановкой приоритетов. Получается примерно так:

(на скриншоте — список файлов в клиенте uTorrent)

Возникает естесственный вопрос: а почему бы не автоматизировать процесс расстановки приоритетов, форсировав тем самым соблюдение последовательности выкачивания файлов?

Такая опциональная возможность могла бы оказаться очень полезной в том же uTorrent. Интерфейсное решение выглядело бы примерно так: при добавлении нового торрента, упорядочиваем список его файлов, в соответствии с нашими потребностями (сортировкой по колонкам таблицы или drag’n'drop-ом элементов списка с возможностью выделения групп файлов); ставим в нужном месте галку «Sequential download» и ждем файлы, которые теперь будут появляться в заданном, а не случайном порядке.

В принципе, такой подход содержит в себе одну негативную деталь. На раннем этапе раздачи контента он будет в какой-то мере снижать эффективность распространения контента между пирами. И, как следствие, снижать скорость появления сидов в сварме (прости, Русский язык). Т.е. последовательный метод закачки довольно эгоистичен, что предполагает необходимость контролировать появление слишком «жадных» пиров на стороне трекера. Впрочем, это уже и так везде реализовано, а каких-то дополнительных изменений, специфичных в условиях автоматической расстановки приоритетов на клиентах, понадобиться не должно.

Такая идея.

Из-за такой узкой специализации, функциональность предыдущей версии меня полностью устраивала, но новый релиз все равно вызвал интерес. Было любопытно, за что именно в RitLabs так щедро увеличили номер версии.

Действительность оказалось довольно прозаичной: мажорный номер версии увеличили, видимо, от того, что закончились дробные номера (предыдущая была 3.99). Ну или тем, что хотелось денег за апгрейд лицензии (это предположение). Надо сказать, выходу 2.0 и 3.0 тоже не сопутствовали какие-то революционные изменения. Функциональность расширялась довольно плавно, хотя еще со второй версии ходили неясные слухи о гипотетической поддержке NNTP в грядущем релизе.

NNTP, кстати, нет до сих пор, но с моей точки зрения это и не важно. Если быть честным, от новой «большой» версии я ожидал только одного: лучшей проработки интерфейса. В принципе, в The Bat! и раньше было все вполне прилично с UI, но оставалось множество деталей, требующей косметической доработки напильником. Где-то поправить отступы, а где-то — разрядить слишком «кучно» расположенные элементы интерфейса. Интерфейс действительно не оставили без внимания, но… Ниже приведу несколько иллюстраций того, что с ним сделали.

Первое, что бросается в глаза — область главного окна в районе заголовка письма:

Во-первых, аляповатые табы из предыдущей версии так и остались неизмененными. Сочетание «плосских» элементов интерфейса (с однопиксельной обводкой) с псевдо-трехмерными, по всей видимости, не вызывает у разработчиков ощущения диссонанса. А на мой взгляд, упомянутые выше табы выглядят глубоко-подавленными над нависающим «объемным» скроллбаром.

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

Дальше.

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

В редакторе писем опять этот нелепый цвет и градиенты.

Складывается такое впечатление, что у них кто-то из менеджмента, посоветовавшись с женой, решил, что «вот в этом окошечке не хватает синенького». Лучше бы починили отступы у названий полей (снизу каждой надписи они должны быть меньше, а слева — больше).

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

Разница в том, что здесь все картинки видны сразу. Многие повторяются по 2-3 раза. Зачем? Кроме того, 42 — это, конечно, глубокая шутка, но отсутствие однородности стиля пиктограмм удешевляет общее впечатление от продукта. Создается впечатление, что на этапе бета-тестирования кто-то напихал в таблицу бесплатных картинок, найденных в интернете (не тех, которые надо, а таких, которые были), а потом так и забыл. Или забил.

Короче говоря, ждем исправлений. А пока откатываемся обратно на честно купленную за казенные деньги третью версию. 32$ (полная цена — 45$, со скидкой 30%) за апгрейд? Ага.

Update: Еще одна деталь. После установки четвертой версии, у меня в системе каким-то образом завелся «Персональный поиск Яндекса», гордо заявив о себе большой и красной буквой «Я» из трея. Пока не понял, шел ли он в комплекте с Батом, но, если так, то это по крайней мере хамство — ставить такой сервис, не спросив разрешения.

Ссылки по теме

• Краткий список нововведений
• Пресс-релиз
• Концепт нового интерфейса The Bat от Артема Горбунова