Бурленье началось...

По ссылке пост на КЫВТ про особенности локализации декстопных приложений. Рекомендую-с.

От себя. Действительно почитайте. Все что там описано, я прочувствовал на собственной шкуре причем глубоко подкожными нервными центрами. И нимало новых матерных слов выдумал, пока решал проблемы. Зачем наступать на собственные грабли, если можно почитать про чужие?

Второе. Некоторые решения там спорны, но автор поста выбрал то-то или то-то решение. Ну например UTF8, мол как его рисовать в программе? От себя - решаемо. Причем легко и непринужденно. Или инициализация сразу всего языка. Опять же спорно, но решаемо с тем же результатом, но чуть иначе. Или навскидку: текст об окончании триала на не том языке. Решаемо! Легко! Но не автоматизируемо, к сожалению.

Дело тут совершенно в другом. У автора поста на КЫВТ были свои резоны выбирать то или то решение. Спорить зачем? Разные резоны, разные подходы, разные точки зрения.

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

PS: на Alconost слишком сильно не ведитесь, робяты... Они вам про плюсы в комментах то расписали, а вот про минусы умолчали. А геморроев в их подходе хватает причем с избытком. Причем не виню я их. Их система для них, а не для нас. Соответственно и плюсы\минусы там под их аудиторию.

PPS: к слову, именно примерно похожая система локализации у меня применяется в Aml Maple и TwinkiePaste. Что характерно, число языков растет как на дрожжах не по дням, а по часам. Alconost ау-у :).
Правда, в TwinkiePaste, как в значительно более поздней разработке система куда как круче и несколько дружественнее нашему брату программеру. С поддержкой генераций полных языковых файлов, обновления старых новыми строками, с аналитикой изменений, поддержкой разных библиотек (pure C++, MFC, WTL), локализацией диалогов, меню, строк - чего угодно. Ну что ж вы хотите. Опыт то накапливается.

Юзабилити. Разделитель в меню

Сегодня про маленький авторский фокус в юзабилити. В частности в меню.

Разделители в меню архиважная вещь. Они помогают группировать команды в визуальные группы. Давно известный факт, что человеческий глаз более-менее хорошо ориентируется, когда в группе от 3-ёх до 7-ми элементов. Если больше, то визуальная навигация будет затруднена. Взгляните на старый GIMP, без разделителей в меню. Это же просто ужас.

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

Пример: меню из TwinkiePaste справа на скриншоте. Разделитель меню показывает число элементов в истории буфера обмена (там цифр больше, но это уже особенности твинкипасты, не имеющие отношения к вопросу).

По-моему неплохо получилось!?! Изначально я этот прием придумал и использовал в Aml Pages. Там команды плагинов, которые встраивались в контекстные меню, как раз отделялись разделителем с надписью "Плагины". Прижилось.

Потом это уже было применено в Aml Assist. Там и вовсе распрекрасно пошло. В меню Ассиста есть группы однотипных команд "Вроде открыть как" (не важно что именно "как", ну например только для чтения), или же "Показать так-то". Эти группы команд однотипны по своей сути. Они выполняют одно и то же действие, но над разными объектами.

Разделитель с надписью выручил на ура. Вместо того, чтобы в каждой команде меню писать "Сделать то-то [название объекта]" был прилеплен разделитель с надписью "Сделать то-то", а ниже уже команды меню с названиями объектов. Шикарно получилось. Вместо однотипных заголовков "Сделать то-то XXX" получили наглядную группу команд меню. Причем сами команды в группе содержат только названия объектов. С одной стороны: для новичков понятное действие в надписи в разделителе. С другой стороны для привычных пользователей, которые знают и пользуются этим действием, группа команд содержат только названия объектов. Позволяя им сосредоточиться, с чем именно будет выполнено привычное для них действие.

Вот такой вот фокус был придуман в последние месяцы. Причем настолько удачный, что благополучно начала растекаться по соседним проектам. Улучшения в массы!

Дизайн иконок или не стоит так делать

Давненько, я ничего сюда не писал, всё бухал работал, дачи, лето – все дела. Ну пора чего-нить и черкнуть. Сегодня еще разок про иконки.  Ниже скриншот как выглядят иконки панели инструментов The Bat.

Это ж ахиреть просто можно. Каждая кнопка отвечает за свои действия. А тем не менее выглядят они практически одинаково. Сплошные емейлики с дополнительной миниатюрой вроде стрелок, перьев и прочия. Это приводит к тому, что все иконки попросту сливаются, и визуально очень мало отличаются. Зачем? Ну зачем везде рисовать почтовый конвертик? Ну понятно, что The Bat это почтовый клиент. Ну ясен пень что “отправка” это отправка письма, и приемка это тоже приемка писем… Ведь ясно как божий день, что отправка ни чемодана в аэропорт, и ни приемка экзаменов. Письма, письма, и только письма. Главная идиома – это действие с письмом. С какого же хера главное (действие) показано мелко, а второстепенное и очевидное (предмет, письмо то есть) – показано крупно.

