воскресенье, 18 декабря 2016 г.

Платные апдейты или подписка!?!

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

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

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

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

В третьих пользователь всегда видит за что платит про обновления. Если ему ничего интересного нет, то и незачем обновляться, и незачем платить. Когда появится интересное ему обновление - милости просим.

В четвертых, более четкая обратная связь с пользователями. Кому-то что-то надо - он просит. Фича появляется в новой версии. Годидзе? Негодидзе? Дорабатывается. В какой-то момент пользователя устраивает новая фича. И он рано или поздно голосует рублем. А "рублем" это сильный довод. Сразу видно, куда развиваться софтине.

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

Поясню: выпускаем мажорный апдейт, с новой мощной фичей. По уму именно в этот момент должны "протухнуть" старые ключи для новой версии. Но вот какая штука. Хорошо бы чтобы пользователи потестили новую фичу. А как? У них ключи уже протухли!?! Если оставим старые, то на кой им платить потом - все ж уже получено? И главное: новые ключи тоже нужно тестировать. Т.е. никуда не деться: ключи нужно протухать практически сразу. И что получаем? Вместо тестирования и фидбека по новой фиче, тестируем больше новые ключи. Которые никоим боком к самой софтинке дела по сути не имеют.

Спрашивается, и на хрена такие геморрои? Два примера прям со сковородки: TwinkiePaste и Aml Pages развиваются по модели оплачиваемых обновлений. И в ус не дую. Проблем ни малейших. Aml Maple по модели платных мажорных апдейтов. И что поимел? Уже почти месяц с релиза нового мажорного апдейта, а приходится доводить до идеала систему лицензирования. На кой эти проблемы?

Век живи - век учись.
PS: с Маплей спасает только одно. У нее очень приличное фан-сообщество, которым весьма нравится моя софтина и им не в западло жалко оплатить мажорные обновления практически сразу. 

пятница, 7 октября 2016 г.

Хозяйке на заметку : многопоточность.

Пейте, курите, занимайтесь любовью… Но ни в коем случае никакой многопоточности!

Note Bene: особливо на этапе проектирования!
Ярлыки для себя на будущее: Aml Pages, асинхронный импорт рисунков веб-страниц, многопоточный причем, мудренная синхронизация… Ни-и-и-ичче просто не понадобилось.

воскресенье, 11 октября 2015 г.

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

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

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

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

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

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

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

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

среда, 16 сентября 2015 г.

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

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

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

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

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

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

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

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

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