Pro- чтиво

Сегодня малехо “пофлудю” о чтиве, о значит, профессиональной (pro-) литературе, благо повод давнишний и вполне значительный.

Хочется поделиться впечатлениями об одной замечательной книге – кою читать и заканчиваю -  “Современные методы описания функциональных требований к системам” Алистера Коберна (Alistair Cockburn).
Если в двух словах - "ве-е-е-счь"!!!
И э-эх, пока собирался писать об сём произведении, с Books.ru книга уже исчезла, а это уже кое о чем говорит. Стоит упомянуть, что книга настолько стоящая, что когда после первого приобретения, она “отрастила себе ноги” и испарилась в неизвестном направлении, то не долго раздумывая, раскошелился и на второй экземпляр.

Итак, о чем же книга? Да собственно o use-case – о вариантах использования. О том как они описываются, как анализируются, как применяются. Прежде чем проектировать, а тем более уж кодить, все-таки сначала нужно описать требования пользователя. Причем не просто описать, а и обосновать, и понять зачем ему это нужно – как и зачем будет использоваться та или иная сущность. Какие варианты использования важны, а какие нет? Какие делать сейчас, а какие потом? Как понять не очень-то очевидные причины самой потребности пользователя в тех или иных возможностях софта? Вот про то, как находить ответы на эти вопросы и написано у Коберна. И написано весьма неплохо!

Чего только стоят высказывания о уровнях целей пользователя или как увязывать эти самые use-case с планом добавления “фич” в следующие версии. Почему фичу “А” сейчас нафиг, а фичу “Б” всё-таки пофиг? Вот почему, а? А у Коберна изложено!

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

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

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

В общем, must have однозначно.
PS: ссылку именно на Books.ru даю все ж таки не случайно. Books.ru, в отличие от какого-нибудь Озона частенько приводит у себя в каталоге и содержание книги, и отрывок. Согласитесь, для нашего девелоперского брата это более чем важно – посмотреть что внутри. Флудить, троллить да баянить все горазды. А вот написать нечто новое толковое да еще и новое – это не каждому под силу.  Просто уж так вышло, что к написанию этого поста мало того что и книга из продажи пропала, Books.ru зачем-то “убил” и ссылки на содержание. Ну да у них там народ более отзывчивый – будем надеяться, что ссылки все-таки вернут, благо просьба об оных уже отправлена (обычно быстро все появляется).

Про хелпы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГУЙ и меню

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

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

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

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

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

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

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

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

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

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

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

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

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

32-ое мая…

Сегодня как-нибудь без программирования. Тут аккурат  на рутьюбе подвернулась давно потерянная ссылка:

Ролик хоть и старинный, но философские мысли навевающий. А завтра между прочим 32-ое мая, которое теперь пройдет и в еще более узкой компании. Как-то они от нас слишком быстро уходят: Григорий Горин… Александр Абдулов… Теперь вот Олег Янковский… Грустно это, господа, грустно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это сладкое слово “халява”

Пробежался после трудового дня по Гугловскому поиску по блогам… А гугловский поиск по блогам иногда ну “стока всиго интереснава выдаёт” , что восклицание “эка!?!” сотрясает воздух само собой, рефлекторно.
Искал я там кое-что конкретное, ну да не об том речь. А за компанию проверил и любимые софтинки… И оба-на! На Aml Maple выложен кряк и кейген!

Отлично просто! Правда за исключением одного, наверное незначительного, логического “И”.
Мапля всё время своего существования, во всех реинкарнациях, дистрибутивах, во все времена и иже с ними всегда была freeware и только. И никакого даже и намека на шаровару.

Вторую часть сего удивительнейшего логического условия “и” можно описать 2-мя ссылками на virustotal.com: ссылка раз и ссылка два-с.
Ссылки ведут на отчеты более 40 антивирусов, и показывают, что оные антивирусы думают про эти якобы кейгены да кряки для абсолютно бесплатной Мапли.

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

М-да… Как говорится, “дураков на Руси еще лет на 100 вперед припасено”. И видимо не только на Руси…