Все напрочь сливается, пользоваться нереально. Сколько лет пользуюсь The Bat`ом, а не могу привыкнуть!!! Важное на такой иконке – должно выделяться максимально: цветом и размером.

А теперь фокус-покус. Уменьшим глубину цвета скриншота до 16 бит. Смотрите что получилось.

Ну и как отличаются чем-то иконки друг от друга? А нихера! Это кстати элементарнейший тест на восприятие: уменьшить цветность и посмотреть сливаются в одно или нет. Даже фотошопить для таких тестов не обязательно. Достаточно просто чуть отодвинуться от экрана и прищурить глаза, и посмотреть. Эффект будет близким.

Никогда так не делайте!

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

2012… Год тихой смерти?

На картинке слева отображена история моих заказов на Озоне… Славный путь, не правда, ли? Только где это я был с 2006-го по 2012-ый?!?

А был я в Books.ru. Как-то случилось, что в далеком 2006-ом мне пришлось заказать книгу именно на books.ru. Уж не помню почему, но какие-то геморройки вышли с Озоном. Ну пришлось, и пришлось. Суть не в этом. В Books.ru я влюбился с первого взгляда. Мне катило абсолютно всё: отличнейший рубрикатор по книгам, возможность полистать книжку перед покупкой, явно “живые” отзывы, гутно работающая служба доставки и много чего другого. Чего только стоила новостная рассылка, это просто слов нет. Можно подписаться не просто на книги, не просто по разделам “детективы”, “про баб-с” и “профессиональная литература” – а выбрать более чем конкретизированные разделы в computer science: что-то вроде “операционные системы” и “языки программирования”, а вот самоучители по Ворду нафиг. Удобно не правда, ли?

Но недавно books.ru учинили редизайн сайта. Много чего работало криво, многое и не работало. Ну да ладно, один переезд стоит трех пожаров. Дело-то житейское. И баг-репорты админам писал, и мнения высказывал, в общем помогал любимому магазину как мог.

Но отчасти воз и поныне там. Товар есть – кнопка “В корзину”. Товара нет – картинка “Нет в продаже”. Где нафиг блин епрст полгода прошло кнопка “Сообщить о поступлении” рядом с товаром?  Ведь раньше на старом сайте была же? Так сложно сделать? Робяты! Books.ru! Вы теряете не просто клиентов, вы начинаете терять уже фан-клуб, а это о чем-то да говорит. Ну прям хоть сам иди прикручивай кнопку к вам на сайт. Верните кнопку, черти!!! Нужна помощь? Нивапрос ©! Все что в силах: код, UX-тестирование, UC-анализ. Просто так. Из симпатии к вам.

PS: а попробуйте угадать, откуда на Озоне появился вдруг заказ в 2012-ом? Ага. Точно, вот у них кнопка “Сообщить о поступлении” была. Они  и сообщили. Поэтому заказ и у них же, а не у books.ru. И это при том, что я с-о-о-овсем, мягко говоря, не в восторге от Озона. Ибо где француз прошел, цыг… всем остальным делать нечего!

Юзабилити. Про трей

Эх, давненько я не брал в руки шашки… Но лучше поздно, чем в штаны!

Напишу-ка я про не очень-то очевидную фичу в работе с треем. Для закваски пронзительная история, она же быль. Повадился у меня последнее время падать Проводник Windows. Падает как заведенный, впрочем при определенных обстоятельствах, но ни о них речь. Проводник после креша  сам перезапускается, но по ходу его перезапуска некоторые софтины в трее не восстанавливаются. Если с каким-нить TypeAndRun это пофиг — убил, и запустил заново, то софт с пользовательскими данными убивать через менеджер процессов уже не хочется. "Че-то я ачкую…" ©. Скажем, к примеру, рухнувшая база данных какого-нибудь The Bat может весьма и весьма попортить крови.

Способов решения проблем с упавшим Проводником, и как следствие, пересоздающейся на лету панели задач есть. Как вариант, ловить сообщение TaskBarCreated и восстанавливаться в трее, есть и другие.
Но есть способ элегантнее, надежнее, а главное комфортнее для пользователя. Приложение, свернутое в трей показывается в списке окон по Alt+Tab.

Это решение зарекомендовало себя просто великолепно.

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

Как показал опыт, для приложений оперирующих пользовательскими данными, возможность подняться из трея с помощью клавиатуры почти обязательна для реализации. Сделал такое в Aml Pages. И ох сколько раз оно меня выручало. Нет слов! Про удобство молчу — у меня самого мышь все больше "для комплекту".

PS: кода вставки в список Alt+tab пока не дам. Потому как  жмот я. Потому как, пока доводил до ума добавление окон в список Alt+Tab, такой херни наворотил, что сам уже с превеликой тоской зрю в свой код. Ревьюить его, ревьюить и еще раз ревьюить.

Если в двух словах. Для окон верхнего уровня задача решается элементарно: нужно при прятке окна создать для него дочернее WS_OVERLAPPED-окошко, и задвинуть его за края экрана. А по активизации последнего из Alt+Tab-списка уже поднять из трея основное скрытое окно.

Но заморочки начинаются, когда необходимо добавить в Alt+Tab тул-окно (окно со стилем WS_EX_TOOLWINDOW).Вот пока реализовывал эту возможность и наворотил говно-коду. Теперь сначала причесать код нужно, а уж только потом "в народ". Так что сорсы как-нибудь позже. А уж если кому невмоготу да срочно — стучите в комменты.

Usability. Совет дня – продолжение.

С пару месяцев назад писал про голосование на RSDN на тему использования “читаете ли вы совет дня”. Если в двух словах, то результаты получились неутешительные. Не читаем! Хм, и странно было бы ожидать чего-то другого. В конце того самого поста я обещал рассказать, как я решил эту проблему. Лениво, конечно, ибо когда сам уже разобрался, то трепаться становиться неинтересно. Но надо раздавать долги. Попробую, но раз лениво, то несколько в декларативном стиле.

Сначала расскажу почему.
Никаких советов дня при запуске. Раз пользователь запускает приложение, то у него явно есть какая-то цель, ежеминутная задача. Он попросту не будет читать никаких поучений. В народе это называется проще: “не пизди под руку”.

Никакой модальности. Зачем кнопка ОК? Она что-то делает? Пусть совет дня показывается где-то сбоку припеку. Не требуя от пользователя никаких действий. Совет это же всего лишь рекомендация. Вы же не удивляетесь отсутствию кнопки ОК на объявлении на двери подъезда?

Теперь как сделано в Aml Pages. Скриншот собственно ниже.

Отдельная панель: Итак, в Aml Pages я сделал совет дня в виде отдельной панели, a la строки состояния. Такая статусбарного вида панель привычна для пользователя и не требует от него никаких действий, не отвлекает его от работы.

Панель совета  внизу окна: т.к. совет дня информация сугубо вспомогательная, то располагаться она должна все-таки внизу. Все в правилах information flow: главное – слева вверху, второстепенное – внизу и справа. А читаем мы в таком порядке…

Навигация в панели: все-таки некоторыми интерактивными возможностями панель советов должна обладать. Какой-нибудь несложной кнопкой “следующий совет”. Главное никакой модальности. Интересно пользователю? Кликнет. Нет, так нет.

Узнать больше: неплохой идеей оказалось сделать возможность перейти к расширенной информации по тематике конкретного совета, к большей статье, документации или еще чему-то подобному. Никаких велосипедов. Советы дня, имеющую такую связанную тему, показываются как гиперссылка на тему. Надо – кликнут. Плюс во всплывающей подсказке пояснительная информация, что за ссылка и куда. В Aml Pages это ссылки на статьи на сайте. Заметьте господа, это даже не “реклама” в дурном смысле – это то самое, ненавязчивое предложение для пользователя.

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

Ну, примерно вот так вот. А напоследок один забавный момент. Как я пришел к тому, что панель советов должна быть внизу, и почему в первой версии все-таки панель советов была вверху окна. Однажды, я с грустью заметил и-э-эх, и сколько же пространства у меня пропадает на пустом месте справа от тулбара вверху окна :(. А не херакнуть ли туда какую-нибудь вспомогательно-справочную инфу? С этого и понеслось, и  в конце концов, начав с обычной прорисовки текста прямо на окне, выросло до идеи отдельной панели. Но все-таки вверху окна приложения, с этого ведь все и началось.

Но потом, несколько пользователей обмолвились, что все-таки отключают панель советов. И это навело на мысли.

• Вверху главного окна расположены панели инструментов. Места там и так немного, поэтому если его не хватает, то под нож идут все вспомогательные моменты. Панель советов, естественно, срубали первой.
• Не стоит мешать информационную часть и инструментальную. Там где инструменты (тулбары), пользователь мышью частенько работает практически на автомате: мышь туды-сюды, клик и готово. В этот момент пользователь в активной фазе работы – он просто не будет читать всякие дурацкие советы, какие-бы замечательные они не были. У него в этот момент свои и причем совершенно другие заботы. А вот когда он решит отдохнуть, и глаза его устало опустятся… А тут, ух-ты, йопты, инфа. Может быть и заинтересует.

Вот таким вот макаром панель советов дня и переехала вниз главного окна приложения. К слову говоря, больше отключения панели советов не наблюдалось. По какому только поводу пользователи не слали мне скриншоты (баги там, проблемы всякие) – у всех панель советов дня была включена. Сработало, однако :)

Всё, уф! Обещал рассказать про советы дня – сделал. Долги кажись раздал… Ну и понятное дело, идею можно развивать, дотачивать, но все это уже будет на 100 и еще 100 процентов зависеть уже от конкретных задач в конкретном приложении.

Technorati Теги: Совет дня

Пользовательский интерфейс: виртуальный ListView

Об актуальном. Как-то последнее время начинаю все с большей и большей теплотой относиться к виртуальному режиму списка (ListView). Ощущение полного контроля над списком: что, как и когда он отображает – настолько впечатляет, настолько завораживает, что нет слов. Действительно, код поначалу приходится сильно доводить, продумывать, вникать в детали. Но это только поначалу. Зато потом, возникает устойчивое чувство, что все работает как надо, что код “сверкает всеми гранями и бесконечно совершенен в своей продуманности, последовательности, и определенности”.

А по сути-то, в виртуальном списке всего лишь выполняется старинный программерский завет, она же отчасти первая нормальная форма: “данные должны быть определены единожды и однозначно”. Если задаются какие-то значения, то только в одном единственном месте. Какие данные есть в бизнес-слое приложения, те в ListView и отображаются. А не извечный геморрой: что в конкретный момент времени в ListView де-факто, а что в модели, и в какой момент времени данные должны обновляться в пользовательском интерфейсе, и кем это обновление инициируется...

А уж вкупе с механизмом CustomDraw и вовсе наступает окончательный дзэн. Эмулировать из виртуального ListView дерево-подобный элемент управления, с ветками, и прочей дребеденью, но в довесок со всеми преимуществами списка и вовсе становится элементарно. В общем, буду краток (ц) – прёт!

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

Technorati Теги: virtual ListView

Светофорные иконки

Сегодня немного об иконках. А точнее о главных иконках приложений. Вот посмотрите на скриншот панели быстрого запуска.

Правая группа иконок смешалась практически в неразличимую массу, причем даже не спасают никакие различия в дизайне: круглая ли, квадратная, восьмеркой или простыней. А между прочим это иконки в панели быстрого запуска, которая по замыслу должна максимально ускорять запуск приложений. Ан нет! Каждый раз пользователю придется выискивать нужный ярлык глазами, всматриваясь в детали.

Насколько в лучшую сторону отличаются иконки слева: Total Commander, любимая 6-ая студия, ну и моя же Aml Pages? Справедливости ради, стоит заметить, что с AP это так вышло, я не специально – так “фишка легла”.

Причем эту картину в панели запуска я наблюдаю каждый день, и каждый раз ломаю глаза, когда нужно что-то стартовать из этой компании. Никогда не задумывался о главной иконке приложения именно в таком контексте… Воистину, настоящий дизайн использует минимум цветов и оттенков. Причем все они образуют единый стиль, а не елку новогоднюю. Вот вам батенька и студии дизайна. Модняво, красиво, но не функционально!

PS: Это еще что! А вот когда все это сообщество работает, а оно ух как часто работает одновременно, то в списке переключаемых окон, показываемому по Alt+Tab, приходится совсем туго с этим разрисованным семейством. А ведь поди всё бренды… бренды… бренды. Проще надо быть, прощее :)

Usability : Совет дня

Учинил на RSDN голосование “Читаете ли вы диалог "Совет дня" при запуске при запуске приложения”. Результаты вполне репрезентативны – проголосовало уже 132 участника. И вот какая картинка получилась.

Нет, не читаю	36%
Читаю пару раз, потом выключаю “показывать в дальнейшем”	23%
Закрываю этот диалог “на автомате”	22%
Читаю всегда	0% (ноль)
Читаю иногда, не отключаю	6%
Читаю полностью первый раз, потом отключаю	5%
Читаю очень редко	1.5%
Если есть кнопка следующий, читаю все - потом отключаю	1.5%

Результаты  я немного округлил. И выкинул некоторые мало интересные, на мой, взгляд, ответы вроде “Я не знаю что такое совет дня” (ответ не в тему, но “слив засчитан” – ибо сам по себе интересен). Но посмотреть точные результаты можно по ссылке выше.

Вот такая вот интересная картина сложилась.  81 (восемьдесят один!!!) процент, условно говоря, вообще не смотрит на диалог совета дня. Или не читает, или пару раз (пока не достал), или закрывает на автомате. Впечатляет, не правда ли? Ходишь в школу, ходишь – бац, вторая смена ©! Как не геморройся с советами дня подавляющее большинство их попросту не читает. Но в любом случае, их никто не читает постоянно. А между тем, подобные советы могут содержать весьма полезную для пользователя инфу, и обучать его ненавязчиво, постепенно показывая ему “рюшечки” в приложении.

А ведь этот пресловутый совет дня должен помогать пользователю, давать ему указания, подсказки. Ан фиг! А почему? Да потому что, не советчик это вовсе, и не заботливый провожатый по приложению – а абсолютно наглый, безмозглый, и совершенно несвоевременный указчик, что делать пользователю да эдак. А пользователь всегда лучше знает, что ему нужно. Обычно затруднения возникают не в цели, а в способах достижения этой цели.

Элементарно, Ватсон. Приложение стартует, и вероятно не само по себе, а по воле пользователя. Разумно предположить, что у пользователя есть свои собственные цели, причем есть прямо сейчас, сию секунду раз уж приложение стартует. А тут на тебе, наставник появился. Да еще и на отвлеченные темы поруководить решился. Совет при запуске не способен угадать цель пользователя, поэтому в 100 из 100 случаев его советы в момент запуска и вовсе не ту степь.

А тем не менее совет дня может быть более чем полезным помощником. Но для этого придется выполнить некоторые условия. Он должен быть ненавязчивым – т.е. не висеть модальным диалогом при запуске, мешая пользователю достичь его сиюсекундной цели. Иначе это не “помощник”, это уже “назойливая поучалка”. Совет должен быть в тему: т.е. быть близким к тематике задачи пользователя – иначе опять не “советчик“, а раздражающий “гуру” на отвлеченные темы. И наконец, совет дня не должен бросаться в глаза, концентрировать внимание пользователя на себе. Это же все таки совет – он не должен отвлекать, он должен помогать.

А бывает ли такое? Ну конечно же, посмотрите на любой солидный веб сайт, к примеру тот же Facebook. Советы расположены рядом с элементами, к которым они и относятся – т.е. ходить далеко за ними нет нужды. Эти подсказки, как правило, сделаны неброским шрифтом. Они не забирают внимание пользователя на себя. Найдется время у пользователя? ОК, прочтет. Нет, так нет – советы ничем и не мешают. И никакой Вам навязчивости, никто не требует закрывать модальное диалоговое окно при входе на сайт!

Немного аж завидно становится обычному советскому десктопному разработчику всем этим веб-два-нольным примочкам. А разве нельзя сделать такое же в десктопе? Варум нихт? Я вот сделал в Aml Pages. А как именно, и главное к каким решениям, почему и как пришел, расскажу в продолжении.

UPDATE: обещанное продолжение здесь

Pro-чтиво: Об интерфейсе

Сегодня еще разок о профессиональном чтиве. Дочитал “Об интерфейсе” (About Face) Алана Купера. Что сказать? Читал сей манускрипт далеко ни один месяц, все-таки под 700 страниц томик. Впечатления остались весьма двойственные…

С одной стороны, одно слово – эпохальная вещь! Все-таки Купер это гуру юзабилити и UX-дизайна. Чего только стоят его принципы проектирования взаимодействия. Как обычно: всё гениальное просто. Вот только некоторые из них, особо импонирующие:

• Считайте пользователей людьми очень умными, но очень занятыми и Пользователи не понимают булевы алгебру. В точку: когда я убрал булеву формальность в фильтрах Aml Pages, все вопросы пользователей исчезли. Пофиг, что с формальной точки зрения раздел документа не подпадает под условия фильтра (считай, запроса) – раз пользователю надо увидеть раздел, значит надо! Ни к чему заставлять отменять или изменять фильтр. Юзеру точно виднее, что ему нужно.
• Избегайте чистого листа. Как только в Aml Pages появились категории страниц по умолчанию, все вопросы по их использованию тут же улетучились сами собой. Редактор категорий есть, да и раньше был. Но как только появились умолчательные примеры категорий – вопросы по ним отпали в принципе.
• Прячьте рычаги катапультирования. И не уговаривайте меня, нет и не будет в Aml Pages команды “удалить все”.
• Пользователи готовы прикладывать усилия соразмерно результату. Действительно готовы. Но только вот не стоит их заставлять достигать результата сразу. Лучше оставлять пользователю возможности для принятия решения, для “маневру” до последнего момента.
• Компьютер работает, а пользователь думает. Вот-вот, робяты! Это по закону Мура производительность процессоров удваивается каждые два года. А производительность пользователя нет! Ну так хотя бы не мешайте ему. Пусть думает, пусть размышляет – этого никакой софт за него не сделает никогда.
• Никогда не подгоняйте интерфейс под метафору. Сколько не прикручивал пружинный, стилизованный под бумажные аналоги, разделитель панелей в Aml Pages – все равно он торчал как в одном месте заноза. Снёс!
• Удаляйте элементы, пока продукт не сломается, а затем верните последний удаленный элемент на место. В яблочко! “Совершенство, это когда не нечего добавить. Совершенство, это когда нечего убрать” (© Антуан де Сент-Экзюпери). Много раз сталкивался с тем, что из продукта что-то пора и выкинуть. Итеративный такой процесс получается. Сначала фичи накапливаются, потом переосмысливаются, а со временем некоторые и канут в воду. Резать, однозначно резать – причем не дожидаясь перитонита.
• В ошибках может и не быть вашей вины, но вы несете за них ответственность. Да здрям автоматический бекап и автосохранение. Сколько нервов они сберегли моим пользователям, а мне времени, потраченного на поддержку.
• Диалоговое окно – это еще одна комната, не ходите в комнату без веской причины. Без разговоров! Все что имеет смысл делать не модальным, просто необходимо так и делать. Модальные диалоги нужны только для группировки сходных функций.
• Не создавайте многострочные вкладки. Вот дернул меня черт за руку, сделать в Aml Pages режим многострочных вкладок, славу богу хоть не по умолчанию. Теперь вот теперь кручу попой изворачиваюсь в общении с пользователями, как бы это убожество в новой версии незаметно убрать. (этот блог читают и пользователи: я ж не спроста хочу убрать. Убрать надо для другого, значительно более удобного решения…).

В общем, что сказать… Книга действительно серьезная, must have однозначно. Но вот с другой стороны, ну такое количество в ней воды, что таки пару раз она мне обеспечила здоровый и быстро наступивший сон. Очень много про то, как “не надо”. А вот изложения как у Дженифер Тидвелл, “как надо” все-таки маловато. Примеры есть, но они не разобраны методично. По стилю изложения About Face немного напоминает легендарную “Психбольницу в руках пациента”. Но! Для такого в стиле “манифеста” 700 страниц имхо все-таки многовато – либо уж кратче, либо методичнее. Хотелось бы больше конкретики, причем с разбором, а не просто примеров из жизни – 700 страниц примеров все-таки требуют хоть какой-то каталогизации.

Но все равно не жалею о времени, потраченном на эту книгу. Чувствуется перо мастера – там такая концовка, такое послесловие, что отрицательные эмоции сильно поутихли. Das ist, проще говоря.

PS: все ссылки как-то сами собой получились именно на фичи моей Aml Pages, а не Aml Maple. Но Aml Pages приложение значительно более богатое фичами, чем “Мапля”. Более того, оно как раз и есть то самое “монопольное приложение”, в отличие от Мапли. На тему разницы между монопольными и временными приложениями у Купера тоже весьма толково и аргументировано расписано.

Technorati Теги: Алан Купер,Пользовательский Интерфейс,Книги

Кто Вы?

Случайно набрел на любопытный психологический тест: Какое оружие Вам подходит? И вот что получил - на тебе:

Вы мыслитель

Вы много думаете и не редкость для вас это уход в собственные мысли настолько глубоко, что можете забыть о том, кто вы есть на самом деле. Ваш интеллект превышает нормы. Вам тяжело найти собеседника, но вы легко можете найти друга. Вы не очень любите лишние движения, за что вас многие считают лентяем. Вы любите рассуждать и учить, но сами вы не очень-то готовы действовать. Любите вкусно поесть удобно на мягком полежать да поразглагольствовать. Романтика в вас присутствует, как и жалость, но все это лишь небольшие дополнения к вам как к личности с незаурядным мышлением. Поэтому, если такой человек, как вы решит убить, то правоохранительные органы вас никогда не заподозрят, да и улик вы не оставите вовсе. По этому ваше лучшее оружие это - Steyr AUG, автомат (штурмовая винтовка), калибр 5.56 NATO, Австрия

Пройти тест

 

Фига-се! Читал и призадумывался, читал и размышлял. Потом посмотрел внимательно на заголовок, и успокоился. Все верно – призадуматься должон был :). Кстати, отдельное спасибо Павлу Малинникову за ссылку на тест.

Наконец-то надумал (наразмышлял :) приделать к Aml Pages поддержку скинов. Уж больно много вопросов вызывает внешний вид моей софтины – на вкус и на цвет товарищей нет. Кому подавай стандартную цветовую схему, кому подавай в стиле Outlook. На всех не угодишь. Тем более, что уже давным-давно есть плагин для быстрого выбора цветовых схем – Aml Colorer. Но со скинами все основательно усложняется: появляются всякие фоновые рисунки, по уму надо чтобы скин распространялся единым файлом, чтобы корректно работал с портабельной версией. В общем, работы по анализу требований и проектированию хоть пруд пруди, и ведь все равно с первого раза обкакаемся идеально не получится.

Но с другой стороны, чем не развлекуха? Разработческое ремесло во многом и сводится к знаменитой фразе: “а ручки-то вот они”. Только для этого нужно сначала грамотно поразмышлять, помыслить толково надо :). Вот и посмотрим, кто мы на самом деле…

Автоматическое обновление и вечный косяк

Большинство современного софта вполне умеет обновлять самое себя через Интернет. Как сделать такое обновление вопрос широких дискуссий. Может быть это будет как в The Bat – просто проверка новой версии на сайте, может как в Google Chrome – скачивание и полностью автоматическая установка новой версии в фоновом режиме. В общем, кто во что горазд.

Но неизменно одно – софтина для обновления обязательно должна выйти в сеть. Без этого никуда. И сколько я перепробовал софта – у всех до единого один и тот же косяк. Если Ваш IE выставлен по умолчанию в offline режим, то софт не может выйти в сеть, и соответственно не может ничего обновить. И не важно из чего это самое “ничего” состоит: из репорта о доступности новой версии, или же это полная установка в фоновом режиме. Обновление не работает и всё тут, самый такой натуральный ППЦФ (“пипец фиче” – фича есть, фича могет, фича модная – только ни хира не работает).

И вот в этом случае, вот совершенно не нужно кивать что мол “только у тебя Гоха IE в вечном оффлайне” (© Arsen). Да мне пофиг! У меня есть свои причины в оффлайне его держать – и причины очень весомые. И тем не менее, несмотря на никакой оффлайновый режим IE, обновление в моей Aml Pages всегда работает.

Поскольку уже подзаколебало писать репорты коллегам – причем коллегам мною весьма уважаемым – про подобные траблы с обновлением, попробую-ка рассказать, как я решал эту проблему в Aml Pages. Опять же да здрям повторное использование кода – будет на что сослаться :), а не кропать заново.

Вкратце: в Aml Pages все обновление сводится к скачке файла с инфой о новых версиях. Дальше уже все на усмотрение пользователя – ставить или нет, посмотреть список изменений и.т.д. Ну да не в этом суть – файл с инфой скачать придется по любому, и обойти оффлайновый режим IE надо.

Оговорю сразу. Существует два вида проверки новой версии: автоматическая по прошествии сколько-то там дней, или ручная, явно запущенная пользователем из команды меню.

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

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

Можно сказать и кратче: есть новая версия? ОК – нужно об этом сказать пользователю. Нет новой версии, нет соединения, поврежден скачанный файл с информацией – все эти подробности ни на хер не нужны. Представьте, сидит себе пользователь, делает что-то свое и вдруг откуда ни возьмись на тебе репорты: “Нет соединения”, “Новых версий не обнаружено”. Да зачем ему вся эта инфа как черт из табакерки – нет и и нет, и нечего пользователя беспокоить.

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

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

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

Элементарно, Ватсон! Делается это просто – всего лишь единственным вызовом API-функции InternetGoOnline!

    BOOL InternetGoOnline (LPCTSTR lpszURL, HWND hwndParent, DWORD dwReserved)

В первом параметре нужно передать URL, по которому собрались обновляться. Второй параметр это HWND окна нашей софтины, он понадобится для сообщений. Третий параметр MS зарезервировала на будущее. Если есть подключение к сети – функция сразу вернет TRUE, в противном случае – FALSE.
Работает эта достославная функция следующим образом:

• Если подключение к сети уже есть, она сразу вернет TRUE, причем безо всяких подтверждений. В этом случае можно быть уверенным, что IE уже в онлайн-режиме и начинать коннектиться к сайту.
• Если подключения нет, то функция выдаст MessageBox “не желаете ли подключиться”. Именно для этого и нужен второй параметр с HWND нашего окна. Если пользователь согласится, то функция выполнит подключение и вернет TRUE. Если пользователь откажется – вернет FALSE.

В автоматической проверке вызовом InternetGoOnline, конечно же, грешить не стоит. Еще чего не хватало, чтобы исключительно вспомогательные и фоновые задания доставали пользователя запросами. Не удалось подключиться, и хрен с ним ладно. Совсем другое дело проверка, запущенная пользователем ручками. В этом случае пользователь принял решение сам, в этот момент его внимание по любому приковано к проверке, и он точно ожидает какого-то отклика. Вот в таком случае, имеет смысл и позвать InternetGoOnline – возможные MessageBox ну никак не смутят пользователя, он все равно ждет ответной реакции от софта. Дык почему б и не спросить, если известно что проблема “на этой стороне”? Это точно лучше, чем сказать невразумительное “ошибка соединения”, тем более что эта “ошибка” решаема здесь и сейчас.

Блин, сколько видел вполне толкового софта – все до единого на этом спотыкаются. И HippoEdit, и LeaderTask и многие другие. Долой непонятки – тем более что их решение, это всего две строки кода.

Вместо дисклаймера: мысль, о том что IE в оффлайн у очень немногих -  совсем не катит. Отмазы это для начальства, а не для пользователей.
Проблема тут вовсе не в дилемме “оффлайн vs онлайн” самой по себе – проблема тут исключительно в последствиях. Почему так, разговор длинный. Но если в двух словах: у кого IE запросто может быть в оффлайне-режиме? Да у гиков! А лично вам нужно чтобы именно гики не могли скачать новейшие апдейты?

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

Пользовательские интерфейсы в синематографе

Присмотритесь-ка на этот скрин интерфейса из голливудского фильма. Строка “Comp.Sys.Kill” ничего не навевает?

Ох, никогда я не забуду
Дот.Нет на службе Голливуда :)

Взято отсюда.

Органайзеры… Доколе!?!

  На RSDN.ru опять поднимаются вечные темы – поиск наилучшего органайзера. И опять традиционная картина: если б молодость могла, если б старость хотела :). И снова вечный скепсис: ниша дохлая. Ага… Щазз! Если люди годами ищут удобный органайзер, и так и не могут найти, какая ж это дохлая ниша? Рыба есть – ловить уметь надо!

Нельзя написать одну программу для всех задач, на все времена и подо все платформы… и одинаково хорошую для всех задач. Приложения для планирования задач неудобны для ведения заметок, а заметки не очень-то подходят для планирования. И уж точно: ни первое, ни второе не относится к напоминалкам. Зато можно написать несколько разных программ, каждую заточенную под свои задачи. Только вовсе не обязательно писать их все – все программы, как и стихи, уже давно написаны. Вполне достаточно научить их взаимодействовать.

Вы никогда не задумывались почему интеграционный софт это просто золотое дно!?! Все очень просто: допустим есть две программы, каждая из которых выполняет свои задачи на “вполне хорошо”. К примеру, Aml Pages для заметок, и LeaderTask для планирования. Можно попеременно пользоваться обоими – ОК, но это простая сумма двух слагаемых.

Хех, integration, в переводе с английского означает “объединение в одно целое”. К чему это? Если научить обе программы хоть немного взаимодействовать, то они начинают увязываться пусть хоть и в простую, но уже систему. А система это всегда больше, чем сумма слагаемых. У системы появляются новые аспекты поведения, которых нет у простой суммы (соседства на харде?) двух программ. Вот поэтому интеграционный софт и есть золотое дно – это создание новых возможностей, которых нет у обоих софтин по отдельности.

Поэтому и бесполезно создавать еще один комбайн, который будет делать всё. Невозможно создать инструмент, который делает всё одинаково хорошо. В принципе, и обухом топора можно забивать гвозди, но обычно для этого выбирают молоток. Абсолютно то же самое и с программой-комбайном. “Всё” не получится! Уж больно у каждой задачи разные цели, разные приоритеты, разные акценты.

Как-то писал почему в Aml Pages нет тайм-менеджмента? Да потому что, это не ее задача – Aml Pages это записная книжка, “записки на манжетах”, копилка для эврик, сохранялка для фрагментов веб страниц – да попросту оперативный блокнот под рукой. Какой там нафиг тайм-менеджмент – чего менеджить, и где там тайм? Это разные задачи вообще по своей сути.

Зато в Aml Pages уже сто лет в обед есть все механизмы для интеграции – на любую заметку можно сослаться откуда угодно, и эту ссылку можно в любой момент открыть извне вообще из любого кода. К примеру, плагин Aml Shortcut  именно на этом и построен – он всего лишь создает ярлык с нужными параметрами для открытия конкретной заметки и только. А чем открывать этот ярлык уже не его забота – пользователь ли кликнул или напоминалка по таймеру через этот ярлык открыла нужную заметку – это неважно.

Вот в этом и заключается вся извечная проблема написания очередных органайзеров. Все как один пытаются создать заново революционную систему, решающую абсолютно все проблемы. Ну-ну! Бог в помощь! Для молодости еще куда ни шло, но в старости пора повторять как мантру: “ложки серебряной пули нет, ее не существует” – можно конечно и топором забить гвоздь, и даже не один, но попробуйте подбить им сапоги…

“Совершенство – это когда не нечего добавить. Совершенство – это когда нечего убрать!” (© Антуан Сент-Экзюпери). В интеграционном софте нечего убирать, он обеспечивает только необходимое – возможность взаимодействия 2-ух софтин, и только. Убирать нечего – потому и совершенство.

PS: напоследок палю идеи. Обратите внимание на некоторые нюансы.

1. По сути своей все напоминалки  напоминают периодически. Но почему это должен быть только текст? Открыть сайт, запустить приложение, открыть документ – это не почти ли то же самое? Взгляните на COM-интерфейс ITaskSheduler – все периодично, но что именно периодично можно описать в широких диапазонах. Можно заюзать и сам интерфейс. Не катит? Кто мешает воплотить ту же идею с нуля самому?
2. Представим следующую ситуацию: вы с отладчиком наперевес уже почти с ногами залезли в окно кода и вовсе перестали реагировать на все внешние раздражители. И в этот момент любимая женщина вам говорит “дорогой, ты просил напомнить, что тебе надо позвонить Ивану”… Нет, нет – не отвлекает, а именно напоминает, привлекает Ваше внимания, но не требует вашей ежесекундной реакции. Не бывало такого?
   ОК, представили себе в уме, ну, а теперь к сути. Где вы видели у любимой кнопку “ОК”, которую нужно нажать чтобы хотя бы быстро закончить свои занятия? Так какого же хе… фига без конца показывать эти засранные MessageBox? Где необходимость сначала ответить на него, а только потом вернуться к своей задаче? Поверьте на слово – 30 минут размышлений, и решение находится – это действительно просто.
3. Ну и последнее. Ни один вменяемый человек никогда не планирует что-то на через неделю ровно на 21:33. Нет, нет, конечно и такое бывает. Но это исключение. Чаще все значительно элементарнее: “завтра вечером”, “в пятницу после обеда”, “как протрезвею проснусь” и.т.д. Тогда на кой хрен, скажите мне, всё завязывать на точные элементы ввода вроде DateTimerPicker? Нарисуйте обычный статик со шкалой: слева утро, справа вечер. Подсветите его слева-направо цветами перехода от желтого (рассвет) к красному (закат) и позвольте пользователю выбирать кликом. Добавьте для наглядности снизу шкалу часов (дней). Пользователи не идиоты, поймут все с первого раза – образы всегда лучше воспринимаются. Очень надо? Ну, добавьте рядом этот DateTimePicker, и синхронизируйте его и выбор на шкале кликом - не помешает. Но поверьте, использоваться он будет исключительно как дополнительное средство и значительно реже.

Для начала, пожалуй, хватит. Авось кому и пригодится высказанное, кого-то вдохновит!?! Один фиг, у меня по-моему никогда не дойдут руки до реализации, особо если учесть что это не последние идеи – их есть у меня…

Умное меню

Узрел в одной софтине меню любопытнейшего, да что там любопытнейшего – это называется экстраординарного поведения. Суть в следующем:

• наблюдаем на экране команды меню. Пока вроде все обычно, не правда ли!?!
• Щелкаем по командам меню. Опять же, не что-то из ряда вон выходящее. Знаем, плавали!

И вдруг, вуаля! Команды меню реагирует на щелчки мыши, но меню автоматически не закрывается. См. скриншот ниже.

Поясню фишку! Это меню для выбора показываемых столбцов в таблице. Стандартное виндовское меню при щелчке по команде с галочкой обычно галочку поставит или уберет, но в любом случае меню закроет автоматом. Но обратите внимание – здесь задача другая: в большинстве случаев нужно за один раз отметить ни один столбец, а несколько. В обычном случае придется открывать меню столько раз, сколько нужно столбцов. Здесь же всё иначе: команды с названиями столбцов реагируют на щелчок, но меню не закрывается! Вы можете продолжать отмечать столбцы. Ну, а изменения в свою очередь вступят в силу, когда вообще уйдем из меню.

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

Как увидел, аж позеленел от зависти и губы сами начали произносить “сцуки… но умные!” (есть мнение что иногда в этом блоге бывал и автор этой софтины, и уж скриншот-то свой , он узнает… Иван, в данном случае это комплимент – решение на пятерку с плюсом).

В прошлом посте аккурат писал про отложенные фичи в Aml Pages. Дык вот одна из отложенных фич – категории, аккурат и уперлась в возможность множественного выбора. В прошлых версиях выбор как раз был одиночным, и под него было написано ух какое умное меню: все из себя owner-draw, с иконками, с цветами, шрифтами и все такое. И меню это решало свои задачи выбора на раз, пользователи были вполне довольны. Возможность же выбрать несколько элементов одновременно в проблему пользовательского интерфейса и уперлась. В бизнес-логике никаких проблем с этим нет, все продумано, все написано. Но вот UI… Весь прошлый одиночный выбор был завязан именно на меню, а меню мульти-выбора не дает. Так что оставалось перепроектировать пользовательский интерфейс, причем достаточно объемную его часть. А это задачка не простая и не быстрая – поведение-то поменяется напрочь, надо полностью переанализировать требования пользователя. На этом-то все и застряло.

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

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

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

Вот такой вот бывает развеселый ГУЙ. Причем не бутафорский, не эмуляция в стиле “нарисуем очень похоже”, а самый что ни на есть разнастоящий, родной, можно даже сказать влитой, ГУЙ. Он и “выглядит как утка”, и “крякает как утка”, и “летает как утка”, да потому что он и есть разновидность “утки обыкновенной”, а разница только в способе “захода на посадку”. Вот такие любопытнейшие головоломки преподносит иногда пользовательский интерфейс.

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

MobileLive – блог о юзабилити

Новый блог – MobileLive. Новый, по крайней мере для меня, блог про юзабилити и пользовательский интерфейс. Пока статей не очень много, но в целом направленность очень порадовала. Давно искал!

Что отдельно понравилось, так это “золотая середина”. Статьи и в меру содержит теории, но и вполне подробно описаны и живые, конкретные ситуации. Ну, поехали по порядку.

Что хорошо: последние выпуски посвящены прототипированию пользовательского интерфейса. Хватит теории, перейдем к практическим занятием. Как-то доводилось заниматься прототипированием UI, ох и натрахался я тогда. Думается мне, размышляется, что-то не то я делал, и не так, да еще и наверное не туда. Поэтому-то и любопытны статьи с фактическим материалом, со ссылками, с примерами.

Что плохо: пока не видно ссылок на конкретный софт для прототипирования UI. А нужны, ой как нужны! Хочется взглянуть, чем пользуется профессионал. Любое обучение ведется на примерах – “смотри и делай как я”. Всегда и во все времена так учили – начиная от первобытных людей на охоте, и заканчивая вполне современными аспирантами и не на очень-то охоте. Но думается, что недостатки эти временные. Вопросы заданы – обещали в следующих постах.

Что ужасно: началось все с анонса в форуме пользовательского интерфейса на КЫВТ.ру. Но впоследствии из блога создалось впечатление, что автор женского пола – “я уделяла… я занималась”. Чего, между прочим, из поста на КЫВТ.ру ну никак не следовало.
Кто ж так делает!?! Нужно ж было сразу в посте недвусмысленно намекнуть, что автор женского пола. Это хоть и не столь очевидный, но для старожилов более чем известный прием: хочешь ответов на КЫВТ.ру – прикинься бабой милой девушкой! Проверено не по разу – прием безотказный! Вплоть до второго аккаунта на КЫВТ… (это все шутка, но нужно ж было к чему-то придраться:).

А вообще блог более чем порадовал – жду продолжения с нетерпением.

Напоследок пару комментариев по делу, что понравилось, а что нет, и почему “нет”. Чтобы не тянуло на засраную хвалебную “журналистки-заказную” рецензию. Глядишь и ASPа (автор блога) прочтет этот пост – авось инфа и сгодится.

GUI я занимаюсь в софте, причем в десктопном – здесь вам не сайты! Причем писать этот самый “гуй” я как-то привык ручками, прямо в коде, на помойку все эти формы да бильдеры (“формовыми гуями прославиться нельзя” ©)
Муторно, оно конечно муторно. Но занятие это благодарное , только когда точно знаешь чего писать, когда перед глазами есть видение, есть какой-то прототип. А вот когда оного нет, боже упаси прототипировать это на каком-нить C++ – работа мама не горюй, долгая и медленная. Но главное, когда прототип завершается, то результат летит в помойку, т.к. получилось не то. На колу мочало, начинай сначала.
Все логично – прототипирование занятие итеративное. Но с такой скоростью прототипированием можно заниматься ну очень долго, что ни в какие ворота. Перепробованы всякие связки для такой работы – но как-то всё не то. Поэтому и хочется ссылок на конкретный софт для прототипирования UI, хочется уже пощупать ручками…

Чтобы самому уж не быть сугубо “тетеретиком нашего движения” приведу пример. Буквально сейчас, за последние недели жестко встала проблема как раз с протипированием двух новых фич в UI. Без прототипа точно никуда – в этой задаче и так дай бог если треть от силы ясна. И что!?! А ничего – воз и поныне там, не сделано ни черта! Просто не знаю как и выкручиваться!

И еще. Не стоит скатываться до статей некоторых (не будем показывать пальцем) сайтов по юзабилити. Уж больно у них статьи какие-то либо в лес, либо по дрова. Или уж вода водой – азбучные истины. Повторение, конечно, мать учения, но не в 30-ый же раз в первый класс!?! Ну прочитаны, прочитаны! уже и Купер, и Раскин, и Тидвелл, и Головач и еще много чего – так что начинать совсем уж “с алфавита” уже неинтересно. Или уж наоборот – сплошные заметки с “полей боёв” – получается какой-то треп в курилке, экий междусобойчик. Либо так, либо сяк – а посредине ничего нету. Дайте ж инфы “второклассникам” - “арифметику” уже вроде как прошли, хотелось бы перейти к “алгебре”…

Итого: мне лично очень понравилось! Задеты вопросы, которые и сам себе не раз задавал – да вот с ответами у меня пока как-то не очень!
2ASPa: С_П_А_С_И_Б_О! Так держать! Больше блогов – хороших разных!

ГУЙ и меню

Настроение последнее время какое-то совсем неписательское…То ли лето пришло, то ли лыжи не едут!?! Сразу как-то вспоминается Андрей Вознесенский:
    «Ни дня без строчки – друг мой дрочит! 
    А у меня ни дней, ни строчек…»

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

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

Но главное меню традиционно играет еще и роль справочника команд. По идее в нем должны быть представлены все команды... По крайней мере, все основные. Буквально вчера ваш покорный слуга достаточно продолжительное время “шарился” в поисках нужной команды по главному меню Google Earth… Ни нашёл, блин! В конце концов, нужная команда, конечно же, нашлась – но скрыта она была в недрах диалога, и в меню никак не проглядывалась. А между тем, если бы она присутствовала в главном меню, я был бы избавлен от необходимости лезть в документацию… Т.е. преимущества меню как полной “энциклопедии возможностей ” вполне очевидны.

Но вот какое дело:, если команда меню где-то названа “А”, то она должна быть везде “А” и только “А”, и никак не “а”, “а” или “А…”

Если речь идет о большом, развитом приложении, обладающим богатым функционалом, сравнительно сложной логикой, и соответственно нагруженным пользовательским интерфейсом – то без меню никак, и меню будет много. И очень многое можно сделать из контекстного меню.

Обычно каждое меню описывается в ресурсах приложения. Но в большом приложении повторяющихся команд в разных меню будет достаточно дофига много. Полбеды само создание меню – все-таки они развиваются вместе с продуктом, постепенно наращиваясь от версии к версии. По ягодке, по ягодке и вот уже полные штаны  кузовок. Но совсем другой объем работы нарисовывается, когда нужно банально изменить название команды меню. Из-за того, что одни и те даже команды рассованы по самым разным контекстным меню, то исправлять придется далеко не единственное название. А это настолько “интеллектуальная” работа, что… в общем, на это просто кладётся! :)

Отдельные контекстные меню в ресурсах дело важное и нужное – другой бы спорил!?! Но обычно при этом  99 из 100 этих команд уже и так есть в главном меню приложения. Посмотрите на тот же самый Microsoft Word: практически любые его команды есть в главном меню.

Но есть и другой подход к формированию меню: создавать контекстные меню на лету, в runtime. Рекурсивно обходится главное меню (тривиально через GetPopupMenu + GetMenuItemCount +  GetMenuItemID), и извлекаются строки по идентификаторам команд. Затем извлеченные строки вставляются в создаваемое на лету контекстное меню через AppendMenuItem. Всё просто.

В развитом продукте выгоды такого подхода вполне ощутимы:

• Выполняется правило единственного определения данных (One Definition Rule, ODR). Если есть какая-либо команда меню, в ресурсах она описана только однажды – только в главном меню. И именно так она и будет выглядеть везде. Пользовательский интерфейс выглядеть “причесанным”. Если команда названа XYZ, то именно так она и названа во всём пользовательском интерфейсе, и никак иначе.
• Сам объем ресурсов в бинарнике будет значительно меньше. “Усилия, потраченные на оптимизацию работы с памятью, всегда оправдывают свои затраты“ – (© кого-то между прочим аж из самой Microsoft, что-ты, что-ты). Сейчас, пожалуй, весомость этого довода не столь уж актуальна, но всё же.
• Рано или поздно придет товарищ Познер встанет вопрос о локализации интерфейса. Понятно, что при таком подходе с минимумом меню в ресурсах переводчику просто физически достанется меньше работы. И опять же снова, как бы не было переведено название команды – оно везде будет идентичным.
• При таком способе разработчик фактически создает GUI руками, и может его поменять в любой момент, как заблагорассудится. Кстати, пункт выше про локализацию и тут имеет значение. В этом случае можно менять строение пользовательского интерфейса, порядок и содержание меню в коде, не оборачиваясь на старые локализации – все равно у вас есть все переведенные команды в главном меню. А дополнительные меню конструируются на лету и именно код определяет структуру и расположение команд.
• Кесерю кесарево, а слесарю слесарево. В ресурсах остаются только строки для перевода, а сам GUI формируется разработчиком в коде, на лету. Предельно легко разделить разработку и локализацию, и выполнять их отдельно и параллельно.  К тому же без взаимных последствий – переводчик изменяет перевод, но никак не структуру интерфейса.

Больше ГУЯ – хорошего и разного… А главное, функционирование и структура которого, легко отделяются от оформления и дизайна.

PS: нет, нет, если у вас всего три меню в приложении – то и “огород” городить не стоит. Но когда их число переваливает за десяток-полтора, и команды дублируются в нескольких местах – этот способ работает, причем работает еще как, с лихвой окупая время потраченное на пару-тройку десятков строк кода. Проверено!
PPS: “Совершенство – это когда не нечего добавить, это когда нечего убрать” (© Антуан Мари Жан-Батист Рожер де Сент-Экзюпери).

Юзабилити. Сплиттеры

Сколько смотрю на разные приложения, простые ли сложные, известные всемирно ли, или из под пера “студента”, повседневные ли аль раз в сто лет юзаемые и всё не перестаю дивиться “продуманности” их юзабилити. Возьмем, скажем, перетаскиваемый сплиттер, который разделяет экран на части.

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

Вот взгляните-ка на скрин rss-вьювера Оперы с моими пометками, а разъяснения к ним ниже…

1. Таскать горизонтальный сплиттер Оперы можно только за верхнюю тонюсенькую линию. Хрена с два в нее мышью попасть у вас получиться… Уверяю. Браво, Опера! Спасибо Норвегия!

2. При этом за нижнюю линию таскать сплиттер нельзя. Почему, [блин] скажите мне? Чем она хуже-то!?! Ну да, ну да… Визуально она немного, но отличается. Но видно это, только если приглядеться. Так почему нужно ломать глаза и вглядываться в эти различия, тем более что такие различия в поведении и вовсе не нужны? Достаточно разрешить таскать и за нижнюю линию и проблема исчезнет. Визуально объекты очень похожи, так почему они функционируют по разному?

3. И наконец, за пустое место на сплиттере перетаскивать и вовсе нельзя. Почему? Пользователь перетаскивает этот сплиттер по паре-тройке раз в минуту. Это очень частое действие, т.к. оно отвечает за компоновку рабочей области пользователя. Регулярно пользователю нужен полный обзор верхнего списка разделов, а тут вдруг ему понадобился максимально развернутый текст статьи для прочтения по-человечески.
Так почему же нельзя таскать за пустое место такой огромный, между прочим, сплиттер? Ведь перетаскиваемость – это его основная обязанность, основное назначение…

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

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

Понимаю, что сплиттер на самом деле забит readonly-контролами редактирования текста, за которые фиг потаскаешь. Но даже и в этом случае очень даже можно “поймать” левый клик мышью, определить над текстом ли кликнули, и решать что делать. Над текстом – начали выделение. Пустое место – отфорвардить управление сплиттеру и начинать перетаскивание… Это ей-богу не сложно кодится!

Рискну дать несколько простых рекомендаций, но имхо они здесь и так очевидны. Если в двух словах, то примерно так:

1. Рабочая область приложения (область данных) – это место, где должен хозяйничать пользователь.  Он, и только он, может определить как надо.
   Тезис прост: это данные. Причем его – пользователя – данные. Ему действительно виднее, что и как. Просто-напросто позвольте пользователю всё эти “что и как” выполнять. Предоставьте ему для этого средства, и чтоб средства работали, а не вызывали матные восклицания.
2. Позвольте ему “это” делать просто. Постарайтесь соблюдать единство поведения.
   В нашем примере: раз можно таскать за верхнюю линию сплиттера, так пусть можно будет и за нижнюю.
3. Есть основные функции элемента управления, в данном примере это перетаскиваемость сплиттера. А есть второстепенные. Главность функции определяется частотой ее применения пользователем. Пусть главные функции будут удобными, пусть будут простыми в использовании.
   А вот второстепенные пофиг или почти пофиг. Даже если они сделаны криво, даже если их вообще нет – на то они и второстепенные – о них мало кто вспомнит. Да и тем, кто вспомнит особо мешать не будет, т.к. второстепенные именно по частоте применения.
   В нашем примере: если нужно скопировать название поста, то уж как-нибудь да выкрутимся (набьем ручками, скопируем из сети, пройдя по ссылке на статью). Если кратче: этот копируемый текст вообще можно выкинуть. Пусть сплиттер будет именно сплиттером, но удобным! А вот копирование – это всё рюшечки. Можно и нужно использовать область без текста именно для перетаскивания, т.к. это функция – основная.

Как в том анекдоте про ферму: “бантиков на кормушках пока не надо, просто навоз сначала уберите” :). Попробуйте соблюдать эти простые, только основные правила. И будет вам “щастье”. Ну или уж не так сильно их нарушайте, чтоб не прям “через двойную сплошную да на глазах у гаишника”.
"Бьют, не за то что пьют, а за то что попадаются". Так не попадайтесь же, и уже одно это изменит отношение пользователя к продукту.

PS: вот вам бабушка и юрьев день freeware. А главное, такие “ляпы” в Опере практически на каждом шагу. Что ж, господа норвеги, такой подход к делу просто не может не радовать меня. Пока вы выдаете такую несусветную хирню корявость интерфейса, я без куска хлеба точно не останусь.

Юзабилити от Microsoft!?!

В MSDN Magazine пишут о юзабилити... Докатились! И такая-то тема да в microsoft`овском-то журнале… Срали, срали и упали не знаю как такое сочетание и называть-то?!? Эка кризис-то на людёв действует :)

