суббота, 27 июня 2009 г.

Про хелпы

В “Компьютерре” в очередной раз собирают вопросы для интервью “по заявкам радиослушателей”. На этот раз вопросы для RITLabs (авторы популярного почтовика The Bat). Ну а т.к. сам я давний поклонник и пользователь Бата, конечно же с интересом полистал. Вопросы задавать не стал, чтобы не добавлять лишней цензуры работы админам, благо у меня они как всегда и едкие, и специфичные. Но сами вопросы пользователей читал с превеликим интересом, благо считаю что Бат один из мощнейших  почтовиков, хотя и с такими же мощными “косяками” (сие не про баги)

А заинтересовал весьма любопытный, злободневный и до боли знакомый вопрос: “почему включенная в состав почтового клиента справочная документация так редко обновляется и постоянно отстает от текущей версии?”.

Хороший вопрос! Годный!
Действительно, частенько хелпы пишутся формально, да еще и с приличным опозданием. Хм, а почему? Вопрос вечный: что раньше, курица или яйцо? Да и так ли важен ответ? Важнее почему пользователь читает старые\неверные хелпы, а как и когда они пишутся это уже детали.

У меня русский хелп к Aml Pages пишется в последний момент да все больше наскоками. Поэтому и вкладывать его в дистрибутив с новой версией попросту нет смысла: версия новая, а дока к ней еще старая. Выкрутился так: русская справка распространяется отдельно (правда, если уж руку на сердце положа, на то было и еще две весомых причины: справка появилась значительно позже, да и весит она в ZIP-архиве как весь остальной дистрибутив вместе взятый).

Но “изюминка” в интеграции Aml Pages и ее справки. Любая попытка обратиться к хелпу, сначала проверяет его наличие и если его нет, сразу предлагает скачать справку с сайта по прямой ссылке.
Такой вариант позволяет выпустить новую версию, и спокойно с недельку “причесывать” справку. Опять же старинные и активные пользователи про такое небольшое отставание в курсе.
А новые… Эх, новые… Да не будут новые пользователи первым делом шариться по справке!
Вы когда-нибудь начинали знакомство с софтом с активного изучения доки? (вот только врать не бум, ладно:). Ну, а когда новый пользователь доходит до незабвенной кнопки F1, ему тут же предлагается скачать справку (повторюсь: ссылка прямая, никаких заходов, подтверждений и.т.п. – число кликов минимально).

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

Впрочем, не буду голословным. Статистика радует – соотношение скачивания справки и самого дистрибутива 1 : 2. Т.е. половина все-таки скачивает!
Любопытны отзывы о справке. Девелоперы и прочие коллеги: “так нельзя!” (мама запретила, Билли обругает). Пользователи: отзывы всё более в превосходной степени “великолепная”, “отличная”.

Понимаю, что эти цифры говорят нечто о скачавших и только о них. И ни черта не сообщают о тех, кто остался без справки. О них можно просто ничего не узнать. Но вот какая загвоздка… Те кто не скачали справку, они всего лишь не_скачали. Возможно они и не пытались – справка не нужна им в силу квалификации, их не устраивает эта софтина в принципе, на первом этапе знакомства им достаточно технической поддержки!?! Конечно, число “обломившихся” неизвестно, но точно понятно, что они не вся эта “потерянная” половина.

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

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

понедельник, 15 июня 2009 г.

Девелоперский отдых, “панимаишь” ©

Всё ж нельзя постоянно заниматься разработкой программного, “панимаишь”, обеспечения! И отвлекаться как-то надо…
Когда-то эдак лет 12 назад я частенько поигрывал в Heroes of Might & Magic, по-моему тогда еще второй версии. Ну и решил я было тряхнуть стариной. Сказано – сделано! Прогулялся по сети, нашел “хирус” какой-то версии, да и выкачал его не вникая в новые фичи, благо поздних версий этой “гамки” толком я и не видел.

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

В общем, помаялся раз, помаялся другой – так и не вспомнил,  что там в этом Heroes`е нужно сделать для продолжения. Забил и бросил это занятие как безнадежное.

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

PS: документация и хелпы к Heroes`у конечно были просмотрены – бред какой-то, ни черта ни понятно – ни тебе примеров, ни тебе прототипов, ни тебе Getting Started! Бардак у вас, товарищи гейм-девы – форменный бардак :)

пятница, 5 июня 2009 г.

ГУЙ и меню

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

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

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

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

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

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

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

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

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

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

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

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

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