воскресенье, 1 мая 2011 г.

Юзабилити. Мысли вслух. Правый клик

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

Ладно, все это типично виндовые мелочи. Хер с ними! Но дело в другом. Давным-давно, очень очень много лет назад, я узрел, что на иконке удаления можно как-то заполучить и меню с выбором устройств.  Причем безо всякого промежуточного диалога. Это, безусловно, удобнее. О сколько лет  и на скольких Виндах я обкликался правой кнопкой мыши по иконке, но так и не узрел желанного меню. А тут как-то смотрю, и вижу это вожделенное меню под рукой сборщика моей кухни (мы его фотки на ноуте листали). А поскольку сборщик был человек благодушный и к себе располагал,  то я безусловно спросил КАК ВЫ ЭТО ДЕЛАЕТЕ (полцарства за совет, двойная оплата, рюмаху на раз – нужное подчеркнуть)

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

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

PPS: а тот самый сборщик кухнями занимался исключительно для хобби. В прошлом у него с 10-ок лет службы в Генеральном Штабе, а там дураков не держат, а потом еще с десяток лет бизнеса. Но по природе своей он заядлый охотник и рыбак. А поэтому, когда дети выросли, бизнес продал, и на полгода пропадает в пампасах с удочками. А в зимний период занимается сборкой кухонной мебели для души (причем у него это весьма шикарно получается). Так что сборщик мебели все таки оказался несколько не типичный. Только сути дела – правый-левый клик – это все равно не меняет!

пятница, 8 апреля 2011 г.

Плагиностроение

На RSDN.ru в форуме по архитектуре программного обеспечения большой аншлаг. Еще бы! Вечные же вопросы задеты: что делать и кто виноват нужны ли плагины в софтине Икс, и как вообще организовать интерфейс плагинов. Всё как-то собирался рассказать, как я проектировал Plugin API для Aml Pages. А главное рассказать миру, какие ошибки допускал, как их исправлял, и на что именно стоит обращать особое внимание.

Но, как водится, если я чего задумал, то выпью обязательно (© В.С. Высоцкий). Выпито достаточно, и естественно, о плагиностроении не написано ни строчки до сих пор. А сказать-то есть чего. Основные архитектурные черты моего Plugin API как раз и описал в посте на RSDN.ru. Но в нем только самые главные черты – взгляд на вещи, а вопросов на самом деле тьма:

  • Могут ли плагины интегрироваться в пользовательский интерфейс хост-приложения?
  • Плагин инициализируется хост-приложением при старте или по требованию? Единожды или многократно?
  • Как взаимодействует плагин и хост-приложение в совместно используемой памяти? Или проще говоря: кто и как выделяет память, и кто, как и когда ее освобождает.
  • Как обеспечивать обратную совместимость старых плагинов, и новых версий Plugin API?
  • Как проектировать основные структуры данных для обмена информацией?
  • Какие сервисы должно или может предоставлять хост-приложение? Или иначе: может ли плагин “попросить” выполнить какую-либо работу само хост приложение.
  • Нужна ли поддержка событий? Т.е. должно ли хост-приложение извещать плагин о возникновении некоторых событий, изменений.
  • Как разруливать ситуацию, если есть две версии хост-приложения Unicode и ANSI?
  • Если хост-приложение локализовано на несколько языков, то на каком языке должен быть UI плагина?

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

Во-о-о-от, значитъ! Будем считать это первым блин комом. Глядишь, этот пост в последствии и заставит меня все таки рассказать побольше о плагиностроении. Ибо пока сам пишешь, все настолько по полочкам разложишь, что конкретный мозг просветляется Plugin API только улучшается.

суббота, 26 марта 2011 г.

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

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

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

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

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

Панель советов дня в моей Aml Pages

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

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

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

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

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

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

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

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

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

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

Technorati Теги:

понедельник, 14 марта 2011 г.

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

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

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

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

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

Technorati Теги:

воскресенье, 27 февраля 2011 г.

Резервное копирование исходного кода

А поговорим-ка о резервом копировании. Началось все с поста “Онлайн Backup-сервис” на незабвенном RSDN. Благо проблемы бекапа исходного кода стояли давно. И чтобы более-менее надежно, и не очень дорого, без рутины и быстро. Надежность – без комментариев. Цена само собой вопрос не последний. Быстрота и удобство – последнее по списку, но не по значению. Как только появляется геморрой в создании бекапа, начинаем класть с прибором на этот самый бекап… Со всеми рано или поздно вытекающими последствиями. А посему идеал, это когда клик и готово – бекап сделан.

Заюзал для резервного копирования веб сервис Dropbox.com. Пользуюсь больше месяца. Впечатления отличные: удобно, быстро, надежно и в меру бесплатно.

Схема использования проста как две копейки. 1) Исходный код в архив. 2) Архив в специальную папку синхронизации на диске. 3) А уж специальная тулза от Dropbox.com видит в папке изменения, и закачивает новые данные на сервер. Само собой, особо критичные исходники  отправляются в  запароленном виде. Приятный сервис, к тому же 2 GB дискового пространства выдаются бесплатно. За большее придется заплатить.

Заодно пришлось поковыряться с этим автоматическим синхронизатором для сервиса. Пользователи давненько просили изваять какой-нибудь плагин для быстрой отправки документов Aml Pages куда-нибудь вовне: е-мейл, внешний сервер и.т.д. А тут все один к одному: и бекап хотелось бы автоматизировать, и пользовательские просьбы, да и всякие фич-реквесты и баг-репорты у меня также и в документах Aml Pages хранятся. Так что в подобном плагине я и сам был заинтересован. Сказано-сделано: изваял плагин Aml2Dropbox. До идеала конечно не доводил: парсинг настроек синхронизатора, архивация в ZIP, да и по мелочам. Но пока работает как часы.