А вот скоро выйдет знаменитая “About Face” Алана Купера (Alan Cooper), но теперь и на русском “Об интерфейсе” – вот это действительно, имхо, ожидаемое событие.
Впрочем, на русском у Купера уже выходила знаменитая “Психбольница в руках пациентов”. Тем, кто с этим концептуальным чтивом знаком – представлять не надо. Остальным, очень рекомендую взглянуть на содержание – это действительно офигенная книга, несмотря на э-э-э-э… название.
Вы только вникните в мысль об особенностях программистского мышления: обычный человек всегда и в первую очередь просчитывает наиболее вероятные ситуации, а программист – первым делом крайние случаи. Ничего такого не замечали за собой?
Сначала проверим что будет, если в графу “возраст” написать ноль, а только потом все остальные числа. (да, да! мы такие :)

True-color иконки в тулбарах

Для любого GUI-приложения не последнее значение имеет внешний вид – дизайн интерфейса.  Мысль не новая. Но далеко не каждое приложение имеет не то, что достойный, а хотя бы минимально приемлемый дизайн. И полагаю, причина тут кроется не только в том, что разработчики не самые замечательные дизайнеры [пользовательских интерфейсов]… Но иногда дизайн-то может быть и есть, но вот интегрировать его в приложение не так-то просто.
- “У вас дизайн еззь?
- Езззь!
- За?ебизззь!” (© )
Но на этом собственно всё: дизайн, конечно, “езь”! Но интегрировать его в приложение никто не спешит.

Почти в каждом приложении есть тулбар (toolbar). И причем занимает он весьма значительное место на экране, и поэтому во многом именно он и определяет внешний вид приложения. Так что, уж если редизайнить, то начиная с тулбаров.

Первым делом, при таком раскладе хочется сменить иконки в тулбарах на truecolor. Вот об этом и пойдет речь. Недавно Begemot выдал мега-полезный пост “Где брать бесплатные иконки”, и это только сподвигнуло к давно откладываемому редизайну иконок в Aml Pages.

Но тут же нарисовалось маленькое, но весьма существенное препятствие. Тулбары в Aml Pages набиты кнопками под завязку, просто в силу того, что и возможностей в Aml Pages немало. А посему перетасовываются кнопки тулбаров у меня чуть-ли не каждую версию – регулярный такой  в общем редизайн GUI.

В Visual Studio я постоянно пользуюсь встроенным редактором тулбаров . И отказываться от этой привычки нет ни малейшего желания – несмотря на всю ограниченность этого редактора, создавать в нем кнопки, перемещать их, редактировать подписи ну и так далее достаточно просто, быстро и удобно. Но есть одно “но”. Даже в не самой старой VS 2005, и уж тем более в моей любимой VS6 сам редактор иконок поддерживает всего 16 (шестнадцать!!!) цветов. Это означает, что редактировать сами изображения нельзя, в противном случае при первом же сохранении измененного изображения вместо кульной true-color иконки получите “кастрированный” вариант в “шашнадцать” цветов.