В общем, отличный сервис. Рекомендую.

Ссылка по теме. К вопросу об архивации исходников. Был у меня скрипт для архивации, но больно заточенный под конкретный проект. А вот здесь выложена отличная подборка скриптов для архивации исходников. Скрипты для Windows, но в соседних постах можно найти и для других ОС. Не в качестве рекламы, а дабы каждый раз не гуглить указанный пост заново. Спасибо автору за скрипты. Толково!

суббота, 26 февраля 2011 г.

МГУ или сказки нашего двора

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

Ссылка по теме: сказки нашего двора или как пожили профессора и спасибо! Обрадовала моя альма-матерь на старости лет. Никак не ожидал, что МГУ им. М.В. Ломоносова в лице именно ее руководства достигнет небывалых высот в такой науке как “обыкновенный развод”… :( Похоже и барон Карл Фридрих Иероним фон Мюнхгаузен был прав, утверждая: “чтобы влюбиться, достаточно мгновения. Чтобы развестись иногда нужно прожить 20 лет вместе”.

Главное здание МГУ им. М.В.Ломоносова. Те самые "башни-невидимки", которых якобы нет в этом монументальном здании.

четверг, 10 февраля 2011 г.

Обратная связь с пользователем

Обратная связь с пользователями это не просто ВАЖНО, это очень ВАЖНО! О важности обратной связи с пользователями для shareware проекта можно говорить бесконечно. Конечно, можно заявить что-то вроде “будьте клиентоориентированы”… Но нет, идите в жопу, у нас не сто рук, и не 48 часов в каждых сутках. Все и вся успеть не получится, поэтому выбирать и расставлять акценты все равно придется. А на что обратить внимание, и как вот тут и начинаются детали.

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

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

  • Раздел Новости на сайте: это старинный и хорошо проверенный временем пример. Как оказывается, очень многие читают и следят за новостями именно на сайте. И пофиг им все остальные каналы распространения информации. А уважать привычки своих пользователей смысл имеет.  Поисковикам кстати эта информация точно лишней не будет . Из минусов: если посетитель на сайте первый раз, ему эти новости “по боку”, только лишние грузяки большими объемами информации.
  • Новостная RSS-лента: это вообще как говорится “заобязательно”. Далеко не все, но очень и очень многие предпочитают следить за новостями по RSS-ленте. Как прикручивать RSS ленту к сайту расскажу чуть позже. Несколько простых приемов и польза от ленты возрастает в разы. От себя скажу, что настолько уделяю внимания RSS-ленте, что не поленился написать под себя любимого собственный WYSIWYG редактор RSS.
  • Форум: необязательно конечно. Это вообще далеко не всем подходит. Но помогает создавать устойчивое сообщество пользователей. Из минусов: администрирование форума это тоже нехилая работа, а хотя бы и по времени.
  • Форма обратной связи: по сути это то же самое что и форум, но в отличие от первого позволяет общаться лично с Вами, а не со всеми подряд. Главное в такой форме возможность отправить сообщение анонимно. Из минусов: спам, конечно же. Но несколько взмахов пера, и количества спама снизится на порядки.
  • Новостная емейл рассылка: кажется один из мощных источников продвижения. Но личное впечатление ну очень двоякое. С одной стороны в моей рассылке написано больше сотни постов. Возраст рассылки составляет уже несколько лет. А я как не знал, так и не знаю кто аудитория этой рассылки. Зато, если пользователь на нее подписан, то это точно наш человек. Т.к. случайно получить выпуск рассылки у пользователя ну никак не получится. Он может только сам, и причем вполне осознанно подписаться. Про плюсы и минусы подробнее в другой раз.
  • Группа в Facebook: конкретного мнения пока у меня не сложилось. Но личное впечатление от Facebook более чем положительное. Чем-то вполне может заменять и емейл рассылку, и отчасти RSS, т.к. во многом функции пересекаются. Запостить новость в Facebook дело 2-ух минут. Удобно, быстро. Но пока продолжительного опыта нет, поэтому затруднительно высказать какое-то определенное мнение. Другие социальные сети: что-то пробовал – не понравилось, а что-то просто откровенный отстой.
  • Uninstall Feedback: это просто святое. И чего только бывало не узнаешь о своей программе, когда пользователь ее удаляет. Даже сам факт вдруг пропажи uninstall-фидбека меня пару раз очень сильно выручал. Важно: 1) просто обязательно давать возможность оставить сообщение анонимно. Никто не будет палить вам свои контакты за здорово живешь. 2) если будете выносить пользователю мозг ядреными капчами вроде этой, такую форму просто проигнорируют. Не получите вообще ничего. 3) В программе удаления обязательно оставлять возможность вообще ничего не отправлять. Пусть это будет банальная галочка “оставить отзыв”, пусть эта галочка даже будет включенной по умолчанию . Но возможность отключить ее у пользователя должна быть. Впрочем, как-то я уже писал про uninstall feedback.
  • Перелинковка: выяснилось что это более чем действенный прием. Написали новость на сайте или в RSS? Ткните туда и ссылку на обсуждение в форуме. Вышла статья в новостной рассылке? Разместите ссылку на нее на сайте. Есть форумы, RSS, и прочия? Пусть ссылки на все это хозяйство будут в документации и в самой программе.

Ну, вроде бы ничего не забыл!?! А поподробнее, по полочками уже в будущих постах.