Ну лиха беда начало – айда в Google в поисках более продвинутого редактора тулбаров. Гуглящий да обрящет! В первых же строках  нашелся искомый редактор для 7-ой студии. Но и он был не лишен недостатков: частенько привирал с фоновыми цветами, не всегда корректно импортировал тулбары из RC-файла, да и нацелен он был все-таки на то, что каждый тулбар переделывается полностью.

А при моем числе кнопок переделывать весь тулбар - работа немалая. А при том, что мои тулбары частенько и меняются, работа эта еще и будет регулярная. И еще важный для меня аспект: все-таки подавляющее большинство уже сделанных кнопок, меня устраивают более чем, и хотелось бы лишь некоторые изменить “на лету”.

Собственно было найдено следующее решение. Редактор изображений в Visual Studio из-за своей намертво-прошитой 16-цветности отпадает как класс . Но тем не менее, сам компилятор ресурсов абсолютно корректно собирает в конечный exe-шник иконки из ico-файлов, не изменяя при этом сами изображения.

ОК! То, что нужно.

1. Глубину цвета “модных” иконок не нарушаем. Т.к. иконки расположены в отдельных ico-файлах.
2. Можем на лету заменить только некоторые кнопки тулбаров, ручками загрузив изображение из ресурсов (через LoadImage).
3. Ничто не заставляет редактировать весь тулбар, да причем еще “ах раз, да еще раз, еще много, много раз” в каждой новой версии.

Дизайнеры, вероятно возмутятся, читая про эти “художества”. Что ж – вы правы! Но я не дизайнер. У меня несколько иная задача: заменить только некоторые иконки в кнопках на лету, причем чтобы не приходилось править код и иконки при малейшем изменении исходников, ресурсов, расположения кнопок и.т.д. Чтоб мухи отдельно, котлеты отдельно.

Сам алгоритм решения прост до неприличия: после загрузки стандартного ресурса тулбара, наш код создает новый ImageList с более “глубокими” цветами. После чего копируют все иконки из старого ImageList`а в новый, заменяя нужные более симпатишными из включенных в ресурсы ico-файлов. И наконец, этот новый ImageList просто-напросто назначается тулбару. Упс! Всё готово! Этот код примерно выглядит так:

Пожалуй стоит сказать и о недостатках такой схемы.  Несколько неприглядно выглядят иконки “дизейбленных” кнопок.

Но это уже на вкус и на цвет. Google легко выдает несколько примеров преобразования иконки в градации серого – как этот или этот. Но  эксперименты показали, что при использовании этих примеров в реальном коде, получается все равно далеко не идеально. Код примеров еще дотачивать и дотачивать до идеала напильником . Но,  хозяева-барины: можно сяк, а можно эдак, в конце концов можно вообще создать отдельный Disabled ImageList из модных иконок… Вовсе не обязательно переделывать весь тулбар снова и снова, как только понадобится улучшить всего лишь пару иконок на кнопках.