Учебник по созданию shareware программ

Advanced Disk Catalog

Advanced Disk Catalog

Advanced Disk Catalog (ADC, http://www.elcomsoft.com/adc.html) — мощная программа каталогизации дисков любого типа: дискет, жестких дисков, CD-ROM и т. п. С ее помощью можно быстро создать базу данных, содержащую сведения о файлах, находящихся на соответствующем носителе. Впоследствии, воспользовавшись функцией поиска, можно быстро узнать, на каком именно диске находится нужный файл.
В один прекрасный день самого начала весны 1997 года Владимир Каталов (автор одной из двух исторических статей в "Компьютерре" 1998 года, положивших начало массовому развитию shareware в России) решил навести порядок среди своих залежей программ на дискетах и CD-ROM. До этого такую "инвентаризацию" он проводил еще в 1995 году, когда дисков было совсем мало, и для этого вполне хватало возможностей небольшой бесплатной утилиты под DOS. Но сейчас требовалось нечто большее. В поисках нужной программы Владимир перебрал около двадцати имевшихся на рынке продуктов (среди которых были и бесплатные, и относительно дорогие), но везде чего-то не хватало. Было решено написать свой собственный каталогизатор дисков, и примерно через неделю, 11 марта, был готов некий "релиз". Дней через десять после этого Владимир решил попробовать продавать новый продукт как shareware, хотя его коллеги смотрели на эту затею без особого энтузиазма...
Первая регистрация программы была оплачена уже 30 марта 1997 года, а всего за первый месяц было целых 12 продаж! Владимир до сих пор ломает голову над причинами такого удачного старта своей программы на shareware-рынке, ведь, по его словам, ADC в то время был довольно слабым продуктом (например, отсутствовала документация, не было инсталлятора). Кроме того, программа была "по знакомству" размешена на сервере одного московского ВУЗа с медленным доступом; она была зарегистрирована всего в трех или четырех интернет-архивах программ, в поисковых системах страница программы была не видна...
Со временем у программы появился инсталлятор, файл справки, был реализован мультиязычный интерфейс — с возможностью легкого добавления поддержки новых языков, сайт программы "переехал" на сервер коммерческого провайдера, в компьютерных журналах появились обзоры ADC, была создана сильная защита от взлома — все это вызывало увеличение количества регистрации. Но особенно заметный скачок уровня продаж — примерно в два раза - произошел после первой поездки автора программы на Shareware Industry Conference (см. разд. "Профессионалы shareware" данной главы) в 1998 году, когда он стал реализовывать новые приемы shareware, которыми с ним поделились зарубежные коллеги.
Сегодня, через четыре года после начала продаж, у Advanced Disk Catalog более десяти тысяч пользователей, не считая нескольких корпоративных клиентов, купивших сразу десятки и даже сотни лицензий.

Adware

Adware

К этой категории относятся программы, которые во время своей работы демонстрируют пользователю рекламу -- чаще всего графические баннеры размером 468x60 точек (Рисунок 1.1). Adware сочетает в себе черты freeware и shareware: с одной стороны, пользователь может использовать программу бесплатно и не обязан регистрировать ее, платя деньги разработчику (последний получает денежные отчисления от рекламодателей); с другой стороны, у пользователя имеется стимул зарегистрировать программу, т. к. после регистрации показ рекламы отключается.

Careware

Careware

Совсем уж экзотический способ, которым распространяется, например, широко известный HTML-редактор Arachnophilia (http://www.arachnoid.com /arachnophilia). В лицензионном соглашении к программе сказано, что пользователь должен на час, день или неделю перестать жаловаться на жизнь и сказать кому-нибудь слова ободрения.

Chameleon Clock

Chameleon Clock

Chameleon Clock (http://www.softshape.com) - это программа-часы, заменяющая собой стандартные часы Windows, находящиеся в Панели задач. Помимо отображения времени, Chameleon Clock имеет функции будильника, календаря и многие другие возможности.
В 1997 году Юрий Герасимов, будущий разработчик Chameleon Clock, работал в одной газодобывающей компании программистом. Базу данных, которая и была собственно его работой, он к тому времени успешно закончил и занимался ее поддержкой, и поэтому у него было некоторое свободное время. "Для себя" он писал различные небольшие программы, в том числе и часы. В один знаменательный день весной 1998 года в руки Юрию попал тот самый журнал "Компьютерра" № 240, с опубликованной в нем статьей "Искусство Shareware" Александра Каталова (см. разд. "Shareware в России" данной главы). Прикинув, что всего пять(!) продаж двадцатидолларовой программы в месяц — это уже больше текущей зарплаты, он решил попробовать: если и "прогорит", основная работа не даст ему умереть с голоду.
Некоторое время ушло на выбор продукта. Как пришла идея часов с поддержкой скинов (т. е. наборов графических элементов, с помощью которых вид программы полностью меняется), Юрий сейчас уже не помнит, но вдохновителем был WinAmp. Кроме того, очень удачным шагом было решение использовать популярность WinAmp для "раскрутки" собственного продукта. Тогда уже было много часов с поддержкой скинов, но все они имели скины, уникальные для каждой программы, и соответственно их число не превышало 10—50 штук. Для сравнения: уже в 1998 году скинов для WinAmp существовало около 3000!
Самая первая версия вышла на русском языке, называлась Winamp Clock, и до сих ее можно найти где-то на Freeware.ru и Download.ru. Она не продавалась и служила больше для обкатки идеи и просто бета-тестирования. Программа была довольно слабой — даже сам автор сегодня не может смотреть на нее без удивления. Тем не менее, именно из нее была сделана первая версия Chameleon Clock: интерфейс программы был просто переведен на английский язык.
Трудностей добавляло то, что Юрий к тому времени совершенно не знал английского языка — и в школе, и в институте он изучал немецкий. Переводами в основном занималась жена Юрия, она же и придумала название Chameleon Clock.
Версия Chameleon Clock 1.0 вышла 7 июля 1998 года. Она работала только под Windows 95, не имела инсталлятора и даже справки. Добавив инсталлятор, Юрий стал распространять через интернет-архивы версию 1.01. Первая продажа была 3 августа, через неделю после выхода версии.
Юрий (с помощью жены) быстро написал справочную систему, исправил пару ошибок и выпустил еще одну версию. Вместе с ней в первый месяц получилось 17 продаж. Увеличению популярности программы очень помог известный интернет-архив Download.com — первая же версия часов попала в его список рассылки Shareware Dispatch, где публикуется информация только об избранных новинках рынка программного обеспечения.
Выходили все новые версии, и вскоре продажи вышли на уровень 30 покупателей в месяц. Так продолжалось несколько месяцев подряд. Первый скачок популярности произошел после добавления ключевой возможности, которая до сих присутствует не более чем у 5% конкурирующих программ — это встраивание в Панель задач и полная замена стандартных часов Windows. Технически это не самая тривиальная задача, но результат оправдал все усилия, потраченные на ее решение. Одновременно цена программы была увеличена с 14,95 до 24,95$, и это только привело к подъему числа регистрации!
Следующий скачок уровня продаж был после увольнения со старой работы и перехода на работу с shareware (так называемое full-time shareware) — примерно через год после выхода первой версии. Больше времени стало уходить на техническую поддержку, продвижение программы, Web-сайт и тому подобные вещи. Как результат, количество регистрации в месяц еще больше увеличилось.
Еще один фактор, благоприятно повлиявший на высокий уровень продаж Chameleon Clock — тщательная проработка пользовательского интерфейса. По оценкам Юрия, до 70%(!) времени, затраченного на работу над Chameleon Clock, ушло только на интерфейс. Зато теперь многие пользователи, по словам Юрия, присылают ему письма примерно с таким содержанием: "После того, как увидели Вашу программу, уже не хочется работать со стандартными часами Windows". Я могу подтвердить это впечатление от Chameleon Clock: после того, как я установил эту программу в рамках обычного тестирования программ из каталога SoftList, я уже не мог терпеть вид нормальных часов Windows — это при том, что я всегда был равнодушен ко всяким украшательствам типа обоев для рабочего стола или скинов для WinAmp! Пришлось приобрести регистрацию Chameleon Clock — тем более, что для российских пользователей она стоит всего 100 рублей.

Commercialcc

Commercialcc

Это коммерческое программное обеспечение, т. е. распространяемое за плату. При этом оплата программы должна быть сделана в момент заказа или получения копии ПО: использование такой программы до оплаты не допускается. Это, конечно же, отталкивает потребителей, не желающих покупать "кота в мешке", поэтому многие компании-разработчики коммерческого ПО распространяют демонстрационные версии своих программ, имеющие ограниченный набор функций и предназначенные для ознакомления потенциальных покупателей с продуктом.
Коммерческие программы в основном распространяются на физических носителях — дисках CD-ROM или дискетах, в "фирменной" упаковке (поэтому такие программы часто называют "коробочными"), снабжаются печатным руководством пользователя и гарантированной технической поддержкой. Коммерческие программы — наиболее массовый тип программного обеспечения, к которому принадлежат такие "монстры", как Microsoft Windows, Microsoft Office, Microsoft Visual Studio, Adobe Photoshop, CorelDRAW, Borland Delphi и многие другие. Именно коммерческим программам пока принадлежит наибольшая часть рынка программного обеспечения.
Как уже упоминалось, многие коммерческие программы распространяются и как shareware. В этом случае программа может стоить несколько дешевле, ведь производитель избавлен от расходов на упаковку, печать руководства пользователя, складских расходов, комиссионных отчислений дистрибьюторам и т. п.

Demo

Demo

Демонстрационные программы представляют собой ограниченные по функциональным возможностям версии коммерческих и shareware-программ, а иногда — просто видеоролики, своеобразные презентации программ. Предназначены они для ознакомительных целей: если пользователю программа понравилась, он может произвести оплату и получить полную версию продукта. Наиболее широко распространена практика применения demo-версий в игровой индустрии: почти каждая новая игра выходит одновременно в виде полной "коробочной" версии и в виде варианта, включающего несколько начальных уровней, который можно бесплатно скачать через Интернет.

Donationware

Donationware

Такие программы распространяются бесплатно и их регистрация не требуется, однако разработчик программы в лицензионном соглашении или документации указывает, что если пользователю программа нравится, то он может (именно может, а не обязан) выслать автору небольшое вознаграждение. Размер вознаграждения либо определен четко, либо оставлен на усмотрение пользователя - "кто сколько может". Иногда размер вознаграждения указывается даже так: "Пришлите мне столько денег, чтобы их хватило на ящик пива!". Для таких случаев придумали даже отдельный термин: "beerware" (от англ, beer - "пиво").
К сожалению, как показывает практика, пользователи очень вяло реагируют на такие просьбы и очень редко высылают деньги разработчикам программ. Некоторые авторы, чтобы хоть как-то стимулировать пользователей зарегистрировать программу, пытаются разжалобить их, указывая такие, например, подробности: "Мне нужно кормить шестерых детей, пожалуйста, не дайте им умереть от голода!"
Donationware привлекало авторов программ в то время, когда программистам-одиночкам было крайне затруднительно самостоятельно принимать платежи от пользователей. Сегодня, с распространением Интернета и появлением десятков компаний-регистраторов, берущих на себя все хлопоты по обслуживанию платежей любых видов, способом donationware свои программы распространяют в основном те авторы, для которых разработка программ — это хобби или развлечение.
Из наиболее известных donationware-программ можно назвать замечательный просмотрщик и редактор графических файлов Irfan View (http:// www.irfanview.com) Ирфана Скилжана (Irfan Skiljan) из Австрии. В лицензионном соглашении Ирфан пишет: "Irfan View распространяется как freeware, но только для частного, некоммерческого использования (это означает -для использования дома). [...] Если вам нравится эта программа, пожалуйста, зарегистрируйтесь, послав 10$ или 15DM (пожалуйста, только наличными) по адресу [...]". Как видите, регистрация программы на таких условиях маловероятна, т. к. почтовые службы многих стран, в том числе и России, запрещают пересылку наличной валюты в почтовых отправлениях. Кроме того, для юридических лиц существуют дополнительные трудности, связанные с ограничениями на операции с наличной валютой.

Download com — один из самых крупных

Рисунок 1.2. Download.com — один из самых крупных интернет-архивов shareware-программ

Eserv

Eserv

Eserv (http://www.eserv.ru) — готовое решение для полноценного доступа к Интернету из локальной сети (через один модем или выделенное соединение). Включает почтовый сервер (SMTP, РОРЗ и IMAP4.1), сервер новостей (NNTP), Web-сервер (с поддержкой CGI, виртуальных серверов, виртуальных каталогов, Web-интерфейсом ко всем серверам комплекта), FTP-сервер (с поддержкой виртуальных каталогов и докачки), proxy-серверы и т. д. Ведущий разработчик пакета — Андрей Черезов.
В конце 1996 года компания "Етайп" (http://www.enet.ru/win/etype/), интернет-провайдер в Калининграде, искала программное средство, которое позволяло бы ее корпоративным клиентам решить вопрос организации внутриофисной почты и прозрачного объединения внутренней почтовой системы с интернет-почтой. Требовались следующие возможности:

использование одной программы как для интернет-, так и для внутри-офисной почты;

простота администрирования; удаленное администрирование;

работа ПО под Windows;

возможность доставки интернет-почты через обычное dial-up-подключение (без выделенного канала);

возможность присвоения каждому пользователю индивидуального интернет-адреса для работы с внешней электронной почтой;

приемлемая стоимость;

русскоязычная поддержка.

Ни один из рассмотренных вариантов решений на базе имеющихся на рынке программного обеспечения не смог удовлетворить сразу всем критериям, поэтому было решено создать свой продукт. На написание первой бета-версии программы ушло всего около пяти дней, и она вышла в свет 25 декабря 1996 года. Тогда Eserv включал в одном модуле РОРЗ, SMTP и HTTP-серверы, SMTP/POP3-коннекторы и dial-up-звонилку, а его размер был всего около 70 Кбайт.
Версия 1.0 появилась в феврале 1997 года, к тому моменту существовало уже много бета-тестеров, среди которых имелись в том числе администраторы двух местных банков, которые были довольны возможностями программы. Цена Eserv была установлена в 60$ (с НДС — 72$) и первая продажа состоялась уже марте. Тот, самый первый, покупатель предложил включить в Eserv и news-сервер, что и было сделано.
На калининградской компьютерной выставке BitExpo, проходившей в апреле 1997 года, компания "Етайп" представляла уже не только свои провайдерские услуги, но и Eserv. Стендовые машины были подключены к Интернету, на одной из них работал Eserv/1.1. Другие участники выставки просились подключиться к Интернету через стенд "Етайп"... Тут же родилась идея включить в Eserv прокси-сервер. Вечером первого дня выставки Андрей Че-резов написал прокси-сервер, и следующие дни еще несколько стендов работали в Интернете — через Eserv.
После выставки к лету 1997 года Eserv вышел на объемы продаж в несколько копий в месяц, к осени — 10 копий в месяц. При этом Eserv почти нигде не рекламировался, он был размещен только на двух зарубежных архивах -bhs.com и tucows.com (их тогда было очень мало) и на единственном российском -- ntutils.quarta.ru. Tucows дал Eserv средненький рейтинг 4 "коровы", и этот рейтинг Eserv/1.1 так и сохранился за ним пожизненно (периодически только меняют номер версии на сайте). Сайт Eserv тогда состоял из одной невзрачной страницы www.enet.ru/win/cherezov/e-serv.html. Чуть позже Web-мастер компании "Етайп" Олег Дулецкий сделал более симпатичный сайт, темы которого были использованы и в Web-интерфейсе Eserv. Несколько копий Eserv в 1997 году было продано в Германию.
Конкуренции тогда никакой не ощущалось — единственным прокси-сервером для Windows был WinGate, из почтовых серверов были только сверхдорогой MS Exchange 4.x и NT Mail. Оба они не умели вытворять с РОРЗ такие трюки, как Eserv, поэтому конкурентами не считались. Чуть позже появились VРорЗ, чешский WinProxy и Mdaemon, но Eserv тогда уже прочно стоял на ногах.
Интересно, что о продаже Eserv на Запад и даже вообще о продажах Eserv вне Калининграда в начале 1997 года никто и не задумывался. Расширить продажи Eserv предложил технический директор "Етайп" Виталий Воронин.
Незарегистрированная версия Eserv тогда ничем не отличалась от коммерческой, пользователи платили не за снятие каких-то ограничений, а просто в качестве "спасибо" за Eserv. Все ограничения, связанные с shareware, появились позже, к осени 1997 года.
Eserv был написан очень вовремя — многие тогда искали замену для DOS UUPC, и ничего подходящего, кроме Eserv, не было ни в России, ни на Западе. Поэтому пользователи рекомендовали Eserv друг другу, и популярность его быстро росла. Сайт тоже был популярен — в первой двадцатке соответствующей категории рейтинга Rambler (top100.rambler.ru/top100).
В октябре 1998 года начались продажи версии 2.0 (это была полностью переписанная с нуля намного более мощная версия, чем 1.6). К тому моменту было уже несколько сотен пользователей версий 1.x, почти все сразу стали приобретать апгрейды (за 20$) и было очень много новых пользователей. Цена на версию 2.0 была установлена в размере 90$ по результатам голосования пользователей на сайте.
Да, сообщество пользователей Eserv, виртуально обитающее в форуме сайта, внесло большую лепту в выработку как технических, так и "маркетинговых" решений в Eserv. Форум все эти годы нежно лелеялся и переносился с сайта на сайт вслед за Eserv. Сейчас там около 15 000 сообщений — настоящая "база знаний".
Уже к ноябрю 1998 года заказы на приобретение Eserv шли таким мощным потоком, что полуручная система продаж, существовавшая в "Етайп", перестала справляться с ним. Андрей Черезов в срочном порядке написал "электронный магазин", где счета выписывались полностью без участия людей, ключи на Eserv автоматически формировались на основе данных из оплаченных счетов, все документы для российских пользователей (счета-фактуры, накладные) тоже автоматически формировались в Web-интерфейсе. Все было автоматизировано, вплоть до печати адресов на конвертах, и все было доступно через Web-интерфейс персоналу компании и пользователям Eserv.
В 1999 году Eserv переехал на домен www.eserv.ru и получил новый дизайн. Большая база установленных Eserv/2.x и относительная сложность Eserv для пользователей (по сравнению с типичными shareware-продуктами, не требующими знания сетевых технологий) привела к некоторому замедлению работ над Eserv/3.0 по сравнению с планом — много времени отнимала поддержка. Сейчас ею занимается несколько человек. Тем не менее, Eserv/3.0 к моменту выхода этой книги, скорее всего, уже появится.

Freeware и другие

Freeware и другие

Говоря об индустрии программного обеспечения, помимо shareware, упоминают и другие типы программ. Вкратце расскажу о них.

Freeware

Freeware

Это свободно распространяемые программы, за использование которых не нужно платить, благодаря чему "freeware" стало синонимом слова "бесплатно". Как это ни странно, сегодня, когда продажа программ является прибыльным бизнесом, число сторонников freeware даже среди серьезных компаний не уменьшается: бесплатная программа — прекрасный инструмент для продвижения новых технологий и продуктов. Например, успех формата документов PDF фирмы Adobe во многом обусловлен бесплатным распространением программы просмотра Acrobat Reader. Браузер Microsoft Internet Explorer, программа общения ICQ — все это примеры популярных бесплатных продуктов, имеющих очень сильные позиции по отношению к своим конкурентам.
Более того, некоторые shareware-продукты становятся бесплатными. Яркий пример -- знаменитый мультимедиа-проигрыватель WinAmp (http:// www.winamp.com). Первоначально он был shareware-программой стоимостью в десять долларов, а после того, как сайт winamp.com стал привлекать миллионы посетителей, разработчики, получая солидные доходы от рекламы, решили сделать свой продукт бесплатным, еще больше увеличив его популярность.

Главная страница официального сайта SIC

Рисунок 1.3. Главная страница официального сайта SIC

Главное окно программы FlashGet

Рисунок 1.1. Главное окно программы FlashGet, демонстрирующей рекламный баннер


Так как загрузка новых рекламных баннеров осуществляется по Интернету с серверов соответствующих рекламных служб, то adware — это в основном такие программы, для работы которых требуется соединение с Интернетом — например, браузеры (Opera), download-менеджеры (ReGet, FlashGet), программы дозвона или ускорители соединения с Интернетом.
Перечисленные выше типы программ сегодня являются наиболее популярными среди разработчиков программного обеспечения. Однако существуют и другие, менее популярные категории программ, о которых, тем не менее, нельзя не упомянуть.

Главное окно ReGet с открытым окном новой закачки

Рисунок 1.4. Главное окно ReGet с открытым окном новой закачки


В марте 1999 года было принято решение расширить штат компании. На работу приняли еще одного программиста, затем появился человек, ответственный за поддержку пользователей, потом новые программисты.
В том же году принято еще одно очень важное решение: выпустить ReGet со встроенным рекламным модулем. Начиная с версии 1.5, ReGet распространяется в двух вариантах: ReGet Pro, который требует регистрации с первого запуска, и ReGet Free, который не требовал регистрации, но показывал рекламные баннеры, т. е. эта версия была adware (см. разд. "Freeware и другие" данной главы). После этого продажи, как и ожидалось, резко упали, но за счет обширной пользовательской аудитории это с лихвой компенсировалось выручкой от показов рекламы.
В январе 2000 года ReGet стал продаваться и на российском рынке. Цена для российских пользователей была установлена в 210 рублей, что является относительно небольшой суммой для такой сложной программы.
В настоящее время, по оценкам компании ReGet Software, аудитория ReGet исчисляется сотнями тысяч человек.

Homepageware

Homepageware

Эти программы напоминают adware. Пользователь не обязан оплачивать регистрацию, но незарегистрированная копия программы при каждом своем запуске автоматически; меняет начальную страницу установленного в системе браузера на домашнюю страницу программы. Homepageware не очень распространено, видимо, потому, что такое варварское обращение с пользовательскими настройками очень раздражает. Кроме того, такая программа сегодня, во времена скандалов, связанных с нарушением приватности и распространением "троянских коней", вызывает подозрения — не производит ли она какие-либо еще более вредоносные действия?

История shareware

История shareware

Open Source

Open Source

Open Source — это развитие концепции public domain software, в которой учтены ошибки предыдущих поколений программистов. "Open Source" можно перевести как "открытый исходный код". Авторы, следующие этой концепции, прежде всего должны распространять свой продукт вместе с исходными текстами. Однако Open Source не ограничивается только условием предоставления исходных текстов программы. Open Source — это система требований к лицензии на программный продукт, которая называется The Open Source Definition (OSD) и представлена на сайте http:// www.opensource.org.
Так, лицензия на продукт не может запрещать распространение программы в составе сборников и коллекций программного обеспечения (как коммерческих, так и бесплатных), а также устанавливать комиссионные отчисления или другие платежи за право распространять программу. К программе обязательно должен быть приложен исходный код. Модифицированное программное обеспечение должно распространяться на тех же самых условиях, что и исходный продукт. Автор исходного продукта даже имеет право требовать, чтобы исходный код к будущим модификациям его программы распространялся без изменений, но в комплекте с соответствующими модифицирующими патчами (patches -- "заплатки").
Полный текст OSD можно прочитать по адресу www.opensource.org/osd.html.
Наиболее сильные позиции концепция Open Source традиционно имеет среди разработчиков программ для операционной системы Linux. Один из самых известных и успешных проектов Open Source — Web-сервер Apache (http://www.apache.org), установленный на большинстве интернет-серверов в мире. Так как этот продукт распространяется в виде исходных текстов, то очень быстро были созданы не только версии Apache для различных платформ, но и его интернациональные версии. Например, Russian Apache (http://apache.lexa.ru) учитывает многообразие русских кодировок текста и обеспечивает правильное отображение текста вне зависимости от типа кодировки, установленной на сервере или в браузере пользователя.
Однако и среди Windows-программ встречаются open source-продукты. Особенно много их среди VCL-компонентов для Borland Delphi и C++ Builder.

Отцыоснователи

Отцы-основатели

Более двадцати лет назад, еще до появления первого IBM PC в 1981 году, распространение платных программ было прерогативой компаний, разрабатывавших и продававших коммерческое программное обеспечение. Программисты-одиночки, писавшие программы для СР/М, Radio Shacks и Apple, распространяли их бесплатно среди групп пользователей и на BBS. Авторы и не думали брать за эти программы какие-то деньги: ведь программы были небольшие, не обеспечивались технической поддержкой и, по мнению разработчиков, не обладали какой-либо рыночной ценностью. Подругому, наверное, и не могло быть, т. к. BBS служили средой для обмена в том числе и пиратскими копиями коммерческого программного обеспечения.
С появлением персонального компьютера IBM PC ситуация не изменилась. Для новой платформы были написаны мощные по тем временам программы: MS DOS, текстовый редактор WordStar, электронная таблица VisiCalc, стоившие довольно дорого: например, цена VisiCalc составляла $200. Программисты-одиночки все также писали небольшие программы и распространяли их бесплатно.
В конце семидесятых годов прошлого века программист Джим Кнопф (Jim Knopf) (p. 1943), работавший в IBM, написал для компьютера Apple программу для печати почтовых этикеток Easy-File. Однако эта программа, по сути, представляла собой небольшую систему управления базой данных (СУБД) и допускала более широкое использование: например, сам Кнопф использовал ее для учета пользователей своей программы.
В 1981 году Кнопф продал свой компьютер Apple II и приобрел только что появившийся в продаже IBM PC. Естественно, он сразу же портировал на новую платформу свое детище (Easy-File была написана на Basic).
Как и многие программисты-одиночки в то время, он распространял свою программу бесплатно. Пользователи Easy-File также бесплатно получали письма (не e-mail, а обычной почтой) с уведомлениями о выходе новых версий. Однако рассылка почтовых отправлений стоила автору немалых денег, и в 1982 году он придумал способ компенсировать свои расходы.
Кнопф продолжал распространять свою программу бесплатно, однако в документации указывал, что каждый, кто желает, может заплатить десять долларов за техническую поддержку программы, в частности, получение писем с уведомлениями о новых версиях программы. Также подчеркивалось, что регистрация программы окажет поддержку автору в разработке и совершенствовании программы.
Примечание
Примечание


Кнопф называл себя Джим Кнопка (Jim "Button"), т. к. "кнопф" по-немецки означает именно "кнопка", и под этим псевдонимом он получил всемирную известность. По его мнению, английское "Button" было более благозвучным и более удобным для маркетинговых целей, чем немецкое "Knopf".
Один из первых пользователей, получивших программу Easy-File, содержащую такую необычную по тем временам просьбу зарегистрироваться, тут же позвонил Кнопфу. Оказалось, что в то же время другой программист, Эндрю Флюгльман, написал коммуникационную программу PC-Talk и стал распространять ее примерно на тех же условиях, что и Кнопф: за техническую поддержку он просил 25$. Кнопф незамедлительно связался с Флюгль-маном, который был очень обрадован тем, что нашел, единомышленника. Коллеги выработали общую стратегию в продвижении своих продуктов: Кнопка назвал свою программу похоже — PC-File, были установлены одинаковые цены на регистрацию программ (25$=), а в документации Флюгльман и Кнопф ссылались на программы друг друга.
В то время мало кто разделял оптимизм Кнопфа и Флюгльмана относительно будущего их новой инициативы. Жена Кнопфа, например, прямо называла его "старым дураком" (old foolish man), т. к. трудно было представить, что хоть кто-то заплатит какому-то программисту-оди ночке деньги за его программу.
Путь распространения программ, избранный Флюгльманом и Кнопфом, оказался очень успешным. Довольно большое количество пользователей изъявили желание оплатить регистрации PC-Talk и PC- File.
Вскоре в популярнейшем компьютерном журнале PC-World появился обзор, в котором PC-File получил великолепные отзывы. Джим Кнопф вспоминает:
"Я со своей семьей проводил отпуск на Гавайях, когда журнал появился на прилавках. Реакция публики была ошеломляющей! Наша домработница была вынуждена забирать почту мешками. Когда мы вернулись домой, эти мешки устилали весь цокольный этаж, и нам приходилось с трудом пробираться среди них, чтобы спуститься в подвал. Мой сын, Джон1, работал днями и вечерами все лето, чтобы только разобрать содержимое этих мешков! Для каждого из нас жизнь уже не могла оставаться такой, как прежде!"
По мнению Кнопфа, потрясающий успех PC-File и PC-Talk был обусловлен следующими факторами:

относительно низкая цена программ по сравнению с аналогами, имевшимися в то время на рынке;

возможность для пользователей попробовать программу в использовании, перед тем, как оплатить се регистрацию, что было исключено при продаже коммерческих программ;

прежде реализация программ шла преимущественно через специализированные магазины. Инициатива Кнопфа и Флюгльмана была радикально новым маркетинговым ходом, и компьютерные издания с большой охотой писали о новом методе распространения программ, что привлекло к PC-File и PC-Talk огромное внимание публики.

Правда, при этом программисты не сразу решились сделать этот бизнес своим основным занятием: Кнопф, например, продолжал работать в IBM, получая в десять раз меньшую зарплату, чем доход, который приносила ему PC-File. Только в 1984 году он был вынужден покинуть IBM, т. к. не мог работать восемь часов днем, а затем еще четыре часа вечером (а также все выходные) посвящать своему "хобби".
Разработка, распространение и техническая поддержка программ, которыми занимались Кнопф и Флюгльман, по сути, и были тем, что сегодня называют shareware. Но тогда этого термина еще не существовало. Флюгльман называл это "freeware". Он даже зарегистрировал это слово как собственную торговую марку, и с этого момента никто не мог использовать термин "freeware" без разрешения автора PC-Talk.
Несмотря на это, Флюгльман потерпел неудачу. Дело в том, что он распространял PC-Talk вместе с исходными текстами, руководствуясь популярной с семидесятых годов прошлого века концепцией public domain software. Очень скоро он потерял контроль над своей программой, т. к. десятки программистов стали распространять собственные продукты, написанные на основе PC-Talk. Впоследствии Флюгльман перестал развивать и поддерживать PC-Talk, потеряв интерес к shareware-бизнесу.
А вот Джим Кнопф выбрал более успешный путь. Он продолжал работу над PC-File, число зарегистрированных пользователей программы росло. Уйдя в 1984 году из IBM, Кнопф основал собственную фирму. В 1987 году в его компании работало 18 человек, и она продавала 10 различных продуктов, а количество зарегистрированных пользователей составило более миллиона человек. Вскоре штат компании увеличился до 35 человек, а объем продаж достиг четырех с половиной миллионов долларов в год.
В 1983 году другой программист, Боб Уоллес (Bob Wallace) (p. 1949), создал текстовый редактор PC-Write и стал распространять его по более экзотичной для тех времен схеме. Регистрация стоила довольно дорого для небольших программ -- 75$, но после оплаты пользователь получал уникальный регистрационный номер, который выводился на заставке программы. Другой пользователь, желавший зарегистрировать свою копию PC-Write, сообщал Уоллесу регистрационный номер, выводившийся на стартовой заставке в его копии программы, т. е. номер человека, предоставившего ему программу. И тот, кто распространил PC-Write среди пользователей, получал от Уоллеса комиссионные. Так пользователи имели возможность не только компенсировать собственные деньги, затраченные на регистрацию программы, но и заработать в несколько раз больше. Например, Майк Качлахан (Mike Callahan), также известный как Dr. FileFinder, который сегодня является признанным экспертом в области shareware, в свое время заработал на регистрациях PC-Write около пятисот долларов.
Замечание 1
Замечание 1


Сегодня такие "партнерские программы" (affiliate programs) очень популярны. Многие авторы программ готовы заплатить до 50% владельцу того сайта, по ссылке с которого пользователь посетил Web-страницу shareware-программы и затем зарегистрировался.
Этот продукт так же, как и PC-File с PC-Talk, оказался очень успешным. Боб Уоллес открыл собственную компанию, QuickSoft, в которой впоследствии работало более 30 человек, а годовой оборот составлял два миллиона долларов. Кстати, именно Боб Уоллес впервые стал называть свою программу "shareware", хотя этот термин не сразу стал популярен.
Нельсон Форд (Nelson Ford), основавший в 1984 году компанию PsL, в это же время вел колонку о таких программах в одном популярном тогда компьютерном журнале (предположительно это был PsL News). Перед Фордом стояла проблема — как называть программы, о которых он пишет? Да, термин "freeware" был широко известен, но он являлся торговой маркой Флюгльмана и не мог использоваться в коммерческих целях. Пытаясь как-то выйти из этой затруднительной ситуации, употребляли сочетание "user supported software" - однако оно было слишком громоздким и к тому же двусмысленным: то ли "программы, поддерживаемые пользователем", то ли "программа с технической поддержкой пользователя".
Чтобы окончательно решить проблему, Форд объявил на страницах журнала конкурс на лучшее наименование этого типа программ. Тогда-то Боб Уоллес и предложил термин "shareware", которым он называл свою программу PC-Write. Уоллес, в отличие от Флюгльмана, не требовал каких-либо прав на термин shareware: по его словам, он увидел это слово в каком-то старом компьютерном журнале еще тех времен, когда о персональных компьютерах IBM PC никто и не думал.
В то время было еще много небольших программ и утилит (например, популярная программа LIST Вернона Берга (Vernon Buerg)), и эти три программы — PC-File, PC-Talk и PC-Write стали наглядным примером того, что написанные программистами-одиночками shareware-программы могут быть реальной альтернативой коммерческим продуктам. Вслед за ними на рынке shareware появилось много новых программ, и нет ничего удивительного в том, что их тоже ждал успех.
А чем сегодня занимаются отцы-основатели shareware? К сожалению, Эндрю Флюгльман скоропостижно скончался в 1987 году. В 1997 году он был посмертно награжден престижной премией "Shareware Industry Award" (см. далее разд. "Профессионалы shareware" этой главы). Термин "freeware", который был зарегистрирован на него, сегодня обозначает просто бесплатные программы. Джим "Кнопка" Кнопф пережил сердечный приступ в 1992 году, когда ему было 49 лет ("В таком нежном возрасте!" - сокрушался Джим) и, решив, что shareware доставляет ему слишком много тревог и волнений, продал свою компанию и ушел из большого бизнеса. В настоящее время он официально находится па пенсии. Боб Уоллес в 1991 году продал свою преуспевающую компанию QuickSoft и отошел от компьютерного бизнеса, посвятив себя написанию психоделических книг. В 2000 году за заслуги в деле становления shareware-индустрии имена Джима Кнопфа и Боба Уоллеса были помещены в Зал Славы (Hall of Fame) Ассоциации профессионалов shareware (см. разд. "Профессионалы shareware" данной главы).

Postcardware или Cardware

Postcardware, или Cardware

Экзотический способ распространения программ, при котором автор просит пользователей зарегистрироваться, прислав ему почтовую открытку. Этот способ вообще не может принести какие-либо деньги — только коллекцию открыток с видами различных уголков земного шара.

Профессионалы shareware

Профессионалы shareware

В середине восьмидесятых годов молодой рцнок shareware привлек тысячи программистов, многие из которых стремились во что бы то ни стало заработать как можно больше денег, причем как можно быстрее. Стремясь получить прибыль и столкнувшись с тем, что пользователи не очень активно регистрировали свои копии программ (что было не удивительно, учитывая многообразие представленных на рынке shareware-программ и наличие множества коммерческих дистрибьюторов), авторы стремились стимулировать пользователей оплачивать регистрации программ. Но сложными схемами, наподобие той, которую применял Боб Уоллес при распространении PC-Write, мало кто себя утруждал. В ход шли более простые и грубые приемы: например, лицензионные соглашения к программам составлялись в таком тоне, что пользователь заочно подозревался в намерении украсть программу, а некоторые авторы вообще писали, что наложили на пользователя проклятие, которое будет действовать до тех пор, пока не будет оплачена регистрация программы.
При этом авторы программ, буквально "выбивая" из пользователей деньги, зачастую не обеспечивали должный уровень поддержки. Программист мог обещать потенциальным покупателям что угодно — круглосуточную техническую поддержку, бесплатные будущие версии продукта, подписку на рассылку уведомлений о новых версиях, а после получения денег мог просто забыть о своем новом зарегистрированном пользователе, или, что еще хуже, вообще исчезнуть. Это привело к тому, что имиджу shareware как реальной альтернативе коммерческих продуктов был нанесен огромный урон. До сих пор почти все крупные корпорации, распространяющие некоторые свои продукты фактически как shareware (та же Microsoft, например), и даже некоторые небольшие компании, изначально ориентированные на рынок shareware, избегают использовать этот термин, применяя более нейтральные обозначения, например, "trial" или "try-before-you-buy".
Естественно, такое положение дел не могло устраивать тех авторов shareware, которые серьезно относились к своему бизнесу. Некоторые из них стали высказывать предложения о необходимости ликвидировать царящий в отрасли хаос и навести порядок на рынке shareware. В 1987 году в Хьюстоне (Техас, США) ведущие авторы shareware, среди которых были Джим Кнопф, Боб Уоллес, Том Смит (Tom Smith, автор популярной коммуникационной программы ProComm), а также представители крупнейших дистрибьюторов shareware (PC-SIG, PBL) и администраторы BBS, собрались на конференцию, посвященную решению этого вопроса. На этой конференции была создана Ассоциация профессионалов shareware — Association of Shareware Professionals (ASP, http://www.asp-shareware.org).
ASP - это некоммерческая организация, первоначально объединявшая профессиональных разработчиков shareware-программ, в которую позже стали приниматься и дистрибьюторы программного обеспечения. Руководит ASP Совет директоров, который непрерывно "заседает" в режиме online с 1987 года — что, скорее всего, является мировым рекордом. Первым председателем совета был избран Джим Кнопф.
ASP установила четкие правила для авторов shareware-программ: не ограничивать без меры функциональные возможности незарегистрированных копий программ, обеспечивать техническую поддержку покупателей, обращаться с пользователями с должным уважением и не оскорблять их. Логотип ASP, размещенный в программе, должен служить своеобразным знаком качества, подтверждающим надежность и солидность автора соответствующего программного продукта.
Правила были установлены и для компаний-распространителей программного обеспечения. Дистрибьюторы shareware-программ, являющиеся членами ASP, не должны вводить потребителей в заблуждение, называя shareware-программы "бесплатными", а также обязаны уважать права авторов программных продуктов.
ASP является сообществом авторов и распространителей программ, где участники делятся своими идеями относительно будущего shareware, обмениваются опытом, помогают друг другу решить возникающие проблемы. ASP оказывает своим членам посильную поддержку в деле продвижения их программных продуктов на рынке. Кроме того, споры между членами ASP и их заказчиками, где стороны не могут по каким-то причинам прийти к соглашению, разрешаются выборным третейским судьей из ASP.
ASP также защищает от посягательств индустрию shareware, и она, как мощная организация, обладает для этого значительно большими возможностями, чем программисты-одиночки. Так, в свое время ASP помешала компании PC-SIG зарегистрировать слово "shareware" как торговую марку. Под влиянием ASP Конгрессом США были внесены поправки в проект одного закона, первоначальная редакция которого была неприемлемой для успешного развития индустрии shareware.
Об ASP и преимуществах членства в этой организации рассказывается в разд. "Ассоциация профессионалов shareware " гл. 10.
Еще одно важнейшее явление в мире профессионалов shareware — ежегодная международная конференция Shareware Industry Conference (SIC, http://www.sic.org).
Осенью 1990 года, встретившись на крупной компьютерной выставке Comdex Fall, группа профессиональных участников рынка shareware, среди которых были уже упоминавшиеся ранее Боб Острандер и Майк Каллахан, Маршалл Маги (Marshall Magee), известный тем, что он первый из разработчиков shareware заработал на этом рынке миллион долларов, Рэнди
МакКлин (Randy MacLean) и Джим Перкинс (Jim Perkins) из компании FormGen, а также Парис Карахалиос (Paris Karahalios), глава компании Triolis, пришли к выводу, что профессионалам shareware нужна собственная конференция, без всей этой суеты и рекламной шумихи, которую сопровождают компьютерные выставки. На такой конференции авторы и продавцы shareware могли бы обмениваться опытом, сообща принимать важные решения, касающиеся будущего shareware, да и вообще просто общаться "вживую".
Через несколько месяцев, в июне 1991 года, благодаря деятельности Боба Острандера и финансовой поддержке его компании PBL, такая конференция состоялась в Индианаполисе (Индиана, США). Тогда она называлась "Летний shareware-семинар" (Summer Shareware Seminar, SSS), и на ней присутствовало около ста человек.
На этой конференции родилась концепция наград share ware-индустрии (Shareware Industry Awards, SIA). Майк Каллахан высказал идею учредить престижную Премию, которая привлекала бы внимание общественности к shareware, придала бы ей значение одной из ведущих отраслей в компьютерной индустрии (ведь в то время еще очень многие считали, что shareware -это удел одиночек и программистов-любителей). Этому, в частности, должна была способствовать и церемония награждения лауреатов Премии, которая бы стала аналогом церемонии вручения знаменитой премии в области киноискусства "Оскар". Инициатива Майка была поддержана его друзьями, идеологами SSS Острандером, МакКлином, Карахалиосом и Перкинсом.
Пятеро друзей основали компанию Shareware Industry Awards Foundation (SIAF), чтобы новая Премия получила официальный статус и была законодательно защищена. Они разработали порядок церемонии вручения Премии, дизайн самих наград, требования к претендентам, механизм голосования и прочие детали. Они решили, что будут принимать участие в работе SIAF по крайней мере три года, если не больше — до тех пор, пока Премия не укрепит свои позиции и дело можно будет передать новым людям. Первое вручение Премии состоялось уже на следующем SSS, в 1992 году, и, по общему мнению, совмещение конференции и церемонии вручения Премии было как нельзя более удачным.
После того как компания PBL, генеральный спонсор Summer Shareware Seminar, была приобретена корпорацией Ziff-Davis, SIAF в 1994 году взяла на себя расходы по проведению конференции, которая с этого момента стала называться Shareware Industry Conference.
После конференции 1994 года, когда стало ясно, что Премия окончательно укрепила свои позиции, в SIAF были приглашены новые специалисты, и почти все основатели компании оставили свою деятельность по подготовке и вручению Премии: сегодня только Майк Каллахан, "отец" Shareware Industry Awards, продолжает работать в совете директоров SIAF.
С каждым годом масштабы проведения Shareware Industry Conference росли, и сегодня SIC является самым значительным событием в shareware-ин-
дустрии (Рисунок 1.3). Премия Shareware Industry Awards вручается более чем по тридцати номинациям как лучшим shareware-продуктам, так и людям, чья деятельность содействовала развитию shareware-индустрии. В конференции ежегодно принимают участие крупнейшие участники рынка shareware — ведущие разработчики программного обеспечения, представители компаний-регистраторов и основных интернет-архивов программ, словом — вся элита shareware. Естественно, каждый из профессиональных участников рынка shareware старается во что бы то ни стало выкроить время в своем рабочем графике и прилететь на очередную Shareware Industry Conference.

Public domain software

Public domain software

Как и freeware, public domain программы также распространяются бесплатно. Однако в отличие от freeware, где автор программы сохраняет за собой все права на нее, разработчик public domain отказывается от своих авторских прав на соответствующую программу: такие программы распространяются вместе с исходными текстами и любой желающий может вносить в программу свои изменения и создавать на ее основе новые продукты.
К сожалению, концепция public domain software не оправдала себя. Основная цель public domain — свободное распространение и развитие программ без всяких ограничений - вскоре потеряла свое значение. Каждый мог взять исходные тексты программы, слегка модифицировать их, а затем распространять эту программу как собственную на коммерческой основе. Автор исходной программы, отказавшись от авторских прав на нее, не имел никакой возможности защитить свое творение.
Яркий пример — X Window, графическая оболочка для операционной системы Unix. Она была разработана компанией MIT и выпущена в свет, снабженная исходными текстами и лицензионным соглашением с очень мягкими условиями. Многие компании, выпускающие коммерческие (и часто очень дорогостоящие) дистрибутивы ОС Unix, включили X Window в свои продукты, естественно, не в виде исходных текстов, а в скомпилированном виде. Поэтому мало кто из пользователей Unix работал с действительно бесплатной X Window, а о свободном распространении и развитии новых вариантов оболочки, ввиду закрытости исходных текстов и наличия коммерческих лицензий, не могло быть и речи.
Примечание
Примечание


Стоит отметить, что компания MIT, разработчик X Window, предвидела такое развитие событий. Просто главной целью в проекте X Window было не "свободное развитие", а распространение продукта среди максимального числа пользователей Unix.

Распространение sharewareпрограмм

Распространение shareware-программ

В период зарождения freeware и shareware, в 1981 — 1982 гг., распространение программ было свободным и бесплатным: в основном это был обмен дискетами среди групп пользователей и копирование программ с BBS. В последнем случае пользователи оплачивали только счета телефонных компаний. Однако число пользователей росло, объемы библиотек и коллекций программ на BBS увеличивались, и их владельцы начали задумываться о том, чтобы как-то компенсировать свои затраты времени, сил и средств. Некоторые администраторы архивов и "сисопы" (системные операторы) BBS стали взимать с пользователей плату за доступ к своим коллекциям программного обеспечения.
В это время Ричард Петерсон (Richard Peterson) из Калифорнии опубликовал в популярном журнале PC Magazine рекламное объявление, где предлагал всем желающим дискету с коллекцией бесплатных и условно-бесплатных программ за шесть долларов. Программы были взяты с BBS одной из групп пользователей, которые, конечно же, возмутились. По их мнению, распространение программ за деньги было абсурдом. Однако очень многим пользователям из разных городов, которые не могли часами перекачивать программы с BBS, предложение Петерсона показалось очень привлекательным. Вдохновленный успехом своей инициативы, Петерсон основал первую компанию по коммерческому распространению дисков с бесплатными и условно-бесплатными программами — PC-SIG (Special Interest Group).
В 1984 году уже упоминавшийся ранее Нельсон Форд открыл компанию Public Software Library (PsL, http://www.pslweb.com), которая занималась распространением программ на дискетах по почте, а также на выставках. Эта компания стала издавать первый журнал о shareware — PsL News.
Примечание
Примечание


PsL News представляет собой журнал, содержащий обзоры программ, появляющихся на рынке. Он печатался с конца 1985 по март 1996 года, а затем был заменен на приложение, размещающееся на CD-ROM с shareware-программами, которое ежемесячно выпускает PsL.
В 1985 году Боб Острандер (Bob Ostrander) создал компанию Public Brand Software (PBS), которая так же, как и PsL, занималась распространением программного обеспечения по почте и на выставках и вместе с PsL была одним из главных дистрибьюторов shareware и freeware. В 1991 году PBS была приобретена компанией Ziff Davis Interactive и составила основу одного из крупнейших online-каталогов программ ZDNet (http://www.zdnet.com /downloads). Следующими из крупных дистрибьюторов появились фирмы Software Labs и Reasonable Solutions, а после них на рынок буквально хлынули сотни и тысячи мелких торговцев, мечтавших быстро разбогатеть на распространении дискет с программами.
Несмотря на то, что PsL, PBL и другие брали деньги не за сами программы, а за дискеты, содержащие соответствующие файлы (т. е. за доставку программ потребителю), их деятельность вызывала большое недовольство авторов распространяемых программных продуктов. Коммерческие дистрибьюторы программ наживали миллионы долларов, по сути, на чужом труде. Они не гарантировали выплату авторам комиссионных от проданных дисков с программами, да чаще всего и не стремились к этому. С другой стороны, брошенный дистрибьюторами клич "Расхватывайте бесплатные программы!" (Get Free Software!) и рекламные акции, которые подчеркивали бесплатность распространяемых продуктов, вводил пользователей в заблуждение, и они не стремились регистрировать свои копии shareware-программ. Многие авторы shareware, в том числе и знаменитый Джим Кнопф, прямо запрещали коммерческое распространение своих программ по каналам дистрибьюторов (правда, для PsL Джим все-таки сделал исключение).
С распространением World Wide Web многие дистрибьюторы программ на дисках и платные BBS открыли собственные Web-сайты и попытались вести свой бизнес по старым законам — например, взимая деньги с пользователей за доступ к сайту. Однако они обнаружили, что в Сети уже существует множество сайтов, которые размещают у себя программы и не берут со своих посетителей ни цента. В новых условиях многие дистрибьюторы, в середине восьмидесятых распространявшие программы на дискетах, не выдержали конкуренции с online-архивами ПО и закрылись. Сами интернет-каталоги программ, в свою очередь, часто не оправдывали ожиданий их создателей: затраты росли, а рекламные поступления не компенсировали вложенных капиталов. Некоторые архивы оказались поглощенными более крупными архивами, другие, например BestZips, просто прекратили свое существование.
Замечние
Чтобы выжить, коммерческие дистрибьюторы программ и интернет-архивы программного обеспечения перенимали друг у друга удачные приемы ведения бизнеса: дистрибьюторы заводили у себя бесплатные архивы программного обеспечения, а интернет-архивы стали периодически выпускать на CD-ROM сборники программ, опубликованных у них, и продавать их. Грань между этими двумя видами бизнеса почти стерлась.
По мере того, как дешевели высокоскоростные модемы и услуги провайдеров, Интернет становился доступен все большему количеству пользователей, а также привлекал крупных коммерческих участников. В ноябре 1995 года корпорация CNet открыла сервер Shareware.com, 23 октября 1996 года она же запустила проект Download.com, который сегодня является одним из самых авторитетных интернет-архивов программного обеспечения (Рисунок 1.2). Появились Web-сайты, посвященные бесплатным и условно-бесплатным программам, и у других компаний. С этого времени основным каналом распространения shareware-программ является Интернет. Однако коммерческие дистрибьюторы программ, несомненно, занимают почетное место в истории shareware, т. к. миллионы пользователей именно через них узнали о shareware-программах и во многом благодаря им shareware завоевало огромную популярность во всем мире.

Развитие индустрии shareware

Развитие индустрии shareware

Помимо образования Ассоциации профессионалов shareware и Shareware Industry Conference, в истории shareware было еще несколько важных этапов, о которых нельзя не рассказать.

В 1987 году была создана компания Apogee, первый производитель shareware-игр. Ее основатель, Скотт Миллер (Scott Miller), придумал оригинальный способ распространения игровых программ: игра разделялась на несколько эпизодов или уровней, в первый из которых пользователь мог поиграть бесплатно, а остальные становились доступными только после регистрации. Одна из самых популярных shareware-игр, Wolfshtein 3D компании ID Software, а также более поздние ее же хиты Doom и Quake были выпущены именно по этой схеме. Компания Apogee, кроме этого, знаменита еще и тем, что первая начала распространять и рекламировать игры других разработчиков, а также тем, что была первой из компаний, открывших собственную BBS для поддержки своих пользователей.

В 1989 году система PsL запустила первый процессинговый центр по приему и обработке платежей по кредитным картам и заказов, сделанных по телефону, факсу, электронной и обычной почте. Эти услуги оказывались shareware-авторам без взимания какой-либо дополнительной платы, а лишь за относительно небольшие комиссионные. Множество независимых shareware-программистов, до этого не имевших возможности принимать платежи самостоятельно или имевших большие затруднения с этим, теперь смогли улучшить качество обслуживания своих покупателей и одновременно посвящать больше времени совершенствованию своих продуктов. В последующее время, особенно с распространением Интернета в 1997—1998 годах, появилось множество компаний, позволяющих обслуживать заказы, сделанные по телефону, почте, факсу и т. д., а также принимать платежи по кредитным картам. Об особенностях работы с такими компаниями-регистраторами рассказывается в гл. 10.

Годы 1991 — 1993 знаменательны тем, что в этот период продажи программ на гибких дисках практически прекратились: дискета как носитель файлов с архивами программ оказалась вытеснена стремительно набиравшим популярность диском CD-ROM (с 1994 года во всехифупных магазинах США новые компьютеры продавались только с установленными CD-ROM-дисководами).

В 1996 году, как уже упоминалось, был открыт сайт корпорации CNet Download.com и еще несколько крупных online-архивов программного обеспечения, и Интернет стал основным каналом распространения shareware-программ.

ReGet

ReGet

ReGet (http://www.reget.com)— один из самых известных так называемых download-менеджеров, т. е. программ, обеспечивающих комфортную загрузку файлов с FTP- и HTTP-серверов. Автор программы — Владимир Романов.
В 1996 году Владимир Романов работал инженером службы поддержки фирмы "Поликом Про" (Санкт-Петербург). Одной из его обязанностей была регулярная загрузка новых версий программного обеспечения с сервера компании Microsoft, который тогда не поддерживал докачку — т. е. возобновление загрузки файла при разрыве связи или остановки процесса загрузки по каким-либо другим причинам. Отсутствие докачки при загрузке больших файлов доставляло Владимиру много хлопот, и когда, наконец, в очередной версии Microsoft Internet Information Server поддержка докачки появилась, Владимир решил написать программу, которая использовала бы эту возможность, что и было сделано в течение месяца (Рисунок 1.4).
Первоначально RegGet имел только консольный интерфейс и назывался WWW Reget. Еще через два месяца появилась версия с графическим интерфейсом, и в конце февраля 1997 года программа была представлена на суд общественности. Владимир не питал особых надежд на какой-либо коммерческий успех своего детища, поэтому ReGet разрабатывался только в свободное от основной работы время и распространялся исключительно по каналам некоммерческой сети FIDO.
Все переменилось после встречи Владимира Романова со Станиславом Гришиным, работавшим тогда региональным торговым представителем московского отделения Microsoft. Станислав сразу разглядел коммерческий потенциал ReGet и предложил план по постепенному превращению ReGet из freeware в shareware. Первым шагом в этом плане было создание официального сайта ReGet с регистрацией для него собственного домена -www.reget.com.
Появление программы в Интернете было с интересом встречено аудиторией. Многие каталоги программного обеспечения разместили у себя ReGet. Благодарные пользователи предлагали Владимиру помощь в переводе интерфейса программы на различные языки. Сначала появилась японская, затем — французская и немецкая версии.
В это время Владимир Романов был внезапно уволен с работы — директор компании случайно наткнулся на страницу, где Владимир разместил свое резюме с пожеланием гораздо более высокой, чем была, зарплаты. У него появилось много свободного времени, и он решил полностью сосредоточиться на развитии ReGet. Программа была практически переписана заново, в нее добавилось множество новых функций. Было решено наконец-то перевести ReGet из разряда свободно распространяемых программ в shareware с 30-дневным ограничением (бесплатная версия осталась только для русскоязычных пользователей). Владимир Романов и Станислав Гришин зарегистрировали оффшорную компанию ReGet Software LLC и от ее имени начали продавать ReGet на западном рынке.

Shareware в России

Shareware в России

По сравнению с мировой индустрией shareware, история которой насчитывает уже около двадцати лет, в России shareware еще очень молодо. Иначе, пожалуй, и быть не могло. В восьмидесятые годы прошлого века, во время зарождения и расцвета shareware, на пространствах существовавшего тогда СССР об этом мало кто слышал. Изоляция от остального мира, относительно небольшой парк персональных компьютеров, отсутствие системы кредитных карт, слабое развитие телекоммуникаций, высокий уровень компьютерного пиратства — в таких условиях, конечно же, ни о каком shareware не могло быть и речи. В начале девяностых, со всеми политическими и экономическими потрясениями, постигшими население России, тоже было как-то не до shareware.
Свою историю shareware в нашей стране ведет только с начала 1998 года. К этому времени в стране установилось относительное экономическое и политическое спокойствие (кризис 17 августа 1998 года был еще далеко) и, самое главное, Интернет — главная движущая сила shareware — для россиян уже перестал быть диковинкой.
Замечание 2
Замечание 2


Конечно, в нашей стране shareware-программисты работали и до 1998 года — например, компания "Етайп" из Калининграда довольно успешно продавала свой продукт Eserv как в России, так и за рубежом. Однако таких примеров shareware-бизнеса было очень немного, и shareware не было заметным явлением в области информационных технологий в России.
23 марта 1998 года вышел в свет еженедельник "Компьютерра" № 1 1 (239), в котором "тема номера" так и называлась — "Shareware". В этом номере была опубликована статья "Искусство Shareware" Александра Каталова, директора московской компании "Элком" (http://www.elcomsoft.com), в которой рассматривались все этапы процесса начала собственного shareware-бизнеса — от выбора идеи для будущей программы и ее написания до заключения договоров с компаниями-регистраторами и технической поддержки пользователей. Статья была написана очень увлекательно и сопровождалась множеством примеров из собственной практики автора.
Примечание
Примечание


Статья в "Компьютерре" была не первой публикацией о shareware в российской прессе. Но именно в ней впервые была описана вся (естественно, насколько это было" возможно в рамках нескольких журнальных полос) технология shareware-бизнеса. Впервые читателю доходчиво объяснили, что shareware — это не что-то бесконечно далекое и недоступное "простому советскому программисту", а вполне реальная возможность для каждого разработчика программ, серьезно относящегося к своему делу.
Через неделю, 30 марта 1998 года, в продаже появился следующий номер "Компьютерры", где тема shareware была продолжена. В статье "Защита shareware-программ" брат Александра Каталова, Владимир, технический директор "Элкома", очень интересно и профессионально рассказал о различных аспектах снабжения программы shareware-ограничениями и их зашиты от взлома.
Отклик на статьи в этих двух номерах "Компьютерры" был вполне сравним с историческим обзором PC-File Джима Кнопфа в журнале PC-World. Поч-
товые ящики Александра и Владимира Каталовых оказались забиты письмами от программистов не только из России, но из бывших республик СССР и даже от наших соотечественников из дальнего зарубежья. И авторы статей в "Компьютерре", что удивительно, находили время очень подробно отвечать на все эти письма.
Примечание
Примечание


Я сам, наверное, никогда не забуду, как в ответ на письмо с парой вопросов, к своему удивлению, получил подробнейший ответ с массой ценной информации, текст которого вполне "тянул" на небольшую статью.
Воодушевленные таким вниманием и поддержкой со стороны "самого Ката-лова" многие программисты стали превращать свои программы, написанные" для себя", в shareware-продукты и помещать их -в Интернете.
Примерно в то же время — в марте 1998 года — Александр Каталов открыл интернет-архив Download.ru (http://www.doanload.ru). Уникальность этого архива состоит в том, что он предназначен в первую очередь не для посетителей, которые, потребляя коммерческую рекламу, для остальных подобных сайтов являются их "кормильцами", а для shareware-авторов только из России и республик бывшего СССР. Если на какой-нибудь крупный shareware-архив типа TuCows программу начинающего автора, скорее всего, просто не возьмут, то на Download.ru такие программы не только принимались, но и авторам программ оказывалась поддержка, причем не только моральная. Александр Каталов, например, не только отвечал на вопросы авторов программ советами, но и одалживал им деньги на регистрацию домена или оплату хостинга (с условием возврата "как сможешь" - - т. е., почти безвозмездно). Он же предоставлял бесплатно место на сервере своей компании под домашние страницы программ и почту, помогал с получением денег от регистраторов, содействовал в решении других проблем при общении с западными хостинговыми, рекламными и прочими компаниями. На Download.ru, помимо русской части сайта, имелась и английская версия, служившая для продвижения "наших" программ на Запад.
Почти одновременно с Download.ru открылся еще один российский shareware -архив - ListSoft.ru (http://www.listsoft.ru). Его автор, системный администратор из Санкт-Петербурга Дмитрий Турецкий, до этого вел в Интернете лист почтовой рассылки с описаниями новых программ (из-за этого архив и получил название "ListSoft"). Ценность рассылки состояла в том, что все публикуемые в нем программы тестировались лично Дмитрием. Читатели могли быть уверенными, что продукты, упоминаемые в рассылке, действительно работают и их возможности соответствуют тем, которые заявляют их авторы. К марту 1998 года архив рассылки уже включал несколько сотен программ, и оформление его в полноценный интернет-каталог было вполне закономерным шагом. Через некоторое время ListSoft обзавелся и английской версией (http://www.listsoft.com), что сделало его еще более привлекательным для shareware-авторов.
Еще через полгода (11 ноября 1998 года) открылся архив, имеющий похожее название — SoftList (http://www.softlist.ru), созданный при поддержке крупнейшего российского интернет-портала List.ru (администратором сайта с первого дня его работы является автор этой книги). На SoftList также была создана английская версия (http://www.softlist.net), так что у shareware-авторов появилась еще одна возможность рекламировать свои программы одновременно и в России, и за границей.
Незадолго до появления "Компьютерры" со статьями Каталовых произошло еще одно важное для российского shareware событие — 17 февраля 1998 года была открыта почтовая конференция SwRus (Shareware Russia). Инициаторами ее создания были автор Delphi-компонентов для доступа к ресурсам компьютера Виктор Ижикеев и разработчик пакета серверов Eserv Андрей Черезов (см. разд. "Успешные российские shareware-проекты" данной главы), которые к этому времени уже имели опыт продаж своих продуктов на Западе и в России. Своими знаниями они решили поделиться и с другими разработчиками. Первоначально конференция работала под управлением Eserv, установленного на офисном компьютере Андрея Черезова, затем, после нескольких переездов, она стала обслуживаться сервером Yahoo Groups. Всю информацию о SwRus можно найти по адресу http://www.swrus.com. Конференция является бесплатной, однако анонимное участие в ней не допускается. В конференции также есть модератор, пресекающий обсуждения, не соответствующие тематике и правилам SwRus.
Популярность конференции росла довольно быстро -- число сообщений было настолько велико, что у SwRus появились "дочки" - самостоятельные конференции, посвященные отдельным вопросам shareware: программированию, защите, созданию сайтов для размещения программ, регистрации программ в интернет-архивах. Также была создана конференция swrus-talks — для любителей просто поболтать на разные темы.
Участники SwRus точно так же, как и их иностранные коллеги за десять лет до этого, стали проводить своеобразные съезды shareware-разработчиков, которые их участниками любовно называются "сврусовками". Там программисты и все, кто просто имеет отношение к shareware, общаются между собой, обмениваются опытом, знакомятся с теми, кого они до сих пор знали только по электронным сообщениям.
Примечание
Примечание


Так как термин "shareware-программа" не очень удобен для частого употребления, то для этой категории стали применять ироничное и задорное "шаровара", а сами российские разработчики shareware стали называть себя "шароварщиками".
Говоря о таком интенсивном развитии shareware в России, следует обратить внимание на то, что все это касалось только разработчиков программ. Российские же пользователи все еще не были потребителями shareware. В ос-
новном программы покупали организации, и, естественно, их в первую очередь интересовали деловые, например, бухгалтерские или финансовые, программы. Для обычных, так называемых "домашних" пользователей shareware-программы были недоступны: владельцев международных пластиковых карт типа Visa и MasterCard было очень мало, а цена даже в 20$ для большинства населения была непомерно высокой. Некоторые российские shareware-программисты пробовали устанавливать льготные цены специально для российских пользователей (исчислявшиеся, к тому же, в рублях). Однако деятельность на российском рынке приносила крошечный доход, т. к. единственный вид платежа, который авторы могли самостоятельно принимать, был почтовый перевод, который не очень-то удобен как для разработчиков программ, так и для пользователей. Проще было махнуть рукой на российский рынок и спокойно получать сотни и тысячи долларов в месяц от продаж своих продуктов на Западе.
Замечание 3
Замечание 3


Из-за того, что объем российского рынка shareware долгое время был очень невелик, "сврусовки" российских shareware-разработчиков не выросли в такое грандиозное мероприятие, как, например, упоминавшаяся ранее Shareware Industry Conference.
Тем не менее, некоторые участники рынка shareware пытались изменить такую неблагоприятную ситуацию на рынке.
В середине 2000 года фирмы МКРсофт и ТФМиК при поддержке Download.ru и ListSoft открыли первую в России регистрационную службу ShaReg (http://www.shareg.com), предназначенную для обслуживания российских пользователей. Теперь стало возможным оплатить программу не только кредитной картой, но и квитанцией Сбербанка, банковским или почтовым переводом, переводом через систему WebMoney.
Авторы программ, регистрирующиеся в системе ShaReg, теперь уже могли не думать о проблеме получения денег от пользователей — все хлопоты взял на себя новый сервис. И если до этого мало кто из российских разработчиков shareware всерьез рассматривал российский рынок, то после открытия ShaReg количество специальных русских версий программ, продающихся по льготной цене 100—300 рублей резко увеличилось, их авторы стали активнее рекламировать свои программы в России.
Замечание 4
Замечание 4


Например, после открытия ShaReg многие программисты, ранее регистрировавшие свои программы только в английской части каталога SoftList, добавили свои программы и в российскую часть архива.
Кроме того, новое предприятие оказывало российским авторам shareware не только содействие по приему платежей от пользователей, но и различные
услуги по продвижению их программ на рынке: регистрацию программ в российских каталогах программ, баннерную рекламу, рассылку пресс-релизов в СМИ и т. п.
Служба ShaReg также позволила частично решить проблему оплаты регистрации shareware-программ зарубежных разработчиков, которые в большинстве своем можно оплатить только при помощи кредитных карт. В данном случае российский регистрационный сервис становился посредником между пользователем, переводящим деньги любым принятым в Российской Федерации способом, и зарубежным банком, обслуживающим разработчика соответствующей программы.
Несмотря на то, что в России есть уже довольно много shareware-разработчиков (конференция SwRus в середине 2001 года имела более шестисот подписчиков), несколько крупных и множество мелких интернет-архивов программ, а также регистрационная служба, российский рынок shareware пока находится в стадии развития. Прошло еще очень мало времени, чтобы shareware в России стало тем, чем оно является в зарубежных странах.

TVicHw32 и TVicPort

TVicHw32 и TVicPort

TVicHw32 и TVicPort (http://www.entechtaiwan.com/tools.htm) — универсальные драйверы, позволяющие программисту получить доступ к аппаратным ресурсам компьютера без использования специальных пакетов типа Windows DDK. В комплект поставки входят DLL-библиотеки для программирования в Visual C++, VCL-компоненты для Delphi-программистов и ActiveX-компоненты.
Разработчик TVicHw32 и TvicPort, Виктор Ижикеев, никогда не думал писать shareware и занялся этим увлекательным делом почти случайно.
По роду основной деятельности Виктору приходится писать программы для управления аппаратурой связи, разрабатываемой и выпускаемой компанией "Компьютерная связь" города Уфы, совладельцем которой он является. В 1996 году компания начала переход на 32-разрядные операционные системы Windows 95 и NT. И тут Виктор с ужасом обнаружил, что все привычные ему языковые конструкции для доступа к аппаратным ресурсам (портам ввода/вывода, физической памяти, прерываниям, DMA) напрочь исчезли из всех его любимых компиляторов. Даже ассемблер не позволял написать пользовательское приложение, содержащее функции доступа к аппаратуре. Оказалось, что доступ к аппаратуре под Win32 возможен только из специальных программ драйверов, выполняемых на уровне ядра операционной системы.
В результате лихорадочного поиска выхода из этой затруднительной ситуации высветились два возможных решения:

Купить за 600$ подписку на MSDN Library Professional, включающую необходимую документацию и инструментарий (Driver Developer Kit, DDK) для написания собственных драйверов устройств.

Купить за те же деньги уже готовые универсальные (generic) драйверы, продаваемые американской фирмой Blue Water Systems.

Извечная проблема: купить рыбу, чтобы поесть один раз, или удочку, чтобы наловить рыбы в любое время. После недолгих колебаний была выбрана "удочка", и Виктор купил подписку на MSDN.
Не стоит описывать здесь мучения Виктора, связанные с почти полным незнанием английского языка, т. к. он всегда и везде изучал немецкий. Но в итоге драйверы Виктор написал и отладил, они до сих пор успешно используются в продукции его фирмы. Но Виктора не оставляла мысль — а если бы драйверы, продаваемые Blue Water Systems, стоили не шестьсот долларов, а сто? Каков тогда был бы выбор? По словам Виктора, он все равно бы купил MSDN. Но ведь другие могут думать иначе, и Виктор решил — попробую продавать!
Для претворения этой идеи в жизнь Виктор сделал следующее:

Драйверы сами по себе никому не интересны, поскольку их не очень просто применять, особенно драйверы для Windows NT. Поэтому для удобства использования Виктор написал к ним "обертку" в виде VCL-компонента для 32-разрядной версии Borland Delphi.

К компонентам были добавлены тестовые примеры использования драйверов для решения самых разных задач доступа к аппаратным средствам.

Не забивая особенно голову проблемами защиты от нелегального использования, Виктор вставил в драйверы так называемые nag screens — экраны напоминания о необходимости зарегистрировать программу (попросту говоря — купить). Больше ничего другого, кроме этих "экранов ворчания" для защиты своего продукта Виктор никогда не использовал. Таким образом, это была демо-версия созданных компонентов и драйверов.

Написал с грехом пополам минимальную документацию в виде простого текстового файла и "содрал" у какого-то другого shareware-продукта лицензионное соглашение.

Придумал цену — 99$. Виктору казалось, что это хорошая цена, поскольку он сам за эту цену аналогичный продукт точно бы купил (железная логика!). Написал адрес для платежей, указал реквизиты предварительно открытого в одном из банков Уфы валютного счета и придумал ужасную английскую, как ему казалось, транскрипцию своей фамилии Ижикеев — Ishikeev. Теперь Виктор изменить ничего не может и продолжает существовать под этой "фамилией".

Запаковал в ZIP-архив, отослал на один-единственный shareware-архив, это был польский сайт, гордо именовавший себя Delphi Super Page, и стал ждать.

Это было в июне 1996 года. Первой покупки Виктор ждал долго, больше месяца, все более и более разочаровываясь в своей никчемной, как ему начало казаться, идее. Но — восторг и изумление! — Виктор получил по почте чек от первого покупателя. И не откуда-то, а из самой NASA — Национального аэрокосмического агентства США! Виктор и члены его семьи с любопытством и радостью рассматривали со всех сторон этот диковинный документ из далекой страны, пришедший в красивом конверте, отпечатанный на голубом бланке с водяными знаками и заветной цифрой 99$.
С чувством "глубокого удовлетворения" Виктор пришел в банк, располагающийся в новом сияющем многоэтажном здании, оборудованном по последнему слову техники. И... весь персонал валютного управления этой суперсовременной организации сбежался посмотреть на чек, выданный американским банком. Они видели подобный документ первый раз в жизни! После долгих консультаций между собой, по телефону с руководством банка, с работниками других банков, в том числе московских, чек был принят на инкассо. Деньги Виктор получил через месяц. С учетом комиссии банка он стал обладателем суммы в 89,42$. Почему именно столько, Виктор так до сих пор и не понял, но все равно ему было очень приятно.
Буквально через несколько дней позвонили из банка сообщить, что пришел перевод на валютный счет, и попросили зайти. Есть второй покупатель, студент из Вены! Но в банке на Виктора вылили ушат холодной воды, заявив словами почтальона Печкина: "Вам посылка пришла, но я ее вам не отдам, поскольку у вас документа нету". Оказалось, что по инструкции Центробанка России можно получить деньги из-за границы только по подписанному, переведенному на русский язык и заверенному нотариусом договору с иностранной компанией или в качестве благотворительного пожертвования.
Виктор, конечно же, отослал по e-mail полную версию пакета покупателю, описал ситуацию и попросил прислать факс с указанием того, что эту сумму он прислал в качестве благотворительного пожертвования. Австрийский студент выполнил просьбу Виктора и прислал факс. Это замечательный документ, который Виктор хранит до сих пор... В банке долго веселились, прочитав текст, который гласил: "Прекратите издеваться над человеком! Отдайте Виктору деньги, потому что он хороший парень!".
Деньги зачислить на счет отказались, потребовав написать бумагу, что Виктор просит переслать деньги назад, отправителю платежа. Виктор, конечно же, отказался подписывать такой документ, ведь это были его честно заработанные деньги! И началось... Из банка звонили каждый день, умоляя написать такую бумагу. Виктор быстренько сообразил, что без его согласия они вернуть адресату деньги не могут, и твердо стоял на своем — свои деньги никому не отдам! Но звонки продолжались и, увы, пришлось сдаться. Деньги были возвращены австрийцу, чем тот был чрезвычайно удивлен и раздосадован. К чести его надо сказать, что он все-таки заплатил деньги Виктору спустя некоторое время.
После этого Виктор сильно приуныл. Не мог же он требовать письменный договор от каждого покупателя или просить его посылать ему благотворительные взносы! Ситуация казалась почти тупиковой. Почти — потому что по чекам он все-таки деньги получал исправно, хотя и с задержкой, выросшей по неизвестным ему причинам сначала до полутора, а затем до двух месяцев (наверное, банк внедрил очередную суперсовременную технологию).
Но некоторое время спустя, а именно в конце 1996 года, Виктор познакомился в Интернете с. замечательным человеком по имени Эшли Оалдана (Ashley Saldanha), американцем, живущим на Тайване, владельцем фирмы EnTech Taiwan (http:/ww\v.entechtaiwan.com) и автором очень популярной программы PowerStrip, значительно расширяющей возможности видеокарт. Знакомство с этим человеком радикально изменило представления Виктора о жизни вообще и о shareware-бизнесе в частности.
Эшли увидел программу Виктора в Интернете и заинтересовался, поскольку он тоже был занят переводом своих программ под Win32 и нуждался в средствах доступа к аппаратуре. Драйверы Виктора не полностью решали его проблемы, и Эшли заказал ему написание других, специально для его программы PowerStrip (они с незначительными изменениями работают до сих пор).
Эшли просветил Виктора, что вовсе не нужно и даже вредно брать деньги непосредственно от покупателей. Оказалось, что уже давно существуют фирмы, которые специализируются на приеме мелких платежей за shareware, аккумулируя их и высылая накопленные суммы авторам. Конечно, эти фирмы удерживают комиссионные с каждой продажи, но, с другой стороны, экономятся значительные средства, теряемые ранее на обработке многих мелких сумм. И еще важный момент — эти фирмы заключают с тобой договор, который ты можешь отнести в банк, сняв всякие проблемы перевода денег непосредственно на твой валютный счет.
С одной из таких американских фирм-регистраторов, WinTech Inc., держателя сайта Virtual Software Store (VSS), Эшли заключил от имени Виктора договор (это было важно, т. к. английский язык, как было сказано выше, Виктор знал тогда плохо), заплатил первоначальный взнос, и shareware-бизнес обрел под собой, наконец, твердую почву. В дальнейшем Виктор заключил договора еще с несколькими фирмами-регистраторами, которых оказалось на удивление много. Но VSS была первой и потому Виктор до сих пор пользуется ее услугами, несмотря на довольно высокий уровень комиссионных в 25%.
Собственно, дальше и рассказывать особо нечего. Бизнес потек на удивление гладко, Виктор периодически выпускал новые версии программы, слегка рекламировался. Надо сказать, что он никогда не уделял много внимания продвижению своих продуктов и это, по его словам, большая ошибка. Как говорит Виктор: "В свое оправдание могу сказать только, что не имел для этого достаточно времени, работая над shareware только в свободное от основной работы время. Кроме того, продажа программистских инструментов требует очень большого объема технической поддержки пользователей, значительно большей, чем при продаже "обычных" прикладных или развлекательных программ. Но, похоже, судьба распорядилась так, что я перейду на full-time shareware business, поэтому в ближайшем будущем я намерен значительно больше времени и средств уделять маркетинговым усилиям".

Успешные российские sharewareпроекты

Успешные российские shareware-проекты

Зачем вам нужно shareware

Зачем вам нужно shareware

Немного рассказав об общих принципах shareware, его истории и тенденциях развития, я предвижу вопрос, которым, возможно, задались некоторые из читателей: "А стоит ли программисту вообще заниматься shareware?"
Действительно, есть ведь множество других способов заработать деньги в области создания и распространения программных продуктов. Например, по сравнению со всеми хлопотами по самостоятельному написанию, рекламе и поддержке компактных shareware-программ, имеющих относительно малую цену и большое количество конкурентов, гораздо более предпочтительным выглядит участие в крупных проектах по заказам корпоративных клиентов. Это, на первый взгляд, сулит хорошую материальную и, что немаловажно, моральную отдачу: приятно чувствовать себя создателем не "какой-то маленькой утилитки", а мощного программного комплекса, от которого зависит работоспособность большой корпорации с громким именем. А доход, получаемый по контрактам с-международными заказчиками, обычно выше, чем поступления от продаж даже довольно успешного shareware-продукта.
Однако на практике все предстает в несколько ином свете. "Отец" российского shareware Александр Каталов рассказывает об опыте работы его компании ElcomSoft с крупными иностранными заказчиками, среди которых -международные корпорации с офисами в десятках стран мира:
"Никакого удовольствия нам работа по контрактам не доставляла. По одному из них мы болтались восемь месяцев между Сингапуром и Москвой, поначалу было интересно, но после шестого полета туда и обратно ведущий специалист проекта буквально взвыл, еще один парень вообще решил уволиться. Заказ мы успешно выполнили, но они начали просить, чтобы еще пару человек приехали в Сингапур на полгодика(!) обеспечивать внедрение и сопровождение. Мы отказались, хотя и получили бы за это время денег больше, чем со всех наших shareware-продуктов за первый год работы. Но зато сегодня shareware в месяц приносит нам больше, чем тот "упущенный" полугодовой контракт!"
Да, в shareware-бизнесе разработчик, как говорится, "сам себе хозяин". Естественно, развитие программ зависит не только от самого автора, но и, например, от пожеланий пользователей, однако с ними работать гораздо интереснее, чем с многостраничным контрактом и. техническим заданием, от условий которых нельзя отступить ни на шаг. Что касается командировок с утомительными трансокеанскими перелетами, то, пожалуй, единственное место на планете, где shareware-разработчику нужно обязательно побывать — это ежегодная Shareware Industry Conference.
Для начинающего программиста shareware-бизнес — еще и отличный путь для поднятия собственного профессионального уровня. Ведь на перенасыщенном рынке программного обеспечения плохие продукты просто никто не покупает. Разработчику волей-неволей приходится постоянно осваивать новые технологии: интеграцию с Интернетом, взаимодействие с Microsoft Office, СОМ-объекты, технологию NET, очередную версию Windows — список можно продолжать бесконечно. Не обойтись без профессионального владения английским языком и знания традиций и делового этикета разных стран - - для общения с пользователями и представителями зарубежных компаний (регистраторов, каталогов программ и т. д.).
Большинство программистов в нашей стране (как, впрочем, и во всем мире) являются штатными сотрудниками достаточно крупных фирм и организаций. Почти всегда имеется "потолок" размера заработной платы, при этом часто не очень высокого уровня. Доходы от shareware-бизнеса могут многократно превышать среднюю зарплату программиста в Москве, не говоря уже о провинции. Вспомните Джима Кнопфа, которому его программа PC-File приносила денег в десять раз больше, чем работа в IBM! Вот, для сравнения, классификация уровня ежемесячных доходов современных shareware-разработчиков, составленная Виктором Ижикеевым:

100—1000$ — начинающие shareware-разработчики или продажи не очень удачного продукта. Чтобы заработать меньше 200$, надо сильно постараться.

1000...3000$ — приличный уровень среднего шароварщика, на который обычно выходят через год-два.

3000...10 000$ — удачные, по нашим меркам, продукты.

10 000$ — наиболее успешные продукты типа WinAmp, WinZip, ACDSee, Paint Shop Pro, ставшие своеобразной классикой shareware.

Но, как часто случается, деньги — еще не все. "Тщеславие — мой любимый порок" - говорил персонаж Аль Пачино в фильме "Адвокат дьявола". Shareware — это уникальная возможность сделать себе имя и стать известным всему миру. Вспомним того же Джима Кнопфа: разве смог бы он получить всемирную известность, оставаясь всего лишь штатным программистом IBM?
Кроме того, shareware — отличный шанс начать собственный бизнес. Начальные затраты минимальны, к тому же не нужно бросать свою основную работу: никто не мешает писать программу в обеденные перерывы, а обрабатывать регистрационные письма и переписку с пользователями по вечерам. Если по каким-либо причинам дело не заладится, можно опять сосредоточиться на основной работе. Но если деятельность на рынке shareware пойдет успешно, то можно стать профессиональным shareware-автором, т. е. заниматься исключительно разработкой и распространением своих программ. По мере увеличения объемов продаж и количества пользователей потребуется нанять специалистов для технической поддержки пользователей или управления финансами — словом, нужно будет уже регистрировать собственную компанию.
Примеров успешных shareware-проектов в России предостаточно. В следующем разделе я расскажу о пяти из них.

Учебник по созданию shareware программ

Borland Delphi

Borland Delphi

Как и Microsoft Visual C++, Borland Delphi позволяет компилировать свои проекты в исполняемые файлы, не требующие каких-либо внешних runtime-библиотек. Их размер, хотя и превышает размер файлов, созданных при помощи Visual C++", все-таки остается довольно компактным, что выгодно отличает Delphi от своего основного конкурента — Visual Basic. Единственное, где нужно быть осторожным, - - это написание резидентных утилит: для этой категории программ объем файла даже в 300—500 Кбайт может оказаться слишком большим и, возможно, придется прибегать к дополнительным хитростям для его уменьшения.
Увы, но усиленно рекламируемая возможность Delphi легко создавать ActiveX-компоненты на практике почти бесполезна: генерируемые компилятором файлы имеют огромный размер и разочаровывающе низкую скорость работы.
А вот "родная" для Delphi технология — Visual Component Library (VCL) -совсем другое дело. Существует огромное число компонентов, причем многие, даже из самых мощных, распространяются совершенно бесплатно.
Трудностей с отладкой проектов, содержащих VCL, в отличие от использования ActiveX, не существует: большинство из имеющихся на рынке компонентов снабжаются исходными текстами, и программист имеет возможность самостоятельно устранить ошибки (а они в VCL встречаются не так уж редко). Кроме того, открытость исходных текстов позволяет разработчику расширить функциональность компонента, а если имеющийся компонент слишком громоздок и имеет неоптимальную структуру, то можно включить в свою программу только фрагменты его кода.
Примечание
Примечание


Часто можно даже не затруднять себя самостоятельным исправлением ошибок в компонентах: число существующих VCL-компонентов так велико, что при обнаружении ошибки бывает достаточно попробовать аналогичный компонент другого производителя. Например, при переходе с Windows 98 на Windows ME в работе компонента, который я использовал для извлечения информации о версии ЕХЕ- и DLL-файлов, стали иногда происходить сбои. После того как я заменил ненадежный компонент его аналогом, нормальная работа программы возобновилась.
Все перечисленные достоинства и недостатки свойственны и другой системе разработки приложений компании Inprise — C++ Builder.

Что еще нужно помнить

Что еще нужно помнить

Главное правило начинающего шароварщика — писать свою программу нужно очень быстро. Современный ранок программного обеспечения очень динамичен: на нем постоянно появляются новые продукты, а существующие расширяют свои возможности. Если вы протянете с выпуском своей программы несколько месяцев, то, когда, наконец, решитесь представить ее публике, вполне может оказаться, что она уже мало кому нужна.
Особенно следует поторопиться, если вы хотите попасть "в струю", т. е. направление, которому посвящена ваша программа, стало популярным совсем недавно (например, как в свое время — утилиты для работы с МРЗ). Вероятно, довольно большое число разработчиков уже пишут программы, аналогичные вашим, и тот, кто первый появится на рынке, "снимет" все "сливки".
Как следствие, от написания первой строки кода до появления первой рабочей версии программы должно пройти 1—2 месяца. Многие разработчики почему-то боятся объявить свою программу финальной версией и бесконечно оттягивают начало продаж своего продукта, выпуская все новые бета- и предварительные версии и предоставляя их ограниченному числу пользователей. Делать этого, по указанным выше причинам, не стоит: ваша программа должна появиться на массовом рынке как можно быстрее.
Помимо этого, на работу нужно настроиться очень серьезно. После прочтения истории shareware и рассказов об успешных российских shareware-проектах (см. гл. 1), у кого-то из читателей, возможно, сложилось впечатление, что стоит выпустить на рынок хоть какую-нибудь программу — и регистрации благодарных пользователей посыпятся, как из рога изобилия. Увы, сегодня все обстоит несколько иначе. Вам придется конкурировать как минимум с несколькими, а может быть, и с десятками соперников, многие из которых находятся на рынке уже не один год и знают, как именно нужно продвигать конкретный продукт. Да и большинство пользователей не платят деньги за первую встреченную программу, а обязательно посмотрят несколько продуктов и выберут самый лучший.
Поэтому если вы действительно хотите добиться серьезного успеха, то установка на результат должна быть бескомпромиссной. Мало просто написать продукт — ваш продукт в своей категории должен быть самым лучшим в мире. Если пишете HTML-редактор — стремитесь сделать его лучше, чем HomeSite. Разрабатываете менеджер файлов — пусть он видится вам лучшим, чем FAR и Windows Commander, вместе взятые. Закладываться нужно на 200%, перепрыгивать через голову, тогда что-то получится. Этот принцип действительно помог многим российским шароварщикам стать лидерами на рынке shareware.

Delphi Basic или С

Delphi, Basic или С

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

Какую программу писать

Какую программу писать

Прежде чем начинать собственную shareware-программу, нужно, конечно же, определиться, что именно вы будете писать. Ошибки, допущенные уже на этом этапе, в конце концов, приведут к тому, что вам придется прекратить развитие своего продукта, а время и средства, затраченные на его разработку и продвижение, окажутся потерянными зря. С другой стороны, правильно выбранная тематика программы может предопределить успех всего shareware-проекта в целом.
Вынужден разочаровать тех, кто ждет от меня готовых идей для будущих проектов. Тематика программы, подсказанная кем-то другим, вряд ли поможет создать успешный продукт. Идея программы должна быть обусловлена вашими собственными предпочтениями.
Дело в том, что программа обязательно должна быть интересной вам самим, вы сами должны ей постоянно пользоваться. Если вы, скажем, пишете собственный файловый менеджер, но при этом предпочитаете применять FAR (http://www.rarsoft.com), например, потому что у него и встроенный FTP-клиент есть, и файлы он копирует без ошибок, то будьте уверены: долго ваш проект не проживет. Очень скоро вы потеряете к нему всякий интерес и забросите его поддержку.
Постоянное использование собственной программы помогает отлавливать на самом раннем этапе ошибки, неизбежно возникающие при подготовке новых версий продукта, и легко устранять их. Конечно, о замеченной ошибке вам могут сообщить и пользователи программы, однако по их письмам не всегда можно сделать вывод о характере ошибки и причинах ее появления.
Кроме того, в процессе применения программы самим автором часто появляются различные идеи по ее совершенствованию. Это особенно ценно для развития программы, т. к. в этом случае автор знает, как наилучшим образом реализовать новую функцию и сделать ее более удобной для пользователей. К сожалению, при использовании некоторых программ появляется ощущение, что их авторы своими творениями не пользуются и даже не представляют, что именно нужно пользователям их программных продуктов — настолько неудобной является работа с ними.
В качестве примера программы, первоначально написанной "для себя" и выигравшей от того, что автор использовал ее постоянно, могу привести свой собственный shareware-продукт — Actual Startup (http://www.actualsystem.com /startup/), утилиту для управления списком программ, запускаемых при старте Windows (такие программы еще называют "менеджерами автозагрузки"). В один прекрасный день мне окончательно надоело то, что буквально каждая вторая программа, устанавливаемая на моем компьютере (например, Netscape Communicator, Microsoft Office, игра Heroes of Might and Magic III), без всякого моего разрешения норовит добавить в автозагрузку вызов своего собственного модуля. Нет проблем — к этому моменту на рынке существовало несколько менеджеров автозагрузки (среди них были и бесплатные), кроме того, аналогичная утилита входила и в состав Windows 98. Однако ни у одной из найденных мною программ не было функции периодической проверки списка запускаемых программ на предмет появления в нем новых "членов", а постоянно просматривать автозагрузку "вручную" было неэффективно. Поэтому я написал собственную программу — Actual Startup. Она не только позволяла просматривать и управлять списком программ, запускаемых при старте системы, но и незамедлительно сообщала о добавлении в него новых пунктов.
Почти сразу после того, как Actual Startup был выставлен на обозрение публики, я стал получать от пользователей сообщения о странной и очень раздражающей ошибке: моя утилита при каждой проверке докладывала о появлении в автозагрузке одних и тех же программ, хотя они вовсе не являлись новыми в списке! .В течение нескольких месяцев(!) я не мог обнаружить причину ошибки. Я запрашивал у пользователей детальную информацию о работе программы, тестировал Actual Startup на разных компьютерах под всеми существующими 32-разрядными версиями Windows, но к решению проблемы не приблизился ни на шаг (нет худа без добра: попутно я нашел еще несколько довольно неприятных ошибок и заодно изучил особенности программирования для разных версий Windows).
Однажды, в очередной раз переустановив Windows, я инсталлировал в числе многих программ и мультимедийный проигрыватель WinAmp. Actual Startup добросовестно сообщил мне, что в автозагрузку был добавлен новый сервис — WinAmpAgent. В отличие от предыдущих установок WinAmp, я на этот раз решил не удалять Agent из списка запускаемых при старте системы программ. И - о, чудо! — через минуту моя утилита опять сообщила о "новой" программе в автозагрузке. Причина загадочной ошибки наконец-то была найдена: оказывается, некорректную работу программы вызывало наличие кавычек в команде, которой запускался WinAmp Agent. Ошибка была устранена в течение двадцати минут, но кто знает, сколько еще времени понадобилось бы на решение проблемы, если бы я не пользовался постоянно своей программой, и сколько регистрации я бы потерял из-за этого!
И все же, какую программу стоит писать? Существует мнение, что продать можно любой продукт, лишь бы он был качественно сделан, и с этим соглашаются многие профессиональные шароварщики. На современном рынке программного обеспечения пользуются спросом самые разные продукты: от крошечных вспомогательных утилит для Windows до сложных научных и инженерных пакетов. Для shareware подходит почти любая программа, особенно если она не повторяет функции, предоставляемые широко распространенными . продуктами типа Microsoft Windows или Microsoft Office, или выгодно дополняет их. Существует много ниш на рынке программного обеспечения, не занятых крупными компаниями: они или не заинтересованы в том количестве пользователей, которое это направление может дать, или считают такие программы несерьезными, или по разным другим причинам. Зайдите на любой более-менее крупный интернет-каталог программ, и вы увидите, насколько разнообразные программные продукты покупают пользователи во всем мире.
Главное, чтобы программа, которую вы хотите написать, пригодилась не только вам, а была бы востребована и другими пользователями. Разумеется, не всегда в этом можно быть уверенным. И в таком случае нужно руководствоваться следующим правилом: "Не пишите программу, не имеющую аналогов на рынке".
На первый взгляд, это утверждение многим кажется абсурдом. Ведь на продукт, находящийся вне конкуренции, спрос гораздо выше! Но в индустрии shareware дело обстоит несколько иначе. Мне известно довольно много примеров того, как проект по разработке уникальной, не имеющей аналогов на рынке программы прекращался из-за того, что вместе с конкурентами у программы отсутствовали и покупатели. С другой стороны, многие продукты, имеющие довольно большое число соперников, продаются просто замечательно. Более того, некоторые разработчики shareware рассказывали мне, что после появления на рынке сильных конкурирующих программ продажи их собственных продуктов даже возросли!
Дело в том, что конкуренты, как это ни странно, подготавливают вам благоприятную почву для вхождения на shareware-рынок. В интернет-каталогах программного обеспечения уже созданы соответствующие тематические категории, а абсолютно новая программа попадет в лучшем случае в раздел "Miscellaneous" (Разное), который традиционно посещается меньше других. Компьютерные журналы часто публикуют тематические обзоры программ -например, я писал для популярного журнала "Мир Интернет" (http:// www.iworld.ru) обзоры Web-редакторов, интернет-ускорителей, FTP-клиентов, утилит для поиска в Сети и др. Всякие же экзотические программы попадали в лучшем случае в краткий и общий "Обзор утилит", часто я вообще не решался что-либо писать о них, т. к. не был уверен, что они будут интересны для читателей журнала.
В каждой категории программ есть свои лидеры: например, среди архиваторов — WinZip, offline-браузеров — Teleport Pro, а файловых менеджеров — FAR (http://www.rarsoft.com). Однако многие пользователи все равно не довольствуются их возможностями и постоянно ищут более новые программы. Например, в конференциях, посвященных программному обеспечению, можно найти много обсуждений "Web-редакторов, лучших, чем HomeSite (http://www.allaire.com)", или "FTP-клиентов, лучших, чем CuteFTP (http:// www.cuteftp.com)". А если какой-либо продукт начинает активно рекламироваться, то он косвенно продвигает и все ее аналоги: пользователи начинают интересоваться этим классом программ, скачивать их из Интернета, пробовать, сравнивать возможности. Даже на страницах журналов иногда появляются обзоры типа "Выбираем замену Outlook Express". Вот и получается, что деятельность конкурентов может принести пользу и вам.
Наметив примерную тематику программ, посмотрите, что уже создано другими разработчиками: наверняка у вас появится множество новых идей. Вряд ли какая-либо программа может удовлетворить потребности большинства пользователей на 100%: одна, например, имеет более красивый интерфейс, другая - какую-нибудь интересную функцию, третья отличается меньшим объемом дистрибутива и высокой скоростью работы, четвертая продается по очень привлекательной цене. Просмотреть продукты, имеющиеся на рынке, выделить лучшие их черты и воплотить их в своей программе — так поступили авторы многих удачных shareware-проектов. Вспомните, например, как Владимир Каталов, прежде чем начать работу над своим Advanced Disk Catalog, сначала протестировал около двадцати уже существовавших программ этой тематики (см. разд. "Успешные российские shareware-проекты" гл. 1).
Если вы замыслили проект грандиозных масштабов — например, создание в одиночку графического редактора, лучшего, чем Adobe Photoshop, то лучше и не думайте. Прежде, чем вы сможете представить публике самую первую бета-версию, пройдет несколько месяцев — целая вечность для области информационных технологий — и, возможно, рынок изменится настолько, что ваш продукт потеряет свою актуальность. Лучше всего посвятить свое время программе, которая, даже имея относительно небольшой набор функций, будет вполне самостоятельным продуктом, а затем, быстро выпустив и начав продавать первую версию, совершенствовать ее, исправлять ошибки, адаптировать согласно требованиям постоянно меняющейся ситуации на рынке.
Кроме того, у крупных компаний по разработке программного обеспечения совсем другие возможности: большой штат сотрудников и такие бюджеты, что программистам-одиночкам и не снились. А вот конкурировать с такими же, как и вы, shareware-разработчиками или даже небольшими shareware-компаниями вполне можно. Ведь здесь, в России, накладные расходы несколько меньше, чем за рубежом, а кроме того, вас вполне может устроить такой доход, который никогда не будет приемлем для иностранного разработчика или, тем более, целой компании.
Однако, к "монстрам" из мира программного обеспечения все-таки стоит присмотреться. Есть такое "правило рыбы-прилипалы": чтобы набрать большую скорость, нужно всего лишь прицепиться к днищу идущего корабля. В индустрии shareware это означает то, что для продвижения собственной программы можно использовать популярность лидирующего на рынке продукта.
Классический пример — всевозможные подключаемые модули, или плагины (от англ, plug-in), которые поддерживают многие популярнейшие программы - например, уже упоминавшиеся WinAmp, Adobe Photoshop, FAR. Плагины традиционно являются предметом повышенного интереса со стороны многочисленной аудитории "основных" продуктов. Не случайно на их Web-сайтах заведены разделы, содержащие ссылки на плагины, что, кстати, является бесплатной и очень эффективной рекламой. А корпорация Microsoft даже периодически проводит конкурсы среди расширений пакета Microsoft Office! Если же написанный вами дополнительный модуль окажется особенно удачным, его, возможно, даже включат в дистрибутив "основного" продукта — вы сами можете представить, насколько увеличится число пользователей вашей программы!
Кроме того, в Интернете существуют специализированные архивы плагинов, например, есть довольно много ресурсов, посвященных модулям для Adobe Photoshop. Программа, опубликованная на таком сайте, привлекает гораздо большее внимание действительно заинтересованной в ней аудитории по сравнению с каким-нибудь крупным общетематическим архивом типа Download.com, где продукт может просто затеряться.
Внимание!
Некоторые разработчики недовольно заявляют: "Зачем это я своим продуктом буду продвигать какой-то там Photoshop". Такая точка зрения является совершенно неправильной: на самом деле все происходит с точностью наоборот.
Еще один пример грамотно задуманной "прилипалы" это поддержка программой какого-нибудь популярного формата файлов.
Например, существует много текстовых редакторов, авторы которых с гордостью заявляют, что их продукты сохраняют свои файлы в формате RTF. Однако мало кто из них заботится о том, чтобы их программа могла работать с файлами текстового процессора Microsoft Word, стандарта де-факто для подготовки офисных документов. Не удивительно, что продажи таких продуктов идут очень вяло.
Еще можно упомянуть такие хрестоматийные примеры, как успех кодировщиков и плейеров МРЗ-файлов, появившихся, как только формат МРЗ стал завоевывать популярность, или большой интерес к программам работы с файлами Adobe Acrobat (PDF).
Если вы хотите посвятить себя разработке игр, следует учитывать, что для shareware-рынка имеет смысл разрабатывать небольшие игры — логические, карточные, или, например, ремейки классических хитов типа "Тетриса" или "Арканоида". Большие проекты вроде сложной стратегической или ролевой игры начинать бесполезно — слишком велики расходы на разработку и издание продукта такого рода. В этой ситуации более разумно обратиться в одно из специализированных агентств по изданию игр — но это уже совсем другая тема.
В случае, если вы имеете хорошие навыки создания приложений для Web-серверов, например, CGl-скриптов, владеете языками С, Perl или РНР, то вы можете заняться shareware и в этой области. Рынок программ для Web-серверов очень привлекателен: во-первых, продуктов на нем в десятки раз меньше, чем на рынке программ для Windows, а значит, менее жесткая конкуренция; во-вторых, спрос очень велик, ведь количество Web-сайтов в мире огромно и растет с каждым днем; в-трстьих, заказать нужный CGI-скрипт в специализированной компании по разработке Web-сайтов для большинства покупателей не по карману, т. к. это стоит слишком дорого — несколько тысяч долларов. Это зажигает зеленый свет перед независимыми Web-программистами, которые могут продавать свои продукты за гораздо более низкую цену. Наибольшим спросом на рынке пользуются, конечно, сложные CGI-скрипты для коммерческого применения: показа рекламы на сайте, ведения online-торговли, работы с базами данных. Также популярны форумы с расширенными возможностями (например, функцией администрирования и ведения различных тематических конференций), системы быстрого обновления содержимого сайта, сбора и анализа статистики посещений и т. п.
Если у вас есть идея какой-либо программы и вы планируете предложить одной из компаний по разработке программных продуктов, чтобы вас приняли на работу и таким образом профинансировали вашу деятельность, то, скорее всего, вы ничего не добьетесь. Просто "под идею" денег вам никто не даст. А вот если вы сами создадите удачный продукт, то существует некоторая вероятность того, что однажды вы получите заманчивое предложение уступить все права на программу и ее исходные тексты за кругленькую сумму.
Тем не менее такие случаи достаточно редки, и у вас гораздо больше шансов "раскрутить" собственный продукт, чем продать его кому-нибудь другому. Например, один из российских программистов пару лет назад написал несколько довольно неплохих shareware-программ и стал активно заниматься их продвижением, надеясь, что его заметят и возьмут на работу в какую-нибудь крупную компанию. Выгодных предложений устроиться на работу так и не поступило, а вот shareware-бизнес пошел так хорошо, что он зарегистрировал собственную фирму и уже сам принимает людей на работу.
И наконец, последний вопрос относительно тематики будущей программы: стоит ли писать shareware для каких-либо операционных систем, кроме Windows 9x и 2000? Скорее всего, нет. Раньше можно было делать проекты под OS/2, у нее были десятки миллионов инсталляций в мире, особенно много в Европе. Но сейчас это количество снижается и новых версий данной операционной системы не предвидится.
Под Unix писать shareware особого смысла нет — там традиционно большая часть программ распространяется бесплатно, в том числе и на условиях Open Source (см. разд. "Freeware и другие" гл. 1).
Несколько отдельно стоит разработка shareware-программ под Windows СЕ, PalmOS и прочие платформы для карманных компьютеров-"наладонников". Писать для них можно на обычном персональном компьютере. Сейчас в связи с бурным развитием данной отрасли компьютерной индустрии, эта платформа имеет шанс "приобрести такое же значение, как и ее "старший брат". Пользователи карманных компьютеров неплохо покупают игры, записные книжки, компактные почтовые клиенты и другие подобные программы. Если у вас есть возможность отлаживать такие программы, то стоит попробовать...

Microsoft Visual Basic

Microsoft Visual Basic

Разработка и распространение shareware-программ в системе Microsoft Visual Basic, при всей простоте самого языка программирования и удобстве среды разработки, сопряжена с некоторыми довольно серьезными трудностями.
Для работы любой программы, созданной в Visual Basic, требуется runtime-библиотека "весом" более мегабайта. Например, при использовании версии 5.0 требуется библиотека msvbvm50.dll, а версии 6.0 - библиотека msvbvm60.dll. Корпорация Microsoft относительно недавно стала поставлять эти библиотеки в составе операционных систем семейства Windows, и автор никогда не может быть полностью уверен, что у пользователя уже есть необходимая для работы программы библиотека. Приходится включать злосчастную DLL в дистрибутив своей программы, потому что предлагать вместо этого скачать ее со страницы разработчика слишком рискованно: многие пользователи будут разочарованы и просто не станут тратить лишнее время, предпочтя поискать продукт другого автора. Как следствие, архив с даже самой простой утилитой будет "весить" около полутора мегабайтов! Например, совсем недавно в конференции SwRus (см. разд. "Shareware в России" гл. 1) как раз шло массовое веселье по поводу обсуждения скромной утилиты, которая всего лишь показывала пользователю его IP-адрес. Увы, скромным в программе был только набор возможностей: объем ее дистрибутива был 1,4 Мбайта!
Другой недостаток shareware-программ, написанных на Visual Basic, — необходимость использования при работе над более-менее сложными проектами
ActiveX-компонентов, которые для этой системы разработки являются единственным способом серьезного увеличения функциональных возможностей программы. Активно продвигаемая корпорацией Microsoft технология на самом деле доставляет shareware-автору немало хлопот.
Несмотря на статус "дополнительной библиотеки" вроде DLL, ActiveX-компонент является, по сути дела, самостоятельным приложением, который, как и любой программный продукт, неминуемо содержит ошибки, проявляющиеся в самый неподходящий момент! Также вполне возможны ситуации, когда нормально функционирующий ActiveX отказывается работать при переходе на другую версию Windows. При этом найти ошибку автору компонента несколько сложнее, чем в случае отладки "обычного" приложения: когда ActiveX-компонент используется третьими разработчиками при написании их программ, возникают такие ситуации, которые автор компонента просто не может предвидеть и создать в процессе отладки. Более того, при подключении к проекту нескольких ActiveX-компонентов вполне может оказаться, что они конфликтуют между собой — в моей практике, по крайней мере, было несколько таких случаев. Что самое неприятное — исправить ошибку никак нельзя, т. к. компоненты поставляются без исходных текстов, только в скомпилированном виде. Иногда возникают трудности даже с отладкой программы из-за багов, возникающих где-то внутри двоичного файла ActiveX: можно довести себя до белого каления, пытаясь выяснить, почему программа не работает, хотя на соседнем компьютере такой же конфигурации оборудования и установленного программного обеспечения все, как говорится, Ok. Писать же автору компонента и просить исправить ошибку часто бывает бесполезно, т. к. он, как уже говорилось выше, может оказаться не в состоянии воссоздать ситуацию, возникшую у пользователя, и локализовать ошибку.
Кроме этого, включение в проект ActiveX-компонентов способно увеличить размеры дистрибутива программы вне всяких разумных пределов. Помимо наличия плохо оптимизированной внутренней структуры самих компонентов, некоторые автору непонятно зачем объединяют несколько ActiveX в один довольно объемный файл. Характерный пример — компонент Windows Common Controls из состава Visual Basic, включающий стандартные элементы управления Windows 95 (ToolBar, StatusBar, TabControl и др.). Поэтому при добавлении хотя бы одного из этих элементов, например кнопочной панели инструментов, объем дистрибутива сразу увеличивается на 650 Кбайт. А ведь еще нужно добавить специализированные DLL-библиотеки из состава Visual Basic для поддержки технологии OLE (основы ActiveX) — а это еще несколько сотен килобайтов!
Примечание
Примечание


Можно, конечно, обойтись без ActiveX-компонентов, программируя на чистом Windows API. Однако при этом теряется единственное преимущество Visual Basic, из-за которого его в основном используют, — высокая скорость и простота разработки.
Многие возлагали надежду на то, что корпорация Microsoft решит проблему необходимости использования громоздких DLL-библиотек и ActiveX-компонентов с помощью своей новой технологии .NET. Однако, по свидетельству бета-тестеров Visual Basic NET, размеры DLL-библиотек в этой системе увеличились еще больше и достигли "чудовищной" величины. А значит, несмотря на то, что Microsoft будет распространять NET-библиотеки в составе своей 64-разрядной операционной системы Windows XP, Visual Basic останется не очень привлекательным средством для разработки shareware-продуктов. Конечно, на рынке присутствуют программы, написанные на Visual Basic, но многие из них просто неконкурентоспособны из-за слишком большого размера дистрибутива.
К сожалению, особого смысла создавать с помощью Visual Basic ActiveX-компоненты для shareware-рынка нет, т. к. аудитория у них будет несколько ограничена. Причиной этого является то, что для работы такого ActiveX-компонента требуется runtime-библиотека из состава соответствующей версии Visual Basic. Поэтому его применение в проектах под Visual C++ и Borland Delphi нерационально. То же самое можно сказать о использовании такого ActiveX в проекте, созданном в другой версии Visual Basic: например, при добавлении компонента, созданного в версии 5.0, в проект, разрабатываемый в редакции 6.0, в дистрибутив готового продукта нужно будет включать и msvbvm50.dll, и msvbvm60.dll (суммарный объем — более 2,5 Мбайт).
Вот где позиции Visual Basic очень сильны — это в области создания дополнений для Microsoft Office: как известно, диалект VB - Visual Basic for Applications (VBA) — является языком программирования Office. В составе Office, начиная с версии 2000, наконец-то появилась полноценная интегрированная среда разработки, напоминающая обычный Visual Basic, позволяющая комфортно создавать и отлаживать приложения для Microsoft Office.
Поэтому, на мой взгляд, Visual Basic хорошо подходит в основном для разработки продуктов по конкретным заказам, (где имеется возможность протестировать программу на компьютерах заказчика, а ее окончательную версию записать на компакт-диск и принести лично или прислать по почте), а также дополнений к Microsoft Office. При использовании Visual Basic для разработки shareware-программ будьте готовы к тому, что у многих ваших конкурентов козырей будет больше, чем у вас — не случайно большинство продуктов на рынке shareware написаны все-таки на Visual C++, Borland Delphi или C++ Builder.

Microsoft Visual C++

Microsoft Visual C++

Одно из основных достоинств Microsoft Visual C++ - относительно небольшой размер ЕХЕ-файла, генерируемого встроенным компилятором при так называемой статической компиляции, т. е. ЕХЕ-файла, для работы которого не требуется дополнительных runtime-библиотек. По этому показателю система опережает своих основных конкурентов - Borland Delphi и Borland C++ Builder. Как следствие, дистрибутивы программных продуктов, созданных с помощью Microsoft Visual C++, отличаются небольшим размером, что делает их более привлекательными для пользователей, загружающих программы через Интернет.
Компактность генерируемых компилятором файлов делает Microsoft Visual C++ наиболее эффективным средством и для разработки DLL-библиотек и ActiveX-компонентов, для которых небольшой размер является основным требованием. Кроме того, в этой области проявляется еще одно достоинство Microsoft Visual C++, почти незаметное при разработке "обычных" приложений — высокая скорость работы двоичного кода, созданного компилятором системы.
Еще один плюс — переносимость приложений, написанных на C++ (правда, без использования библиотеки MFC), на другие платформы. Конечно, сейчас наибольшую часть рынка shareware занимают программы для MS Windows, однако у операционных систем Linux и BeOS неплохой потенциал, и если в будущем вы решите сделать версию своего продукта и для других платформ, это будет не так уж и сложно. А для некоторых программ, например сетевых средств, написание версии для Linux может понадобиться уже в начале разработки Windows-версии.
Пожалуй, единственный недостаток Visual C++ для shareware-программиста, особенно новичка в этой области, обусловлен, как это ни странно, тем, что эта система является стандартом де-факто в сфере профессиональной разработки программного обеспечения. Дело в том, что среди всевозможных библиотек и дополнительных компонентов для Microsoft Visual C++ бесплатных продуктов относительно немного. Серьезные печатные руководства и подписка на CD-ROM с документацией также стоят недешево. Впрочем, для многих программистов этот недостаток таковым и не является — все зависит от характеристик разрабатываемой программы, а также квалификации и требований самого shareware-автора. Возможно, вам хватит и обширной документации и множества примеров исходных текстов, размещенных в Интернете, а также информации из тематических конференций.

Выбор названия программы

Выбор названия программы

После того как вы определились с тематикой программы, нужно решить, как вы ее назовете. К этому делу следует подходить также ответственно, как, например, к выбору имени для ребенка — ведь от этого будет зависеть, будет ли "жизнь" вашей программы успешной и яркой или ваше детище будет прозябать в безвестности.
Первое, что приходит на ум начинающему шароварщику, — это назвать программу как-нибудь кричаще и вызывающе — с использованием слов "best", "great", "cool" и т. п. Например, совсем недавно мне встретился анонс продвинутого менеджера интернет-закладок. Автор программы назвал свое детище... конечно же, "SuperCool Bookmark".
Такие напыщенные названия отрицательно влияют на имидж программного продукта — они прочно ассоциируются с любительским творчеством начинающих и слишком молодых программистов, занимающихся разработкой программ из развлечения. В крайнем случае, это может сойти за слишком назойливую рекламу, что, сами понимаете, не добавляет симпатий со стороны потенциальных покупателей.
Другим минусом всех этих "super", "cool" и им подобных является то, что программу с таким названием практически невозможно найти в Интернете с помощью поисковых систем. В ответ на запрос типа "+super +cool" поисковая машина выведет сотни тысяч ссылок, и ссылка на вашу программу будет далеко не в первой тысяче. Это очень важно, т. к. поисковые системы являются одним из основных ресурсов, приводящих к вам новых пользователей (см. гл. 9, 10).
Другая ошибка, которую совершают некоторые авторы, — это выбор названия, которое никак не отражает назначение программы. Даже если оно будет красивым и приятным на слух, но ничего не говорит потенциальным пользователям о том, для чего именно предназначена программа, то пользователи так и останутся "потенциальными", в том числе и потому, что возникнут проблемы при поиске программы в поисковых системах, и даже в Интернет-каталогах программ.
В качестве примера могу привести download-менеджер FlashGet (http:// www.amazesoft.com). Первоначально автор, Кевин Ху (Kevin Hou), назвал свою программу JetCar (в дословном переводе с английского - "реактивный автомобиль"), избрав в качестве эмблемы красную гоночную автомашину. Номер версии еще не достиг 1.0, a JetCar пришлось переименовать во FlashGet, чтобы он более явно ассоциировался с классом download-ме-неджеров, лидерами в котором являются продукты с похожими названиями — ReGet и GetRight, — отражающими назначение программы (в данном случае — получение (англ, get) файлов с интернет-серверов).
Более того, нужно постараться избежать любой двусмысленности в названии продукта. Тут мне, к сожалению, приходится обратиться к своему опыту. Два года назад, подбирая название для собственной программы (менеджера автозагрузки Windows), я без особых колебаний остановился на слове "RunServices". Во-первых, так называется один из ключей системного реестра Windows, где хранятся параметры команд, автоматически запускаемых при старте операционной системы, а во-вторых, "services" в названии программы намекало на некоторую техническую "продвинутость" целевой аудитории продукта: На практике оказалось, что такое название больше подходит для менеджера процессов наподобие Диспетчера задач в Windows NT и Windows 2000. Среди невольно введенных в заблуждение оказался даже обозреватель одного из крупнейших архивов программного обеспечения Tucows (http://www.tucows.com). Он совершенно неправильно написал, что RunServices будто бы "позволяет просмотреть, какие приложения и DLL в настоящий момент запущены на вашем компьютере. Вы можете затем закрыть или временно отключить приложения, съедающие ценные ресурсы". В таком некомпетентном обзоре в большей степени, конечно, виноват сам обозреватель Tucows (естественно, в своей заявке я указал четкое описание функций программы), однако, если бы RunServices называлась более понятно, например, "Startup Manager", я уверен, возможностей для возникновения таких недоразумений было бы гораздо меньше. Поэтому я решил переименовать свою программу в "Actual Startup".
Пытаясь придумать оригинальное название своей программы, некоторые авторы искажают написание обычных слов, заменяя в них одну-две буквы. Вот и появляются программы, зовущиеся, например, "AllPicturez". Этот прием нельзя назвать удачным, по крайней мере, я не могу припомнить среди успешных shareware-проектов продукт с названием такого рода. Ведь если для некоторых нас такое название может звучать необычно, то для зарубежных пользователей это просто безграмотное написание слов, которое, как известно, не добавляет положительных эмоций.
Замена буквы "s" на "z" - особенно большая ошибка: так традиционно любят "отмечаться" хакеры и крякеры, взламывающие системы защиты или ворующие различную ценную информацию (примеры такого хакерского "словообразования" вы наверняка встречали в Интернете - "warez", "filez", "rulez", "toolz" и т. п.). Поэтому, скорее всего, пользователь решит не скачивать и тем более не приобретать программу с таким названием из-за опасений получить на свой компьютер "троянского коня" или отдать номер своей кредитной карточки в руки нечестных людей. Пожалуй, исключение из этого правила составляют программы, работающие в области безопасности системы, подбора паролей, удаленного администрирования и т. п. Разработчиками и пользователями таких продуктов очень часто являются бывшие или действующие хакеры, поэтому здесь встретить понимание аудитории гораздо легче. Но, с другой стороны, среди пользователей этой категории программного обеспечения много полицейских участков, частных детективных агентств, есть даже департаменты ФБР и ЦРУ — т. е. те, кто хакеров не любит, а наоборот, борется с ними всеми доступными способами. Поэтому я бы не советовал вам экспериментировать со всякими "Terminalz" или "Serverz" - - незачем так рисковать понапрасну: английский язык, хотя и не так "велик и могуч", как русский, но оригинальное название для своей программы вы сможете подобрать и без такого "творчества".
Удачным противопоставлением бездумному коверканью терминов может служить искусная игра слов. Например, в свое время мне очень понравилось название InSite, которое звучит так же, как и английское "insight" (означающее "проницательность" и "интуиция"), и одновременно идеально подходит для применения в области Web-технологий.
Существует еще один момент, который может помочь вам в раскрутке своей программы. На некоторых крупных shareware-архивах, например, уже упоминавшихся Download.com и Tucows, список программ сортируется не по дате поступления в каталог, а по алфавиту. Как следствие, наибольшее внимание посетителей архива получают программы, названия которых начинаются на "А", "В", "С" и другие буквы, идущие в начале латинского алфавита.
Многие авторы, конечно, это знают, и поэтому используют различные "хитрости", чтобы название программы начиналось на "А". Например, одно время существовала повальная мода добавлять к названию слово "advanced" (продвинутый). В качестве иллюстрации можно привести результат поиска этого слова в каталоге SoftList (http://www.softlist.ru/cgi-bin/search.cgi?query=advanced), содержащий несколько десятков программ с названиями, начинающимися с "Advanced". В конце концов появление новых продуктов с такими названиями стало вызывать у пользователей иронию — если существует, например, "Advanced System Tweaker", то где же тогда "обычный" System Tweaker? К тому же новые программы с "продвинутыми" названиями частенько на самом деле оказывались маломощными поделками, компрометируя слово "advanced" в названии программы. Поэтому на смену "advanced" пришли другие слова, например, "active" (эффективный, действенный), "actual" (современный, реальный, подлинный). Некоторые поступают еще проще, поставив в начале названия неопределенный артикль "а".
Более гибкое решение — добавление в начало названия программы инициалов разработчика или аббревиатуры названия компании, например, ACDSee, ASPack, AYPad и т. п. В этом случае, помимо лучшей позиции в алфавитном списке программ, гораздо легче добиться уникальности названия. Почему это важно — читайте ниже.
Примечание
Примечание


Конечно, не стоит думать, что продукт, название которого начинается, например, на "Q" или "W", заранее обречен на провал. Просто, начиная такой проект сейчас, когда shareware-рынок перенасыщен, будет чуть-чуть сложнее достичь популярности. К тому же, подавляющее большинство архивов программного обеспечения сортируют списки продуктов все-таки не по алфавиту, а по дате поступления программ в каталог.
Помимо каталогов программ, большая часть аудитории узнает о shareware-программах через поисковые системы. Многие поисковые механизмы при индексировании Web-страниц и выполнении поисковых запросов посетителей специальные символы и знаки препинания либо игнорируют, либо интерпретируют как элементы синтаксиса собственного языка запросов. Учитывая эту особенность сетевых поисковых машин, нужно стремиться не использовать в названии программы специальных символов или знаков препинания, например дефисов, знака "плюс", вопросительных или восклицательных знаков. Последний вариант, однако, довольно распространен — вспомните широко известные CorelDRAW!, The Bat! и др. Например, название популярного в России и за рубежом пакета серверов E-serv было заменено на Eserv исключительно в целях улучшения "находимое™" программы в поисковых системах.
Кстати, об инициалах в названии программы. Некоторые авторы идут еще дальше — включают в название программы свое имя или фамилию. Это — ошибка, потому что, как свидетельствует практика, программа, называемая именем автора, у пользователей прочно ассоциируется с любительским творчеством, отсутствием поддержки и т. п. Давно прошли те времена, когда программы расхватывались, как горячие пирожки, a "Norton Commander" звучало более солидно, чем "Microsoft Windows". Потенциальные покупатели сегодня разборчивы и осторожны, — они гораздо охотнее доверяют продуктам, продающимся от лица компании.
Это, конечно же, не означает, что, прежде чем начинать продажи, вам нужно будет обязательно зарегистрировать собственную фирму. Вполне достаточно просто придумать себе псевдоним и выступать, к примеру, не как Alexey Ivanov, а как AV Software. Вместо "software" подходят и другие термины, ассоциирующиеся с современными наукоемкими технологиями: research, labs, technology, tools, products, works и т. п.
Естественно, такой подход слишком уж прост, и лучше взяться за дело более творчески, т. к. яркое название вашей программы легче запомнится пользователями и сделает раскрутку вашего проекта более эффективной. Юрий Герасимов, автор программы Chameleon Clock (см. разд' "Успешные российские shareware-проекты" гл. 1), выбирая название для бранда, от имени которого он будет распространять свой продукт, даже выработал целую методику:
"Сначала придумывается несколько возможных групп-направлений. Вплоть до самых диких, т. к. первое правило мозгового штурма — ничего не критиковать в процессе генерации идей. В моем случае это были скины, desktop-программы, красивые программы, слоган "Time to change" (Время перемен) и даже "место, где живет Chameleon Clock".
Затем под каждую группу пишется списочек всевозможных названий: у меня их было более сотни.
После этого — мучительный процесс отбора 3—7 лучших названий в каждой группе, сопровождающийся проверкой занятости соответствующих интернет-доменов в зоне .com, консультациями на предмет "нравится/не нравится" с друзьями, с женой, коллегами, родственниками и т. п.
Потом пишется подробное письмо американским и вообще англоязычным покупателям с просьбой помочь в выборе. Описываются все свои группы, свои варианты и размышления по этому поводу. Максимально подробно, чтобы не было впечатления, что разработчик сам над этим не думал и просит подумать за него — наоборот, надо сказать, что ты думал так много и придумал столько хороших вариантов, что даже не знаешь, какой выбрать.
Дальше нужно дождаться реакции. Важно мнение людей, для которых английский язык является родным — только они могут подсказать вам, что самое благозвучное для вас название на самом деле неприемлемо — скажем, из-за особенностей сленга или местных традиций.
В моем случае интересным вариантом, от которого многие просто пищали, был сайт www.lizardtree.com (место, где живет Chameleon Clock) — вплоть до того, что просили отдать это имя, если я сам его использовать не буду (я не сделал ни того, ни другого). В ряду других вариантов был сайт www.shapesoft.com, и один из покупателей, голливудский консультант, преддожил переделать его в сайт www.softshape.com как более благозвучный и даже сексуальный, и сам предложил слоган "Software doesn't have to be ugly" (Программное обеспечение не должно быть уродливым). Тут пришла моя очередь пищать — Happy End".
Как вы видите, при выборе названия нужно обязательно проконсультироваться с зарубежными пользователями и при этом проверять, не используется ли выбранное вами название уже кем-то другим.
Обратите внимание на то, что относительно будущего названия для вашего продукта нужно обязательно консультироваться не просто с англоговорящими пользователями, а с теми, для которых английский язык является родным. Только они могут указать вам на различные лингвистические тонкости, из-за которых вашу программу просто никто не захочет купить, или, наоборот, подскажут вам лучший вариант.
Замечание 1
Замечание 1


При этом из-за разницы в культурных традициях вариант, который российский программист вряд ли выберет в качестве названия для своего продукта, окажется вполне благозвучным для зарубежного пользователя. Например, американцы очень уважают змей, которые считаются символом мудрости, и название, включающее английское "snake", может быть неплохим вариантом, однако мало у кого из россиян змеи вызывают положительные эмоции. А слово "maniac" в США в первую очередь обозначает увлекающегося человека, фаната, а не извращенца, как в России.
В крайнем случае, спросите совета у профессионального и квалифицированного переводчика, работавшего за рубежом, или посмотрите в библиотеке самый обширный англо-русский словарь, напечатанный в течение нескольких последних лет. Такие словари учитывают особенности современного английского языка и обычно содержат и сленговые словоформы.
Что касается проверок, не используется ли выбранное вами название уже кем-то другим: если вы не сделаете этого, может оказаться, что выбранное вами название не только занято, но и официально зарегистрировано в качестве торговой марки. А это через некоторое время обязательно приведет к конфликту с владельцем прав на нее, и вам придется в лучшем случае спешно переименовывать свою программу или сайт, а в худшем — сильно страдать материально. Кроме того, многие пользователи, занимаясь поиском вашей программы в Интернете, будут натыкаться на сайт "тезки". Скорее всего, вашу программу также не возьмут и серьезные каталоги программного обеспечения, чтобы избежать путаницы из-за множества программ с одинаковыми именами.
Проверку уникальности выбранного вами названия можно проводить в три этапа.

Проверка, не является ли выбранное название чьей-то зарегистрированной торговой маркой. Сделать это можно по адресу http:// www.nameprotect.com.

Проверка, не используется ли название кем-то другим. Для этого можно воспользоваться одной из крупнейших поисковых систем AltaVista (http://www.altavista.com). Введите в поле образца для поиска интересующее вас слово (если вы проверяете сочетание слов, то обязательно в кавычках и только строчными буквами) и нажмите кнопку Search (Поиск). Если в результате запроса ничего не было найдено или было найдено несколько ссылок, к предмету поиска не относящихся, то этот этап можно считать пройденным.

Проверка, не зарегистрирован ли соответствующий домен в зоне .com (это можно сделать, например, по адресу http://www.domainsearch.ru) (О доменах и их регистрации см. гл. 9).

Если все три этапа были пройдены успешно — выбранное вами название можно считать пригодным для использования.

Учебник по созданию shareware программ

Какие права есть у программиста

Какие права есть у программиста

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

право авторства — т. е. право считаться автором программы. Какими бы резкими не были повороты в судьбе автора, кто бы ни владел программой — но автором программы всегда будет считаться тот, чьим трудом она создана — и это право у автора никто не отнимет;

право на имя — т. е. право определять форму указания имени автора в программе: под своим именем, под условным именем (псевдонимом) или анонимно;

право на неприкосновенность (целостность) — т. е. право на защиту как самой программы, так и ее названия от всякого рода искажений или иных посягательств, способных нанести ущерб чести и достоинству автора. Это право, в отличие от прав на авторство и на имя, после смерти автора может передаваться по наследству, чтобы наследники могли защищать честь и достоинство автора.

Замечание 3
Замечание 3


Неотчуждаемость и непередаваемость личных неимущественных прав дает основание такому распространенному заблуждению, что лишь эти права и являются "авторскими", т. к. они могут принадлежать только автору. На самом деле объем правомочий, охватываемых понятием "авторское право", гораздо шире — в него входят и имущественные права.
Вторая группа авторских прав — имущественные. Такие права, после создания программы принадлежащие ее автору, могут передаваться по договору, и в результате этого обладателями таких прав могут становиться как частные лица, так и организации.
Общий смысл имущественных прав — это право использовать программу или разрешать ее использование в любой форме и любым способом. В частности, автор (или обладатель исключительных прав на программу) имеет право осуществлять или разрешать:

выпуск программы в свет;

воспроизведение программы (полное или частичное) в любой форме, любыми способами;

распространение программы. Это право в индустрии shareware нарушается чаще всего, когда кто-то начинает распространять чужие программы без разрешения правообладателя;

модификацию программы для ЭВМ или базы данных, в том числе перевод программы с одного языка на другой. Это право также нарушается достаточно часто — например, когда пользователи из неанглоговорящих стран переводят интерфейс программы на свой родной язык, изменив DLL- или ЕХЕ-файлы программы. Впрочем, авторы относятся к таким самодельным модификациям своих программ лояльно (если, конечно, других изменений, например взлома защиты, нет) — ведь это только повышает популярность программы.

Допускаются и другие способы использования компьютерных программ, Закон не устанавливает их точный перечень, завершая список словами "иное использование программы". Важно то, что все права на любое использование программы принадлежат автору (или тому, кому эти права автором переданы).
Замечание 4
Замечание 4


Среди пользователей распространено мнение, что программу в некоммерческих целях можно использовать бесплатно — это якобы разрешают статьи Закона об авторском праве и смежных правах. Это — всего лишь неудачная попытка оправдать использование пиратских копий программ "домашними" пользователями. Разрешения бесплатного использования программ в некоммерческих целях в законодательстве нет, только автор вправе решать, на каких условиях можно пользоваться его программой.
Имущественные права на программу, как уже упоминалось выше, могут быть переданы полностью или частично другим физическим или юридическим лицам. Передача прав осуществляется по договору, который заключается в письменной форме. Этот договор обязательно должен определять объем и способы использования программы, порядок выплаты и размер вознаграждения, срок действия договора. Кроме того, имущественные права на программу переходят и по наследству.
Использование программы осуществляется также по письменному договору с правообладателем. Естественно, при массовом распространении программ физически невозможно с каждым пользователем отдельно заключать договор. В этом случае допускается применение особого порядка заключения договоров, например путем изложения типовых условий договора на передаваемых экземплярах программ.
Таким особым порядком заключения договора на использование программы является лицензионное соглашение.

Лицензионное соглашение

Лицензионное соглашение

Лицензионное соглашение (License Agreement, также End-User License Agreement (EULA) — лицензионное соглашение для конечного пользователя), прикладываемое к копии программы, является юридическим документом, определяющим, условия, на которых владелец прав на программу разрешает ее использование. По сути дела, это двусторонний письменный договор между правообладателем и пользователем, договор, имеющий упрощенный порядок заключения: под ним не ставятся подписи его участников. Такое лицензионное соглашение считается заключенным, если пользователь устанавливает, копирует или осуществляет доступ или иным образом использует программу. Если пользователь не согласен с условиями лицензионного соглашения, то он обязан прекратить использование программы и удалить ее файлы со своего компьютера. Объем прав, предоставляемых лицензионным соглашением, называется лицензией.
Для shareware-программ, которые распространяются в виде файла инсталлятора, лицензионное соглашение обычно выполняется в виде текстового файла license.txt и/или раздела в справочной системе. Для того чтобы пользователь мог сразу ознакомиться с его условиями, и в дальнейшем лицензионное соглашение было всегда под рукой, рекомендуется:

включить показ текста лицензионного соглашения в инсталлятор программы, чтобы пользователь не смог продолжить установку, не нажимая кнопку Согласен. Большинство современных пакетов для создания инсталляционных программ позволяют организовать эту функцию;

при инсталляции программы создавать папке соответствующей программы в меню Пуск не только ярлык к файлу программы, но и к файлу license.txt. Можно также включить кнопку Лицензия для просмотра лицензионного соглашения в окне О программе (About).

Замечание 5
Замечание 5


Кто-то из читателей, возможно, с иронией отнесется к тому, сколько внимания уделяется мной лицензионному соглашению. Тем не менее, лицензионное соглашение является действительно значимым юридическим документом, уважаемым не только официальными лицами, но и обыкновенными пользователями, особенно в странах Западной Европы и Северной Америки, которые являются основными легальными потребителями shareware-программ.
Большинство shareware-разработчиков особенно не утруждают себя самостоятельным составлением лицензионного соглашения к своим программам. Они просто копируют текст лицензионного соглашения к какому-нибудь известному и успешному продукту, справедливо рассудив, что условия такого соглашения выработаны профессиональными юристами, отражают сложившуюся в отрасли практику и "проверены временем". С юридической точки зрения в таком заимствовании нет ничего противозаконного: тексты юридических документов не защищаются авторским правом, и их можно копировать и изменять совершенно свободно.
Тем не менее, даже если вы копируете лицензионное соглашение из дистрибутива какого-либо другого продукта, внимательно прочитайте его текст. Возможно, он не совсем подойдет именно вашему продукту. Иногда доходит до смешного: автор программы предлагает своим пользователям перевести ее интерфейс на разные языки в обмен на бесплатную регистрацию, в лицензионном же соглашении (позаимствованном у другого shareware-продукта) написано, что перевод программы запрещен.
Учтите, что грамотное лицензионное соглашение к shareware-программе должно содержать следующие основные положения.
Во-первых, в самом начале лицензионного соглашения должен быть указан правообладатель программы, т. е. обладатель имущественных прав на нее. Так как распространение даже тех программ, написанных всего одним человеком и продвигаемых им же, все равно лучше всего производить от лица "фирмы", т. е. под псевдонимом, то в качестве правообладателя в лицензионном соглашении должно быть указано название этой "фирмы".
Во-вторых, из лицензионного соглашения пользователю должно быть четко видно, что право на использование программы он получает только после регистрации, а до этого он может использовать ее в течение тестового периода. Кроме констатации факта необходимости регистрации, нужно указать ее порядок — ссылку на страницу регистрации, цену программы и т. п.
Чем, например, плохи лицензионные соглашения ко многим "коробочным" продуктам, например, той же Microsoft Windows? Из их содержания совершенно не понятно, что программа должна быть куплена в магазине за определенную сумму. Такое лицензионное соглашение уже предоставляет пользователю право на использование программы, вне зависимости от того, каким образом в его руки попал соответствующий продукт. Из-за этого, например, к ответственности за незаконное использование "коробочных" программных продуктов практически невозможно привлечь "частного" пользователя. Обвинению довольно сложно доказать, что пользователь знал, чем отличается его диск с нелицензионной версией Windows от так называемых "упрощенок", т. е. версий "коробочных" продуктов, выпускаемых в простом оформлении, без коробки и печатной документации, в виде обычного компакт-диска, который к тому же продается по цене, примерно эквивалентной стоимости пиратского диска.
Другое дело — грамотно составленное лицензионное соглашение к shareware-программе. Вот, например, выдержки из текста файла license.txt, прилагаемого к известному файловому менеджеру FAR (http://www.rarsoft.com), в переводе с английского:
"Каждый может использовать это программное обеспечение в течение тестового периода продолжительностью в 40 дней. Если вы захотите использовать FAR после этого 40-дневного тестового периода, вы ОБЯЗАНЫ зарегистрироваться.
Зарегистрировавшись, пользователь получает неэксклюзивную лицензию использовать FAR на одном компьютере в любых законных целях".
И, чтобы у пользователя не возникло ложного впечатления, что он уже зарегистрировался, например, заполнив какую-нибудь опросную форму на сайте или приняв участие в online-голосовании, сообщается:
"Чтобы зарегистрироваться, Вы должны заполнить регистрационную форму и отослать ее вместе с регистрационной платой на один из авторизованных регистрационных сайтов (см. файл far_site.txt после установки программы)".
Разработчики архиватора WinZip (http://www.winzip.com) пошли еще дальше: они составили для своей программы два отдельных лицензионных соглашения — для незарегистрированных и зарегистрированных пользователей.
В третьих, в лицензионном соглашении, конечно же, должен быть указан объем прав, предоставляемых пользователю.
Одно из основных прав, предоставляемых пользователю, — право использования программы. Перечислить все то, что подразумевается под словом
Неэксклюзивность лицензии означает, что права, предоставляемые по ней пользователю, правообладатель может предоставить и кому-либо еще.
"использовать", невозможно, поэтому обычно в лицензионном соглашении также перечисляют такие действия, которые пользователю с продуктом производить запрещается. Например, может быть запрет изменять, дизассемб-лировать программу, сдавать ее в аренду, распространять зарегистрированную версию и т. п. А в лицензии на архиватор RAR (http://www.rarsoft.com), например, указывается: "Вы не можете использовать, копировать, эмулировать, клонировать, сдавать в аренду, давать напрокат, продавать, изменять, декомпилировать, дизассемблировать, передавать лицензированную программу или ее часть иначе, чем это описано в данной лицензии".
Для некоторых типов программного обеспечения могут указываться и специфические виды использования. Например, лицензии на компоненты и библиотеки для разработки программ могут включать разрешение использовать эти библиотеки и компоненты для разработки различных категорий программ — в зависимости от стоимости регистрации. Например, лицензия, приобретенная за 30$, может разрешать использование продукта для разработки только freeware и shareware-программ, а лицензия за 100$ может допускать разработку любого программного обеспечения, в том числе и коммерческого ("коробочного").
Кроме этого, в лицензии должно быть указано, на каком количестве компьютеров может быть установлена зарегистрированная пользователем программа. Большинство соглашений такую информацию содержит — кроме того, уже при заполнении регистрационной формы на сайте компании-регистратора пользователю предлагается выбрать, на сколько именно компьютеров он хочет приобрести лицензию — 1,3, 5, 10, 20 и т. д. Некоторые программы не имеют лицензий на несколько компьютеров: если такую программу планируется применять, например, в локальной сети предприятия или компании, то нужно купить соответствующее количество "однопользовательских" лицензий. Однако такой порядок не всегда удобен. Например, многие пользователи спрашивают разработчиков shareware-программ: а что делать, если требуется работать с программой и на домашнем компьютере, и на переносном? Ведь было бы несправедливо заставлять пользователя приобретать еще одну лицензию на программу. Мне нравится, как этот вопрос решен в лицензионном соглашении к WinZip: "Эта копия WinZip может быть либо использована одним лицом, которое работает с данным программным обеспечением на одном или нескольких компьютерах, либо установлена на одном компьютере (рабочей станции), к которому не одновременно имеют доступ несколько человек, но не оба варианта сразу".
При определении объема прав, передаваемых пользователю, всегда существует вероятность, что составитель лицензионного соглашения забыл указать какие-либо права, которые он передает или, наоборот, не передает пользователю. Также возможна ситуация, когда по истечении некоторого времени могут появиться новые возможности использования программы, которые обусловлены закономерным развитием науки и техники. В результате этого может получиться так, что пользователь, руководствуясь принципом "что не запрещено, то разрешено", будет использовать программу способом, против которого обладатель прав обязательно возражал бы. Для того чтобы исключить возникновения такой коллизии, во многих лицензионных соглашениях записывается следующее положение: "Любые другие права, не указанные явно в настоящем Соглашении, принадлежат [наименование правообладателя]". Аналогичный смысл имеет уже процитированная выше фраза из лицензионного соглашения RAR: "Вы не можете использовать [...] лицензированную программу или ее часть иначе, чем это описано в данной лицензии".
Помимо объема передаваемых прав, нужно указать территорию, на которой программа может применяться. В большинстве соглашений авторы пишут, что их продукты можно использовать в любой стране мира. Это, конечно, очевидно, однако такое уточнение необходимо, т. к. в лицензионном соглашении, как юридическом документе, не должно быть никаких неясностей.
К теме территориального распространения прав относится вопрос о том, что делать, если законы страны, где живет пользователь, противоречат условиям лицензионного соглашения. Думаете, это актуально только для тех нецивилизованных стран, где авторское право отсутствует, и разработчики программ никак не защищены? Вовсе нет, такая ситуация вполне возможна и в России. Например, по российскому законодательству пользователь может передать (например, продать) имеющуюся у него лицензионную копию программного продукта кому-либо еще, при условии, что он прекратит использование продукта и сотрет у себя на компьютере все соответствующие файлы. Лицензии на большинство приложений, рассчитанных на массового пользователя, это позволяют. Но не все. Например, однажды мне попалось в руки лицензионное соглашение к программе для научных расчетов, стоимость которой составляет ни много ни мало 30 000$. В нем был пункт, запрещающий передачу экземпляра программы третьим лицам без согласия компании-производителя.
Такие коллизии между условиями лицензионного соглашения и правилами, установленными законодательством, разрешаются достаточно просто: право пользования программой предоставляется только на условиях, описанных в лицензионном соглашении. Поэтому если пользователь не согласен с ним, то он обязан прекратить использование копии продукта, вернуть ее производителю и получить свои деньги обратно. Но, чтобы внести окончательную ясность, некоторые разработчики предусмотрительно записывают в лицензионном соглашении: "Если условия данного Соглашения противоречат законодательству Вашей страны, использование данного продукта запрещается".

Может ли ваш босс отнять у вас программу

Может ли ваш босс отнять у вас программу

Этот вопрос волнует многих начинающих shareware-разработчиков, так часто путь в shareware-бизнесе начинается с места штатного программиста в какой-нибудь компании, а первая shareware-программа нередко пишется в рабочее время и на оборудовании, принадлежащем работодателю.
Некоторые думают примерно так: "Да что я, зря все эти годы работал программистом за крошечную зарплату? Вон, в прошлом году закончил проект, из-за которого у меня начальник немало крови попил, босс доволен остался, даже премию в два оклада выписал... Возьму-ка я ту программу, оформлю ее как shareware и буду продавать! Ведь автор-то — я!"
Поступать так не стоит даже и пытаться. Скорее всего, вам будет предъявлен серьезный иск в нарушении авторских прав, и выйти из судебного разбирательства победителем нет шансов. И вот почему.
Имущественные права на программу (как и другое произведение), созданную в порядке выполнения служебных обязанностей или по заданию работодателя (так называемая служебная программа), принадлежат работодателю, если в договоре между ним и автором не предусмотрено иное. Естественно, работодатель, который и так выплачивает автору "зарплату и несет другие расходы, связанные с содержанием персонала, заинтересован в полной передаче имущественных прав на программу.
У автора остаются личные неимущественные права — например, право на авторство, на имя и т. п. Но обладание этими правами не позволяет автору заниматься распространением программы — это относится к сфере имущественных прав, которые, как уже говорилось выше, по умолчанию принадлежат работодателю.
Чтобы программа считалась служебной, работодатель должен четко зафиксировать конкретные служебные обязанности сотрудника (например, в должностной инструкции) или выдать ему служебное (например, техническое) задание, причем обязательно в письменной форме.
Для того чтобы закрепить взаимоотношения работодателя и автора при работе по какому-либо определенному проекту, работодатель может заключить с автором договор, в котором будут подробно расписаны условия работы. Чтобы увеличить заинтересованность своего сотрудника в результатах работы по созданию программного обеспечения, работодатель может определить размер выплаты автору в качестве вознаграждения, дополнительно к заработной плате, определенного процента с дохода или прибыли, полученной работодателем от реализации данной программной разработки.
А вот если программист пишет на рабочем месте программу без ведома работодателя, в свободное от выполнения основной работы время — например, какие-то утилиты "для себя", то все авторские права, в том числе и имущественные, в данном случае сохраняются за автором. Конечно, работодатели не одобряют такую деятельность, и лучше стараться не предавать ее огласке.

Нужно ли регистрировать или патентовать свою программу

Нужно ли регистрировать или патентовать свою программу

Согласно российскому законодательству о правовой защите программ для ЭВМ, а это в первую очередь Закон Российской Федерации о правовой охране программ для электронных вычислительных машин и баз данных №3523-1 от 23 сентября 1992 года, авторское право на компьютерные программы возникает в силу их создания. Для признания и осуществления авторского права на программу не требуется депонирования, т. е. сдачи экземпляра программы на хранение, регистрации, патентования или соблюдения иных формальностей. Такой упрощенный порядок признания прав автора программы применяется для более надежной их защиты, т. к. в случае необходимости регистрации программы авторские права оставались бы без охраны, если автор по каким-либо причинам не мог зарегистрировать свою программу.
Автором программы признается физическое лицо (т. е. конкретный человек, а не организация), в результате творческой деятельности которого эта программа создана.
Замечание 1
Замечание 1


Исключительные права на программу (см. разд. "Какие права есть у программиста" этой главы) могут передаваться авторами другим лицам — как физическим, так и юридическим, т. е. организациям. Поэтому, говоря о правах на соответствующую программу, да и вообще на любое произведение, охраняемое авторским правом, употребляют термин "правообладатель", а не "автор", т. к. владелец прав на программу не обязательно является ее автором.
Для оповещения о своих правах на соответствующую программу правообладатель может поместить в ней (обычно в диалоговом окне О программе (About), справочной системы и файле readme.txt) знак охраны авторского права (Рисунок 3.1), состоящий из следующих элементов:

Буквы С в окружности или в круглых скобках.

Наименования (имени) правообладателя.

Года первого выпуска программы в свет.

Так как shareware-программы в основном предназначаются для иностранного рынка, то знак охраны авторского права в них обычно пишется на западный манер:

Слово "Copyright" (что означает "авторское право").

Буква С в окружности или в круглых скобках.

Год первого выпуска программы в свет и через средний дефис — год выпуска последней версии программы (естественно, если они не совпадают).

Наименование (имя) правообладателя.

Фраза "All rights reserved".

Примечание
Примечание


Иногда, при составлении уведомления об авторских правах на русском языке, в него включают перевод фразы "All rights reserved": "Все права защищены", или дословный перевод: "Все права зарезервированы". Нужно сказать, что применение и первого, и тем более второго варианта перевода является неправильным, т. к. смысл этой фразы означает примерно следующее: "Все права принадлежат правообладателю". Всеобщая же распространенность упомянутых выше лаконичных имеющих угрожающий оттенок переводов, обусловлена, видимо, желанием обладателей авторских прав более четко донести до публики смысл знака ©.
Таким образом, типичное объявление своих авторских прав на shareware-программу выглядит так:
Copyright © 1998-2002 AVSoftware. All rights reserved.

Окно About sharewareпрограммы

Рисунок 3.1. Окно About shareware-программы с информацией об авторских правах


Замечание 2
Замечание 2


Вопреки распространенному мнению, знак © не является указанием на то, что программа где-то зарегистрирована. Это — только оповещение об авторских правах.
Несмотря на то, что регистрация программ не требуется, обладатель прав на программу может по своему желанию зарегистрировать ее в Российском агентстве по правовой защите программ для ЭВМ и баз данных.
Для этого грамотно должна быть оформлена заявка (см. "Правила составления, подачи и рассмотрения заявок на официальную регистрацию программ для электронных вычислительных машин и баз данных", утвержденные Приказом РосАПО от 5 марта 1993 г. № 7п). В заявку, помимо информации о программе и ее авторе, включаются материалы, идентифицирующие программу, в том числе реферат. После одобрения заявки программа включается в Реестр программ ЭВМ, сведения о ней публикуются в официальном бюллетене Роспатента, а автору выдается свидетельство об официальной регистрации.
Государственная регистрация, несмотря на свой официальный статус и внешнее сходство с процедурой патентования, не имеет и сотой доли значения последней и не предоставляет никаких дополнительных прав. Например, тех материалов, которые предоставляются на депозитное хранение в Российском агентстве по правовой защите программ для ЭВМ и баз данных, недостаточно для проведения технической экспертизы при разрешении возможного спора об авторстве той или иной программы. Регистрация в основном нужна только тогда, когда планируется передача авторских прав на программу, и лицу, передающему права, требуется официальное подтверждение своих полномочий, чтобы предъявить его своему партнеру. Поэтому регистрация программ на практике — не очень частое явление.
А можно ли запатентовать свою программу, чтобы она была так же надежно защищена, как, например, и изобретения? Согласно п. 3 ст. 4 Патентного закона компьютерные программы и алгоритмы не относятся к числу патентоспособных изобретений, т. е. патентование программ не допускается.
Вопрос о том, нужно ли ввести в Российской Федерации патентование программ - очень дискуссионный. Большинство из российских ученых считают, что патентование компьютерных программ является нецелесообразным по многим причинам. Например, программы и так уже охраняются авторским правом, и эта охрана возникает в момент создания программы. А вот для того, чтобы защитить программу патентом (при этом о.бъем прав, представленных правообладателю, будет такой же, как и в случае защиты авторским правом), нужно заполнить заявку, соблюсти определенные формальности, заплатить относительно крупные пошлины. Если по какой-то причине срок уплаты пошлины будет пропущен, то патентная охрана прекращается. Авторское же право на программу действует в течение всей жизни автора и еще пятьдесят лет после его смерти, что является, учитывая скорость морального старения компьютерных программ, практически вечностью. Кроме того, возможны коллизии и злоупотребления, вызванные наличием дублирующих друг друга способов охраны программ для компьютеров.
Противоположная точка зрения тоже имеет сторонников, т. к. патентование программного обеспечения допускается в иностранных государствах. Однако, изучая практику по этому вопросу, существующую за рубежом, можно предположить, что патентование в обозримом будущем вряд ли коснется shareware-программ. Например, в США, Великобритании и Европе, в Европейском патентном ведомстве, участниками которого являются 19 стран Европы: Германия, Австрия, Франция, Бельгия, Испания, Италия и др., патентуются такие программы, при использовании которых уже известное аппаратное обеспечение приобретает новые свойства. Естественно, такого рода программы имеют слишком высокую стоимость разработки и достаточно специфическую область применения, чтобы быть распространяемыми на shareware-рынке.

Учебник по созданию shareware программ

Фрагмент файла с переводом интерфейса

Рисунок 4.4. Фрагмент файла с переводом интерфейса программы Intranet Chat на русский язык. Каждой форме соответствует отдельная секция, каждому элементу управления — отдельный ключ


В заключение я хотел бы обратить ваше внимание на излишнюю торжественность, которая сопровождает процедуру смены языка интерфейса в некоторых программах. После того, как пользователь выберет новый язык интерфейса, программа сообщает ему, что для того, чтобы сделанное изменение вступило в силу, нужно перезапустить программу. Их авторам так и хочется сказать: "Не делайте из своей программы культа!" (см. разд. "Поменьше эгоизма" данной главы). Ведь существует достаточно большое количество shareware-продуктов, язык интерфейса которых меняется прямо "на лету", без перезапуска самой программы. Все, что нужно для этого — немного времени программиста, потраченного на реализацию соответствующих функций.

Инсталлятор архиватора WinZip

Рисунок 4.3. Инсталлятор архиватора WinZip запрашивает согласие пользователя на изменение системных настроек и рабочей среды, в том числе и на добавление ярлыков в меню Пуск и на Рабочий стол

Мудрое хранение настроек

Мудрое хранение настроек

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


Можно также размещать настройки своих программ в двоичных файлах — так, как это делали программы в эпоху DOS. Однако сегодня этот подход особой популярностью не пользуется.
INI-файлы были основным способом хранения параметров программ еще в Windows 3.1. Системный реестр, также существовавший в ней, почти не использовался (Windows NT 3.51, активно работавшая с реестром, была распространена не очень широко). Вследствие этого программисты писали свои программы так, чтобы они сохраняли свои конфигурационные данные только в INI-файлах.
С выходом Windows 95 ситуация изменилась. Корпорация Microsoft провозгласила системный реестр основным хранилищем настроек не только самой операционной системы, но и всех ее приложений. Соответственно, разработчикам программ для Windows рекомендовалось использовать для сохранения параметров своих продуктов системный реестр, а не INI-файлы.
Прошло более пяти лет — целая вечность в мире информационных технологий, — а INI-файлы так и не утратили своей актуальности. Ведь далеко не всегда системный реестр может быть оптимальным средством для хранения настроек программ.
Основное достоинство реестра, по мнению некоторых экспертов, — относительная сложность повреждения информации, хранящейся в нем, из-за действий неопытных пользователей. Да, конечно, в каталоге Windows есть утилита regedit.exe, с помощью которой можно делать с реестром почти все, что угодно, однако начинающему пользователю до нее добраться гораздо сложнее, чем до INI-файла, для модификации которого достаточно просто дважды щелкнуть по нему мышью. Кроме того, Windows автоматически создает резервные копии системного реестра, и в случае его неосторожного повреждения может самостоятельно восстановить его. Если же пользователь случайно удалит или переименует INI-файл, то никто, кроме самой программы, не позаботится о ее нормальном функционировании.
На практике INI-файлы вовсе не так беспомощны. Функции чтения INI-файлов в современных системах программирования устроены таким образом, что удаление или некорректная модификация INI-файлов почти всегда не оказывает какого-либо отрицательного влияния на работу программы. А уж если включить в нее несколько строк кода, с помощью которых будет проверяться корректность чтения параметров из INI-файлов, то надежности работы программы на этом участке ничего не будет угрожать.
В то же время INI-файлы как средство хранения настроек программы обладают значительными преимуществами.
Во-первых, это касается скорости чтения и записи параметров. По мере того, как пользователь устанавливает все новые и новые программы, файл системного реестра на его компьютере разрастается до размера в несколько мегабайтов. Конечно, доступ к настройкам, хранящимся в INI-файле, объем которого обычно составляет несколько килобайтов, осуществляется гораздо быстрее. А т. к. чтение и запись настроек во время сеанса работы программы происходит довольно часто, разница в скорости может сэкономить немало времени.
Замечание 1
Замечание 1


Некоторые программы сохраняют свои настройки только в момент завершения работы — например, когда пользователь выбирает из меню File команду Quit или когда он нажимает кнопку с крестиком в заголовке главного окна. Однако такой подход является не совсем разумным, т. к. в случае некорректного завершения работы программы — в результате системного сбоя или отключения питания, все настройки, сделанные пользователем, пропадут, и при следующем запуске программы ему придется заново задавать все параметры. Поэтому запись всех настроек в INI-файл или системный реестр нужно производить, не откладывая — например, после нажатия кнопки ОК в диалоговом окне изменения параметров приложения.
Во-вторых, программы, хранящие свои конфигурационные данные в INI-файле, а не в реестре, гораздо удобнее в использовании, если на компьютере присутствуют несколько версий Windows — например, большинство пользователей, устанавливая Windows 2000, сохраняют возможность загрузки Windows 98 или Windows ME — как говорится, "на всякий случай". Так как любая версия Windows работает со своим файлом системного реестра, то под каждой версией Windows программу, использующую реестр, нужно настраивать отдельно, что сильно раздражает. А вот если параметры хранятся в INI-файлах, то пользователь даже и не будет замечать, что в прошлый раз он работал с этой программой под другой версией Windows.
Описанное здесь преимущество INI-файлов также способно сэкономить много времени и при переустановках операционной системы, которые, как вы знаете, не редкость (некоторые даже рекомендуют переустанавливать систему регулярно, раз в два-три месяца — так сказать, для профилактики). После того как Windows инсталлирована заново, программы, хранящие свои конфигурационные данные в INI-файлах, даже не нужно переустанавливать и настраивать (если, конечно, они не копируют в каталог Windows\System собственные DLL-библиотеки). Это особенно полезно, если в настройках программы хранится большое количество важной информации. Например, файловый менеджер FAR размещает в системном реестре, помимо параметров собственной работы, логины и пароли доступа к FTP-сайтам. Если об этом забыть и не скопировать настройки программы из реестра при помощи поставляемого с FAR командного файла SaveSettings.bat, то при переустановке Windows вся эта информация будет просто потеряна.
А вот что в системном реестре организовано лучше — это работа с конфигурациями для разных пользователей. Достаточно просто сохранять параметры работы программы не в ветви HKEY_LOCAL_MACHINE, а в HKEY_CURRENT_USER, и Windows при старте будет автоматически загружать нужный набор параметров для соответствующего пользователя.
Для INI-файлов такого стандартного средства не существует. Однако можно легко решить эту проблему. Например, с помощью функций Windows API можно получать логин, под которым вошел в систему текущий пользователь, и все настройки для него хранить в файле вида <имя_пользователя>.ini. А если ваша программа функционально достаточно сложна, то можно написать для нее целый менеджер пользовательских профилей, наподобие входящего в Windows 2000 — опытные пользователи наверняка это оценят и будут уважать вашу программу еще больше.

Не делайте из программы культа

Не делайте из программы культа

Некоторые авторы превращают работу со своими программами в подобие торжественного ритуала. Они никак не могут допустить, чтобы пользователь забыл о существовании их программ хотя бы на минуту и полностью сосредоточился на своей работе. Такие программы назойливо лезут в глаза, стараясь подчеркнуть свое, по мнению их авторов, особое значение для пользователя.
Я имею в виду в первую очередь такую, казалось бы, мелочь, как так называемый splash screen ("всплывающий экран"), т. е. заставку, появляющуюся при старте программы. Конечно, разговор об оформлении продукта больше подходит для гл. 5 "Пользовательский интерфейс", однако сплэш-скрин — характерный пример не только неправильного подхода к проектированию интерфейса программы, но и неправильного подхода к созданию всей программы в целом.
В больших продуктах вроде Microsoft Windows 2000 или Adobe Photoshop, запуск которых даже на мощных компьютерах длится заметное время, стартовая заставка имеет вполне практическую цель: развлекать пользователя во время запуска и показывать ход процесса загрузки приложения. Вместе с тем в больших программах сплэш-скрин не держится на экране ни на мгновение больше необходимого. Например, Microsoft Word 2000 грузится на моем новом компьютере за полторы секунды, и я даже не могу толком рассмотреть промелькнувшую на экране заставку. Однако многих авторов небольших по сравнению с "монстрами" shareware-программ такая ситуация, когда пользователь не успевает рассмотреть на заставке название программы, ее версию, имя автора и адрес сайта, не устраивает. И они специально замедляют загрузку программы, вставляя паузу в несколько секунд, и при этом не предоставляют никакой возможности отключить показ заставки!
Однако нужно обратить внимание на то, что заставка, висящая несколько секунд при старте программы, является мощнейшим источником раздражения пользователей. Не случайно одним из стандартных способов стимуляции пользователей регистрировать shareware-программы является показ при старте приложения экрана с напоминанием о необходимости регистрации, которое нельзя закрыть в течение нескольких секунд (так называемый nag screen). (См. гл. 6.)
Совершенно недопустимым, на мой взгляд, является принудительный показ стартовых заставок в программах, которые предназначены для их ежедневного запуска в начале работы компьютера — антивирусов, часов, утилит управления устройствами компьютера и т. п. Ежедневное созерцание появляющихся один за другим экранов с логотипами программ может вывести из себя кого угодно. Например, я отказался от использования прилагавшейся к моей новой материнской плате утилиты мониторинга ASUS Probe именно из-за надоедливого сплэш-скрина. То же я мог бы сказать и об антивирусе Antiviral Toolkit Pro, чью заставку с раскрытым зонтом я уже терпеть не могу, если бы без эффективной антивирусной защиты можно было обойтись. И зачем только разработчики обрекают легальных пользователей, купивших их программу, на такие страдания?
Вред сплэш-скринов, замедляющих запуск приложений, как глобального дефекта программы, а не просто неудачного элемента интерфейса, подчеркивает, например, Лу Гринзоу, авторитетный специалист в области разработки приложений. Он также обращает внимание на то, что каждая программа, показывающая пользователю стартовую заставку, обязательно должна иметь возможность ее отключения1.

Не трогайте системные файлы и настройки

Не трогайте системные файлы и настройки

В первую очередь нужно обратить внимание на недопустимость изменения системных файлов и пользовательских настроек без разрешения пользователя. Вам наверняка встречались программы, уже во время установки которых становится ясно: их авторы не допускают и мысли о том, что на компьютере пользователя будут работать какие-либо иные приложения. Поведение программ, считающих себя "пупом всей системы", очень разнообразно. Они изменяют файлы autoexec.bat и config.sys, заменяют системные DLL, позволяют устанавливать себя только в одну папку, причем часто — исключительно в корневой каталог диска С:, добавляют ярлыки в верхний уровень меню Пуск (а не в подменю Программы) и на Рабочий стол. Изменяют ассоциации файлов, делают стартовой страницей установленного в системе браузера домашнюю страницу разработчика программы, при каждом запуске добавляют себя в секцию автозагрузки и многое другое (Рисунок 4.2). При всем разнообразии поведения их объединяет одно: все это они проделывают, даже не спросив разрешения пользователя.

Относитесь к пользователю с уважением

Относитесь к пользователю с уважением

При работе с некоторыми программами никак не удается отделаться от ощущения, что их авторы делают тебе одолжение — слишком уж лаконичны и порой даже грубы сообщения, выдаваемые их программами. Характерный пример — сообщение, с которым у многих пользователей ассоциируется операционная система Microsoft Windows и которое стало объектом большого количества шуток и анекдотов: "Программа выполнила недопустимую операцию и будет закрыта. Если ошибка будет повторяться, обратитесь к разработчику".
У вашей программы гораздо больше шансов понравиться потенциальным покупателям и обойти своих конкурентов, если вы будете относиться к своим пользователям с уважением и элементарной вежливостью. Для этого нужно не так уж много:

делайте сообщения, выдаваемые вашей программой, более-менее информативными;

сопровождайте сообщения об ошибках словом "извините", показывая, что вам жаль, что ваша программа, даже если в данном случае и не по своей вине, вынуждена расстроить пользователя;

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

Многие российские разработчики shareware следуют этому -правилу буквально во всем. Например, даже если пользователь в окне регистрации программы вводит код, приобретенный ранее по украденному номеру кредитной карточки, то в ответ выводится вежливое сообщение о причинах того, почему программа не может быть зарегистрирована, и рассказывается о том, как приобрести программу легальным путем. Поддаться порыву обозвать пользователя вором и процитировать ему Уголовный кодекс было бы неразумно, т. к. пользователь, возможно, просто не знает, как нужно регистрировать программы и думает, что случайно попавшийся ему в Интернете ключ является вполне законным средством. Если вежливо объяснить ему, в чем дело — не исключено, что он оплатит регистрацию (в практике такие случаи не редкость), а в дальнейшем будет рекомендовать программу всем своим друзьям и знакомым. А вот если он будет оскорблен — еще одного пользователя можно будет считать потерянным.
Да, вежливость shareware-авторов чаще всего обусловлена не альтруизмом, а желанием заработать больше денег. Однако пользователей это не особенно волнует, и они охотно оплачивают регистрации программ, работа с которыми приносит удовольствие.

Поменьше эгоизма

Поменьше эгоизма

Многие shareware-программы напоминают мне некоторых моих преподавателей из университета, считавших, что их предмет — самый главный из всех дисциплин учебной программы и именно он станет ни много ни мало делом всей жизни каждого из их студентов. Подобно им, страдающие эгоизмом программы всем своим видом и поведением демонстрируют, что компьютер, операционная система, да и сам пользователь созданы только для того, чтобы удовлетворять их малейшие прихоти.
Естественно, пользовательская аудитория таких эгоистичных программ не отличается многочисленностью. Ведь на рынке существует большое количество программных продуктов, авторы которых руководствуются принципом "Пользователь всегда прав". Итак, какие правила нужно соблюдать для того, чтобы у пользователей остались наилучшие впечатления от работы с вашей программой?

Продуманная локализация

Продуманная локализация

Рано или поздно любой shareware-разработчик, размышляя о том, как увеличить аудиторию своей программы, решает перевести интерфейс продукта, кроме английского, и на другие иностранные языки. О том, как это может повлиять на успех shareware-проекта будет рассказано в гл. 10, а сейчас я хотел бы поговорить о технических аспектах реализации этой задачи.
Классический пример нерационально выполненной локализации - это операционная система Windows, версии которой для разных языков не только откомпилированы заново, но и имеют различия на уровне ядра. Куда проще было бы и для самой Microsoft, и для пользователей, по крайней мере, европейских и латиноамериканских стран, сделать одну международную версию на базе существующей паневропейской редакции. Включить в эту версию поддержку национальных раскладок клавиатуры и кодировок текста и приложить к ней файлы со списком всех текстовых строк на разных языках, которые можно было бы подключать во время загрузки системы. Это облегчило бы жизнь, кстати, и shareware-разработчиков, которым тогда не приходилось бы, например, оставлять в конференциях такие полные отчаяния сообщения:
"Люди, есть ли у кого-нибудь Windows 98 Second Edition 4.10.222.A с немецкой локализацией, причем именно с тремя двойками? Очень срочно нужно, наша программа у клиента глючит под ней, а у нас именно такой нет. Не дайте погибнуть сайт-лицензии! (дорогостоящая лицензия на большое число пользователей — С.Ж.)"
Конечно, реализовывать локализацию своей программы так, как это делает Microsoft, было бы неразумно. Можно убить огромное количество времени, компилируя версию для каждого языка, создавая для них отдельные инсталляторы и закачивая их на сервер провайдера. А уж о том, что бы зарегистрировать все национальные версии в интернет-каталогах программного обеспечения, не может быть и речи.
Конечно, shareware-разработчики подходят к локализации своих программ более рационально. Строки, используемые в программе — сообщения, меню, подписи к элементам управления, подсказки и пр., хранятся в отдельных файлах. Эти файлы обычно называются так же, как и язык, на котором выполнены хранимые в нем строки, а чтобы отличать их от других файлов данных, им присваивают какое-нибудь специальное расширение — например, Ing (от англ. Language — язык).
Немаловажный вопрос — какую структуру должны иметь языковые файлы. Некоторые программисты используют для хранения строк двоичные файлы, например, DLL. Однако в этом случае появление переводов интерфейса программ на иностранные языки только замедляется (а это как раз и не входит в интересы разработчика). Дело в том, что основную часть переводов будут делать пользователи этих же программ, являющиеся жителями соответствующих стран, например, в обмен на бесплатную регистрацию. А ведь далеко не каждый пользователь обладает соответствующей квалификацией и программными средствами, позволяющими самостоятельно отредактировать ресурсы, хранящиеся в двоичных файлах.
Конечно, ради перевода интерфейса известных и популярных программ, например WinZip, Teleport Pro, Opera, многие готовы как следует покопаться в ресурсах DLL. Например, в каталоге SoftList опубликовано довольно большое количество "патчей" для перевода интерфейса многих популярных программ на русский язык. Но, заметьте, в основном переводят именно известные программы, которые являются мировыми бестселлерами.
Скромные shareware-программы тоже становятся объектом самодеятельного творчества благодарных пользователей. Например, один российский разработчик рассказывал, что его программу китайцы самостоятельно перевели на китайский язык — сам он узнал об этом случайно, анализируя статистику посещений своего сайта. При этом пользователем из Китая была проделана серьезная хакерская работа, потому что исходный ЕХЕ-файл программы был специальным образом упакован, а ресурсы — зашифрованы. Но, что удивительно — все shareware-ограничения были оставлены, ссылки на страницу регистрации и сайт разработчика также не были изменены. Но такие "подвиги" пользователей относительно "середнячков" shareware-рынка — скорее исключение, чем правило.
Гораздо выгоднее хранить варианты перевода интерфейса в обычных текстовых файлах, имеющих формат INI-файлов. Такие файлы пользователи легко могут редактировать сами. Достаточно приложить к программе образец языкового файла с английскими строками — и любой, кто имеет навыки работы с текстовым редактором, может сделать на основе этого образца такой же файл для своего родного языка.
Замечание 2
Замечание 2


Учтите, что отдельный файл с переводом интерфейса на английский язык — это не более чем образец для новых переводов, непосредственно программа не должна этот файл использовать. Английский вариант интерфейса должен быть жестко "прошит" в программу — это обеспечит ее корректную работу в том случае, если какие-то строки в языковом файле (или даже сам этот файл) отсутствуют.
Существуют даже специальные ActiveX- и VCL-компоненты, предназначенные для реализации многоязычного интерфейса программы. Но, я думаю, что пользоваться ими особого смысла нет. Включение таких компонентов в проект лишь неоправданно увеличит его размер, ведь с технической точки зрения реализация интерфейса на разных языках — достаточно тривиальная задача. Стандартные функции, имеющиеся в современных системах программирования, а также их "основа" -- функции API Windows замечательно справляются с чтением секций и ключей INI-файлов, не доставляя разработчику никаких хлопот.
Для того чтобы сделать код, отвечающий за чтение строк с описанием интерфейса, более компактным и универсальным, строки для каждой формы хранятся в секции файла, название которой совпадает с именем формы.
Подписи к элементам управления, находящимся на этой форме, соответствует ключ, который называется так же, как и элемент управления (Рисунок 4.4). В результате при открытии формы запускается цикл, в котором опрашиваются все элементы управления, расположенные на форме, и соответствующие им текстовые строки считываются из языкового файла.

Программа WinZip поместила свои

Рисунок 4.2. Программа WinZip поместила свои ярлыки в верхний уровень меню Пуск без всякого разрешения пользователя


Обычно о том, что программа занимается самоуправством относительно системных ресурсов, в лучшем случае упоминается в readme-файле или одном из разделов справочной системы. Но такого упоминания, смахивающего на обычную "постановку перед фактом" недостаточно! Программа обязательно должна предупредить пользователя о том, что сейчас последует изменение ресурсов и настроек системы, и предоставить ему возможность запрета этих действий.
После того, как инсталлятор такой программы завершит свою работу и пользователь увидит, во что теперь превратилась его рабочая среда, недовольство этим автоматически перенесется и на саму программу. Возможно, пользователь запустит ее, чтобы мельком посмотреть на то, что же так исковеркало его систему, но долго такая программа на его компьютере не задержится.
Некоторые разработчики полагают, что иногда спрашивать разрешение пользователя на модификацию каких-либо системных настроек не требуется. Например, если программа хранит свои данные в файлах не с каким-либо распространенным расширением вроде txt или html, а с экзотическим, предположим, fgh или hjk, то можно безбоязненно зарегистрировать их в системе на собственную программу, не запрашивая разрешение пользователя. Однако программных продуктов на рынке очень много, и вполне может оказаться, что избранные разработчиком расширения fgh или hjk уже используются другой программой. Более того, пользователь предпочитает открывать эти файлы именно с ее помощью. Это один из примеров того, что программа и ее инсталлятор должны обязательно запрашивать разрешение пользователя на замену системных файлов, модификацию настроек операционной системы и рабочего окружения пользователя (Рисунок 4.3).

Размер имеет значение

Размер имеет значение

После прочтения разд. "Delphi, Basic или С" гл. 2, где я уделил повышенное внимание размеру исполняемых файлов, генерируемых компиляторами современных систем программирования, некоторые из читателей, возможно, решили, что я являюсь сторонником тотального минимализма и рекомендую оптимизировать каждый байт кода. Нет, это не так — затраты времени и сил на такую кропотливую работу могли окупиться разве что лет десять назад, когда ни один серьезный программист не мог обойтись без знания ассемблера, а 64 Кбайт (да, вы прочитали правильно, килобайтов, а не мегабайтов) оперативной памяти казались огромным пространством. Я считаю, что размер файла программы должен быть не минимальным, а адекватным ее возможностям, т. е. соответствовать набору функций, предоставляемых пользователю.
"Стоп!" - скажут опытные программисты. — Не имеет значения, каков размер файла программы, важно, каков размер данных, используемых программой!" Абсолютно верно. Программа, ЕХЕ-файл которой имеет объем, например, всего 300 Кбайт, будучи запущенной, займет в оперативной памяти в несколько раз больше места. Дополнительное пространство в памяти "отъедают" переменные и их массивы, используемые программой, но больше всего занятых ресурсов приходится на всевозможные DLL-библиотеки, ведь для реализации почти любой функциональной возможности у Windows заготовлена специальная DLL (табл. 4.1).
Все эти DLL совместно используются разными Windows-приложениями, и когда ваша программа запускается, чаще всего большинство нужных библиотек уже "сидят" в памяти. Именно поэтому стандартный Диспетчер задач в Windows NT и Windows 2000 показывает какие-то дикие цифры — по несколько мегабайтов занимаемой оперативной памяти на каждый запущенный процесс, в том числе и на крошечные вспомогательные утилиты.
Таблица 4.1. Назначение DLL-библиотек в Windows 2000

	Назначение библиотеки	Название файла	Объем файла, Кбайт
	Работа с системным реестром Windows	advapi32.dll	64
	Элементы управления Windows 9x	comctl32.dll	564
	Стандартные диалоги (Открыть файл, Печать т. п.)	comdlg32.dll	172
	Поддержка мультимедиа	devcon32.dll	352
	Графическая библиотека Windows	gdi32.dll	152
	Функции ядра Windows	kernel32.dll	460
	Поддержка MFC (для приложений на VC++)	mfc42.dll	972
	Сетевые функции	mpr.dll	56
	Менеджер аудиосжатия	msacm32.dll	100
	Поддержка WebCheck	msidle.dll	28
	Runtime-библиотека Visual C++	msvcrt.dll	260
	Сетевые функции	netapi32.dll	20
	Поддержка NT API	ntdll.dll	20
	Поддержка ActiveX	ole32.dll oleaut32.dll	772 582
	Поддержка RPC	rpcltc1.dll rpcrt4.dll	28 332
	Функции оболочки Windows	shell32.dll	1368
	Поддержка меню, окон и т. п.	user32.dll	68
	Поддержка мультимедиа	winmm.dll	64

Однако для shareware размер именно файла программы, а особенно ее дистрибутива, имеет очень большое значение.
В первую очередь это обусловлено, конечно же, тем, что основной средой для распространения программ является Интернет. Несмотря на то, что пропускная способность каналов связи постоянно растет, около половины пользователей испытывают трудности с загрузкой файлов объемом более чем 1 Мбайт. Да-да, примерно 50% пользователей прекращают процесс закачки больших файлов, не дождавшись его завершения (по мере того, как увеличивается размер файла, который требуется загрузить, процент неудачных закачек, естественно, растет). Виной тому, конечно, не зловредность пользователей, а то, что многие из них не применяют специальные программы для загрузки файлов типа ReGet, GetRight, GolZilla и пр., а предпочитают скачивать даже многомегабайтовые файлы, просто щелкая мышью по ссылкам в браузере. Вследствие этого имеет смысл поместить на странице загрузки файла программы рекомендацию все-таки использовать down-load-менеджеры для закачки (Рисунок 4.1).

Рекомендация применения downloadменеджеров

Рисунок 4.1. Рекомендация применения download-менеджеров в разделе "Download" сайта ActualSystem.com


Кроме того, значительная часть серверов, хранящих файлы программ, подключена к Интернету по медленным каналам (загрузка больших файлов предъявляет достаточно жесткие требования к пропускной ширине канала), что тоже вносит свою лепту в статистику неудачных загрузок.
Очень важно и то, что большой размер файла программы может сильно ударить по карману... самого автора программы. Видите ли, для того чтобы выйти на более-менее приличный уровень продаж, нужно добиться, чтобы вашу программу скачивало как можно больше людей — ведь, по статистике, регистрацию программного продукта оплачивают не более 1—2% из загрузивших его пользователей. Предположим, что вашу программу скачивают 100 человек в день, что позволяет надеяться на скромный уровень в 1—2 продажи в день, а объем ее дистрибутива составляет 2 Мбайт. В этом случае ежедневный исходящий трафик с вашего сайта составит 200 Мбайт, а месячный -- 6 Гбайт. В то же время, большинство хостинг-провайдеров включают в тарифы за 10—20$ в месяц ограничение месячного трафика на уровне 3—5 Гбайт. Поэтому вам придется переходить на более дорогостоящий тариф, что будет довольно разорительно в случае, если ваши прогнозы на количество регистрации не оправдаются, — например, большую часть из этих ста закачек могут приходиться на долю уже зарегистрированных пользователей, которые имеют право на бесплатное получение будущих версий программы.
Размер файла программы, а также ее дистрибутива, является очень важным параметром, по которому пользователи оценивают качество программы. Это в первую очередь относится к вспомогательным утилитам, которые в полном смысле должны являться "небольшими" — как по функциональным возможностям, так и по размеру файла. Непомерно "раздутые" программы вызывают только отрицательные эмоции, в том числе и откровенные насмешки и издевательства. Прочитайте, например, форменную "порку", которую устроили на сайте "BloatBusters" программе Solar Winds DNS Resolver no адресу radsoft.net/bloatbusters/sw_dns.htm. Скромная по набору функций утилита, которая всего лишь возвращает имя компьютера по его IP-адресу
(и наоборот), имеет дистрибутив объемом в 3,5 Мбайт(!). Авторы обзора тут же написали похожую программу, ZIP-архив которой занимает на диске компьютера... 9 Кбайт.
Для утилит важен еще и такой аспект. Многие из них предназначаются для постоянной работы на компьютере пользователя. Как правило, таких утилит (их называют резидентными) у каждого пользователя несколько. Это — антивирус, программы для управления звуковой картой и видеоадаптером, часы, утилита системного мониторинга, программа проверки почты и т. п. Естественно, неразумно выделять каждой из них даже по 2 Мбайт оперативной памяти — так никаких новейших модулей RAM не напасешься. Поэтому если утилита, которую решил попробовать пользователь, имеет ЕХЕ-файл размером в мегабайт или два, то это уже наводит на грустные мысли.
К сожалению, многие из авторов не осознают того, что пользователи сегодня, когда shareware-рынок перенасыщен программами, гораздо более разборчивы, чем хотя бы пару лет назад, когда хороших продуктов было не так много. Например, автор одной из программ для хранения паролей в анонсе своего продукта восторженно пишет (цитирую в переводе с английского): "Она такая маленькая, — 2,1 Мбайт, — что требуется всего 4 минуты на скорости 56 Кбайт, чтобы скачать ее!". Я не знаю, чего такого можно было написать в такой дистрибутив, если аналогичная утилита, написанная на Delphi, в архиве будет иметь объем, в десять раз меньший. Вероятно, всему виной (как и в случае с упомянутым выше 3,5-мегабайтовым DNS Resolver) громоздкие DLL-библиотеки и ActiveX-элементы.
На самом деле такую "маленькую" программу мало кто даже начнет скачивать, не говоря уже о ее тестировании и уж тем более покупке. Небольшой размер программы традиционно ассоциируется с высокой квалификацией ее автора и, как следствие, свидетельствует о хорошем качестве продукта. И если потенциальный пользователь программы зашел в соответствующий раздел интернет-архива программного обеспечения и видит несколько похожих по назначению программ, он, конечно же, сначала выберет более скромные по размеру продукты.
Могу привести еще один пример большого значения размера программы для пользователей. Одно время, в списках программ на SoftList.ru не указывались размеры их дистрибутивов — эта информация была только на страницах с подробными данными о конкретной программе (откуда можно было и скачать ее). Посетители каталога буквально завалили меня просьбами указывать размер файла программ и в списках — чтобы не тратить времени зря, переходя на страницы с подробной информацией о программе и тут же возвращаясь обратно, едва только увидев, сколько мегабайтов им предстоит скачать. То есть продукты, размер которых был слишком велик, пользователей уже не интересовали.
Как же можно уменьшить размер файлов программы? Это тема для специализированных справочников по программированию. Тем не менее, я хотел бы обратить внимание на очень распространенную ошибку shareware-разработчиков: использование слишком громоздких компонентов — как ActiveX, так и VCL. Постарайтесь не брать для своего проекта первый найденный в Интернете компонент, а поищите и попробуйте его альтернативы.
Например, компания TurboPower (http://www.turbopower.com) распространяет два очень похожих пакета компонентов для Delphi и C++ Builder -SysTools и Orpheus. Компоненты из пакета Orpheus используют один общий, довольно большой файл заголовков и описаний процедур и функций. Поэтому добавление одного-единственного компонента из этого пакета сразу увеличивает ЕХЕ-файл программы на 500 Кбайт. А вот библиотека SysTools организована более рационально, и добавление компонентов из этого пакета совсем немного увеличивает исполняемый файл проекта.
Но, как это ни странно, небольшой размер программы иногда может и отрицательно сказаться на ее продвижении. Например, один из российских разработчиков shareware, распространявший свой продукт по цене в 1000$, рассказывал, что фирма-регистратор, услугами которой он хотел воспользоваться для приема платежей, отнеслась к нему с большим подозрением — и все из-за того, что дистрибутив его программы был размером всего 650 Кбайт. Другой пример — сложные по своему назначению программы, такие как графические редакторы, инженерные пакеты, мультимедийные продукты: здесь пользователи больше доверяют объемным, в несколько мегабайтов, программам, т. к., по распространенному мнению (которое, впрочем, не лишено смысла), мощный пакет не может быть объемом всего в несколько сотен килобайтов. Именно поэтому я и говорю не о том, что программа обязательно должна быть как можно более компактной, а о том, что ее размер должен быть адекватным ее функциональным возможностям.

Учебник по созданию shareware программ

Альтернативное управление

Альтернативное управление

Ваша программа должна одинаково хорошо управляться как с помощью мыши, так и клавиатуры. Не должно быть функций, которые можно выполнить только мышью (за исключением традиционно "мышиных" операций -например, рисования в графических редакторах). Наиболее популярные функции следует снабдить "горячими клавишами" для их быстрого вызова. При выборе комбинаций клавиш не забывайте о привычках и навыках пользователей: остановитесь на тех комбинациях, которые обычно используются в программах такого рода. Например, если вы разрабатываете файловый менеджер в стиле Проводника Windows, то лучше создавать комбинации, традиционные для Windows-программ (табл. 5.1); если же вы ориентируетесь на Norton Commander, то, например, для функции обновления списка файлов присвойте "горячую клавишу" +, а не Windows. Но, наверное, в такой ситуации идеальный, но, естественно, не самый легкий вариант — предусмотреть для функций программы две "схемы" горячих клавиш, чтобы удовлетворить потребности приверженцев обоих стилей работы с файлами.
Таблица 5.1. Стандартные комбинации клавиш в Windows

	Операция	Комбинация клавиш
	Новое (окно, письмо, файл и т. п.)	+
	Открыть	+<0>
	Сохранить	+
	Печать	+
	Отменить	+
	Повторить	+
	Вырезать	+, +
	Копировать	+, +
	Вставить (из буфера обмена)	+, +
	Вставить (новый объект)
	Удалить
	Выделить все	+
	Найти	+
	Найти далее
	Заменить	+
	Обновить
	Справка

Бритва Оккама или KISS

Бритва Оккама или KISS

Философский принцип, носящий название "Бритва Оккама", гласит: "Не множить сущности без надобности". Или, как говорят американцы, KISS ("Keep It Simple, Stupid" •- "He усложняй, болван").
На языке интерфейсов это означает, что:

любая задача должна решаться минимальным числом действий;

логика этих действий должна быть очевидной для пользователя;

движения курсора и даже глаз пользователя должны быть оптимизированы.

Простым на первый взгляд требованиям из этого списка на самом деле не так уж легко следовать. Для проектирования сложного по своим функциям и простого для понимания интерфейса требуется немалые опыт, знания и особое чутье. Как пишет Лу Гринзоу: "Если и есть в мире что-то такое, что почти все программисты постоянно повторяют наизусть, как мантры, но при этом откровенно игнорируют, так это — принцип KISS".
Принцип KISS перекликается с несколькими из эвристических правил Якоба Нильсена - ''Эстетичный и минималистический дизайн", "Равенство между системой и реальным миром", "Понимание лучше, чем запоминание". KISS более универсален и применяется практически во всех сферах человеческой деятельности, в том числе и в области, очень близкой к теме книги—в программировании.

Даже самая простая программа должна иметь меню

Рисунок 5.20. Даже самая простая программа должна иметь меню


И, конечно же, не стоит забывать о контекстных меню — меню, появляющихся при щелчке правой кнопкой мыши на каком-либо объекте и содержащими команды для работы с этим объектом. Разработка таких меню -дело, хотя технически очень простое, но при этом довольно кропотливое. Тем не менее, затраты времени и сил обязательно окупятся. Операционная система Windows 95 и ее последующие версии приучили пользователей к мысли, что при щелчке правой кнопкой мыши появляется контекстное меню. Щелчок правой кнопкой мыши стал уже настолько естественным действием, что профамма, не "понимающая" его, напоминает человека, который не слышит, что ему говорят. Контекстное меню — одна из самых сильных привычек пользователей и навык, который имеют даже малоопытные новички. Нужно обязательно учитывать это при разработке интерфейсов собственных программ.
Некоторые авторы программ забывают о значении термина "контекстное меню". Такое меню должно содержать только те команды, которые относятся к объекту, которому принадлежит меню. Вызывать по щелчку правой кнопкой мыши, меню из пары десятков пунктов и уж тем более дубликат главного меню программы не имеет смысла: практическая ценность такого "контекстного" меню равна нулю.
Но и переоценивать значение контекстных меню не нужно. При всем их удобстве и эффективности это всего лишь дополнительный элемент интерфейса, а не его основа. При проектировании программы они должны создаваться в расчете на использование совместно с главным меню, но ни в коем случае не как его замена. Дело в том, что несмотря на большую популярность контекстных меню, есть люди, которые ими никогда не пользуются. Кроме того, в некоторых случаях контекстное меню не всегда удобно, по сравнению с главным меню, кнопочной панелью инструментов или клавиатурой. Таким образом, если контекстное меню — единственный способ управления программой, то это будет вызывать отрицательную реакцию пользователей: никому не нравится, когда его лишают привычных средств работы и навязывают что-то другое, не всегда удобное и полезное.

Другие принципы построения интерфейсов

Другие принципы построения интерфейсов

Конечно, помимо эвристических правил Якоба Нильсена, тех минимальных требований, которым должен удовлетворять интерфейс любой программы, существует довольно большое число принципов создания интерфейсов, о которых в своих трудах говорят специалисты, причем специалисты не только в области дизайна интерфейса. Ведь при проектировании интерфейсов применяются данные психологии, геометрии и других наук. Эти принципы, хотя и не обязательны при проектировании интерфейсов, но при их реализации программа будет выглядеть гораздо более выигрышно.

Флажки и переключатели

Флажки и переключатели

Флажки (Checkboxes) и переключатели (Option Buttons) используются для одной цели: для выбора из группы предложенных вариантов. Разница между ними, как вам, наверное, известно, состоит в том, что флажки используются для выбора одновременно нескольких вариантов из группы, а переключатели позволяют сделать выбор в пользу только одного варианта.
К сожалению, даже некоторые довольно авторитетные специалисты не придают большого значения этому различию между флажками и переключателями. В очередном номере Visual Basic Programmer's Journal 101 Tech Tips for VB Developers, вышедшем в августе 1999 года, был опубликован небольшой кусок кода, который модифицировал функциональность группы флажков, позволяя им работать, как переключатели: с их помощью можно было выбрать только один вариант из предложенных. "Такое изменение может быть полезно, если вы хотите использовать флажки вместо переключателей", -говорилось в публикации. Редактор сайта iarchitect.com с иронией предложил заменить вторую часть этой фразы на следующее: "...если вы хотите запутать ваших пользователей". Ведь само появление на экране группы флажков сразу говорит пользователю о том, что сейчас ему можно будет сделать выбор нескольких вариантов, а не одного-единственного. Поэтому ни в коем случае не применяйте флажки для организации выбора одного варианта из группы.

Гибкость и эффективность использования

Гибкость и эффективность использования

Правило вполне закономерное, ведь программа в первую очередь должна решать задачу (см. разд. "Основы построения интерфейсов" данной главы), над которой работает пользователь. Однако при проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Но нужно учитывать, это во многом разные потребители, с разными требованиями к программе и разным стилем работы. Если сделать простой интерфейс с минимумом опций, который будет легок для освоения новичками, то более опытные пользователи не смогут работать с программой достаточно эффективно, чтобы удовлетворять свои потребности.
Для решения этой проблемы прибегают к простому приему: функции, которые ускоряют работу, оформлены так, что они не видны начинающим, но легко доступны продвинутым пользователям. Самый простой пример — это "горячие клавиши", с помощью которых можно быстро вызвать часто выполняющиеся функции программы, в частности открытие и сохранение файлов. Обозначения "горячих клавиш" пишутся рядом с соответствующими пунктами меню, поэтому они, с одной стороны, не мешают новичкам (они могут воспользоваться мышью для выбора пункта меню или щелчка по кнопке на панели инструментов), а, с другой стороны, легко доступны опытным пользователям.
Разработчики системы программирования Microsoft Quick Basic, которая была очень популярна еще в восьмидесятых и начале девяностых годов, пошли еще дальше: они предусмотрели два варианта главного меню приложения: полный и сокращенный, между которыми можно переключаться одним щелчком.
Другой пример реализации универсального "интерфейса для каждого" — возможность выполнить сложные функции программы как с помощью Мастера, который, словно за руку, проведет начинающего пользователя по всем этапам процесса, так и вручную, посредством настройки опций в соответствующем диалоговом окне.

Информированность пользователя

Информированность пользователя

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

Интерфейс имитирующий лицевую

Рисунок 5.7. Интерфейс, имитирующий лицевую панель проигрывателя компакт-дисков


Самый распространенный пример реализации этого принципа — построение интерфейсов, имитирующих объекты реального мира. Часы, калькуляторы, проигрыватели компакт-дисков, записные книжки — большинство из программ, осуществляющих эти функции, выглядят почти точно так же, как их материальные аналоги. А знаменитая Мусорная корзина на Рабочем столе Windows или Macintosh, в которую можно "бросить" ненужный файл или папку — почти хрестоматийный пример построения интерфейса на основе объектов реального мира. Да и сам способ "перетащи и брось" (Drag-and-Drop) — прекрасная иллюстрация этого принципа, абсолютно естественная операция даже для тех пользователей, кто впервые сел за компьютер.
Однако такое заимствование идей из окружающего мира нужно производить очень осторожно. Дело в том, что программы, которые уже знакомы пользователю — тоже часть его мира, часть его знаний, навыков и привычек. Поэтому некоторые детали компьютерных интерфейсов являются для пользователей более привычными, чем объекты реального мира — это особенно касается элементов интерфейса, реализующих функции, не имеющих прямых аналогов в реальном мире. В качестве примера можно привести известный мультимедийный проигрыватель WinAmp. Для управления воспроизведением музыкальных композиций программа использует кнопки Play, Stop, Pause и др., очень напоминающие аналогичные по назначению кнопки на проигрывателях, стоящих в наших квартирах. Но вот кнопка, расположенная справа от них, которая на "настоящем" аппарате открывает лоток CD-плейера, в WinAmp, вопреки ожиданиям, не открывает лоток CD-ROM-дисковода, а вызывает окно Открыть файл. Это несколько сбивает с толку, т. к. в очень многих аналогичных компьютерных программах такая кнопка как раз служит для открытия/закрытия лотка дисковода CD-ROM.
Поэтому интерфейсы, которые полностью, т. е. без всяких исключений, копируют объекты реального мира, почти всегда в результате получаются не очень удобными, т. к. пользователь тратит довольно много времени, пытаясь освоить абсолютно новый интерфейс. Например, эксперимент компании IBM в области интерфейсов, использующих в качестве своей основы модели реальных материальных объектов — программа Real Phone, считается полным провалом: число проблем, возникающих при освоении "реального телефона", очень велико.

Эстетичный и минималистический дизайн

Эстетичный и минималистический дизайн

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

Эвристические правила Якоба Нильсена

Эвристические правила Якоба Нильсена

Три основных принципа проектирования интерфейсов компьютерных программ, о которых я рассказал в предыдущем разделе, являются, безусловно, чрезвычайно полезными и эффективными, все же они представляют собой довольно общие правила. Далеко не каждый, а уж тем более начинающий разработчик интерфейсов, сможет качественно выполнить свою задачу, руководствуясь только ими. Требуются более конкретизированные правила, которые давали бы развернутую картину стратегии построения интерфейсов.
Одними из самых цитируемых в книгах по HCI являются десять так называемых эвристических правил известнейшего американского специалиста в области проектирования интерфейсов Якоба Нильсена (Jakob Nielsen), разработанных им совместно с другим исследователем, Рольфом Моличем (Rolf Molich). Формулировку этих принципов в оригинале можно прочитать по адресу http://www.useit.com/papers/heuristic/heuristic_list.html. Это десять главных заповедей любого разработчика компьютерных интерфейсов, т. е. минимальные критерии, которым должен отвечать интерфейс любой программы.

Каталог скинов на сайте www winamp com

Рисунок 5.24. Каталог скинов на сайте www.winamp.com


Таким образом, сделав свой продукт совместимым со "шкурам" WinAmp, вы одним выстрелом убиваете не двух, а трех зайцев, получая:

десятки тысяч готовых скинов, доступных пользователям;

огромную потенциальную аудиторию, значительная часть которой вполне может из потенциальной стать реальной: многие пользователи захотят заполучить, например, калькулятор или записную книжку, которые выглядят так же, как и их любимый WinAmp;

возможность эффективно рекламировать свою программу: наличие в описании программы слов "поддержка скинов WinAmp" дает неплохой отклик со стороны пользователей на поисковых системах и в online-архивах программного обеспечения.

Если вы захотите встроить в свою программу поддержку скинов, то сначала хорошенько подумайте: а действительно ли "шкуры" так необходимы вашему продукту?
Традиционно поддержка скинов встраивалась в программы, которые либо имитируют предмет, который существует в реальном мире (плейер, калькулятор, часы и т. п.), либо ориентируются на сферу развлечений, либо оба варианта сразу. Поэтому способность менять свой вид при помощи "шкур" для таких программ стала уже привычной и почти обязательной функцией. Однако авторы, разрабатывающие программы, которые не попадают в указанные тематические группы (например, системные утилиты), впечатлив-шись успехом скинов, также встраивают в свои продукты их поддержку, ожидая, что это благоприятно скажется на популярности программы.
Шаг, на мой взгляд, спорный. Пользователей системных утилит или, скажем, бизнес-программ не очень-то привлекают всякие украшательства, скорее, наоборот. Ведь скины, как уже говорилось в предыдущем абзаце, ассоциируются с развлекательными программами, и упоминание "шкур" может серьезно повредить имиджу программы. Кроме того, поддержка скинов часто реализуется программистами с помощью громоздких ActiveX-компонентов, что неоправданно увеличивает размер программы. Для некоторых программ, например системных утилит, главное требование к которым — компактность, это может оказаться слишком большой жертвой, принесенной ради красоты.
Но, уж если вы все-таки встроили в свою программу поддержку скинов, позаботьтесь о том, чтобы пользователь мог ее отключить, вернувшись к традиционному виду. Стандартное оформление Windows-приложений - это тоже своеобразный скин, и у него есть немало приверженцев.

Кирпичики интерфейса

Кирпичики интерфейса

Итак, вы познакомились с теорией проектирования интерфейсов и практическими рекомендациями по выбору типа интерфейса и приданию ему профессионального вида. Настало время поговорить о самых мелких частицах интерфейса, из которых, как дом из кирпичей, строится внешний вид программного продукта, — элементах управления (компонентах).
В графическом пользовательском интерфейсе элемент управления -- это средство, при помощи которого пользователь взаимодействует с компьютерной программой. Качество этого взаимодействия зависит от двух аспектов:

соответствия элемента управления выполняемой им задаче;

от последовательности правил, по которым функционирует элемент управления.

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

Командные кнопки

Командные кнопки

Наиболее частая ошибка начинающих разработчиков интерфейсов — использование в проекте нестандартных кнопок, включающих, помимо текста, также и графику. Во-первых, из-за обычно невысокого качества графики выглядят такие кнопки очень непрофессионально; во-вторых, почти всегда у автора программы не хватает рисунков на все кнопки, имеющиеся в программе, и часть кнопок приходится делать обычными, с текстовыми подписями и без рисунков. Нарушается принцип последовательности, что, сами понимаете, не добавляет интерфейсу привлекательности.
Пожалуй, единственная категория программ, в интерфейс которых можно включать кнопки с графикой, — это игры. Здесь такие кнопки могут оживить стандартный интерфейс Windows-программ, придать ему более праздничный и нарядный вид.
Командная кнопка — один из тех элементов управления, для которых наиболее часто применяется динамически изменяемое свойство disable, т. е. отключение кнопки, когда она перестает реагировать на нажатия, и ее включение, в зависимости от текущего состояния программы. Для индикации состояния отключения граница вокруг кнопки и буквы текста на ней становятся светло-серыми.
Динамическое отключение и включение кнопки выглядит очень эффектно и производит впечатление высокого искусственного интеллекта программы (в большинстве случаев так и есть). Например, в диалоговых окнах кнопка ОК остается недоступной до тех пор, пока пользователь не введет необходимые данные, т. е. при каждом изменении информации происходит ее проверка. И вот здесь нужно быть очень осторожным. Дело в том, что пользователь при вводе сложных данных может не иметь информации о том, что именно он делает неправильно. "Серая" отключенная кнопка только говорит ему о том, что он что-то сделал не так, как нужно — например, ввел неверные или неполные данные, но вот в чем конкретно состоит проблема... И никто не может подсказать пользователю, что необходимо сделать, чтобы заветная кнопка наконец стала реагировать на нажатия мышью. Было бы гораздо лучше, если бы кнопка ОК была доступной, а после ее нажатия выдавалось бы сообщение об ошибке.
Лично мне приходилось не раз сталкиваться с описанной выше проблемой. Однажды я даже не смог зарегистрировать законно приобретенную копию shareware-программы: кнопка Зарегистрировать все время оставалась отключенной, несмотря на ввод в текстовое окно регистрационного кода. И информацию о том, что именно я делаю неправильно, я смог получить, только написав письмо автору программы... Поэтому при проектировании интерфейса собственной программы, Actual Startup, я решил не поддаваться соблазну сделать диалоговые окна слишком "умными". Кнопка ОК в окне создания нового "сервиса" становится доступной даже при вводе неправильных данных, зато после ее нажатия появляется окно с сообщением об ошибке и информацией о том, как ее исправить.

Кошелек Миллера

Кошелек Миллера

Этот принцип назван так в честь ученого-психолога Г. А. Миллера, который исследовал кратковременную память, проверяя выводы, сделанные ранее его коллегой, Г. Эббингаузом. Эббингауз пытался выяснить, сколько информации может запомнить человек без каких-либо специальных мнемонических приемов. Оказалось, что емкость памяти ограничена семью цифрами, семью буквами или названиями семи предметов. Это "магическое число" семь, служащее своего рода меркой памяти, и было проверено Миллером, который показал, что память действительно в среднем не может хранить более семи элементов; в зависимости от сложности элементов это число может колебаться в пределах от пяти до девяти.
Если необходимо в течение короткого времени сохранить информацию, включающую больше семи элементов, мозг почти бессознательно группирует эту информацию таким образом, чтобы число запоминаемых элементов не превышало предельно допустимого. Например, номер банковского счета 30 637 402 710, состоящий из одиннадцати элементов, будет, скорее всего, запоминаться как 30 63 740 27 10, т. е. как пять числовых элементов, или восемь слов (тридцать, шестьдесят, три, семьсот, сорок, двадцать, семь, десять).
Применяя принцип кошелька Миллера в дизайне интерфейсов, следует группировать элементы в программе (кнопки на панелях инструментов, пункты меню, закладки, опции на этих закладках и т. п.) с учетом этого правила— т. е. не более семи в группе, в крайнем случае — девяти. Взгляните, например, на главное окно программы-словаря ABBYY Lingvo 6.0: четырнадцать кнопок на верхней панели, между которыми нет ни одного разделителя, воспринимаются гораздо хуже, чем кнопки на панели внизу, которые разделены на группы.
Итак, принцип кошелька Миллера говорит о семи плюс-минус двух элементах. Но если взглянуть на программы, интерфейс которых совершенствовался годами (тот же Microsoft Word), то можно заметить, что число объектов (пунктов меню, кнопок на панелях инструментов) в группах доходит до шести-семи довольно редко, а в основном элементы сгруппированы по три-четыре объекта. Такие небольшие группы объектов наиболее хорошо воспринимаются взглядом пользователя, уже слегка утомленного сложными интерфейсами современных программ. Я думаю, при проектировании интерфейсов программ верхнюю границу кошелька Миллера — семь-девять элементов — нужно применять очень осторожно, стараясь обходиться группами, содержащими максимум пять объектов.

Масштабирование шрифтов

Масштабирование шрифтов

Нужно учитывать, что на разных компьютерах установлены различные по масштабу шрифты: одни пользователи предпочитают крупный шрифт, другие — более мелкий. Из-за этого текстовые подписи (на кнопках, панелях и т. п.), которые автор поместил в своей программе, при запуске продукта пользователями могут увеличиваться в размерах. Многие элементы управления автоматически подстраивают свои размеры согласно содержимому, но некоторые, например Строка состояния (StatusBar), таким свойством не обладают, и текст в этом случае может обрезаться.

Меню Файл с командами вызова недавно открывавшихся файлов

Рисунок 5.11. Меню Файл с командами вызова недавно открывавшихся файлов


Еще одна составляющая часть правила "Гибкость и эффективность использования" — необходимость предоставлять пользователю возможность быстрого выполнения частых действий. Варианты реализации этого очень разнообразны: это и уже упоминавшиеся "горячие клавиши", и команды для вызова последних открывавшихся файлов, и меню, в которых сначала показываются наиболее часто выполняющиеся команды, и макросы, и даже целые языки программирования, встраиваемые в приложения, наподобие Visual Basic for Applications в продуктах семейства Microsoft Office.

Меню грамотно спроектированной

Рисунок 5.19. Меню грамотно спроектированной программы чрезвычайно информативно


Замечание 3
Замечание 3


Если главное окно программы выполнено в виде диалога, т. е. окна, имеющего фиксированную границу, то в таком окне строка меню не обязательна. Однако некоторые авторы, высоко оценивая эргономику меню, включают его и в диалоговые окна.
Теперь — о том, что же можно помещать в меню. Некоторые авторы считают, что для простых программ меню вовсе не нужно, т. к. не стоит делать меню ради двух-трех пунктов. Но даже программа, которая ничего не делает, достойна меню как минимум из двух пунктов: Файл, где находится команда Выход и Справка, включающий подпункт О программе (ведь потенциальные пользователи должны знать, куда отправлять свои денежки, правда?).
Пункт Файл, даже если программа непосредственно с файлами не работает, очень желателен, я бы сказал — необходим. Просто Файл — настолько привычный элемент меню, что все основные команды (начать новую работу, сохранить результаты, выйти из программы) пользователи ищут прежде всего там. Пункт Справка я рекомендую включать в любое меню по двум причинам: во-первых, пользователь сразу видит, что в программе есть справочная система и есть куда обратиться в случае возникновения затруднений; во-вторых, если в строке меню содержится только один пункт -Файл, то это выглядит не очень красиво. Добавление еще одного пункта уравновешивает картину.

Меню

Меню

Список команд по работе с программой, предлагаемых на выбор пользователя — одно из самых старых и универсальных средств организации интерфейса компьютерных программ.
В самых первых программах, предназначенных для работы на персональных компьютерах, меню представляло собой список операций, и для выбора какой-либо из них требовалось нажать на клавиатуре клавишу с цифрой, обозначающей порядковый номер соответствующей команды в меню. В программных продуктах для IBM PC середины 80-х годов, большинство из которых работало в текстовом режиме экрана (тот же Norton Commander), меню уже имело сложную структуру: команды были разбиты на группы, названия которых выводились в строке вверху экрана; по ниспадающим спискам команд можно было перемещаться нажатием клавиш со стрелками, а выбор делать при помощи клавиши . Во многих программах к управлению подключилась мышь.
С расцветом Windows и ростом популярности графического интерфейса меню заняло основное место среди средств управления компьютерными программами. Законодатель мод в области интерфейсов Windows-приложений — корпорация Microsoft — постоянно улучшала внешний вид и эргономику меню. В Windows 95 в меню были добавлены графические пиктограммы и возможность перемещения курсора мышью, а не только клавиатурой, как в Windows 3.1; в Windows 2000 появились "умные" меню, в которых первыми показывались наиболее часто вызываемые пользователем команды.
Но, тем не менее, всех этих заслуг меню в деле построения интерфейсов не производят на некоторых авторов программ никакого впечатления, и они -о ужас! — начинают считать, что без меню в программе вполне можно обойтись. Я как-то спросил одного из shareware-авторов, в главном окне программы которого присутствовала только кнопочная панель инструментов, а меню не было. "Да ну его... Я не знаю, чего туда помещать" - услышал я в ответ.
Вопрос "Что помещать в меню?" я рассмотрю чуть позже, а пока хотел бы обратить внимание на обязательность присутствия меню в главном окне программы. Это, если угодно, такое же правило хорошего тона, как и любое из эвристик Якоба Нильсена, о которых рассказывалось выше. Отказываясь от включения меню в проект своей программы, автор игнорирует опыт и навыки пользователей, заставляет их отказываться от стиля работы, к которому они привыкли. Особенно меня забавляет, когда авторы не делают в программе меню, но создают кнопочную панель инструментов: последняя появилась в интерфейсе программ для персональных компьютеров относительно недавно и, конечно, не может быть полноценной заменой меню. Хотя бы потому, что меню — это не просто список команд, это еще и многофункциональная "шпаргалка" по работе с программой, "шпаргалка", которая всегда под рукой (как известно, читать справочные файлы пользователи не очень любят). Достаточно провести мышью по строке меню вверху экрана, и можно выяснить набор функций программы, комбинации "горячих клавиш" и даже — объяснение назначения кнопок на панели инструментов.

Microsoft Access запрашивает подтверждение

Рисунок 5.2. Microsoft Access запрашивает подтверждение действия, которое не будет иметь никакого значения


А этот пример особенно часто приводится в качестве иллюстрации к рассказу о "тупых" интерфейсах. Утилита преобразования текстовых файлов, включенная в Microsoft Word, способна распознать формат открываемого файла. Но, тем не менее, она просит пользователя подтвердить, что структура файла была определена правильно. Во многих случаях (например, когда человек открывает файл, созданный не им, или просто при недостатке знаний) он не может указать, каков формат файла на самом деле. Но, т. к. его все-таки просят сделать выбор, он начинает колебаться, выбирать из списка другие форматы, что приводит к некорректным результатам.

Microsoft Word не слишком уверен

Рисунок 5.3. Microsoft Word не слишком уверен в собственных возможностях по преобразованию файлов


Еще один известный пример интерфейса, который дает повод поразиться "глупости" компьютера. Если в текстовом редакторе WordPad открыть обыкновенный текстовый файл и, даже ничего в нем не меняя, попробовать сохранить его, то программа сообщит, что такая операция "приведет к потере форматирования". Особую пикантность этой ситуации придает тот факт, что в текстовом (ASCII) файле какое-либо форматирование отсутствует изначально.
Есть и откровенно дурацкие сообщения, которые заставляют задуматься, почему современный мощный компьютер стоимостью несколько сотен долларов обладает интеллектом простого калькулятора. Впрочем, очень часто такие сообщения вызваны ошибками в самой программе.
Нужно заметить, что, как и в любой другой науке, принципы построения интерфейсов компьютерных программ тесно взаимосвязаны. Нарушение одного правила почти наверняка повлечет нарушение и другого. Например, если при работе пользователя с программой на экране появилось сообщение заставляющее усомниться в том, что компьютер может справиться со своими функциями (третий принцип), то о соблюдении первого принципа (прозрачность интерфейса) говорить тоже не приходится, т. к. вместо того, чтобы продолжить работу, человек вынужден теряться в догадках: "Что бы это значило?"

Небольшая палитра инструментов

Небольшая палитра инструментов

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

Одинаковое расстояние между элементами управления

Одинаковое расстояние между элементами управления

Если элементы управления на форме приложения располагаются на разном расстоянии между ними, то это сразу придает интерфейсу непрофессиональный вид. Наоборот, аккуратно выстроенные на форме кнопки, переключатели, флажки и другие элементы -- признак качественной работы.

Однаединственная форма "нетрадиционной

Рисунок 5.10. Одна-единственная форма "нетрадиционной ориентации" придает всему интерфейсу крайне непрофессиональный вид


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

Описание ошибки

Описание ошибки

Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки. Многие разработчики программ опасаются делать сообщения об ошибках очень информативными, чтобы не "пугать" начинающих пользователей техническими подробностями. Однако в этом случае нарушается описанный выше принцип гибкости и эффективности использования: опытные пользователи, получив слишком краткое сообщение об ошибке, не могут выяснить ее причину. А программа, в которой появляются какие-то непонятные ошибки, в конце концов начинает производить впечатление некачественной поделки.
Самое простое решение — создать в справочной системе программы соответствующий раздел, разъясняющий содержание проблемы и причины ее возникновения. В самом же диалоговом окне с сообщением об ошибке может присутствовать кнопка Справка для вызова этого раздела. Чисто технически реализовать это очень просто: в современных системах программирования для ее создания таких дружественных сообщений об ошибках достаточно при вызове функции MessageBox указать флаг наличия кнопки Справка и идентификатор соответствующего раздела справки. А вот составление подробных описаний ошибок, которых, к тому же, может быть очень много, для shareware-программистов гораздо более нудное и неприятное занятие.
Еще один пример решения, причем более изящного, данной проблемы является кнопка Подробнее, при нажатии на которую диалоговое окно с сообщением об ошибке "распахивается", отображая более подробную информацию о причине возникновения сбоя. Так, например, организованы многие сообщения об ошибках в 32-разрядных версиях Windows, самое известное из которых - "Программа выполнила недопустимую операцию и будет закрыта". За кнопкой Подробнее в этом сообщении скрывается имя программы-виновника, а также адрес места возникновения ошибки.
Замечание 1
Замечание 1


Обратите внимание, что даже в "распахивающихся" сообщениях об ошибках, несмотря на то, что в них присутствует подробная информация, все равно должна присутствовать кнопка Справка для вызова раздела справочной системы с описанием соответствующей ошибки. Это необходимо потому, что обращение к справочной системе программы является более привычным для пользователя, чем менее распространенные "распахивающиеся" диалоговые окна.
К сожалению, такие изящные сообщения об ошибках в прикладных программах для Windows встречаются не очень часто, т. к. их включение требует хотя и несложной, но кропотливой работы.
Очень важно помнить то, что сообщение об ошибке должно содержать ее описание нормальным человеческим языком. Некоторые программисты совершенно серьезно считают, что такие лаконичные сообщения, в стиле известного в Интернете "Error 216", производят на пользователя неизгладимое впечатление: чем "загадочнее" программа, тем она сложнее и, в конечном итоге, "круче". Но, на самом деле, эффект сродни тому, что был уже описан выше: непонятные ошибки возникают только в некачественных поделках.

Описание решения проблемы

Описание решения проблемы

Как уже упоминалось выше, информация о том, как исправить ошибку или решить проблему имеет даже большее значение, чем собственно описание ошибки или проблемы. Ведь подсказка, помогающая решить проблему, способствует реализации одного из принципов построения пользовательского интерфейса — программа должна помогать выполнить задачу, а не становиться этой задачей.
Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. Дело в том, что не все пользователи догадываются нажать спасительную кнопку Справка, хотя это было бы вполне естественным ходом (как известно, в английских версиях Windows в этих случаях используется слово "Help" - "Помощь").
При описании пути решения проблемы, как и при написании любой документации, нужно избегать составления слишком объемных текстов, т. к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Лучше всего составить что-то наподобие пошаговой инструкции, каждый шаг из которой составляет 1—2 предложения.

Основы построения интерфейсов

Основы построения интерфейсов

Когда говорят о научных основах проектирования пользовательских интерфейсов, в первую очередь упоминают термин HCI. HCI — это аббревиатура английского Human-Computer Interaction, что переводится как "взаимодействие человека и компьютера". На Западе HCI — это целая профессия, ей обучают в университетах, выдавая дипломы "Специалист по HCI". Издается много журналов по этой теме, существует большое количество Web-сайтов. В России, к сожалению, эта наука не пользуется особой популярностью, например, у нас настоящих специалистов по HCI можно буквально пересчитать по пальцам одной руки.
Как легко догадаться по названию, составными частями HCI являются: человек (пользователь), компьютер и собственно их взаимодействие. Пользовательский интерфейс (англ, user interface, UI) является своеобразным коммуникационным каналом, по которому осуществляется взаимодействие пользователя и компьютера.
Лучший пользовательский интерфейс -- это такой интерфейс, которому пользователь не должен уделять много внимания, почти не замечать его. Пользователь просто работает, вместо того, чтобы размышлять, какую кнопку нажать или где щелкнуть мышью. Такой интерфейс называют прозрачным — пользователь как бы смотрит сквозь него на свою работу.
Чтобы создать эффективный интерфейс, который делал бы работу с программой приятной, нужно понимать, какие задачи будут решать пользователи с помощью данной программы и какие требования к интерфейсу могут возникнуть у пользователей. Это сделать гораздо легче, если вы используете свою программу для собственных нужд (см. разд. "Выбор названия программы" гл. 2), ведь в данном случае вы являетесь не только разработчиком, но и пользователем программы, смотрите на нее глазами ее аудитории.
Огромную роль играет интуиция — если разработчик сам терпеть не может некрасивые и неудобные интерфейсы, то при создании собственной программы он будет чувствовать, где и какой именно элемент нужно убрать или добавить. Необходимо иметь художественный вкус, чтобы понимать, что именно придает интерфейсу красоту и привлекательность.
Западные исследователи в области HCI сформулировали основные принципы проектирования пользовательских интерфейсов компьютерных программ. Как и в любой другой науке, существует довольно много различных методик и классификаций, которые можно найти в книгах по HCI, выпущенных за рубежом, а также на иностранных Web-сайтах.
Если говорить о самых общих принципах проектирования пользовательских интерфейсов, то можно назвать три основных положения:

Программа должна помогать выполнить задачу, а не становиться этой задачей.

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

Программа должна работать так, чтобы пользователь не считал компьютер дураком.

Довольно эмоциональные формулировки, но, тем не менее, поразительно верные.
Первый принцип — это уже упоминавшаяся выше прозрачность интерфейса. Интерфейс должен быть легким для освоения и не создавать перед пользователем преграду, которую он должен будет преодолеть, чтобы приступить к работе. Вспомните надоедливый splash screen ("всплывающий экран"), о котором я уже рассказывал (см. разд. "Не делайте из программы культа" гл. 4) -это тоже пример интерфейса, который, вместо того чтобы помогать пользователю выполнить работу, эту работу только и создает.
Второй принцип часто нарушают те авторы программ, которые слишком недооценивают умственные способности пользователей. В глазах таких разработчиков пользователи видятся толпой этаких бестолковых болванов, в лучшем случае — беспомощных и нерадивых созданий, не способных разобраться в самых элементарных ситуациях. Это обусловлено разными причинами
Во-первых, традиционным слегка высокомерным отношением программистов к простым пользователям. Это еще можно было понять в восьмидесятых и начале девяностых годов XX века, когда обычные персональные компьютеры не имели доступных широкой аудитории программных и аппаратных средств для построения привлекательных графических интерфейсов и работы с ними. Самой распространенной операционной системой в то время была MS DOS, основанная на интерфейсе командной строки. Поэтому эффективно работать с персональным компьютером могли люди только с довольно серьезной подготовкой. Кроме того, парк "персоналок" был относительно невелик даже в США, не говоря уже об остальных странах, и, как следствие, число пользователей компьютеров было небольшим.
Сегодня же такой пренебрежительный взгляд на пользователя явно неуместен. Работа с персональным компьютером предполагает относительно небольшую начальную подготовку пользователя: интерфейсы компьютерных программ, в первую очередь операционной системы Windows, являющейся законодателем мод в индустрии массового программного обеспечения, становятся все проще и доступнее для понимания людей. Да и число компьютеров в мире сегодня в несколько раз больше, чем десять лет назад.
Вторая причина слишком большой недоверчивости программистов к познаниям и квалификации пользователей — чрезмерное увлечение построением так называемой "защиты от дурака". Дело в том, что классические учебные курсы по программированию учат, что большинство ошибок в работе программы вызываются не дефектами исходного кода или программного окружения, а действиями пользователя — например, вводом данных неправильного формата (допустим, текста вместо цифр). Поэтому программист при разработке приложения должен написать функции по проверке результатов как можно большего числа действий пользователя и предусмотреть максимальное количество вариантов развития событий. Это совершенно правильный подход, но многие программисты настолько усложняют "защиту от дурака", делают ее такой громоздкой, что работа пользователя с программой начинает напоминать известное "шаг вправо, шаг влево считается побегом". Происходит довольно обычная вещь: то, что задумывалось как решение проблемы, само начинает создавать проблемы.
И, наконец, третья причина во многом обусловлена поведением самих пользователей. Часто при возникновении малейших затруднений при работе с программой пользователь тут же обращается в службу технической поддержки, не удосужившись даже взглянуть на справочную систему продукта, посмотреть секцию "Ответы на частые вопросы" на Web-сайте программы или даже просто чуть-чуть подумать! Отчасти тут вина самих авторов программ. Как говорят опытные разработчики пользовательских интерфейсов: "Если уже на этапе знакомства с программой пользователь вынужден обращаться к справочной системе, над интерфейсом нужно серьезно работать".
Поэтому, чтобы соблюсти второй из общих принципов построения интерфейсов и не давать пользователю повода почувствовать, будто его принимают за идиота, не нужно давать разрабатываемой программе слишком большие полномочия и право указывать пользователю, что именно ему делать. Некоторые программисты не знают или не желают осознавать этого и загоняют пользователей своих программных продуктов в тесные рамки, навязывая определенный стиль работы.
Один из примеров такого неправильного отношения к пользователю является отказ программы выполнить вполне естественную с точки зрения пользователя программных продуктов такого рода операцию и вывод диалогового окна, требующего выполнить какую-то другую последовательность действий. Этим "прославился", например, известный текстовый редактор "Блокнот" из состава Windows 95. Если пользователь открывал эту программу и решал перед началом набора текста дать создаваемому "Блокнотом" по умолчанию файлу "Untitled" какое-нибудь имя, выбрав из меню команду Сохранить как, редактор отказывался сделать это, показывая сообщение: "Вы не ввели какой-либо текст, чтобы его можно было сохранить. Наберите какой-нибудь текст, а затем попытайтесь [сохранить его] снова". Этим создатели "Блокнота" не только отвергли стиль работы очень многих пользователей (перед началом набора текста дать имя файла), но сбили с толку и тех, кто был знаком с "Блокнотом" по предыдущим версиям Windows. Например, в шестнадцатиразрядной Windows 3.1 "Блокнот" позволял сохранять пустые файлы безо всяких проблем. Опытные пользователи, знакомые с принципами работы операционной системы, тоже были в недоумении: если из контекстного меню Проводника Windows в меню Создать выбрать пункт Текстовый документ, то получившийся файл длиной 0 байт открывается "Блокнотом" без каких-либо затруднений. К счастью, в последующих версиях Windows "Блокнот" стал более дружественен к пользователю.
Другой пример недооценки возможностей пользователя — вывод информационных сообщений в ситуациях, когда этого не требуется. Многие авторы наделяют свои программы излишней "болтливостью" из благих намерений — например, для того, чтобы облегчить освоение продукта или информировать пользователей о полезных функциях программы. Однако вполне может оказаться так, что пользователь уже достаточно уверенно чувствует себя при работе с программой и не нуждается в подсказках, выскакивающих каждую минуту, а некоторые полезные, с точки зрения автора программного продукта, функции для конкретного пользователя таковыми не являются. Поэтому среди разработчиков программного обеспечения хорошим тоном считается предоставление пользователю возможности отключить вывод информационных сообщений. Это позволяет сохранить легкость освоения продукта для начинающих пользователей и одновременно с этим добиться, чтобы информационные сообщения не вызывали у опытных пользователей раздражения.

Осторожно скины

Осторожно: скины

Скин (англ, skin — кожа, шкура) — это набор графических изображений, с помощью которых можно менять внешний вид программы. Естественно, сама эта программа должна поддерживать работу со скинами.
Человек всегда стремится как-то выделиться, придать себе и своим вещам индивидуальность. Многие люди стараются так украсить собственный дом, автомобиль, рабочее место, чтобы они отличались от других. То же самое наблюдается с компьютерами: пользователи устанавливают в качестве "обоев" Рабочего стола Windows понравившиеся картинки, перенастраивают цветовую и звуковую схемы. Введение возможности изменить вид программы по своему вкусу - закономерное развитие компьютерных интерфейсов, еще один шаг к удовлетворению желания пользователей настраивать все "под себя" и индивидуализировать себя и свое окружение.
Хрестоматийный пример программы, использующей скины, — это мультимедийный плейер WinAmp (http://www.winamp.com). Именно после ее выхода слово "скины" стало очень модным. Огромной популярностью стали пользоваться программы, как и WinAmp, позволявшие менять "кожу", online-коллекции скинов (например, сайт http://www.skinz.org). Слово "скины" буквально завораживало пользователей, и они торопились скачать и опробовать любой программный продукт, в описании которого оно встречалось. Естественно, сам WinAmp тоже не остался без внимания, заполучив огромную аудиторию пользователей со всего мира, и его часто приводят как пример удачного маркетингового хода.
На стремительный рост популярности скинов тут же отреагировали авторы инструментов для разработки программного обеспечения: на рынке быстро появилось множество VCL- и ActiveX-компонентов, позволявших программистам легко встроить в собственные продукты поддержку скинов, и таким образом, снабдить свою программу одной из самых модных функций.
Однако у этих компонентов есть на первый взгляд не заметный, но, тем не менее, очень значительный недостаток. Каждый из этих компонентов, как правило, работает только с собственным форматом скинов. Вследствие этого, в программах, в которых поддержка скинов организована при помощи таких компонентов, не могут быть скины из других программ, например из того же WinAmp. Кроме того, количество "шкур", которые есть в распоряжении программиста, использующего один из таких компонентов, обычно очень невелико, не более 10—20.
Некоторые программисты не обращают на эти доводы никакого внимания: "Подумаешь, несовместимость форматов, ну и пусть, что скинов мало -главное, они, скины, ЕСТЬ!" Но давайте-ка немного порассуждаем. Если каждая программа использует собственный формат скинов, значит, существует вероятность, что в разных программах скины будут также разные (на самом деле именно так и есть). Кроме того, раз для каждой программы существует всего лишь по паре десятков "шкур", то пользователь точно не сможет выбрать из них ту, которая устраивает его на сто процентов. И теперь представьте картину: каждая программа на компьютере пользователя имеет разный вид, да к тому же и не полностью устраивающий хозяина системы. Кстати, вряд ли пользователи будут самостоятельно рисовать скины к вашей программе: это не такое уж простое занятие, а в ситуации, когда
скины требуются сразу для нескольких программ на компьютере, это дело становится и вовсе бесперспективным.
Гораздо более выигрышный вариант — пойти в фарватере лидера (прием, который действенен не только в области программирования вообще и скинов в частности). Кандидатура на эту роль только одна: WinAmp. Посудите сами:

WinAmp — самая популярная программа, которая поддерживает скины. Благодаря действительно хорошим функциональным возможностям и бесплатности, она чаще всего используется как плейер звуковых файлов;

к WinAmp уже нарисовано огромное количество скинов — более сорока трех тысяч (!) на август 2001 года;

некоторые программы независимых разработчиков уже поддерживают скины WinAmp.

Панель инструментов Adobe Photoshop

Рисунок 5.21. Панель инструментов Adobe Photoshop


Тип границы кнопок на панелях инструментов — тоже не такой простой вопрос, как кажется. Традиционно кнопки на инструментальных панелях точно так же, как и обычные командные кнопки, имели объемную границу вокруг них. Сложившийся порядок нарушил выход версии 3.0 браузера Microsoft Internet Explorer. Кнопки на панели инструментов этой программы имели "плоский" вид: граница появлялась на них лишь после того, как пользователь наводил на кнопку курсор мыши. Оригинальную, хотя и не бесспорную идею охотно подхватили все разработчики, и сегодня практически все программы имеют "плоскую" панель инструментов. Лично я разделяю мнение, что "плоская" панель инструментов выглядит очень необычно и интересно, однако есть пользователи, которым больше по душе традиционное оформление панели инструментов, когда кнопки выглядят именно так, как должны выглядеть кнопки. И те разработчики программ, которые стараются не упускать из виду даже самые незначительные мелочи, предусматривают в своих продуктах возможность смены пользователем вида панели "обычный"/"плоский", тем более что технически реализовать такую функцию в программе очень просто — нужно менять значение всего одного

Панели инструментов

Панели инструментов

Кнопочные панели инструментов (Toolbars) - излюбленный компонент многих разработчиков. С ним окно программы сразу приобретает более привлекательный, солидный и профессиональный вид. Любовь программистов к панелям инструментов настолько велика, что они, как я уже рассказывал чуть выше, даже отказываются в пользу них от святая святых пользовательского интерфейса — меню! Конечно, популярность компонента приводит к тому, что многие начинающие разработчики при включении панелей инструментов в свой проект сталкиваются с некоторыми "подводными камнями".
Панель инструментов — довольно сложный и, так сказать, "капризный" компонент. Для его поддержки в Windows включена специальная библиотека — comctl32.dll. За историю развития операционных систем семейства Windows 9.x эта библиотека пережила несколько обновлений, что привело к тому, что в программах, созданных на более поздних версиях системы, с "новыми" версиями comctl32.dll, панель инструментов не может работать, если программа запущена под одной из предыдущих версий Windows. Опытные разработчики обязательно включают в справочные файлы своих программ информацию об этой проблеме. Они выкладывают на своих Web-сайтах новую версию comctl32.dll, чтобы пользователи не самых последних версий Windows могли нормально работать с программой. А вот если программист забывает об этом, то вскоре ему начинают приходить письма от пользователей с сообщениями о странной ошибке, в результате которой на кнопках панелей инструментов не видны пиктограммы.
Кстати, о пиктограммах. В интернет-конференциях, посвященных разработке программного обеспечения, часто задают вопрос: "Можно ли для панелей инструментов своих программ брать пиктограммы (иконки) из чужих продуктов?" Если кратко ответить на этот вопрос, то такое "заимствование" запрещено. Пиктограммы, как произведение изобразительного искусства (пусть и очень миниатюрное), охраняется авторским правом, и только автор (или лицо, которому он передал свои права) может использовать эти пиктограммы, а также разрешать или запрещать их использование (см. гл. 3 "Немного об авторском праве").
Однако все зависит от самих владельцев прав на так понравившиеся вам пиктограммы. Некоторые из них, закрыв глаза, смотрят на нарушения своих авторских прав, справедливо полагая, что копия никогда не превзойдет оригинал. Например, считается незазорным заимствовать для своих проектов пиктограммы из продуктов пакета Microsoft Office (а их там огромное количество — подойдет, наверное, для любой программы). Сама корпорация Microsoft не считает это злом, все это способствует унификации интерфейсов программ, которая является одним из положений идеологии Windows.
А вот, например, если вы решите позаимствовать для своей программы пиктограммы популярного менеджера закачек ReGet (http://www.reget.com), то вряд ли это окажется незамеченным. Эти пиктограммы были созданы специально для ReGet в одной из самых крупных студий дизайна в России -Студии Артемия Лебедева (http://www.design.ru), и разработчик ReGet — компания ReGet Software, конечно же, заинтересована в том, чтобы никто, кроме нее, не пользовался этими уникальными пиктограммами.
Но, если уж вы решили позаимствовать для своей программы пиктограммы из другого продукта, постарайтесь, чтобы у вас они обозначали те же функции, что и в оригинальной программе. Иначе будет нарушен принцип последовательности, и пользователи будут испытывать затруднения с освоением вашего программного продукта.
При проектировании панелей инструментов допускается, чтобы при нажатии и удерживании кнопки мыши на некоторых кнопках Панели инструментов вызывалось подменю с дополнительными командами. Если вы решили снабдить Панель инструментов в своей программе такими "сложными" кнопками, то позаботьтесь о том, чтобы соответствующим образом выделить их, иначе пользователь может и не догадаться, что это не обычная кнопка. Например, много нареканий вызывает интерфейс стратегической игры SimCity 2000: некоторые (но не все) кнопки на панели инструментов содержат подменю, появляющиеся, если нажать и не отпускать кнопку мыши на одной из них. Но пиктограммы на кнопках никак не указывают на эту их особенность. В результате у многих пользователей возникают проблемы при освоении интерфейса: признаться, в свое время я сам долго не мог понять, почему щелчок мышью по кнопке с изображением электростанции не позволяет мне добавить атомную электростанцию, хотя такая возможность была в предыдущей версии игры. Оказалось, что соответствующий тип электростанции, как и несколько других, вызывается из подменю, которое "спрятано" в кнопке.
А вот разработчики Adobe Photoshop были более последовательны: в нижнем правом углу каждой "сложной" кнопки в качестве индикации помещено изображение стрелки.

Понимание лучше чем запоминание

Понимание лучше, чем запоминание

При разработке интерфейса нужно делать все объекты, функции, действия видимыми и легко доступными пользователю. Минимизируйте запоминание — пользователь не должен постоянно стараться удержать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент пользователю должно быть ясно, что нужно делать в данный момент. В хорошем интерфейсе инструкции по использованию системы всегда видимы или легко доступны для вызова в любое время, когда это требуется. Это может быть реализовано как в виде продуманной организации элементов интерфейса, так и непосредственно в виде подсказок пользователю. Хороший и очень известный пример — анимированная надпись, которая появляется на панели задач Windows и "подъезжает" к кнопке Пуск: "Начните работу с нажатия этой кнопки".
Это правило отражает принцип прозрачного интерфейса — интерфейса, который понятен и не заставляет пользователя вспоминать, какую же кнопку нужно нажать или какой пункт меню выбрать в данный момент.

После нажатия кнопки Подробнее

Рисунок 5.13. После нажатия кнопки Подробнее появляется дополнительная информация об ошибке


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

Последовательность и стандарты

Последовательность и стандарты

Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Принцип последовательности при разработке интерфейсов должен соблюдаться буквально во всем.
Во-первых, последовательность при выборе средств оповещения о событиях и действиях. Например, информация о текущем статусе программы, как уже говорилось при рассмотрении принципа "Видимость состояния системы", обычно выводится в статусную строку в нижней части экрана, а сообщения с результатами запросов пользователя — в отдельном диалоговом окне. Сообщения о критических ошибках при этом должны сильно отличаться от обычных информационных сообщений: например, они могут сопровождаться резким звуком.
Во-вторых, последовательность при оформлении элементов интерфейса. Если дизайн форм вашей программы основан на классическом интерфейсе Windows-приложений, характеризующемся строгой цветовой гаммой, прямыми линиями и углами, то очень странным выглядело бы решение придать одному из окон программы овальную форму и раскрасить его яркими цветами. Увы, но такие случаи не редкость.
В-третьих, последовательность при выборе терминов. Пользователей не должно сбивать с толку то, что три разных понятия, используемых в вашей программе, на самом деле означают одно и то же. И дело даже не в том, чтобы подобрать наиболее точное определение какому-либо термину. Главное — решить для себя, что для обозначения какого-то конкретного действия или события вы будете применять один конкретный термин, при этом будете использовать его четко определенным способом (например, слово "Интернет" вы будете писать с прописной буквы и склоняя), и в ходе работы над программой от этого правила не отступать. Это можно назвать своеобразной разработкой собственного стандарта.

Предупреждение ошибок

Предупреждение ошибок

Этот принцип широко распространен и в обычной жизни, вне сферы компьютеров и интерфейсов для них. "Пожар легче предупредить, чем потушить" - гласил один из плакатов, изданных в конце девяностых годов Министерством внутренних дел для обучения людей технике пожарной безопасности. "Преступление легче предупредить, чем раскрыть" -- гласит одно из правил науки криминологии.
Применительно к теме проектирования интерфейсов компьютерных программ, принцип предупреждения ошибок означает следующее: "Дизайн, который предупреждает возникновение проблем, лучше, чем самое хорошее сообщение об ошибке".
Интерфейс, предупреждающий возникновение ошибок и связанных с ними проблем, образно называют "услужливым". Программа как бы заботится о пользователе, будучи всегда готовой предложить пользователю помощь, дать подсказку.
Кроме того, уменьшение вероятности возникновения ошибок пользователя при работе с программой достигается тщательной проработкой всех элементов интерфейса и его концепции в целом в соответствии с правилами проектирования интерфейсов. Интуитивно понятный, легкий для освоения интерфейс у большинства пользователей не вызывает никаких затруднений.
Принцип предупреждения ошибок, хотя и упоминается Якобом Нильсеном в списке его эвристических правил пятым по счету, по моему мнению, должен быть указан в нем последним, т. к. он имеет значение принципа, обобщающего все остальные правила. Ведь интерфейс, предупреждающий возникновение ошибок и проблем, должен информировать пользователя о статусе программы, давать ему контроль над работой приложения, общаться с пользователем на понятном ему языке, соответствовать принципу последовательности и т. д.

При взгляде на Панель задач можно

Рисунок 5.18. При взгляде на Панель задач можно легко узнать, какой документ открыт в Microsoft Word, а вот какие документы загружены в UltraEdit, Aditor и Adobe Photoshop — нет

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

В новых версиях программных продуктов постепенно происходит отказ от традиционной схемы построения заголовков окон. Например, Microsoft уже перевела на новый формат заголовка окна свои продукты — от простого "Блокнота" из состава Windows до программ пакета Office 2000.

Пример непоследовательного выбора

Рисунок 5.16. Пример непоследовательного выбора элементов управления: в двух функционально похожих окнах используются кнопки разного вида пример реализации принципа последовательности, сформулированного Якобом Нильсеном.

Пример реализации многодокументного интерфейса

Рисунок 5.15. Пример реализации многодокументного интерфейса


Примеры реализации MDI-интерфейса - это, в частности, различные многооконные, редакторы: текстов, изображений, музыки, системы управления базами данных, электронные таблицы — в общем, любые программы, в которых осуществляется одновременная обработка нескольких файлов.
Долгое время "сферы влияния" SDI и MDI были четко разделены: одно-документный интерфейс использовался в функционально простых программах, тогда как на основе мультидокументного интерфейса строились более сложные приложения. Традиция была нарушена после появления Web-браузера Netscape Navigator: программа допускала работу с несколькими документами (Web-страницами), однако интерфейс был однодокументным: для каждой новой открываемой страницы создавалось новое, независимое от остальных SDI-окно. Идея была повторена специалистами корпорации Microsoft, разрабатывавшими конкурирующий продукт — Internet Explorer, a затем и развита: в текстовом процессоре Microsoft Word для Windows, имеющем классический MDI-интерфейс, в версии 2000 (9.0) документы стали открываться в независимых окнах, однако переключение между ними осуществлялось не только при помощи Панели задач Windows, но и способом, традиционным для мультидокументного интерфейса — меню Окно. Таким образом, сегодня, помимо традиционных SDI- и MDl-интерфейсов, существует и некий "промежуточный" вариант.
При выборе типа интерфейса для своего продукта исходите не только из функциональных его возможностей, но и из того, какой тип интерфейса наиболее часто встречается среди аналогичных программ, т. е. воспользуйтесь принципом заимствования. Например, не важно, что файловый менеджер, который вы разрабатываете, умеет - работать одновременно с несколькими списками файлов. Привыкшие к SDI-интерфейсу Norton Commander пользователи неодобрительно относятся к программам, заставляющим их отказываться от своих привычек. Например, функции работы с множественными окнами в аналоге Norton Commander, DOS Navigator используются небольшим числом пользователей, а предок Проводника Windows -- File Manager из Windows 3.x — вообще прослыл программой с очень неудобным интерфейсом, т. к. при работе с ним без следования концепции мультидокументного интерфейса обойтись нельзя. А вот для текстовых редакторов, несмотря на инициативу Microsoft, отказавшейся от MDI-интерфейса в WinWord, многодокументный интерфейс более удобен и привычен.

Принцип группировки

Принцип группировки

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

Распознавание и исправление ошибок

Распознавание и исправление ошибок

"Помогайте пользователю, распознавать и исправлять ошибки" - говорит Якоб Нильсен. Это правило определяет проектирование сообщений об ошибках. Хорошие сообщения об ошибках — это сообщения, которые объясняют, в чем состоит проблема и, самое главное, как ее исправить. Таким образом, хорошее сообщение об ошибке должно состоять из двух частей.

Равенство между системой и реальным миром

Равенство между системой и реальным миром

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

Различное расстояние между элементами

Рисунок 5.17. Различное расстояние между элементами управления придает интерфейсу непрофессиональный вид

Разработчики Microsoft Internet

Рисунок 5.1. Разработчики Microsoft Internet Explorer совершенно правильно предположили, что не все пользователи будут использовать по умолчанию


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


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

Реакция текстового редактора Microsoft

Рисунок 5.6. Реакция текстового редактора Microsoft Word на выбор пользователем команды меню Статистика


Часто реакция на одно и то же действие различается именно в зависимости от того, кем это действие произведено. Пример — функция автоматической загрузки своих новых версий по Интернету, имеющаяся во многих программах. Если пользователь самостоятельно отдает команду проверить наличие обновлений, то обычно после этого пользователю демонстрируется диалоговое окно, где отображаются результаты проверки — вне зависимости от того, были результаты проверки отрицательными или положительными. Если же такая проверка выполняется автоматически (например, при каждом запуске программы), то обычно пользователю сообщается информация, что обнаружена новая версия продукта. Сообщения о том, что новая версия программы не найдена, или сообщения об ошибках обычно не выводятся, чтобы не отвлекать пользователя от работы и не раздражать его.
Помимо текстовых сообщений, выводящихся в окне программы, для организации обратной связи могут быть использованы и другие средства. Самое популярное из них — звук. Звуковое оповещение может быть полезным в самых различных ситуациях. Наиболее часто звук помогает тогда, когда появление на экране модальных окон нежелательно, а сообщения в статусной строке могут быть не замечены (например, если главное окно программы, как таковое, отсутствует). Это является типичным, например, для утилит, периодически проверяющих e-mail-ящики на наличие свежей почты. Другое полезное применение звука — оповещение пользователя, находящегося не за компьютером, а где-то поблизости. Также звуковое сопровождение окажет помощь пользователям с ограниченными возможностями (например, с плохим зрением).
Важно помнить, что звуковое оповещение не должно быть основным средством организации обратной связи. Звук должен лишь дополнять текстовые сообщения. Иначе пользователь может пропустить сообщение -- ведь на компьютере может отсутствовать звуковая карта или звук может быть отключен. Таким образом, исчезнет единственное средство организации обратной связи, и работа с программой станет очень неудобной или вообще невозможной. Интересно, что эта особенность интерфейса специально используется некоторыми shareware-авторами для стимуляции пользователей оплачивать регистрации. Например, в незарегистрированной версии программы получения сообщений по сети Vypress Auvis (http://www.vypress.cora) оповещение о приходящих сообщениях с помощью всплывающих окон отключено — до регистрации можно пользоваться только звуковым оповещением. Как следствие, работа с программой становится очень некомфортной, т. к. основная область ее применения — локальные офисные сети, где количество компьютеров, не оснащенных звуковыми картами, довольно велико.
Среди других средств организации обратной связи можно упомянуть запись сообщений в log-файл, отправку сообщений по e-mail. Естественно, они применяются в качестве дополнительных способов оповещения — например, для сбора статистики или доступа удаленных пользователей, подключающихся к системе по каналам связи.

Сообщение о незначительных ошибках

Рисунок 5.5. Сообщение о незначительных ошибках в строке состояния Internet Explorer


Что касается зависимости выбора средства обратной связи от типа действия, вызывающего ее, то традиционно считается, что если пользователь сделал какое-то действие -- например, запустил процесс кодирования большого файла или дал команду подсчитать количество знаков в тексте, — и ожидает какого-то результата, то этот результат (или сообщение об ошибке) должен быть выведен в отдельном окне. Если же результат, о котором требуется сообщить пользователю, просто текущая информация о процессе, и не является прямым следствием действий пользователя, то в данном случае можно ограничиться отображением соответствующего сообщения в строке состояния.

Сообщение о возможной потере форматирования

Рисунок 5.4. Сообщение о возможной потере форматирования

Создание профессионального интерфейса

Создание профессионального интерфейса

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

Списки

Списки

Элемент управления Список (ListBox) один из самых популярных во всей палитре компонентов для создания интерфейса. Он позволяет легко просматривать большие объемы информации и осуществлять выделение нужных строк. Однако у него есть неприятная особенность: отсутствие горизонтальной линейки прокрутки. Из-за этого слишком длинные строки обрезаются на границе элемента, что особенно неприятно, если таким образом становится недоступной какая-либо важная информация.
Во избежание возникновения подобных проблем нужно тщательно протестировать работу программы, чтобы выяснить, возможна ли ситуация, что в список будут выведены слишком длинные строки, чтобы уместиться в нем полностью. Если это не исключается, то можно предусмотреть средства, позволяющие все-таки полностью просмотреть "обрезанную" строку, например, при двойном щелчке мышью на интересующей пользователя строке выводить на экран небольшое окошко, где требуемый текст отображается полностью. Еще один хороший путь решения этой проблемы — заменить элемент Список (ListBox) более функциональным, скажем, ListView (в нем, например, Проводник Windows выводит список файлов). Задав определенным образом некоторые свойства ListView, можно добиться его полного внешнего сходства с традиционным списком, однако в отличие от последнего в окне ListView будет присутствовать горизонтальная линейка прокрутки.

Справка и документация

Справка и документация

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

Средства обеспечения обратной связи

Средства обеспечения обратной связи

Выбор конкретного средства обратной связи зависит от типа информации, которую нужно донести до пользователя, а также типа действия, которое вызывает потребность в обратной связи.
Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках — в статусной строке окна приложения без остановки его работы. Характерен пример браузера Microsoft Explorer: если открыть запрашиваемую Web-страницу в данный момент невозможно (например, отсутствует соединение с Интернетом), то на экране появляется модальное окно с сообщением о критической ошибке. Если же страница была успешно загружена, но при этом возникли незначительные ошибки, то соответствующее сообщение отображается в строке состояния программы.

Стандартные элементы интерфейса

Стандартные элементы интерфейса

Постарайтесь не использовать в своей программе нестандартные элементы интерфейса - например, командные кнопки не только с текстом, но и с рисунком, или комбинированные списки со сложной рамкой, которые в изобилии можно найти в online-коллекциях VCL и ActiveX-компонентов. Хотя бы потому, что именно так поступают профессиональные разработчики интерфейсов. "Чем стандартнее компоненты, тем лучше и профессиональнее вид" - не раз приходилось слышать от опытных авторов. Посудите сами: вы когда-нибудь видели в программе от Microsoft, Corel или Adobe элемент управления, сделанный начинающим программистом, выложенный в Интернете и сопровожденный припиской в файле readme.txt: "Это мой первый опыт в создании компонента, поэтому не пинайте слишком сильно!"
Замечание 2
Замечание 2


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

Свобода действий пользователя

Свобода действий пользователя

Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Очень часто пользователь дает различные команды по ошибке (например, случайно нажав не ту кнопку или "промахнувшись" мышью мимо нужного пункта меню), и у него должен быть "аварийный выход" из этой ситуации, четко обозначенный в программе. Чаще всего такой "выход" реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Кроме этого, нажатие на клавиатуре клавиши является традиционным и поэтому привычным для большинства пользователей средством "аварийного выхода". Характерно, что "escape" в переводе с английского означает "побег, уход". Оно также незаменимо тогда, когда кнопка Cancel (Отмена) недоступна — чаще всего в Главном окне приложения, ведь размещение кнопок OK, Cancel, Help и других здесь, в отличие от диалоговых окон, не допускается. В частности, Microsoft Word при выполнении трудоемких и продолжительных по времени операций, например чтения очень больших файлов, выводит в строку состойния индикатор, отображающий ход процесса и сообщение: "Для отмены нажмите . Клавиша аналогично работает и в Adobe Photoshop, позволяя прервать загрузку большого файла или выполнение сложного фильтра, и во многих других приложениях.
Хорошим тоном считается, если позволяет текущая ситуация, сочетать оба эти способа — кнопку Cancel (Отмена) и клавишу : современные системы разработки приложений для Windows при проектировании форм диалоговых окон позволяют назначить кнопке свойство срабатывания по нажатию клавиши . Как следствие, для пользователя привычным действием при попадании в ситуацию, из которой ему поскорее хочется выбраться, является именно нажатие клавиши . Что может быть проще: не нужно искать глазами какую-то там кнопку Cancel (Отмена), достаточно ударить по клавише в верхнем левом углу клавиатуры — и готово!

Свойство Flat компонента Toolbar

Рисунок 5.22. Свойство Flat компонента Toolbar отвечает за "плоский" вид панели

Свойство кнопки Cancel в среде

Рисунок 5.9. Свойство кнопки Cancel в среде Borland Delphi определяет, будет ли кнопка срабатывать при нажатии клавиши


Еще одно, причем немаловажное, средство выхода из ошибочной ситуации — функции Undo (Отменить) и Redo (Повторить). Они являются настолько удобными и поддерживаются таким большим количеством программ, что пользователи уже привыкли к ним и подсознательно ожидают, что любое произведенное действие можно отменить, вернувшись к предыдущему состоянию. Функция Undo (Повторить) даже стала предметом многих шуток и историй о том, как привыкший к компьютеру человек, в реальном мире разбив далеко не виртуальную вазу, или сделав ошибку в простом, "бумажном", письме, непроизвольно ищет кнопку Undo (Отменить).
Все это просто обязывает разработчика качественного интерфейса компьютерной программы поддерживать функции Undo и Redo. Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно будет выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.

TabOrder "Правильный" порядок

TabOrder. "Правильный" порядок

TabOrder — это порядок, в котором экранный курсор перемещается по элементам управления в форме при нажатии клавиши <Таb> на клавиатуре компьютера. На стадии разработки программы, при размещении элементов управления на форме, TabOrder эквивалентен тому порядку, в котором создаются эти элементы. Однако в процессе проектирования программы автор многократно меняет расположение элементов на форме, какие-то из них удаляет, добавляет новые компоненты. В результате почти всегда оказывается, что TabOrder не соответствует тому порядку, в котором визуально расположены элементы, и при нажатии клавиши <ТаЬ> курсор хаотично скачет по экрану вместо последовательного перемещения по компонентам.
Опытные разработчики по окончании проектирования формы обязательно проверяют TabOrder и, при необходимости, корректируют его. А вот начинающие авторы, увы, часто забывают об этом.

Текстовые подписи

Текстовые подписи

Казалось бы, какие "подводные камни" могут быть при использовании одного из самых простых элементов управления — Label? Во-первых, не забудьте о масштабировании шрифтов: чтобы текстовая подпись автоматически подстраивала свои размеры согласно содержащемуся в ней тексту, проверьте, что свойство AutoSize имеет значение True. Во-вторых, также присвойте значение True свойству Transparent (если ваша среда разработки поддерживает его) — это приведет к тому, что фон подписи станет прозрачным, и гарантированно убережет вас от возникновения проблемы.
Вот такой он непростой, элемент Label: "обрезанный" текст и фон, не соответствующий фону основной формы, могут сильно испортить отношение пользователя ко всей программе.

Типы интерфейса Windowsпрограмм

Типы интерфейса Windows-программ

В справочниках по созданию приложений для Windows интерфейсы программ традиционно делятся на два вида: однодокументный и многодокументный интерфейсы.
Однодокументный интерфейс (Single Document Interface, SDI) характеризуется тем, что главное окно программы, основанной на нем, не может содержать других окон, кроме диалоговых (окон настройки, информационных сообщений, сообщений об ошибках и т. п.). Как видно из его названия, такой интерфейс предназначен для работы с одним-единственным документом (под документом здесь понимается не только ассоциирующийся с этим словом у большинства пользователей текстовый файл, но и вообще любой объект — например, список папок на диске компьютера). За примерами использования SDI-интерфейса далеко ходить не надо: достаточно вспомнить входящие в Windows утилиты Блокнот, WordPad, Paint, Проводник и т. д.
Многодокументный, или мультидокументный, интерфейс (Multi-Document Interface, MDI) отличается от SDI тем, что главное окно программы может содержать другие, подчиненные окна, которые нельзя переместить за пределы основного окна. Такие подчиненные окна называют "child", т. е. "детскими", а окно, которое их содержит, соответственно, "parent" -"родительским". Как родительские, так и детские окна могут иметь свои меню, причем меню главного окна меняется на меню подчиненного окна, если последнее максимизируется, расширяясь до его, главного окна, границ.

Умное заимствование

Умное заимствование

Заимствование широко распространенных приемов дизайна интерфейсов и удачных находок авторов конкурирующих программ позволяет резко сократить время обучения и повысить комфорт пользователя. При работе он будет использовать уже приобретенные навыки -- этот вопрос затрагивает и принцип равенства между системой и реальным миром.
Заимствование чужих интерфейсных находок не является чем-то зазорным. Программы, лидирующие на рынке, являются неистощимым источником вдохновения для разработчиков более мелких программ, поразительно напоминающих легендарный Norton Commander: FAR, Volcov Commander, DOS Navigator, DISCo Commander

В меню сначала показываются часто

Рисунок 5.12. В меню сначала показываются часто выполняемые команды, а после щелчка по стрелке — все остальные

В окне программы WinAmp кнопка

Рисунок 5.8. В окне программы WinAmp кнопка со сгрелкой, направленной вверх, не открывает лоток CD-ROM-привода, а вызывает окно Открыть файл


А вот дизайн популярной программы Lotus Organizer, наоборот, считается классическим примером удачного заимствования объектов реального мира. Главное окно программы выполнено в виде ежедневника с закладками — объекта, к которому пользователи уже давно привыкли. Но, тем не менее, в окне Lotus Organizer присутствуют традиционные, чисто "компьютерные" элементы — кнопочная панель инструментов и меню. Дело как раз в слове "традиционный" - - к панели кнопок и меню пользователи давно уже привыкли, и это помогает им быстро освоить программу. А если бы дизайнеры Lotus в своих экспериментах пошли дальше и заменили бы меню и панель кнопок на, скажем, изображение офисного шкафа с парой десятков ящиков и полочек, то интерфейс программы стал бы громоздким и запутанным.

Видимость отражает полезность

Видимость отражает полезность

Смысл этого принципа состоит в том, чтобы вынести самую важную информацию и элементы управления на первый план и сделать их легкодоступными пользователю, а менее важную — переместить, например, в меню.
Этот вопрос уже немного затрагивался при разговоре о принципе Якоба Нильсена "Эстетичный и минималистический дизайн", правда, в привязке к отражению полезности.
Отличие принципа "Видимость отражает полезность" как раз и состоит в том, что интерфейс программы должен быть построен вокруг объектов, с которыми манипулирует пользователь, и отражать состояние текущего объекта. Реализацию этого принципа вы видите каждый раз, когда пользуетесь компьютером: контекстные панели инструментов в программах пакета Microsoft Office, которые меняются в зависимости от того, с какой частью программы (редактором, предварительным просмотром, рисованием и т. п.) в данный момент работает пользователь. Еще один пример — уже упоминавшееся меню Пуск в Windows ME и Windows 2000: по умолчанию в них видимы наиболее часто используемые, т. е. полезные для пользователя, пункты.

Видимость состояния системы (правило обратной связи)

Видимость состояния системы (правило обратной связи)

Система (в данном случае — компьютерная программа) должна всегда информировать пользователя о состоянии своей работы с помощью соответствующих средств, в разумное время. При рассмотрении этого правила нужно учитывать несколько аспектов.

Вкладки

Вкладки

Вкладки (Tabs) широко используются при проектировании интерфейсов современных программ, с тех самых пор, как вышла Windows 95, в которой практически каждое диалоговое окно содержало вкладки. Нужно отдать должное этому элементу управления: он не только выглядит не менее эффектно, чем кнопочная панель инструментов, но и очень эффективен, позволяя логически группировать большое количество информации, позволяя пользователю комфортно воспринимать ее.
Да, вкладки позволяют упорядочить большие объемы данных, однако это полезное свойство вкладок сходит на нет, если число самих вкладок становится слишком большим. Здесь явно наблюдается противоречие с правилом кошелька Миллера (см. разд. "Другие принципы построения интерфейсов" данной главы), определяющим, что человек может удерживать в своей кратковременной памяти семь плюс-минус две сущности. Поэтому в нескольких рядах вкладок, которые уже перестают умещаться в рамках диалогового окна, очень легко запутаться. Даже тот десяток вкладок, которые находятся в окне Параметры Microsoft Word, вызывает многочисленные нарекания со стороны пользователей. Действительно, мало кому не приходилось беспорядочно щелкать по вкладкам окна настроек Microsoft Word, чтобы отыскать нужную опцию.
Но что же тогда делать авторам функционально очень сложных программ, где диалоговые окна заполнены самой разной информацией? Без вкладок все окажется словно сваленным в одну большую кучу, в которой разобраться будет гораздо труднее, чем в десятке вкладок.
Если посмотреть, как эта проблема решается в известных shareware-программах, то можно заметить, что их авторы стремятся уменьшить число вкладок в диалоговых окнах за счет разделения всех вкладок в новые группы, где число вкладок относительно невелико. Например, в главном меню популярного почтового клиента The Bat! (http://www.ritlabs.com) есть отдельный пункт — Свойства, а в нем — несколько подпунктов, вызывающих соответствующие диалоговые окна: Редактор писем, Быстрые шаблоны, Подключение и администрирование и т. п. В некоторых из них вообще отсутствуют вкладки, а некоторые обошлись всего лишь двумя-тремя вкладками. В не менее популярном текстовом редакторе UltraEdit аналогичным образом разнесены окна настройки самого редактора и вспомогательных утилит. В уже много раз упоминавшейся программе Chameleon Clock, в окне Свойства создано три группы опций: Настройки, Действия и Виды (переключение между ними происходит при помоши панели в стиле Microsoft Outlook), в которых находятся по четыре-пять вкладок (а в опции Виды их вообще нет).

Время оповещения

Время оповещения

Промежуток времени, в который пользователь получает информацию о реакции на его действие или о событии, должен быть минимальным. Это особенно важно, т. к. от наличия или отсутствия у пользователя информации о текущем состоянии системы определяет его дальнейшие действия. Если он не будет знать, что последняя операция была завершена неудачно, то последующие действия могут вызвать новые ошибки.
При разработке большинства приложений обеспечение мгновенной реакции на события и действия пользователя не представляет никакой сложности. Однако в некоторых случаях это может быть затруднительным. Например, один программист, специализирующийся на разработке сложных приложений для Web-серверов, рассказывал, что многие пользователи просят дополнить существующий Web-интерфейс (формы с элементами управления на Web-странице) e-mail-интерфейсом — т. е. возможностью управлять системой с помощью сообщений электронной почты. Техническая реализация этого не представляет никакой сложности, однако это ставит под угрозу стабильность работы системы. Дело в том, что при управлении серверным программным обеспечением посредством e-mail, проходит немало времени между моментом отправки письма и моментом его обработки на сервере. При обнаружении ошибки (например, запрос пользователя был сформулирован неправильно) сервер высылает пользователю письмо, которое будет получено пользователем еще через некоторое время. Таким образом, время оповещения становится слишком большим, чтобы можно было уверенно работать со сложным серверным приложением, где любая операция должна осуществляться только с учетом того, что все предыдущие завершены успешно.

Всплывающая подсказка на Строке состояния

Рисунок 5.23. Всплывающая подсказка на Строке состояния


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

Всплывающие подсказки

Всплывающие подсказки

Всплывающие подсказки (ToolTips) — это, конечно, не самостоятельные элементы управления, хотя в коллекциях компонентов и можно найти модули для создания сложных (многострочных, с разными типами шрифтов, с графикой и т. п.) подсказок. На практике они применяются как дополнение к другим элементам управления, выдавая пояснение относительно назначения соответствующего элемента. Стоит пользователю на секунду задержать курсор мыши над интересующим его элементом, как появляется небольшой желтый прямоугольник с поясняющим текстом.
Нужно помнить, что всплывающие подсказки — спутник далеко не любого компонента на форме приложения. Традиционно они используются для "озвучивания" назначения только кнопок на панелях инструментов, секций на строке состояния и..., пожалуй, все. Есть некоторые случаи использования всплывающих подсказок для других компонентов (например, вертикальная линейка прокрутки в Microsoft Word или меню Пуск в Windows 2000), но это скорее исключение, чем правило.

Выбор цветов

Выбор цветов

Здесь ситуация в точности такая же, как и со шрифтами: никакого выбора. При проектировании интерфейса нужно вообще забыть о свойстве Цвет (Color) элементов управления. Оставьте цвета стандартными, и пусть ваша программа выглядит так, как этого хочет ее пользователь, а не автор (хорошая идея — предусмотреть в программе возможность изменения цветовой гаммы различных частей интерфейса: многие пользователи любят настраивать цвета "под себя", причем так, что другому человеку такое "сочетание" цветов может показаться совершенно неудобоваримым). И в этом, нужно сказать, авторам программ повезло: они лишены одной из самых главных забот дизайнеров и художников, какие же цвета выбрать для своего нового творения.
Многие программисты все-таки жестко прописывают в своей программе используемые цвета, и это может служить причиной возникновения одного неприятного эффекта. Дело в том, что, как вы знаете, с помощью Панели управления можно легко изменить цветовую гамму Windows. Жестко фиксируя в своей программе выбранные цвета, автор не учитывает, что его программа выглядит хорошо только до тех пор, пока она работает на компьютере с такой же цветовой гаммой, как и на компьютере разработчика. Если же ее запускают в системе с другим цветовым оформлением, то результат может выглядеть, мягко говоря, не очень хорошо. Для предотвращения таких досадных ошибок в процессе разработки программы нужно время от времени переключаться на другие цветовые "схемы" Windows, проверяя, как ваша программа будет выглядеть на компьютере с нестандартной цветовой гаммой.

Выбор шрифтов

Выбор шрифтов

Здесь все просто — автор не должен выбирать никаких шрифтов. Оставьте их такими, какими они определены по умолчанию, а лучше — укажите в свойстве Шрифт (Font) соответствующие глобальные переменные Windows: WindowText, MenuText и т. д. В этом случае смена пользователем стандартных шрифтов Windows по своему вкусу с помощью Панели управления отразится и на внешнем виде вашей программы. Таким образом, пользователь, запустив ваш продукт, окажется в знакомом ему окружении.
Еще один вопрос — предпочтительное начертание шрифтов. Современные системы программирования допускают указание для свойства Шрифт, помимо обычного (normal) начертания еще и полужирное (bold), курсивное (italic) и подчеркнутое (underlined), а также их сочетания. Многие авторы, обрадовавшись предоставленным возможностям, охотно ими пользуются, применяя различные комбинации шрифтовых начертаний. На самом же деле в интерфейсах Windows-программ принято использовать всего два начертания: нормальное и полужирное (последнее — для выделения какой-либо важной информации, заголовков и т. п.). Применение курсива или подчеркивания, которое, к тому же, пользователь ошибочно может принять за гиперссылку — это дурной тон.

Заголовок окна (формы)

Заголовок окна (формы)

Хотя в палитрах доступных программисту компонентов современных систем создания приложений отсутствует такой элемент управления, как заголовок окна, он определяется свойством Заголовок (Caption) объекта Форма (Form), ему нужно уделять не меньшее внимание, чем кнопкам, спискам и тому подобным элементам.
Заголовок главного окна программы традиционно используется для вывода информации о двух вещах: названии программы и названии документа, с которым в данный момент работает пользователь (если, конечно, в программе вообще предусмотрена обработка каких-либо документов). Так вот, вопрос в том, в каком порядке должна помещаться в окне программы такая информация?
Вопрос вовсе не праздный, как кажется на первый взгляд. Традиционно в программах с мультидокументным интерфейсом в заголовке окна сначала помещается название программы, а затем — название открытого документа. Однако для пользователя более удобным является другой порядок расположения информации в заголовке окна, когда первым идет название открытого документа, а после него — название программы. Такой подход к организации заголовка окна имеет следующие преимущества:

если название документа помещается в заголовке окна первым, то оно всегда видимо на кнопке, представляющей соответствующую программу на Панели задач Windows, и узнать, какой в данный момент открыт документ, не представляет никакого труда. А вот если в заголовке окна сначала идет название программы, то, следовательно, оно и видно на Панели задач, и для того, чтобы выяснить, с каким именно документом работает данное окно, нужно переключиться в него (или навести курсор на кнопку Панели задач и подождать секунду, пока не появится всплывающая подсказка);

Значение пользовательского интерфейса

Значение пользовательского интерфейса

Один из самых частых вопросов, которые задают в конференциях начинающие shareware-авторы — нужно ли делать для программы красивый пользовательский интерфейс? Опытные разработчики единодушны в своем мнении: привлекательный интерфейс программе просто необходим!
Многие "чистые" программисты, т. е. разработчики, не занимавшиеся собственно продвижением своих программ, считают, что основное — эффективность внутренней структуры программы, а интерфейс — дело десятое.
Однако в shareware-бизнесе главное — это не собственно программа, а ее продвижение. И интерфейс, пожалуй, является решающим фактором, который будет влиять на то, как пользователи воспринимают продукт и, следовательно, как они его покупают. Мало кого волнует, что ваша утилита, например, выполняет чтение больших файлов на полсекунды быстрее, чем продукт конкурента. Но если пользоваться вашей программой неудобно или просто неприятно, то покупатели предпочтут конкурирующий продукт.
В конференцию SwRus время от времени врывается какой-нибудь новичок с отчаянным воплем: "Помогите! Написал хорошую программу, сделал для нее сайт, зарегистрировал в online-архивах — а ее почти никто не покупает! Что делать?" Но стоит скачать программу, установить и запустить ее — все сразу становится ясно. ИНТЕРФЕЙС. Многие shareware-продукты до того неприятны в использовании, что вызывают чувство отвращения. В этой ситуации то, что программу покупают хотя бы 1—2 человека в месяц, можно считать феноменом.
Слишком многие пренебрегают пользовательским интерфейсом. Некоторые даже гордятся некрасивым интерфейсом своих программ: "Эти фенсчки никому не нужны". Но насчет этого хорошо написал Юрий Герасимов в своей статье "Улетный интерфейс" ("Компьютерра", № 42, 1998, http:// www.computerra.ru/offline/1998/270/1778/): "Красота программы, как и самолета, — не в лишних украшательствах. Самолет, увешанный бантиками, с художественной лепкой и резными крыльями красного дерева не пролетит и ста метров. Красота состоит в целесообразности всей конструкции самолета, в еще большей степени это относится к программам".
Опытные разработчики уделяют созданию интерфейса повышенное внимание — даже больше, чем собственно программированию функциональных возможностей. Косвенным подтверждением того, что это время было потрачено не зря, является не только высокий уровень продаж, но и письма благодарных пользователей. Например, интерфейс программы Offline Explorer (http://www.metaproducts.com) делался в течение нескольких месяцев — но зато теперь ее авторам приходят письма о том, что ее интерфейс — один из самых дружественных пользователю. В ходе работы над другим успешным shareware-проектом, уже упоминавшемся Chameleon Clock (см. разд. "Успешные российские shareware-проекты" гл. I), около 70—80 процентов времени было затрачено именно на интерфейс. Но теперь от пользователей этой программы приходят многочисленные письма с восторженными отзывами буквально о всех элементах интерфейса Chameleon Clock -- начиная от "Quick Intro" (простой обучающей программы) до дизайна форм.

Золотое сечение

Золотое сечение

Золотое сечение — это самая комфортная для глаза пропорция. Форма, в основе построения которой лежит сочетание симметрии и золотого сечения, способствует наилучшему зрительному восприятию и появлению ощущения красоты и гармонии.
В математике пропорцией называют равенство двух отношений: а : b = с : d.
Отрезок прямой АВ можно разделить точкой С на две части следующими способами:

на две равные части АВ : АС = АВ : ВС;

на две неравные части в любом отношении (такие части пропорции не образуют);

таким образом, когда АВ : ВС = ВС : АС.

Последнее и есть золотое деление или деление отрезка в крайнем и среднем отношении.
Золотое сечение — это такое пропорциональное деление отрезка на неравные части, при котором весь отрезок так относится к большей части, как сама большая часть относится к меньшей; или другими словами, меньший отрезок так относится к большему, как больший ко всему.
а : b = b : с или с : b = b : а.
Отрезки золотой пропорции выражаются бесконечной иррациональной дробью 0,618..., если с принять за единицу, а = 0,382. Отношение же отрезков а и b составляет 1,618.
Прямоугольник с таким отношением сторон стали называть золотым прямоугольником. Он также обладает интересными свойствами. Если от него отрезать квадрат, то останется вновь золотой прямоугольник. Этот процесс можно продолжать до бесконечности. А если провести диагональ первого и второго прямоугольника, то точка их пересечения будет принадлежать всем получаемым золотым прямоугольникам.
Есть и золотой треугольник (равнобедренный треугольник, у которого отношение длины боковой стороны к длине основания равняется 1,618), и золотой кубоид (прямоугольный параллелепипед с ребрами, имеющими длины 1,618, 1 и 0,618).
Золотое сечение не является искусственным явлением. Оно очень широко распространено в природе: золотое сечение можно найти в пропорциях тел многих растений и животных, а также морских раковин и птичьих яиц. Но наиболее впечатляющий пример "применения" природой принципа золотого сечения — человеческое тело. Оно целиком и его части (лицо, руки, кисти рук и т. п.) насквозь пронизаны пропорцией 1,618.
Принцип золотого сечения был открыт людьми еще в глубокой древности. Знаменитые египетские пирамиды в Гизе, например, основаны на пропорциях золотого сечения. Более молодые мексиканские пирамиды и античный храм Парфенон также содержат в себе пропорцию 1,618.
С развитием дизайна и технической эстетики действие закона золотого сечения распространилось на конструирование машин, мебели и т. д. Проектирование компьютерных интерфейсов — не исключение. Формы диалоговых окон и элементов управления, стороны которых относятся как 1,618, очень привлекательны для пользователей. Например, очень много восторгов у пользователей программы Chameleon Clock (http://www.softshape.com) вызывает такая, казалось бы, обыденная вещь, как вид диалогового окна Свойства. А все потому, что при его проектировании использовался именно принцип золотого сечения.

Учебник по созданию shareware программ

ASProtect взломщики отдыхают

ASProtect: взломщики отдыхают

В конце разд. "Реализация защиты и ее взлом" этой главы приведен "скорбный" список из дюжины продуктов для организации защиты shareware-программ, которые были взломаны. Но все-таки есть в этой категории продукт, защита которого пока остается нерушимой. Его не раз рекомендовали как отличное средство организации защиты и в российской конференции SwRus, и в зарубежных, например, news:comp.shareware.authors. Называется он ASProtect (http://www.aspack.com) и написан нашим соотечественником Алексеем Солодовниковым. От одного опытного специалиста в области компьютерной безопасности мне приходилось как-то слышать такие слова: "Во времена ASProtect можно с защитой уже особо и не париться".
Действительно, ASProtect обеспечивает комплексную защиту shareware -программ:

упаковку и шифрацию кода, данных, таблиц импорта и ресурсов файлов программы;

генерацию очень длинных и сложных ключей (как статических, так и динамических);

"черные списки" для блокировки украденных ключей;

обработку ограничения работы программы по времени; П распознавание активности отладчика;

специальные API-функции для взаимодействия ASProtect с защищаемой программой.

Механизм защиты ASProtect основан на принципе "конверта", в который как бы помещается приложение. Сначала код, данные, таблицы импорта и ресурсы файлов программы шифруются и упаковываются с использованием оригинального алгоритма ASPack, при этом двоичный код анализируется на предмет наличия в нем API-функций ASProtect, и код, отвечающий за защиту, присоединяется к концу исходного файла. Размер этого кода — около 40 Кбайт, но за счет упаковки приложения по алгоритму ASPack объем файла программы сокращается более чем на 50%.
После запуска ЕХЕ-файла программы управление передается к тому самому, в 40 Кбайт, модулю защиты. Он проверяет целостность файла, активность отладчика (при его обнаружении работа защищенной программы прекращается), наличие регистрационного кода, обрабатывает ограничение работы по времени и, наконец, расшифровывает и распаковывает данные основного приложения и передает ему управление.
Наличие API-функций, с помощью которых ASProtect взаимодействует с защищаемым приложением, многократно повышает сложность взлома защиты. С освоением этого API нет никаких сложностей: функции имеют простой синтаксис, и, кроме того, в документации к программе приводятся примеры внедрения защиты на C++, Delphi и Visual Basic.
Регистрационные коды, генерируемые ASProtect, имеют минимальную длину 137 символов. В программе есть диалоговое окно Украденные ключи. Если автор программы обнаружит, что какой-либо из выданных ключей попал в руки злоумышленников, то он может поместить его в список, еще раз запустить процедуру защиты ЕХЕ-файла — и программа перестанет воспринимать этот ключ.
Если запустить поиск по слову ASProtect, например, в http://www.yandex.ru, то можно найти много страничек, где рассказывается о том, как взломать защиту ASProtect. Но все это относится только к ранним версиям пакета, в механизме защиты которых существовали "дыры". К версии 1.2 все ошибки были исправлены, и с тех пор, несмотря на многочисленные попытки, защита ASProtect так никем и не была сломана.
Примечание
Примечание


Отдельные случаи взлома программ, защищенных ASProtect 1.2, известны. Однако, как оказалось, авторы этих программ при реализации защиты не использовали одну из важнейших функций ASProtect— шифрование кода. А без шифрования кода взломать защищенную ASProtect программу не может только начинающий крякер.
ASProtect, естественно, не является бесплатным продуктом, и его цена относительно высока для начинающего шароварщика — 99$. Но в то же время это одно из самых выгодных вложений на этапе начала собственного shareware-проекта.

Демоверсия

Демо-версия

Демо-версия — самый простой для реализации, но одновременно самый неудобный вид защиты. Из программы просто удаляются некоторые фрагменты кода, в результате чего функциональные возможности программы сильно ограничиваются. Такая "урезанная" версия затем выкладывается на Web-сайт, а оплатившим регистрацию пользователям высылается "полная" версия по электронной или обычной почте либо сообщается "скрытый" от посторонних адрес, по которому ее можно скачать.
Достоинство этого варианта в том, что "взломать" саму программу невозможно — ведь программная защита как таковая в ЕХЕ-файле отсутствует. С другой стороны, зарегистрированная версия программы может легко стать доступной всем, а не только тем, кто ее оплатил. Например, кто-нибудь из купивших программу может выложить ее где-нибудь в Интернете или, если зарегистрированная версия не высылается по почте, а скачивается с Web-сервера — опубликовать "секретный" адрес для всеобщего пользования. Самое обидное, что у автора нет никаких шансов узнать, кто именно из пользователей сделал ему такую гадость (если только виновник сам не укажет себя).
Разработчику же распространение программы в виде демо-версии доставляет много хлопот. Например, рассылка зарегистрированных версий по электронной, не говоря уже об обычной, почте сопряжена с большими накладными расходами. Если же пользователи должны загружать "полную" версию с Web-сервера, то автор программы должен постоянно быть готовым к тому, что экземпляр полнофункциональной версии появится в свободном доступе где-нибудь в Сети, а убрать ее оттуда окажется очень непросто. Если разработчик захочет защититься от скачивания "полной" версии незарегистрированными пользователями с помощью опубликованного кем-то "секретного" адреса, ему следует поместить файл с дистрибутивом программы в специальный защищенный паролем каталог на своем сервере. Далее необходимо постоянно добавлять в настройки имена новых пользователей, имеющих право доступа к этому каталогу, а также удалять имена пользователей, опубликовавших свои логины и пароли в Интернете.
Демо-версии не так удобны и для пользователей. Например, для получения полной версии нужно обязательно иметь доступ в сеть Интернет (рассылка "полных" версий обычной почтой встречается очень редко), а это не всегда возможно, ведь дистрибутив программы может быть переписан у знакомых или куплен на CD-ROM со сборником shareware-программ. Кроме того, доступ этот должен быть довольно быстрым, чтобы перекачать из почтового ящика большой файл (кстати, многие почтовые серверы настроены таким образом, что не принимают большие файлы).
Как видите, недостатки этого вида защиты более весомы, чем достоинства, поэтому в shareware демо-версии используются очень мало. Их можно распространять разве что дополнительно к ограниченным по времени или функционально версиям -- включать на CD-ROM, раздавать на выставках — т. е. применять исключительно в рекламных целях.

Функционально ограниченная версия

Функционально ограниченная версия

В отличие от демо-версии, в функционально ограниченной версии возможности "урезаны" не окончательно, а только до регистрации программы. Код, с помощью которого реализуются эти функции, из файлов программы не удален, однако при запуске программа определяет, что она не зарегистрирована, и переходит в "ограниченный" режим работы.
Какие именно функции закрыть — решает, конечно, сам автор программы. Можно, например, запретить сохранение настроек. Графические редакторы обычно при сохранении изображения добавляют в него штамп "Сделано в зарегистрированной версии"; системы управления базами данных работают с ограниченным числом записей или таблиц программы поиска в Интернете, опрашивают только одну-две поисковых системы вместо "полного комплекта" и т. д. Главное — не перестараться с ограничением функций и не превратить свою программу в маломощную поделку, иначе пользователь может просто не оценить полезные свойства программы и решить, что регистрация ему не требуется. Нужно стараться не выкидывать какие-то функции, а ограничивать их мощь, чтобы пользователь попробовал их и хотел бы использовать в полную силу. Это своеобразная "приманка" в охоте за регистрация-ми пользователя. А вот если какие-то функции программы в незарегистрированной версии не доступны полностью и о них только рассказывается в справочной системе, то это является не таким сильным стимулом для пользователей.
Как и в случае с "time-limited''-версией, функциональные ограничения незарегистрированной версии могут быть сняты без оплаты программы, при помощи взлома защиты.
Помимо этих трех основных видов стимулирования пользователей к оплате регистрации, применяется еще и так называемый nag-screen (см. Рисунок 6.1), что в дословном переводе означает "экран ворчания". Это — диалоговое окно, которое появляется чаще всего при запуске программы (а иногда — в момент осуществления ключевых функций, при завершении работы или вообще случайным образом), и сообщающее, что данная версия программы является ознакомительной и что для использования программы требуется регистрация.
Nag-screen ("экран ворчания"; из-за неблагозвучности русского перевода этот термин употребляют в оригинальном виде) — очень эффективный способ стимуляции пользователей, т. к. он является мощным источником раздражения, о чем я уже напоминал в разд. "Не делайте из программы культа" гл. 4. Интересный факт: один из самых популярных мировых архивов бесплатных программ называется NoNags (http://www.nonags.com) чем не прозрачный намек на особую "любовь" пользователей к nag-screen. Некоторые специалисты советуют, от греха подальше, не включать в программы nag-screen, чтобы "не превращать заказчиков в своих врагов". Но, по другому распространенному мнению, если при проектировании защиты программы чувствовать меру и не делать "экраны ворчания" слишком навязчивыми и агрессивными, то можно значительно повысить число своих пользователей.
Nag-screen можно использовать как совместно с каким-либо другим видом защиты (например, в моей программе Actual Startup nag-screen присутствует совместно с тридцатидневным испытательным сроком), так и в качестве единственного "стимулятора" регистрации, как например, в WinZip (см. Рисунок 6.1).

Хакеры и крякеры

Хакеры и крякеры

О них наслышан, наверное, каждый, кто хоть немного интересуется информационными технологиями, а уж компьютерными программами — особенно. Ведь, как известно, именно хакеры и крякеры занимаются взломом защит shareware (и не только) программных продуктов, позволяя кому угодно работать с программами без каких-либо ограничений и, естественно, не платя разработчику никаких денег.
Сначала нужно сказать о том, что настоящие хакеры, которые являются высококлассными специалистами в области компьютерной безопасности, взломом защит программных продуктов не занимаются. Ведь по сравнению с проникновением в компьютерные сети и кражей ценной информации взлом программ, большинство из которых можно купить всего за 20-30$ -слишком мелкое и неприбыльное дело: ведь денег за это не платят! Для взлома защиты программы не нужно того опыта и знаний, которыми обладает квалифицированный хакер, для него это пустяки, на которые не следует отвлекаться.
Примечание
Примечание


Известны немногочисленные случаи, когда взломщикам все-таки поступали заказы от коммерческих предприятий на слом защит очень дорогих — стоимостью в тысячи долларов — программных продуктов. Но цена такого заказа — всего лишь около пятидесяти долларов; что, учитывая небольшой спрос на такой "коммерческий взлом", никак нельзя назвать прибыльным бизнесом.
Взломом защит компьютерных программ занимаются так называемые крякеры. Термин этот произошел от английского "crack", что в данном случае означает (цитата из конференции newsralt.cracks) "любой метод, применяемый для преодоления защиты компьютерной программы, чтобы сделать возможным ее неограниченное использование без платежей ее автору". Вообще говоря, если следовать правильной английской транскрипции, то следовало бы говорить не "крякер", а "крэкер", но последнее по звучанию уж слишком похоже на название печенья "крекер", да и термин "крэк" давно закреплен за одним из видов сильнодействующего наркотика, поэтому вместо этого говорят "кряк".
Что же представляет из себя типичный крякер? Чаще всего это подросток, учащийся в школе, в лучшем случае — на первых курсах ВУЗа. В этом возрасте человеку присущи, помимо всего прочего, два свойства: во-первых, желание самоутвердиться, показать всем, что он "круче", чем более взрослые люди и, во-вторых, отсутствие заботы о заработке денег и содержании семьи. Этим и объясняются действия крякеров, занимающихся делом, которое не приносит им никаких денег. Стремясь самоутвердиться, они идут на все, лишь бы громко заявить: "Именно я сломал эту крутую прогу!" Они взламывают даже FAR, который для жителей бывшего СССР бесплатен, лишь бы доказать свое мнимое превосходство над известным разработчиком. Или, например, не будучи в состоянии вскрыть защиту какой-то программы, покупают по украденному номеру кредитки регистрационный номер, а затем пишут программку, которая "прописывает" в нужное место ЕХЕ-файла этот номер, что не является взломом и не свидетельствует о "победе" крякера. Тем не менее, эта программка выкладывается в Сеть под видом кряка, и ее автор восторженно кричит в news- и Web-конференциях: "Сломал, сломал!" А некоторые даже честно покупают регистрационный код за свои кровные и публикуют его в Интернете, заявляя, что самостоятельно подобрали его и, следовательно, защита в этой программе никудышная. Shareware-авторы шутят, что даже если делать отдельные демо- и полные версии программ, то крякеры, стремясь во что бы то ни стало заявить о взломе, напишут гигантский файл, который будет конвертировать одно в другое, и гордо назовут это "кряком!"
Правда, есть небольшое количество крякеров, которые стараются действовать честно, соблюдая даже некий "кодекс чести". Видимо, это те, кто уже вышел из юношеского возраста, получил хорошую профессию и работу и занимается взломом программ из "спортивного" интереса, изучая на практике различные механизмы защиты. Они с уважением относятся к труду авторов программ и не боятся признавать свои поражения. Так, например, известный крякер Saltine, не сумев-в течение многих недель взломать защиту программы Advanced Disk Catalog (http://www.elcomsoft.com), заявил, что видит единственный способ преодолеть защиту программы — прописать правильный код в тело ЕХЕ-файла (описанный выше нечестный метод псевдовзлома), но не будет этого делать, т. к. это не по-джентльменски. Позже он законно приобрел регистрационный код к Advanced Disk Catalog, но не стал его раздавать всем желающим.
Как бороться с крякерами? Некоторые shareware-разработчики вообще не уверены, что это нужно делать. По наблюдениям многих из них, появление в Интернете кряков к программам не очень сильно сказывается на динамике продаж. Исключение составляют Россия и страны с традиционно низким уровнем жизни: количество регистрации от пользователей из этих государств после появления кряков падает в несколько раз. Если продукт не ориентирован полностью на Россию, то это не принесет больших убытков: число пользователей из этих стран и так невелико. А вот если автор продает бухгалтерскую или банковскую программу — кряки могут нанести серьезный урон бизнесу. Но большинство shareware-авторов не может сказать, что наличие кряков им очень сильно мешает — скорее, отсутствие кряков помогает.
Примечание
Примечание


Существует любопытная точка зрения, что в начале развития программы кряки даже могут оказать услугу ее автору. Взломанная пррграмма быстро распространяется среди большого числа пользователей, а затем, когда выходит версия с более сильной защитой, которую не могут сломать, то привыкшие к программе пользователи вынуждены все-таки оплатить регистрацию. А вот если бы программа с самого начала была снабжена сильной защитой и кряков не существовало бы, все эти пользователи выбрали бы какой-нибудь аналогичный продукт.
Что касается борьбы с крякерами, то самый надежный метод — это сильная защита от взлома. Договориться с крякерами нельзя: можно убедить одного, но договориться со всеми или группой -- невозможно. Закрывать Web-сайты, на которых размещены кряки, тоже бесполезно: их слишком много, да и провайдеры не всегда реагируют на письма с жалобами. Так что лучше всего не зависеть от крякеров или провайдеров, а полагаться только на свои силы, улучшая стойкость защиты собственных shareware-программ.

Кодогенератор к WinZip

Рисунок 6.3. Кодогенератор к WinZip


Нужно сказать, что защита большинства программ взламывается всего за 10—15 минут. Для этого нужно лишь несколько инструментов: дизассемблер, отладчик, еще несколько утилит и хотя бы базовое знание ассемблера (впрочем, без последнего часто можно обойтись).
Вариантов того, как крякер "подбирается" к защите и ломает ее, может быть много. Рассмотрим основные из них.
Чаще всего крякер стремится подобрать к программе регистрационный код, чтобы зарегистрировать на ее себя и опубликовать пароль в Интернете. Тогда сбудется "голубая мечта" крякера - мировая известность: любители "халявы" станут использовать этот пароль при разблокировании своих копий программы, и в диалоговых окнах О программе (About) в графе Registered by будет стоять имя крякера.
Обычно процесс регистрации программы организован так. Пользователь попадает в диалоговое окно Регистрация, нажав соответствующую кнопку в nag-screen или вызвав соответствующий пункт меню. Он вводит в текстовое поле ключ и нажимает кнопку ОК, после чего программа проверяет соответствие введенного ключа некоторым условиям. Эта верификация может быть очень сложной и запутанной, но в конце концов она приходит к закономерному результату, а именно операции сравнения введенного ключа с некоторым образцом или записи в регистр памяти результата верификации.
Дело в том, что все операции, программируемые при помощи языков высокого уровня (C++, Delphi, Basic), используют вызовы функций API Windows или обращения к runtime-библиотекам. Все эти функции легко отслеживаются отладчиком. Если же программа использует динамические ключи, то перед сравнением введенного регистрационного номера она по также введенному имени пользователя генерирует "правильный" ключ, который замечательно виден при помощи отладчика. Однажды я почувствовал всю эффективность этого метода на себе. Когда я впервые написал подобную защиту к одной из своих программ, то отослал эту программу знакомому программисту, который иногда, ради развлечения, взламывал различные shareware-продукты. Он перезвонил через десять минут и сообщил правильный регистрационный код, а заодно рассказал, что код ему в отладчик "выложила" сама моя программа.
Если же автор программы хорошо потрудился над защитой и пароль подобрать невозможно, то крякер с помощью дизассемблера и отладчика находит в программе место, где определяется, зарегистрирована ли программа или нет, модифицирует значение, возвращаемое проверочной функцией (например, безусловный переход меняется на условный). После этого пишется маленькая программа, которая делает то же самое, но не в памяти, а в самом ЕХЕ-файле (это и есть патч).
Кроме того, можно сделать и так: "вырезать" из ЕХЕ-файла программы код, который отвечает за генерацию ключей, и вставить его в маленькую программку, которая будет создавать правильные ключи для всех желающих, т. е. будет кодогенератором.
Если в программе применяется ограничение по времени, то это открывает крякерам дополнительную лазейку в защите. Заключается она в том, что время первого запуска (или количество запусков) хранится во внешнем файле (INI или системном реестре). С помощью бесплатных программ File Monitor и Registry Monitor, которые можно скачать с сайта www.sysinternals.com, легко выяснить, к каким ключам в реестре и каким файлам обращается программа, какие данные туда пишет и какие читает. А дальше не составит никакого труда найти соответствующие вызовы в программе при помощи отладчика и дизассемблера.
Естественно, такая ситуация авторов shareware-программ не устраивает. Они стремятся усилить защиту, но, увы, некоторые из них выбирают не совсем правильный путь.
Кому-то кажется хорошим вариантом привязка к компьютеру. Из программы очень легко получить какие-то данные о системе (например, серийный номер жесткого диска), и поэтому в воображении программиста быстро вырисовывается такая схема: пользователь высылает автору эти данные, который, после подтверждения оплаты, вычисляет на их основе регистрационный код и высылает его пользователю. В программе закодирован тот же самый алгоритм, происходит сверка и — готово. Если же код попадет в чужие руки, то на других компьютерах он работать не будет.
Тем не менее этот способ обычно доставляет больше неудобств зарегистрированным пользователям, чем крякерам, т. к. сломать такую защиту очень легко: здесь работает тот же фокус с патчами, "препарирующими" проверочные функции. А вот честному пользователю придется изрядно помучиться, если он поменяет компьютер...
Та же ситуация возникает с аппаратными ключами, подключаемыми к параллельному порту компьютера (типа HASP). Ведь проверка все равно осуществляется в программе, а следовательно, и эта защита может быть легко взломана. Так и есть - "патчи" существуют ко многим системам защиты при помощи аппаратных ключей. При этом эти ключи доставляют много хлопот как разработчикам (высокая стоимость — нужно обеспечить доставку ключей заказчикам), так и пользователям. Например, при подключении к параллельному порту аппаратного ключа экономического Project Expert 7.0 подключаемый к этому же порту имеющийся в нашем офисе сканер Hewlett-Packard перестает нормально работать.
Существует достаточно много программных продуктов, которые позволяют авторам реализовать защиту для своих программ. Это - IntelliSecure R2, TimeLock, ShareLock, CrypKey, StopCopy, Unlocker, RSAgent32, Software Licensing System, ZipLock, BuyOnet, UnBox, Vbox. Но, к сожалению, все они давно уже вскрыты (см. http://www.fravia.org), и воспользоваться ими — все равно, что приложить к программе подробную инструкцию по ее взлому.

Напоминание о регистрации архиватора WinZip

Рисунок 6.1. Напоминание о регистрации архиватора WinZip


Однако нужно вспомнить, что деньги возникли когда-то как средство обмена одной материальной ценности на другую. Сейчас их можно потратить и на удовлетворение духовных потребностей — например, сходить в театр, -но суть от этого не меняется. Потратив деньги, мы что-нибудь получаем взамен. Исключение — меценатство.
Но что получит человек взамен, если ему предлагают потратить 20$, заплатив за shareware-программу, в которой нет никаких ограничений, никакой защиты? Ничего. Кто-то скажет: "Программу". Но программа у пользователя уже есть. Вот и выходит, что автор просит у него деньги, взамен ничего не давая.
Shareware с ознакомительной версией, в которой есть ограничения, в этом смысле более корректно. Пользователь покупает за свои деньги именно программу, точнее возможность нормально ее использовать. А вот фактически бесплатная программа, имеющая статус shareware, ставит пользователя в двусмысленное положение. Здесь могут работать только меценатские мотивы, желание материально поддержать разработчика программы. Но меценаты — прослойка достаточно обеспеченных людей, и деньги они тратят, как правило, на социальные и прочие общественно полезные проекты. Разработка программ к ним не относится.
Что касается WinZip... Да, незарегистрированная версия программы не имеет никаких ограничений, кроме напоминания о необходимости регистрации. Даже это напоминание можно убрать совершенно бесплатно — генератор, который создает коды для "регистрации", написан уже очень давно, а разработчики WinZip не меняют механизм проверки кодов при выходе новых версий. И, тем не менее, только через одного из дистрибьюторов WinZip продается на сумму более чем сто тысяч долларов в месяц.
Но при этом нужно помнить, что WinZip, как говорится, "попал в струю" -тогда, в начале 1996 года, Windows 95 и Интернет набрали уже большую популярность, но средств удобной работы с файлами и архивирования не было — альтернативой Norton Commander и pkzip был Проводник Windows, только крайне неудобный. И тут, когда существовала неудовлетворенная потребность работать с архивами не из командной строки, а из графического интерфейса пользователя (прежде всего у десятков миллионов "чайников", только что купивших Windows 95), появился WinZip во всей красе. Пусть не самый удобный, но зато понятный и, самое главное — это было настоящее GUI application for Windows 95! Конечно же, WinZip распространился очень широко.
Но это исключение из правил, такое же исключение, как бесплатный мультимедиа-плейер WinAmp, который, даже будучи несколько лет назад shareware-программой ценой в десять долларов, не имел никаких ограничений. Эти программы были пионерами и распространились чрезвычайно широко. Здесь (в этом случае) сработала такая маркетинговая схема: сначала вы имеете небольшое количество регистрации, но затем, после того как продукт распространится максимально широко, даже небольшой, по сравнению с числом пользователей, процент продаж приносит вам очень много денег.
Но, появись эти программы сегодня, когда рынок насыщен ZIP-архиваторами и мультимедиа-плейерами — вряд ли они стали бы такими же популярными и прибыльными, как тогда. Поэтому не нужно полагаться на такую схему. Дайте пользователю почувствовать, что взамен своих денег он получил что-то вполне определенное.

Напоминание в текстовом редакторе

Рисунок 6.2. Напоминание в текстовом редакторе UltraEdit-32, что она будет работать еще 42 дня


В чем же считать "испытательный срок" - в днях или запусках? Чаще всего отсчет ведется в днях. Тридцать дней — стандартная продолжительность этого срока, указанная в Уставе Ассоциации профессионалов shareware. Если же выбрать для отсчета запуски, то может получиться ситуация, когда пользователь еще не успел изучить работу с программой, а количество запусков уже превысило лимит незарегистрированной версии и программа отказывается работать — ведь невозможно предугадать, с какой интенсивностью программа будет использоваться. Мне как-то попалась "звонилка" (утилита для дозвона к интернет-провайдеру), "испытательный срок" которой исчислялся всего пятнадцатью запусками. Программа работала не очень корректно, из-за чего приходилось ее постоянно перезапускать, и когда милосердно отпущенные мне 15 запусков прошли, я так и не успел с ней разобраться. Естественно, о регистрации, которую настойчиво стала требовать программа, не могло быть и речи.
Сложность реализации этого вида защиты состоит в том, что ограничение работы по времени может быть снято и, таким образом, в руках пользователя, не заплатившего за программу ни копейки, окажется полнофункциональная версия.

Ограниченная по времени версия

Ограниченная по времени версия

Ограниченная по времени (time-limited) версия — более распространенный вариант, хотя и более сложный для реализации. Незарегистрированная версия после установки на компьютере пользователя работает какой-то период времени, исчисляемый либо в днях (обычно 30 дней), либо в запусках (Рисунок 6.2). По истечении этого срока программа прекращает работать, выводя после запуска сообщение об окончании "trial period" и необходимости зарегистрироваться.

Реализация защиты и ее взлом

Реализация защиты и ее взлом

Как видно из разд. "Виды защиты" этой главы, сегодня для shareware-рынка актуальны два типа защиты программ: ограничение по времени работы и ограничение по функциям. О демо-версиях говорить особенно не нужно, т. к. это очень простой и одновременно очень непопулярный вариант реализации защиты shareware-программ.
При ограничении по времени программа хранит в каком-нибудь файле дату первого запуска и при очередном запуске проверяет, сколько дней осталось до окончания ознакомительного срока. Если ограничение по времени исчисляется в количестве запусков, то программа при первом запуске записывает в файл начальное значение счетчика и при каждом последующем запуске это значение увеличивается па единицу и проверяется, не превышен ли лимит на число запусков, установленный автором. В случае положительного результата (ознакомительный срок закончен) программа перестает работать.
Что касается ограничения по функциям, то здесь тоже не нужно много объяснять. При старте программа проверяет, зарегистрирована ли она, и в зависимости от этого решает, разблокировать ли недоступные для незарегистрированных пользователей функции или нет.
В обоих случаях — при временном и функциональном ограничении — программа разблокируется посредством ввода регистрационного ключа. Эти ключи бывают двух видов: статические, которые заранее определены автором программы, и динамические, т. е. генерируемые в зависимости от каких-то исходных данных — чаще всего имени пользователя.
Как только программа появляется на shareware-рынке, она почти сразу привлекает внимание взломщиков, которые, немного потрудясь, выпускают к программе кряки.
Кряки делятся на две основные группы: патчи и кодогенераторы. Патч (patch) — это небольшая программка, которая модифицирует один или несколько файлов исходной программы таким образом, чтобы отключить защиту. Кодогенератор (keygen) — также небольшая программа, которая генерирует регистрационные ключи, введя которые можно разблокировать ту или иную shareware-программу (Рисунок 6.3). Иногда крякеры публикуют в Интернете не кодогенератор, а просто подобранный регистрационный номер (serial number, reg. code или просто serial code).

Усиление защиты

Усиление защиты

А теперь — несколько рекомендаций и советов, которые могут помочь повысить стойкость защиты shareware-программы перед атаками крякеров. Часть из них приводится на сайте www.fravia.org, на котором опубликовано много статей о взломе компьютерных программ и систем защиты, часть — рассказана опытными разработчиками shareware-программ, которые противостоят крякерам не один год.

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

Очень хороший шаг — упаковать- ЕХЕ-файл программы "интеллектуальным" упаковщиком наподобие AsPack (http://www.aspack.com). Применение такого упаковщика может очень сильно защитить программу, значительно затрудняя анализ структуры кода крякером.

Храните важную информацию (например, дату первого запуска, количество запусков) в файле, к которому и так происходит много обращений. В этом случае чтение секретной информации "затеряется" на фоне остальных обращений, и это будет не очень легко обнаружить при использовании вышеупомянутой утилиты File Monitor.

Сохраняйте пароли в каком-либо "необычном" месте, например в полях свойств базы данных.

Сохраняйте пароль в нескольких местах одновременно.

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

Развитие предыдущего совета: пусть регистрационный код удовлетворяет нескольким условиям, которые проверяются не сразу, а с интервалом в несколько дней. Таким образом, крякер подбирает код, который удовлетворяет первому условию и "успокаивается" на этом. Главное — поместить фрагменты кода, которые отвечают за проверку разных условий, в разные части программы, чтобы крякер при взломе "первого рубежа" не догадался о втором.

Совет, выполнение которого будет особенно эффективным в сочетании с советами 6 и 7 — не сообщать о том, что введен неправильный код, "открытым текстом". Лучше выводить сообщение о критической ошибке и просьбу связаться с разработчиком. Пользователи будут думать, что это ошибка в программе, и будут писать автору об этом. И тут уже будет ясно, кто пользуется программой законно (например, просто ошибся при вводе кода), а кто установил кряк. Последним можно предлагать оплатить регистрацию, чтобы избавиться от досадной "ошибки".

Делайте небольшую (продолжительностью 1—2 секунды) при возврате результата в ответ на введенный пользователем пароль. Это сделает невозможным подбор правильного регистрационного кода путем прямого перебора вариантов при помощи специально написанной программы.

Делайте свои регистрационные коды очень длинными и сложными, чтобы простой перебор вариантов занял у крякера несколько тысяч лет (если, конечно, у него нет дома суперкомпьютера).

Вычисляйте системную дату не при помощи стандартных функций, а определяйте ее по дате изменения файлов system.dat, system.а0 и bootlog.txt.

Не нужно давать осмысленные имена важным файлам и функциям, например, IsValidSerialNum.

Если вы используете статические ключи, то делайте их похожими на программный код или названия функций (например, "73AF" или "GetWindowText"). Это действительно очень эффективно и сбивает с толку многих крякеров.

Не используйте жестко "прошитые" в программу строки текста для уведомления пользователя о том, что пароль правильный (или неправильный). Это первое, на что смотрит крякер. Генерируйте эти строки динамически или используйте хотя бы самое простое шифрование.

Используйте "перекрестные" проверки CRC-кодов ваших ЕХЕ- и DLL-файлов.

И, наконец, никогда и никому не рассказывайте, как устроена ваша защита.

Замечание 1
Замечание 1


Любая защита, которую даже теоретически нельзя сломать, все-таки ломается, если к злоумышленнику попадает правильный регистрационный ключ (например, в результате покупки по украденному номеру кредитной карточки). Здесь — полная аналогия с бытом: любой самый совершенный замок откроется, если иметь ключ. Поэтому нужно не терять бдительности и помнить, что самая нерушимая защита — еще не решение проблемы кряков.
Надеюсь, эти советы помогут вам построить очень сложную и даже невозможную для взлома защиту. А если вы все-таки не уверены в своих силах -читайте следующий раздел.

Виды защиты

Виды защиты

Существует три основных типа защиты shareware-программ: демо-версия, ограниченная по времени версия и функционально ограниченная версия.

Зачем нужна защита

Зачем нужна защита

Наличие защиты в shareware-программах обусловлено самим принципом shareware: "Попробуй, прежде чем купить". Разработчик предоставляет свою программу для тестирования, а если программа понравится, то пользователь может оплатить регистрацию. Если бы распространение копий программы строго контролировалось, а все пользователи были известны, что называется, "в лицо", с получением денег за программу не было бы почти никаких проблем. Но shareware-программы скачиваются по Интернету огромным числом людей, находящихся от автора на большом расстоянии. Для того чтобы стимулировать пользователей оплачивать регистрацию, программисты включают в программу всевозможные ограничения, отличающие незарегистрированную версию от зарегистрированной.
В самом начале развития shareware-индустрии, во времена расцвета PC-Talk и PC-File (см. разд. "История shareware" гл. 1), условно-бесплатные программы не имели никаких ограничений. В документации автор просто указывал, что пользователи, если программа им понравится, могут прислать ему определенную сумму денег.
С появлением множества других shareware программ эта схема быстро потеряла свою эффективность. Многие разработчики на своем опыте убедились, что при отсутствии защиты программу покупают очень мало, зато при вставке в программу хотя бы экрана, напоминающего о необходимости регистрации продукта, число зарегистрированных пользователей резко увеличивается. Защиту не заменит даже то, что вместо денег за регистрацию требуется прислать всего лишь заполненную анкету: пользователей, действительно сделавших это, будут единицы. У пользователя должен быть реальный стимул зарегистрировать программу, одного лишь сообщения о ее статусе shareware в лицензионном соглашении недостаточно.
Несмотря на это, начинающие шароварщики до сих пор пытаются начать продавать свою программу без защиты, лишь с напоминанием о необходимости зарегистрироваться, указанным не в самом заметном месте — в справочной системе, файле readme.txt или диалоговом окне О программе. Многих вдохновляет пример WinZip, который распространяется в виде полнофункциональной версии и всего лишь напоминает о необходимости зарегистрироваться (Рисунок 6.1).

Учебник по созданию shareware программ

Adobe Acrobat

Adobe Acrobat

Adobe Acrobat (Рисунок 7.5) был разработан компанией Adobe как более эффективная альтернатива HTML. Как известно, основное достоинство HTML -независимость платформы: HTML-документ можно прочитать на компьютере с любой операционной системой, главное, чтобы было установлено средство просмотра HTML-файлов. Однако при этом документ выглядит на разных компьютерах по-разному: это зависит от установленных на компьютере пользователя шрифтов и других системных настроек, а также названия и версии средства просмотра HTML. Как известно, страница, отлично отображаемая в Internet Explorer, может вообще не показываться в Netscape Navigator, и наоборот. А уж многочисленные мелкие, но раздражающие искажения, которые возникают при просмотре страниц в разных браузерах, давно стали предметом горячих споров в интернет-конференциях.

Документация на Webсайте

Документация на Web-сайте

Некоторые разработчики слишком буквально понимают термин "online help", который на самом деле обозначает справочную систему в электронном, а не печатном, виде. Поэтому при нажатии клавиши или вызова меню Help в их программе, запускается установленный в системе интернет-браузер и загружает... раздел "Справка" с Web-сайта разработчика программы!
Это пример того, как не следует делать документацию. Ведь у пользователя она всегда должна быть под рукой, а размещение справочной системы в
Интернете часто приводит к тому, что пользователь не может получить к ней доступ тогда, когда ему требуется помощь. Например, пользователь может скачать программу дома, а использовать ее на работе, где по каким-либо причинам выход в Интернет может отсутствовать, и наоборот. И даже если доступ в Интернет на компьютере имеется, то домашнему пользователю для выяснения каких-то деталей относительно работы с программой нужно дозваниваться до интернет-провайдера, что при частых обращениях к справочной системе очень раздражает. Кроме того, скорость доступа к справочной системе, размещенной в Сети, не сравнима со скоростью чтения файла Справки с жесткого диска компьютера. И наконец, не нужно забывать, что за пользование Интернетом провайдеры берут деньги, а значит, доступ к справочной системе программы тоже будет платным!

HTML Help

HTML Help

HTML Help (Рисунок 7.3) — новый формат файлов для документации, разработанный Microsoft как замена "старичку" WinHelp. Первой операционной системой, в которую был включен HTML Help, стала Windows 98.

Как писать документацию

Как писать документацию

Прежде чем писать документацию, нужно определить ее будущую структуру, т. е. из каких разделов она будет состоять.
На выбор структуры справочной системы shareware-программы влияют два фактора. Во-первых, разработчик пишет не просто описание программы, а систему помощи, которую пользователи будут читать чаще всего при возникновении каких-либо проблем при работе программой, а не от праздного любопытства. Во-вторых, автор программы разрабатывает ее не "для себя", а для продажи на shareware-рынке.
Для решения первой задачи, т. е. помощи пользователям в преодолении различных проблем с освоением и работой с программой, следует включить в документацию раздел Introduction (Введение), в котором рассказать о назначении программы, а также гораздо более объемный раздел Description (Описание), в котором дать описание меню, диалоговых окон и прочих элементов программы.
Считается, что для составления текста справочных систем применяются два подхода: либо вы рассказываете для чего что-то предназначено, либо о том, как что-то сделать (wanting to know vs. wanting to do). Однако, на мой взгляд, при определении структуры и содержания Справки эти два подхода нужно объединить и добавить в документацию раздел How to... (Как сделать...). Дело в том, что все вопросы, с которыми пользователи обращаются к справочной системе, можно разделить на две группы: "Что означает этот элемент (меню, кнопка, флажок и т. п.)?" и "Как мне сделать то-то (отфильтровать данные, переформатировать текст, настроить параметры и т. п.)". Если же в документации будет только описание элементов программы, то на вопросы категории "Как мне сделать то-то?" найти ответ для не очень опытных пользователей будет гораздо сложнее.
Кроме того, нужно создать в Справке раздел Technical Support (Техническая поддержка), где указать адреса e-mail, по которым пользователи могут задать свои вопросы, а также привести ссылки на источники дополнительной информации о программе, если они имеются: форум на Web-сайте, список ответов на часто задаваемые вопросы (FAQ) и т. п.
Для отражения в документации принадлежности программы к shareware-программы следует создать раздел Registration (Регистрация), где завести подразделы, в которых рассказать о цене программы, дать ссылки на Web-сайты компаний-регистраторов, указать преимущества статуса зарегистрированного пользователя (например, бесплатные обновления, отсутствие ограничений функциональности программы) и другую информацию по этой теме.
Если у вас имеется несколько shareware-продуктов, то удачным шагом будет создание еще одного раздела: Our products (Наши продукты), где будет дана информация о ваших других программах и ссылки на их Web-страницы и файлы для загрузки. Эта информация будет полезна для тех пользователей, которые получили дистрибутив программы не с Web-сайта разработчика (а, например, скачали его с сервера интернет-архива или купили в составе сборника shareware-программ на CD-ROM) и ничего не знают о других продуктах этого же автора. Очень часто бывает, что люди начинают интересоваться ими, скачивают, тестируют и — оплачивают регистрацию.
При написании текста важно помнить, что справочная система, которую вы пишете, предназначается не для специалистов, а для пользователей, и поэтому писать нужно на простом и понятном языке. Не надо замахиваться на труд энциклопедических объемов: давайте краткую, но при этом точную информацию, с помощью которой пользователи могут получить ответы на свои вопросы.
Для российских программистов, составляющих справочную систему, большая проблема — английский язык. Одно дело меню и небольшие информационные сообщения в интерфейсе программы, здесь больших сложностей нет (хотя в некоторых российских программах даже в меню и диалоговых окнах встречаются ошибки). Но вот документация... Здесь требуется более глубокое знание языка. Грамматические и орфографические ошибки очень сильно портят впечатление обо всем продукте, и это приводит не только к отрицательным обзорам в журналах и на Web-сайтах, но и существенно снижает объем продаж. Качественный английский язык документации -одно из самых главных требований к серьезному shareware-продукту.
Самый простой вариант, на котором останавливается большинство авторов, — это перевод текста на английский язык знакомым или нанятым за плату переводчиком. Лучше всего будет после этого разместить на Web-сайте программ объявление с предложением для пользователей из Великобритании или США проверить имеющийся у вас перевод документации в обмен на бесплатную регистрацию копии вашей программы. Человек, для которого английский язык является родным, сможет наиболее эффективно довести качество перевода до хорошего уровня.
Некоторые начинающие разработчики, стараясь сильно не занимать себя проблемой написания качественной справочной системы на хорошем английском языке, проступают так: находят аналогичный продукт и почти полностью копируют его документацию, заменяя разве что название программы и ссылки на сайт разработчика. Хотя идея получить с минимальными затратами времени и сил профессиональную англоязычную справочную систему очень заманчива, делать этого ни в коем случае нельзя. Это обычное нарушение авторских прав, иными словами — плагиат. Рано или поздно это все равно раскроется, восстановить потерянную репутацию в глазах пользователей, обозревателей, работников shareware-сервисов будет очень трудно.
Один из российских разработчиков shareware рассказывал такую историю. Некий иностранный программист, продававший конкурирующую программу (утилита для общения в локальной сети), украл у него полностью всю документацию, включив ее в дистрибутив своего продукта. Однако он забыл исправить адреса, на которые указывали ссылки в Справке: текст на них был изменен, но вели они по-прежнему на оригинальный Web-сайт. Пострадавший от плагиата смотрел на это сквозь пальцы, т. к. его программа продавалась очень хорошо, и мелкий конкурент его не особенно волновал. Но однажды он получил письмо от пользователя, который интересовался, почему ссылка из документации программы, которую он недавно приобрел, ведет на совсем другой сайт, где продается вроде бы похожий продукт. "Это что, новая версия?" - спрашивал удивленный пользователь. Наш соотечественник объяснил ему ситуацию и предложил этому человеку, т. к. он уже купил программу плагиатора, скидку (в 20%) при переходе на свой продукт. Пользователь согласился: воров никто не уважает.

Контекстная справка

Контекстная справка

Пользователи обычно не любят запускать справочную систему из меню Help (Справка), т. к. в этом случае приходится самостоятельно искать нужный раздел Справки. Зато они вполне готовы нажать клавишу в каком-либо диалоговом окне или воспользоваться кнопкой с вопросом ("What's This?" "Что это такое?"), чтобы получить пояснение именно по текущей ситуации.
Разработка контекстной системы помощи — это вопрос, затрагивающий и тему построения интерфейсов. Есть, например, даже такой принцип: "Предлагайте помощь". Для того чтобы пользователь программы при работе с ней чувствовал себя человеком и видел, что автор хочет сделать его работу наиболее простой и понятной, нужно позаботиться о том, чтобы программа всегда могла бы пояснить пользователю порядок действий в текущий момент.
Конечно, не нужно предлагать помощь также навязчиво, как известная скрепка-помощник из Microsoft Office (Рисунок 7.6). Созданный для придания "ящику" большей интеллектуальности и, так сказать, человечности, Помощник заслужил неоднозначные отзывы. У некоторых пользователей, которые не смогли понять, как отключить Помощника, скачущая по экрану скрепка даже вызывала истерику.

NetHelp — аналог HTML Help от компании Netscape

Рисунок 7.4. NetHelp — аналог HTML Help от компании Netscape


Существует также несколько аналогичных форматов HTML Help, также использующих язык HTML для описания структуры справочной системы: NetHelp от компании Netscape (Рисунок 7.4), WebHelp от Oracle и, наконец, JavaHelp от Sun. Однако эти форматы не получили сколько-нибудь широкого распространения и используются в основном в продуктах соответствующих фирм-разработчиков.

Один из самых крупных интернетархивов

Рисунок 7.1. Один из самых крупных интернет-архивов ПО — Tucows — не принимает программы без документации

Печатная документация

Печатная документация

Документация, отпечатанная типографским способом, столь привычная для коммерческих программных продуктов, для shareware — явление очень редкое. Если она все-таки имеется, то обычно продается отдельно и за довольно большие деньги, порой превышающие стоимость самой программы.

Перспектива

Перспектива

Здесь, конечно же, все козыри у HTML Help, который создан как замена WinHelp и усиленно продвигается Microsoft. Нет сомнений, что в будущем имеющие недостатки HTML Help будут устранены, а функциональные возможности — еще больше расширены. Более того, я думаю, что HTML Help изменит существующий подход к созданию документации и, возможно, серьезно поменяет вид и структуру справочных систем. Очень важно и то, что хорошо составленная и грамотно оформленная документация в формате HTML Help производит благоприятное впечатление на обозревателей компьютерных журналов и архивов. Какой же формат выбрать? Каждый, конечно же, решает сам. Лично я пока остановился на WinHelp. Меня привлекает его надежность (независимость от установленного в системе интернет-браузера и стопроцентная его поддержка во всех версиях существующих Windows), высокая скорость работы, хорошие возможности для создания файлов Справки (пока я не чувствую потребности в Dynamic HTML или JavaScript). To, что WinHelp - уже "старичок" по сравнению с модным HTML Help, на мой взгляд, даже плюс: пользователи уже привыкли к нему и работают с такими справочными системами без проблем.
На самом деле не нужно бояться сделать неправильный выбор и предпочесть "не тот" формат документации. Большинство современных программ по разработке справочных систем (см. разд. "Средства создания документации" данной главы) позволяют сохранять файлы как в формате WinHelp, так и HTML Help (а некоторые поддерживают еще большее число форматов). Поэтому в будущем можно без особых трудностей перейти с одного формата на другой. При желании можно даже поставлять в дистрибутиве программы документацию в обоих вариантах: WinHelp и HTML Help, позволяя пользователю самому выбрать предпочтительный формат. Программ с таким оригинальным решением проблемы выбора формата документации я пока не встречал, но, если бы это случилось, то лично на меня, в том числе и как на пользователя, это произвело бы большое впечатление.

Помощник из Microsoft Office

Рисунок 7.6. Помощник из Microsoft Office


Лучше сосредоточить свои усилия в другом направлении. Например, все диалоговые окна программы должны содержать кнопку Help (Справка). Это касается не только диалогов, в которых непосредственно осуществляется и ввод данных (например, окон Настройка), но и информационных диалогов, например, диагностических или сообщений об ошибках.
Так как при появлении на экране диалога у пользователя чаще всего появляется вопрос "Почему?", то вполне стандартным приемом является дополнение текста диалога подсказкой: "For help, press F1" (Для справки, нажмите F1). Использование такого предложения помощи полезно не только в диалогах, но и в обычных окнах, где оно выводится в строку состояния сразу после старта программы. И даже если пользователю в настоящий момент справка не нужна, такое ненавязчивое предложение помощи как бы сигнализирует, что программа, в случае необходимости, может дать пояснения.
Нужно помнить, что контекстная помощь — это не только разделы в файле Справки, которые вызываются из соответствующих частей программы. К контекстной помощи также относятся подсказки, появляющиеся в строке состояния, когда пользователь ведет мышью по пунктам меню. Не нужно забывать и про всплывающие подсказки к кнопкам на панелях инструментов и секциям строки состояния.
С контекстной справкой связан интересный случай, который еще раз напомнил не только составителям документации, но и проектировщикам интерфейсов о том, что с пользователями нужно обращаться максимально вежливо и учтиво. Как рассказал один из посетителей Web-сайта iarchitect.com, однажды справочная система инженерного пакета AutoCAD Mechanical от фирмы Autodesk показала вот такое сообщение.
Кому-то это сообщение - "Нажми здесь, идиот" -- может показаться смешным, но на самом деле оно выражает скорее пренебрежительное отношение к пользователю. Как оказалось, человек, ответственный за этот участок программы, пошутил, полагая, что это сообщение не увидит ни один пользователь. Но его работодатель, компания Autodesk, не оценила его чувство юмора: служащий был уволен, а тысячам заказчиков компании были разосланы письма с извинениями.

Пример документации в формате Adobe Acrobat

Рисунок 7.5. Пример документации в формате Adobe Acrobat


Adobe Acrobat, пo замыслу разработчиков, и предназначен для решения этой проблемы: документы в этом формате можно просмотреть не только в любой операционной системе (существуют версии этого продукта для Windows, MacOS и Unix), но именно в том виде, как задумывал его автор. При этом пользователю доступны гораздо большие возможности, чем предоставляют WinHelp или HTML Help: можно распечатать весь документ целиком, масштабировать не только текст, но и графику, поворачивать страницы на 90 градусов и др.
Adobe Acrobat (расширение файлов — pdf) очень популярен как формат для хранения документации к различному компьютерному "железу": материнским платам, видеокартам, акустическим системам и т. п. Среди разработчиков программного обеспечения (особенно шароварщиков) он не очень распространен, хотя некоторые крупные компании (например, McAfee, Symantec) используют его для подготовки справочных систем к своим продуктам.
На мой взгляд, минусы Adobe Acrobat, которые препятствуют его использованию в качестве средства организации Справки для shareware-программ, следующие:

отсутствие функций Windows API, с помощью которых можно вызывать отдельные разделы документации в формате Adobe Acrobat, обеспечивая, таким образом, контекстную Справку к различным элементам программы;

недостаточная распространенность программы Adobe Acrobat Reader, которая требуется для просмотра PDF-файлов. Несмотря на то, что Reader — бесплатный продукт, он установлен далеко не на каждом компьютере, и было бы неэтично заставлять пользователя скачивать его дистрибутив (около 10 Мбайт) лишь для того, чтобы просмотреть справочную систему небольшой shareware-программы. А вот поставщики комплектующих для компьютеров, прикладывая к своим изделиям диск CD-ROM с документацией в формате Acrobat, без проблем могут включить на этот же диск и инсталлятор Acrobat Reader. Что касается поддержки HTML Help, то браузер Internet Explorer уже давно поставляется вместе с Windows, а о WinHelp и говорить не нужно: файл winhelp.exe прочно обосновался в дистрибутиве системы;

довольно высокая стоимость пакета для создания PDF-файлов, которое называется так же, как и сам формат — Adobe Acrobat, а также средств для конвертации PDF независимых разработчиков. А вот для создания справочных систем в форматах WinHelp и HTML Help можно обойтись бесплатными продуктами.

Пример справочной системы в формате HTML Help

Рисунок 7.3. Пример справочной системы в формате HTML Help


HTML Help отражает новую политику Microsoft: во-первых, полная интеграция приложений с Интернетом, во-вторых, использование HTML как основного формата файлов: в процессе подготовки справочной системы разработчик должен сохранять текст в формате HTML, а для просмотра получившегося после компиляции СНМ-файла требуется, чтобы на компьютере пользователя был установлен интернет-браузер Microsoft Internet Explorer 3.02 или выше. Впрочем, некоторые специалисты восприняли появление HTML Help скептически: разработка нового формата, по их мнению, была обусловлена не заботой о пользователях, а желанием Microsoft добиться перелома в так называемой "войне браузеров" и добиться преимущества над основным конкурентом своего Internet Explorer — Netscape Navigator (в то время большая часть рынка интернет-браузеров принадлежала "Навигатору").
В HTML Help устранены недостатки предшественника: можно распечатать не только текущий раздел, но и все его подразделы; вся справочная система находится не в пяти, а всего одном файле с расширением chm. Правда, исчезла полнотекстовая индексация файла, и возможности поиска в Справке несколько снизились.
Примечание
Примечание


Некоторые авторы прикладывают в качестве документации к своим программам просто несколько HTML-файлов, без компиляции их в СНМ-файл формата HTML Help. Это, конечно, не может являться полноценной заменой HTML Help: скорее, это некоторый промежуточный вариант между текстовым файлом readme.txt и "настоящей" Справкой.

Пример справочной системы в формате WinHelp

Рисунок 7.2. Пример справочной системы в формате WinHelp


У WinHelp очень мало недостатков. Один из самых серьезных — невозможность печати всего справочного файла целиком, в результате чего приходится посылать на принтер каждый раздел отдельно. Другой минус — то, что каждый экземпляр справочной системы может состоять из пяти файлов (табл. 7.1): не слишком изящный способ организации документации.
Таблица 7.1. Файлы справочной системы в формате WinHelp

	Тип файла	Назначение
	HLP CNT GID FTS FTG	Основной текст справочной системы Оглавление справочной системы Конфигурационный файл Полнотекстовый индекс Группы для полнотекстового индекса

В целом формат WinHelp достаточно удобен и универсален, и поэтому, несмотря на появление нового формата — HTML Help, активно продвигаемого Microsoft, WinHelp по-прежнему очень популярен среди разработчиков справочных систем.

Скорость работы

Скорость работы

Как уже упоминалось, для чтения СНМ-файлов формата HTML Help используется браузер Internet Explorer, который вызывает много нареканий за высокие требования к системным ресурсам и относительно медленную работу. Действительно, при вызове Справки в формате HTML Help, особенно имеющей довольно большой объем, задержки в работе по сравнению с WinHelp хорошо заметны.

Средства создания документации

Средства создания документации

Сделать справочную систему не так уж сложно. Для создания справочных файлов в формате WiuHelp можно использовать Microsoft Word, а также бесплатный компилятор Help Workshop, который можно скачать с сайта Microsoft или взять из дистрибутивов многих средств разработки приложений (Visual C++, Visual Basic, Delphi) или специализированных продуктов для создания справочных файлов. Для подготовки Справки в формате HTML Help требуется любая программа для редактирования HTML (от простейшего Блокнота до навороченного FrontPage 2000) и, опять же, компилятор.
Однако разрабатывать справочные системы традиционными средствами не очень удобно. В частности, в этом случае не так уж легко отслеживать структуру готовящегося файла Справки и синхронизировать ее с RTF и HTML-файлами. Кроме того, при написании WinHelp-документации в редакторе Microsoft Word нужно запоминать различные спецсимволы и стили выделения текста, которыми описывается структура и форматирование файла Справки. А это, надо сказать, посложнее, чем синтаксис HTML.
Конечно, продуктов независимых разработчиков, которые существенно облегчают задачу создания справочных систем, существует очень много, от самых простых до целых интегрированных сред разработки. Самые простые не представляют большого интереса, т. к. они обладают довольно слабыми возможностями и при этом неудобны для использования; единственное их достоинство — бесплатность или очень низкая цена. Лучше обратить внимание на продукты более высокого класса, которые позволяют очень эффективно решать задачу создания справочных систем.
Продуктов в этой группе также немало. Самые известные из них — AnetHelp-Tool (http://www.anetsoft.com), Help & Manual (http://www.ec-software.com), Windows Help Designer (http://www.winhelp.gr), HelpMagician Pro (http:// www.helpmagician.com), RoboHelp Office (http://www.bluesky.com). Интерфейс всех этих программ организован примерно одинаково. Слева находится окно, в котором в древовидной форме отображается структура файла справки; справа - окно WYSIWYG-редактора в стиле Microsoft Word.
С помощью окна слева можно легко переходить от одного раздела справки к другому, создавать новые разделы, переименовывать и удалять их. Встроенный редактор обычно обеспечивает все необходимые функции по обработке содержания справочной системы: добавление перекрестных ссылок, форматирование текста и абзацев, вставку таблиц и списков, добавление специальных символов и командных кнопок, вставку изображений, звуков, анимации и других объектов. Конечно, обязательны функции поиска/замены текста, проверки орфографии (английской), импорта и экспорта файлов различных форматов (TEXT, RTF, HTML). Также эти программы умеют сохранять проекты как в форматах WinHelp, так и HTML Help, так что проблема выбора формата Справки стоит не так остро. Многие продукты имеют функции анализа проектов различных систем программирования (Visual C++, Delphi, Visual Basic) и автоматической генерации разделов Справки ко всем диалоговым окнам, пунктам меню и элементам управления, а также исходного кода на соответствующем языке программирования для вызова этих разделов.
Конечно, у каждой программы имеются уникальные возможности, которые могут повлиять на выбор в пользу одной из них. Так, AnetHelpTool позволяет редактировать файлы Справки в двух режимах — Runtime и Design: в первом режиме можно просматривать документ практически в том же виде, как он будет выглядеть в WinHelp после компиляции, а во втором — редактировать текст и графику. Кроме того, этот продукт поддерживает множество форматов справки: WinHelp, HTML Help, JavaHelp, Web-сайт, документацию для печати. Windows Help Designer довольно компактен, к тому же хранит проект не в файле специфического формата, а в RTF, так что при необходимости можно подправить файл Справки в Microsoft Word, не прибегая к утомительной процедуре импорта-экспорта. HelpMagician Pro отличается мощным редактором с поддержкой стилей, а также вызывающим ностальгию интерфейсом в стиле Windows 3.1. RoboHelp Office — это не просто программа для создания справочной системы, а мощный интегрированный пакет с просто потрясающими возможностями, состоящий из двух отдельных программ — RoboHelp Classic (поддержка WinHelp) и RoboHelp HTML (поддержка HTML Help, Oracle Help, WebHelp, Java Help), а также пятнадцати утилит. Из них особого внимания заслуживает известная программа What's This? Help Composer, которая сканирует готовый ЕХЕ-файл приложения, написанного на Visual C++, а также проект Visual Basic (к сожалению, Delphi не поддерживается) распознает все содержащиеся в программе диалоги и позволяет указать для них подсказки. После этого текст подсказок записывается обратно в ЕХЕ-файл (!) — вот такое простое до гениальности решение.
Как видите, у разработчика существует большой выбор средств для создания справочных систем. Остается посмотреть их и выбрать, то, которое придется по душе.

Текстовый файл

Текстовый файл

Чисто теоретически, документация может быть выполнена в виде обычного текстового файла — например, readme.txt. Однако для серьезной shareware-программы один текстовый файл — явно недостаточно. В крайнем случае, readme.txt может быть временной заменой справочной системы на этапе, когда программа существует в виде бета-версии. У готового же к продажам продукта документация должна быть оформлена в одном из форматов, специально предназначенных для справочной системы.
В то же время файл readme.txt тоже должен входить в дистрибутив программы, служа важным дополнением "основной" документации. Readme.txt обычно содержит краткую информацию о продукте: номер версии, дата выпуска, имя разработчика, адрес домашней страницы, важные заметки о текущем выпуске (новые возможности, необходимость установки каких-либо компонентов и т. п.). Особенности, из-за которых формат ASCII не подходит для создания полноценных справочных систем — отсутствие возможностей для удобной навигации по страницам и поиска,. — здесь являются достоинством. Благодаря им, пользователь может быстро получить доступ к важной информации, не путаясь в многочисленных страницах традиционной справочной системы.

Виды документации

Виды документации

Возможности

Возможности

Конечно, по функциональности справочной системы HTML Help значительно опережает своего предшественника. К услугам разработчика все то, что поддерживает браузер Microsoft Internet Explorer: не только "обычный" HTML, но и Dynamic HTML, таблицы стилей (CSS), JavaScript и т. д. С помощью этих инструментов можно реализовать такие функции, которые WinHelp и не снились.
Однако за все нужно платить, и "красоты" HTML Help — не исключение. Дело в том, что, включив в оформление документации все эти "навороты", автор не может быть уверен, что на компьютере пользователя справочная система отобразится корректно. Вид Справки может быть самый различный: от небольших искажений до полной нечитабельности. Это зависит от многих факторов, например, от версий браузера, установленных у автора и у пользователя. Например, если у пользователя более старая версия, чем у автора, то многие элементы справочной системы могут быть невидимыми. Другой вариант — персональные настройки браузера, например, запрет выполнения JavaScript или установленный специфический шрифт. Более того, не редки случаи, когда на компьютере вообще не установлен Internet Explorer, и просмотр файла HTML Help невозможен. Например, один из российских shareware-программистов рассказывал, что ему пришлось отказаться от формата HTML Help в пользу WinHelp из-за того, что ему стали приходить письма от пользователей примерно такого содержания: "В фирме, в которой я работаю, корпоративная политика состоит в отказе от Internet Explorer, и со всех компьютеров этот браузер удален и установлен Netscape Navigator.
Вследствие этого я не могу просмотреть Справку к Вашей программе. Вышлите, пожалуйста, мне ее текст в каком-нибудь другом формате". В то же время большинство разработчиков не пользуются и 10% всех возможностей Internet Explorer, предпочитая привычные средства подготовки документов: перекрестные ссылки, форматированный текст, таблицы, списки, графические изображения. А со всем этим превосходно справляется и WinHelp. Кроме того, у последнего перед HTML Help есть даже некоторые преимущества именно в области создания справочных систем. Например, во всплывающих (popup) окнах WinHelp допускает форматированный текст, а HTML Help - нет (см. http://msdn.microsoft.com/library/en-us/htmlhelp/html /hwHTMLHelpFrequentlyAskedQuestions.asp?frame=true#6). Интересно, что в этой ситуации специалисты Microsoft советуют продолжать пользоваться WinHelp.

WinHelp или HTML Help?

WinHelp или HTML Help?

Как видно из предыдущего раздела, сегодня существует два реальных варианта для реализации справочной системы: WinHelp и HTML Help. Какой же из них предпочесть?

WinHelp

WinHelp

WinHelp (Рисунок 7.2) — настоящий долгожитель среди форматов справочных систем. Программа winhelp.exe, обеспечивавшая работу HLP-файлов, входила в состав еще шестнадцатиразрядных версий Windows. Несмотря на свой почтенный возраст, WinHelp — довольно эффективный формат для организации документации: он позволяет хранить в HLP-файлах форматированный текст (включая таблицы, списки и тому подобные элементы), графику, видео, анимацию, звук, проводить поиск, индексировать справочный файл для более эффективного поиска.

Зачем нужна документация

Зачем нужна документация

Многие разработчики считают, что справочная система для их продуктов совершенно не нужна. Это и не удивительно: автор досконально знает свое творение, и оно кажется ему абсолютно простым для понимания и освоения. Если быть откровенным, то у программистов существует прямо-таки природное отвращение к написанию документации: это занятие представляется им на редкость нудным и скучным. Многие из них согласны проводить целые дни и ночи напролет, как говорится, "в глубокой отладке", но ни в коем случае не описывать все эти меню, диалоговые окна и т: п.
Между тем документация — это одно из основных отличий программы "для себя" от серьезного продукта, который можно успешно продавать на shareware-рынке, С помощью Справки пользователи могут быстро найти ответы на возникающие у них вопросы по работе с программой, что произведет на них благоприятное впечатление и поможет сделать выбор в пользу оплаты регистрации продукта. А многие компьютерные журналы и online-архивы программного обеспечения даже не рассматривают программы, не имеющие справочной системы (Рисунок 7.1), не говоря уже о получении положительных отзывов и наград ("звезд", "коров" и т. п.) от обозревателей. И наконец, хорошо составленная справочная система избавляет разработчика от необходимости отвечать на одни и те же вопросы пользователей.
Что касается того, что "моей программе Справка не нужна — там и так все понятно"... Практика показывает, что у большинства пользователей рано или поздно возникают затруднения при освоении программ. К тому же уровень квалификации у всех разный: не каждый может разобраться, например, в специфическом формате файлов или механизме записи макросов.

Учебник по созданию shareware программ

Borland Delphi позволяет определять

Рисунок 8.1. Borland Delphi позволяет определять сложные номера версий для создаваемых программ


Некоторые из читателей, возможно, подумают: "Как это все запутанно". И будут совершенно правы! Для многих пользователей даже такие простые номера версий, как 3.1 или 6.0, сложны для запоминания, не говоря уже о номерах типа 5.00.2614.3500 (Рисунок 8.2). Действительно, можете ли вы вспомнить полный номер версии браузера Internet Explorer, установленного у вас?
В 1994 году, готовя к выпуску новую, 32-разрядную версию Windows, в корпорации Microsoft решили отказаться от традиционной нумерации версий, назвав свою новую разработку не Windows 4.0, a Windows 95. Нет, "обычный" номер все равно остался (чтобы убедиться в этом, достаточно в командной строке дать команду ver), однако он стал предназначаться для сведения опытных пользователей и специалистов. "В массы" продукт продвигался как Windows 95 — именно из-за того, что, по мнению Microsoft, традиционные номера версий не понятны большинству пользователей и запутывают их. Этот шаг оказался удачным, и корпорация Microsoft при наименовании своих продуктов продолжает пользоваться правилом, которое, перефразируя старый флотский принцип, звучит так: "Каждая версия Windows или любого другого продукта должна иметь имя собственное" - пускай даже это имя собственное выбрано в честь года выпуска программы. Windows 95 OSR, Windows 98, Windows Millennium, Windows 2000, Windows XP — в официальных названиях операционных систем линейки Microsoft Windows не встретишь традиционных "4.1" или "5.0".

Демонстрация текста лицензионного соглашения

Демонстрация текста лицензионного соглашения

Как уже говорилось выше, согласие с условиями лицензионного соглашения — это условие, при котором инсталляция программы может быть продолжена. В этом — суть лицензионного соглашения как "оберточной" лицензии. Значит в инсталлятор нужно не забыть включить окно с текстом License Agreement, чтобы пользователь мог продолжить установку, только нажав кнопку Согласен или установив соответствующий флажок (переключатель).

Номера версий

Номера версий

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

номер версии состоит из двух частей, разделенных точкой;

цифры до точки обозначают номер основной версии (так называемой "мажорной версии" (major version);

1—2 цифры после точки обозначают номер вспомогательной версии (так называемой "минорной версии" (minor version)).

Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если в программу были внесены небольшие изменения, то меняется первая цифра после точки; если сделанные изменения совсем уж незначительны, то меняется вторая цифра после точки.
Многие разработчики используют более сложные номера версий, учитывающие и так называемые релизы (release) и билды (build). Первый термин обозначает номер "промежуточной" версии, содержащей исправления ошибок; второй — номер перекомпиляции проекта (Рисунок 8.1).

Окно программыинсталлятора

Рисунок 8.3. Окно программы-инсталлятора


Некоторые авторы программ, начав распространение своих продуктов на российском рынке и как freeware, привыкли к тому, что инсталлятор к ним делать не нужно. Некоторые из разработчиков даже с гордостью делают приписку к описанию своей программы: "Не требует инсталляции". Это, с одной стороны, оправданно: пользователь может быть уверен, что процесс копирования программы на диск его компьютера будет под его контролем, системные настройки не будут отредактированы без его ведома или в папку WINDOWS/SYSTEM не будет записано никаких "левых" файлов. Правда, все это может быть сделано уже самой программой при первом запуске ее ЕХЕ-файла. С другой стороны, недоверие к инсталляторам со стороны пользователей в основном обусловлено низкой надежностью старых версий Windows (например, 3.x) и плохим качеством программ сторонних разработчиков, появившихся на рынке в то время, — например, механизм удаления уже установленной под Windows программы работал малоэффективно. Сейчас, по прошествии очень большого для индустрии информационных технологий периода времени, ситуация сильно изменилась, и большинство пользователей рассматривают инсталлятор как помощника в работе, а не обузу, придуманную авторами программ для засорения жестких дисков пользователей.
С увеличением объема продаж через Интернет, бумом shareware, сокращением доли "коробочных" продуктов на рынке и переход некоторой их части в разряд shareware, инсталлятор стал играть роль не только программы установки, но и "упаковки" программного продукта, что имеет большое значение в деле защиты авторских прав.
Дело в том, что в то время, когда большинство платных продуктов были "коробочными", т. е. продавались в фирменной упаковке, лицензионное соглашение, в котором правообладатель разрешал использование программы, печаталось прямо на этой упаковке. Текст лицензионного соглашения обязательно начинался со слов: "Вскрывая упаковку данного программного продукта, Вы подтверждаете свое согласие с условиями настоящего лицензионного соглашения". Лицензионные соглашения даже стали называть "оберточными лицензиями", т. е. лицензиями, опубликованными на упаковке.
После того как все больше программ стало распространяться по компьютерным сетям, в том числе и по Интернету, термин "оберточная лицензия" стал терять смысл — ведь "обертки" как таковой 'уже не было! И тогда роль упаковки стал играть инсталлятор: перед началом процесса установки продукта он демонстрирует пользователю текст соглашения и требует поставить флажок или переключатель Согласен для продолжения установки (Рисунок 8.4). А слова "Вскрывая упаковку данного программного продукта..." заменились на "Устанавливая данный программный продукт..." Таким образом, лицензионное соглашение, оформленное в электронном виде, продолжают называть "оберточной лицензией".
Конечно, нельзя не упомянуть о том, что иногда без инсталлятора просто не обойтись — например, когда для нормальной работы устанавливаемой программы требуется скопировать в папку WINDOWS/SYSTEM и зарегистрировать в системе ActiveX- и DLL-библиотеки, типы файлов и т. п.

Папка для установки по умолчанию

Папка для установки по умолчанию

Мне до сих пор попадаются программы, инсталляторы которых предлагают создать папку программы для копирования файлов не в папке C:\Program Files, а в корневом каталоге диска С:. Конечно, в большинстве случаев можно выбрать для установки любую другую папку, в том числе и Program Files, но, во-первых, это раздражает, т. к. приходится совершать лишние операции, а во-вторых, приходится все равно устанавливать такую программу в каталоге С:\, т. к. никогда нельзя быть уверенным в том, что программа будет нормально работать в папке Program Files — например, из-за проблем с длинными именами файлов. Кто-то может удивиться тому, что в наше время, когда на рынке господствуют 32-разрядные операционные системы, какие-то программы "не понимают" длинные имена файлов, но на самом деле такие программы встречаются, и я бы не сказал, что очень редко.

Периодичность выпуска

Периодичность выпуска

Первая версия вашей программы должна появиться как можно быстрее. Это требование обусловлено природой shareware-рынка, динамично развивающегося, заполненного множеством ожесточенно конкурирующих между собой продуктов. Если слишком долго тянуть с выпуском первой версии, программы, то, когда она все-таки выйдет в свет, вполне может оказаться, Что конкуренты ушли далеко вперед, и такая программа уже никому не нужна. В конце концов, это же не рынок freeware, где пользователи согласны работать с продуктом только потому, что он бесплатен.
То, что первая версия программы должна появиться как можно скорее, не означает, что можно выпустить ее в свет сразу же, как только в ней появятся хоть какие-то функции. Нужно вести разработку программы быстрыми темпами, чтобы сразу сделать мощный продукт, а не заявлять о выходе первой версии программы, над которой программист работал всего пару дней и которая является слабой поделкой.
Да, очень важно, чтобы первая версия появилась быстро, но при этом не была функционально слишком слабой. Иначе пользователи, попробовав новую программу в деле, будут сильно разочарованы и потеряют интерес к последующим версиям продукта, которые, возможно, будут не такими уж плохими. Избежать этого поможет, в частности, постепенное изменение позиционирования продукта на рынке параллельно с развитием функциональных возможностей, а не первоначальный "замах" на более высокий уровень.
Например, компактный Web-редактор, в котором есть черты некоторых более продвинутых продуктов, встретит гораздо больше симпатий, чем "аналог FrontPage", где пользователь сразу же обнаружит отсутствие некоторых нужных функций и досадные ошибки, которые не позволят новой программе выглядеть достойно по сравнению с конкурентами.
Конечно, выпуском одной версии история развития вашей программы не ограничится (по крайней мере, я на это надеюсь). Программа будет совершенствоваться, будут выходить новые версии. Немаловажный вопрос — как часто должны появляться новые версии продукта?
Частые обновления программы имеют несколько плюсов:

почти о всех online-архивах списки программ сортируются по дате поступлений (т. е. новые программы всегда расположены в начале списка), кроме того, новые программы попадают на страницу "Что нового?" (имеющую относительно остальных страниц очень высокую посещаемость), а в некоторых архивах — даже страницу;

выход новой версии всегда привлекает внимание к продукту. Например, многие интернет-обозрения, посвященные компьютерам и программам для них, охотно публикуют анонсы новых shareware-программ. Появляется повод, например, разослать в редакции online- и offline-изданий пресс-релизы с сообщением о выпуске новой версии продукта;

частые появления новых версий программы свидетельствуют о том, что продукт активно развивается. Например, в news-конференциях пользователей программного обеспечения я не раз читал, как среди достоинств той или иной программы упоминается "frequently updated";

с появлением новой версии устаревают все крякерские патчи к данной программе (если таковые, конечно, имеются). Кроме того, если в программе изменен алгоритм генерации регистрационных ключей, то все опубликованные в Интернете ключи также перестают работать в новой версии.

В то же время иногда частые обновления программы могут не иметь положительного эффекта или даже приносить вред. Так, слишком частый выход новых версий (раз в одну-две недели или чаще) отрицательно сказывается на имидже программы: пользователи начинают полагать, что эта программа - "buggy", т. е. имеет множество ошибок, для исправления которых и выпускаются, собственно, все эти обновления. Еще один пример — публикация новых версий в интернет-архивах, чтобы обеспечить более выгодную позицию в их списках программ. Крупные каталоги программного обеспечения, способные привлечь к продукту внимание большой аудитории, обновляют свои базы данных очень неспешно: может пройти несколько недель и даже месяцев, прежде чем информация о новой версии появится на страницах архива. С другой стороны, многие мелкие архивы, работающие более оперативно, приводят гораздо меньше пользователей, чем рассчитывал автор программы, готовя новую версию. Наконец, нужно учитывать и то, что при слишком частых обновлениях программы пользователи вовсе не будут скачивать и устанавливать каждую появляющуюся новую версию. Если в имеющемся у них варианте программы нет явных ошибок, откровенно мешающих нормальной работе, то, скорее всего, многие пользователи будут проводить обновления после выхода нескольких новых версий. Так что получается, что иногда все те затраты времени, сил и средств, сделанные автором для быстрого выпуска новой версии программы, не приведут к ожидаемому результату.
На самом деле периодичность выхода новых версий программы в большинстве случаев не является постоянной. На этапе бета-тестирования, когда новые функции еще до конца не отлажены, новые версии могут выходить очень часто — даже каждый день, чтобы оперативно исправлять ошибки, некоторые из которых могут серьезно мешать нормальной работе программы. После выхода версии 1.0 (т. е. первого официального релиза) может сохраняться довольно высокая периодичность обновлений — раз в один-два месяца, чтобы привлекать внимание новых пользователей. Выпускать новые версии чаще, чем раз в месяц, нецелесообразно, т. к. в этом случае проявятся все те недостатки частых обновлений, о которых говорилось выше,
По мере того как программа совершенствуется, набирает популярность, новые версии могут выходить все реже и реже. В частых обновлениях уже нет необходимости: число пользователей уже достаточно велико, а новые узнают о программе не со страниц "Что нового?" интернет-каталогов, а из других источников (например, по рекомендациям друзей и знакомых); большинство возможностей, характерных для таких программ, уже реализовано; основная часть ошибок исправлена. В этом случае появление обновлений или их длительное отсутствие не очень сильно влияют на динамику продаж. Но, естественно, выпуск новых версий программы хотя бы раз в полгода демонстрирует пользователям, что данный проект по-прежнему работает и развивается.

Подготовка дистрибутива

Подготовка дистрибутива

Итак, инсталлятор программного продукта готов: файл setup.exe лежит в папке вашего shareware-проекта. В принципе, этот файл уже является дистрибутивом программы, и его можно смело распространять через Интернет. Многие авторы так и делают: переименовывают файл setup.exe так, чтобы его название было созвучно названию программы, и размещают его на Web-сервере.
Это распространенный, но не совсем правильный подход к выбору варианта оформления дистрибутива. Лучше всего — упаковать ЕХЕ-файл инсталлятора ZIP-архиватором. Помимо файла setup.exe, в архив нужно включить еще и файл readme.txt, содержащий наиболее важную информацию о программе и ее текущей версии, а также файл file_id.diz, в который записывается название программы, ее версия и короткое (10—20 слов) описание.

Пример файла file_id diz

Рисунок 8.7. Пример файла file_id.diz


По свидетельству тех shareware-разработчиков, которые размещают на своих Web-сайтах программы сразу в двух вариантах — ехе и zip, оба варианта скачивают примерно равное количество пользователей. Тем не менее, с ZIP-архивами работать удобнее, что подтверждают письма от посетителей архива SoftList: в некоторых из них содержатся довольно эмоциональные просьбы публиковать на сайте только программы, дистрибутивы которых оформлены в виде ZIP-файлов, и даже обязать авторов программ распространять свои программы только упакованными в архив. Конечно, выполнить такие просьбы по разным причинам невозможно, но сам по себе факт наличия подобных просьб со стороны пользователей показателен, тем более, что просьб искоренить формат ZIP в области распространения дистрибутивов программ не поступало.
Читатели, наверное, обратили внимание на то, что, говоря об использовании архиватора, я все время упоминаю об одном формате — ZIP. Ведь существует множество других архивных форматов, некоторые из которых более эффективны, чем ZIP — например, широко распространенный в России RAR Евгения Рошаля (http://www.rarsoft.com). Дело в том, что ZIP является стандартом де-факто для распространения файлов в Интернете, чего о других архивных форматах не скажешь. Конечно, существуют исключения, обусловленные, в частности, спецификой платформы, для которой предназначен файл: например, программы для Linux традиционно упаковываются в архивы tar.gz. Но когда речь идет о распространении через Интернет программного обеспечения для Windows, здесь выбора нет: только ZIP, и никакой другой архиватор.
Большое значение для распространения программ среди зарубежных пользователей имеет и тот факт, что существует большое количество бесплатных ZIP-архиваторов, а вот тот же RAR (как его версия для Windows -WinRAR) — shareware-продукт, за использование которого (в данном случае — всего лишь для того, чтобы распаковать чужую программу) нужно платить. И, хотя в комплект поставки RAR входит бесплатная утилита UnRar, которая предназначена только для распаковки файлов, большинство пользователей о ней ничего не знают, т. к. автором RAR она не особо рекламируется. Получается, что автор shareware-продукта, упакованной RAR (или другим небесплатным архиватором), вынуждает пользователя заплатить деньги только за право разархивировать программу. Один из российских shareware-разработчиков рассказывал, что в то время, когда он пользовался архиватором RAR для упаковки дистрибутива своих программ, он как-то даже получил письмо с упреком. "Чтобы запустить Вашу программу, я должен зарегистрировать RAR!" - писал пользователь.
Примечание
Примечание


Надеюсь, мои слова будут поняты правильно: критикуется, конечно же, не то, что за пользование архиватора требуется платить, а то, что в данном случае пользователя вынуждают платить за программу, которая ему фактически не нужна.
Пожалуй, единственный тип программ, дистрибутивам которых противопоказана упаковка любым архиватором и которые должны распространяться только в виде исполняемого файла ("голый" инсталлятор или самораспаковывающийся архив), - это... ZIP-архиваторы. Очень часто пользователь скачивает из Интернета дистрибутив одной из таких программ как раз для того, чтобы разархивировать другие ZIP-файлы, и поэтому ему, скорее всего, будет просто нечем распаковать дистрибутив, сжатый ZIP-архивом.
Наконец последний вопрос, который мне хотелось бы рассмотреть в данном разделе, — это вопрос о том, какое имя должен иметь готовый файл дистрибутива, т. е. файл, который пользователи будут качать из Интернета. Есть три возможных варианта: оставить ему стандартное имя вроде setup.zip, дать имя на основе названия программы (предположим, abc.zip) и добавить ко второму варианту номер версии — например, abc20.zip будет означать версию 2.0.
Первый вариант, конечно, отпадает: имя файла setup.zip ничего не скажет пользователю о названии программы, когда он скачает этот файл, а через некоторое время (например, наводя порядок на жестком диске) решит выяснить, что же он содержит.
Последний, третий по счету вариант представляется идеальным: в имени файла содержится указание не только на название программы, но и на номер ее версии. Пользователь, едва взглянув на имя файла, может сделать вывод о назначении этого дистрибутива. Кроме того, при таком методе наименования файлов соответствующий дистрибутив — нужной программы и нужной версии — легко найти на специализированных файловых поисковых системах наподобие www.filesearch.ru.
Однако, при всех достоинствах, этот способ имеет большой недостаток. После выпуска очередной версии программы ссылки на ее файл быстро расползаются по всему Интернету: автор регистрирует программу в различных online-архивах, а некоторые архивы сами добавляют эту программу в свои базы данных. Но после того, как в свет выходит новая версия программы, имя файла меняется: ведь версия программы тоже изменилась. В результате все ссылки, которые стоят на файл программы на страницах интернет-каталогов программного обеспечения, компьютерных обозрений и других информационных ресурсов, перестают работать, и соответственно посетители не могут скачать программу по этим ссылкам. С помощью небольшой настройки Web-сервера эту проблему можно решить (см. гл. 9 "Ваша программа в Интернете"), но не все авторы shareware-программ имеют возможность произвести такую настройку. Чтобы хоть как-то поправить положение, разработчику приходится писать письма администраторам соответствующих архивов или заполнять Web-формы с просьбой изменить ссылку на файл программы. Беда в том, что крупные архивы, как уже упоминалось (см. разд. "Периодичность выпуска" данной главы), могут обновить информацию о программе в своих базах данных спустя недели и даже месяцы после того, как получат соответствующие запросы, и все это время файл программы не будет доступен для посетителей данных сайтов. И никто не знает, сколько зарегистрированных пользователей из-за этого недосчитается программа... Учитывая сказанное выше, мне наиболее оптимальным представляется вариант номер два: имя файла включает только название (или его аббревиатуру) программы, без номера версии. В таком случае название остается более-менее понятным, а внешние ссылки на файл программы остаются рабочими при выходе новых версий программы. Правда, при поиске в файловых системах трудно будет найти конкретную версию данной программы. Однако этим стоит пожертвовать ради того, чтобы внешние ссылки на файл программы сохраняли свою работоспособность после выхода ее новой версии: это окажется гораздо более выгодным в плане увеличения числа зарегистрированных пользователей.

Пример программыдеинсталлятора

Рисунок 8.5. Пример программы-деинсталлятора


Деинсталляция — это не просто удаление файлов с компьютера, которое, в общем-то, может произвести любой пользователь вручную. Деинсталляция подразумевает удаление всех следов пребывания программы в системе (записей в реестре и других системных файлах, DLL-библиотек в папке WINDOWS/SYSTEM и т. п). Если же вся эта информация остается в системе, то она по мере установки на компьютер все новых и новых приложений накапливается, что отрицательно сказывается на стабильности работы операционной системы.
Да и удаление файлов деинсталлятором не такой уж и простой процесс. Дело в том, что по умолчанию деинсталлятор настраивается так, чтобы удалить только те файлы, которые были установлены ранее. Если при удалении файлов программы деинсталлятор обнаруживает в ее папке файлы, которые не были туда установлены инсталлятором, то он пропускает их, а иногда (это зависит от того, какой программой был создан деинсталлятор) вообще прекращает свою работу, чтобы не удалить важные файлы, например документы, созданные пользователем. Но на практике не все "новые" файлы могут действительно являться документами пользователя: вполне возможно, что это файлы, созданные операционной системой в связи с работой данной программы на этом компьютере.
Например, если справочная система продукта выполнена в формате WinHelp, то обычно программа установки копирует на диск компьютера файлы с расширением hlp и cnt (основной файл и файл с оглавлением Справки). Но стоит пользователю хоть один раз посмотреть справочную систему, как на диске будет создан файл с расширением gid, а если пользователь проведет расширенный поиск — создаются файлы FTS и FTG (см. табл. 7.1). Поэтому файлы с этим расширением также нужно включить в настройки программы-деинсталлятора.
То же самое относится и к ключам в системном реестре с настройками программы. Часто эти ключи создаются не инсталлятором, а самой программой, в процессе работы пользователя с ней. В результате эти записи не удаляются деинсталлятором и остаются в реестре, увеличивая его объем и ухудшая скорость работы Windows. Вследствие этого нужно настроить деин-сталлятор на удаление всех ключей, которые могут быть созданы программой в процессе ее использования.
Как известно, деинсталлятор приложения для Windows может быть запущен двумя способами: посредством выбора соответствующего пункта в группе с ярлыками программы в меню Пуск и при помощи апплета "Установка и удаление программ" Панели управления Windows. Некоторые программы генерации инсталляторов, например уже упоминавшийся InstallWise, предоставляют пользователю возможность при удалении программы воспользоваться любым из этих способов на свой выбор: соответствующие пункты присутствуют как в меню Пуск, так и в апплете "Установка и удаление программ" Панели управления. Однако некоторые shareware-продукты можно удалить только одним способом. Нельзя сказать, что это удачный ход с точки зрения удобства работы с программой. Можно испытать сильное раздражение, например, последовательно вызвав Панель управления, апплет "Установка и удаление программ", прокрутить длинный список и не найти ту программу, которая вам требуется, прокрутить этот список более медленно, тщательно вчитываясь в названия продуктов, чтобы не пропустить интересующую программу, задуматься, как же все-таки удалить эту злосчастную программу и т. д.
Наконец, когда инсталлятор и деинсталлятор созданы, нужно обязательно протестировать их работу: насколько хорошо продукт устанавливается на компьютер и удаляется с него. Кто-то из читателей сочтет это замечание не нужным — ведь необходимость тестирования любой программы кажется само собой разумеющейся вещью, однако мне время от времени встречаются программные продукты, после инсталляции которых не работают даже ярлыки в меню Пуск, не говоря уже о более серьезных ошибках при проектировании программ установки. При этом нужно постараться найти возможность протестировать работу инсталлятора и деинсталлятора на компьютерах с различными версиями Windows, в том числе и с разными локализациями.

Содержимое "правильного" дистрибутива

Рисунок 8.6. Содержимое "правильного" дистрибутива


Главный недостаток распространения "голого" файла setup.exe, без его "оборачивания" архиватором, состоит в том, что пользователь может узнать, какую именно программу содержит дистрибутив, только установив ее. Хотя авторы обычно дают файлу дистрибутива имя, производное от названия программы, оно нередко совершенно ничего не говорит пользователю, т. к. выглядит как аббревиатура и номер версии — например, cp32e45.exe: попробуйте догадайтесь, что за этим малопонятным набором букв скрывается Netscape Communicator версии 4.5 для Windows 9.X/NT/2000.
Если же инсталлятор упакован архиватором, а в архиве находится и файл readme.txt, то пользователь может узнать, какая именно программа представлена данным дистрибутивом без ее непосредственной установки, а также получить много дополнительной информации о ней (что нового появилось в этой версии, какие существуют системные требования и т. п).
Некоторые читатели, возможно, спросят: "А зачем в архив нужно еще включать и файл file_id.diz? Ведь много информации уже есть в readme.txt?" Это действительно так, однако file_id.diz более удобен для чтения, если пользователю всего лишь нужно узнать название программы и ее версию. Но самое главное — многие архиваторы, файловые менеджеры, каталогизаторы автоматически извлекают из архивов файлы file_id.diz (традиция снабжать дистрибутивы файлами file_id.diz идет еще со времен DOS) и показывают (или обрабатывают другим образом) их содержимое. В результате пользователь получает описания упакованных файлов из таких архивов без необходимости открывать их вручную и самостоятельно читать файлы readme.txt. Не случайно текст в файле file_id.diz принято записывать небольшими по длине строками, чтобы описание помещалось в информационные окна соответствующих программ.

Создание инсталлятора

Создание инсталлятора

Созданную новую версию программы, в принципе, уже можно распространять среди пользователей. Запаковать ЕХЕ-файл ZIP-архиватором, добавить в этот архив readme-файл и файл справки, и разместить получившийся ZIP-файл в Интернете. Однако для серьезной shareware-программы этого мало. Нужно создать к своему продукту специальную программу установки, или, как ее еще называют, инсталлятор ("install" - устанавливать) (Рисунок 8.3).
Почему shareware-программе необходим инсталлятор? На это есть несколько причин.

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

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

Инсталлятор — своеобразная "упаковка" программы, имеет большое значение для оповещения пользователя об условиях лицензионного соглашения.

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

Создание ярлыков в Главном меню

Создание ярлыков в Главном меню

Я уже говорил в разд. "Не трогайте системные файлы и настройки" гл. 4 о том, что группа с ярлыками для установленной программы должна находиться исключительно в папке Программы Главного меню, а не в его первом уровне или где-то еще. Если же вы считаете, что ярлык к вашей программе пригодится пользователю и на Рабочем столе или, например, в первом уровне Главного меню, то инсталлятор программы должен создавать такие ярлыки только с разрешения пользователя.
Если ярлык программы помещается не в собственную группу в меню Программы, а в одну из стандартных групп — например, Автозагрузка или Стандартные, то нужно учитывать, что в локализованных версиях Windows их названия различаются, и не повторять ошибок разработчиков пакета утилит Microsoft PowerToys, в процессе установки которых даже под русской версией Windows ярлыки создаются в группах "Accessories" и "Startup", которые, конечно, в данной локализации Windows игнорируются.
Помимо установки, программа должна иметь возможность деинсталляции, т. е. удаления себя из системы. Программа, производящая эту операцию - деинсталлятор (Рисунок 8.5), — как правило, генерируете» той же программой, которая использовалась для создания инсталляторов. Хотя большинство программ для генерации инсталляторов предоставляют разработчику самому решить, нужен ли его программе деинсталлятор, на самом деле он фактически является обязательным для любого серьезного программного продукта.

Текст "оберточной лицензии" в окне инсталлятора

Рисунок 8.4. Текст "оберточной лицензии" в окне инсталлятора


Самостоятельная подготовка инсталлятора — довольно простое дело. Существует огромное количество продуктов независимых разработчиков (как бесплатных, так и shareware и коммерческих), позволяющих создавать программы установки. Какую из них предпочесть? Давайте посмотрим, на какие параметры нужно обратить внимание при выборе программы создания инсталляторов.
Сначала, экономичность. Казалось бы, для любой программы главное — это функциональные возможности, но здесь они отходят на второй план. Первое, на что стоит обратить внимание при рассмотрении программы создания инсталляторов — объем файлов, которые она генерирует. Ведь функции и диалоговые окна инсталлятора также требуют определенного пространства на диске, в результате файл инсталлятора вместе с содержащимся в нем сжатыми файлами программного продукта окажется несколько больше, чем, например, объем ZIP-архива с теми же файлами внутри.
Эта разница между "обычным" архивом и инсталлятором существует и при использовании различных программ может оказаться очень значительной. Например, известнейший пакет InstallShield (облегченные версии которого, кстати, входят в комплекты поставки многих систем разработки приложений), "добавляет" к дистрибутиву программы более мегабайта! Конечно, использовать InstallShield можно разве что в том случае, если готовую программу планируется распространять не через Интернет, где у более компактных программ есть больше шансов привлечь к себе внимание пользователей. Тем не менее, некоторые shareware-разработчики все равно применяют InstallShield. Например, я иногда спрашиваю авторов, присылающих мне заявки на публикацию своих программ в каталоге SoftList: "Почему Ваша программа, являясь вроде бы небольшой утилитой, имеет архив размером почти 2 Мбайта?" "Да не беспокойтесь, — слышу я в ответ, — сама программа занимает всего 500 Кбайт, а все остальное — инсталлятор!" Нет, программа установки, "съедающая" втрое больший объем, чем непосредственно "основной" продукт — слишком большая роскошь для shareware. Итак, как я уже упоминал, InstallShield, на мой взгляд, разумно использовать для "обертки" к программам, которые не планируется распространять по компьютерным сетям — например, написанных под конкретный заказ или рассчитанных на публикацию на CD-ROM и ему подобных носителях.
Другие программы по созданию инсталляторов гораздо более умеренны в своих аппетитах. Собственно, громоздкость InstallShield явилась своеобразным катализатором появления аналогичных, но более компактных продуктов: shareware-разработчики, которым для распространения своих продуктов через Интернет требовался более экономичный инсталлятор, писали собственные генераторы программ установки, а затем некоторые из них, в свою очередь, были оформлены как самостоятельные shareware-продукты.
Одним из самых популярных среди разработчиков shareware-программ является пакет Installer Wise (http://www.mindvision.com). Помимо широких возможностей, о которых вы прочтете ниже, он создает достаточно компактные программы установки: разница между ZIP-архивом с файлами программы и инсталлятором будет всего около 180 Кбайт. CreateInstall 2000 российской фирмы Gentee (http://www.gentee.com) еще более экономичен — после его работы дистрибутив программы увеличивается всего лишь на 40 Кбайт. Есть, конечно, еще немало программ для генерации инсталляторов, но большинство из них создают относительно компактные установочные программы- в пределах 200 Кбайт. Более "прожорливые" аналоги практически не имеют шансов выжить на рынке shareware (тот же InstallShield, например, в основном применяется при оформлении больших коммерческих продуктов), а их появление в дистрибутивах shareware-программ обусловлено в основном неопытностью автора соответствующей программы.
Вторым по значению фактором выбора программы для создания инсталляторов является набор функциональных возможностей, который она предоставляет разработчику. Естественно, по этому параметру разные продукты в этой категории различаются, и порой очень сильно. Являются ли возможности той или иной программы достаточными — зависит в основном от особенностей этой программы.
Для многих программ -вполне подходит несложный процесс установки, состоящий из небольшого числа стадий: показ лицензионного соглашения, предложение выбрать папку для установки, выбор группы в секции Программы меню Пуск и непосредственно сам процесс копирования файлов и создания ярлыков в Главном меню. В этом случае подойдет практически любая программа для генерации инсталляторов, в том числе и из категории бесплатных продуктов. Правда, среди последних действительно хорошую программу придется поискать: многие программы из этой группы имеют раздражающие недостатки вроде неудобного интерфейса или отсутствия возможности переопределить внешний вид инсталлятора.
Если же в процессе установки требуется еще и регистрировать DLL-библиотеки и ActiveX, предоставлять пользователю выбор языка интерфейса или устанавливаемых компонентов программы, выводить определяемые автором программы диалоговые окна и обрабатывать результат действий пользователя, изменять ассоциации файлов, делать записи в реестре, перегружать компьютер по окончании установки и т. п., требуется более продвинутый генератор инсталляций. Это уже упомянутые мной Installer Wise, Create Install и др.
И наконец, немаловажным вопросом при выборе программы создания инсталляторов является удобство работы с ней. Часть программ этого типа (к счастью, небольшая), например уже упоминавшийся выше InstallShield, a также InnoSetup (http://www.domain.com), для описания инсталлятора (вид диалоговых окон, обработка событий и т. д.) используют специальные скриптовые языки (Рисунок 8.6), вследствие чего освоение такого продукта замедляется. Для преодоления этой проблемы другими авторами написаны специальные визуальные конструкторы, генерирующие текст скриптов по параметрам, указанным пользователем в диалоговом режиме — например, ISTool (http://www.bhenden.org/istool), создающий скрипты для InnoSetup.
Впрочем, являются ли скрипты недостатком или нет — зависит от взглядов и предпочтений самого shareware-разработчика. Некоторым авторам программ больше нравятся как раз работать со скриптами, к тому же в этом случае часто имеется возможность более тонко настроить параметры инсталлятора, чем при использовании диалоговых окон.
Основная часть программ для создания инсталляторов работают с пользователем в диалоговом режиме, позволяя визуально конструировать будущий инсталлятор: выбирать стадии процесса установки, описывать вид диалоговых окон, определять другие параметры — имена устанавливаемых файлов, регистрируемые расширения файлов, названия и пути к создаваемым ярлыкам и т. д.
Работать с такими программами, конечно, гораздо проще, чем с теми, которые используют скрипты.
Каким же должен быть "правильный" инсталлятор? Вместе с большинством программ для их создания поставляются примеры готовых проектов установочных программ, кроме того, в качестве наглядного примера можно посмотреть инсталляторы известных и популярных продуктов. Но я бы хотел обратить внимание на некоторые важные детали, которыми пренебрегают некоторые разработчики.

В сложных номерах версий не так уж легко ориентироваться

Рисунок 8.2. В сложных номерах версий не так уж легко ориентироваться


Примеру Microsoft последовали другие корпорации, производящие программное обеспечение, а за ними — и некоторые shareware-разработчики программ. Особенно много было программ с индексом "98", т. к. именно в 1998 году в западных странах случился "бум" Интернета, вызвавший, в том числе, и стремительное развитие shareware-рынка. Но одновременно авторы, применившие новомодный прием, оказались в двусмысленном положении. Крупные компании, выпускавшие большие программные пакеты, обновляли свои продукты раз в один-два года, и вполне могли использовать номер соответствующего года в качестве номера версии. А для shareware-программ такой принцип нумерации версий оказался неудобен, т. к. большинство продуктов на этом рынке обновляется несколько раз в год. Для того чтобы пользователи могли отличать одну версию от другой, разработчику все равно приходилось применять традиционную систему номеров версий: 1.0, 1.01, 1.1 (например, Zet Picture Viewer 98 1.0). Но при наступлении нового года цифры "98" в названии устаревали, и приходилось менять их па "99" или "2000". После этого у пользователей возникал закономерный вопрос: "Что это — только новая версия или полностью новый продукт?" Таким образом, одновременное использование двух систем нумерации версий одного shareware-продукта еще более запутывает потребителей.
Не менее интересен и вопрос политики изменения номеров версий по мере развития shareware-продукта.
Еще со времен появления первых программ для персональных компьютеров существует пользовательский стереотип, который очень распространен и сегодня: только с версии 2.0 программа становится достойна внимания. Такое мнение выработалось в результате разочарований, которые испытывали пользователи, попробовав многочисленные программы, стремительно заполнившие рынок программного обеспечения, в том числе и shareware.
Вследствие этого я всегда рекомендую разработчикам программ как можно скорее преодолеть "барьер номера 2.0" и выпустить версию 2.0 своего продукта. Очень многие авторы программ, по моим наблюдениям, как-то даже боятся увеличивать номера версий своих программ. Типичная ситуация -они начинают отсчет номера версии не от 1.0, а от 0.00, в то время как номер версии меньше единицы традиционно воспринимается пользователями как указание на очень предварительную и "сырую" версию программы. Например, download-менеджер FlashGet (http://www.amazesoft.com) достаточно долго имел номер версии, меньший, чем 1.0 (0.8, 0.9 и т.д.), но при этом был качественным продуктом с обширными возможностями, развитым интерфейсом и объемной документацией.
Еще один пример — разработчик, постоянно создавая новые версии с достаточно большим количеством изменений и дополнений, меняет только вторую цифру после точки, выпуская версии 1.01, 1.02, 1.03 и т. д. В результате программа, пережив выпуск уже нескольких десятков версий, имеет номер типа 1.21. А теперь представьте ситуацию: пользователь (или, например, редактор журнала, собирающий информацию для обзора shareware-продуктов), заходит на сайт online-архива программ и видит в списке два конкурирующих продукта: один, имеющий номер версии 1.21, и второй, обозначенный как 2.5. При сходстве остальных параметров этих программ (тип лицензии, размер, описание возможностей) предпочтение в большинстве случаев будет отдано второму варианту.
"Боязнь" разработчиков программ к существенному изменению номера версии обусловлена в основном тем, что они опасаются негативной реакции пользователей. На мой взгляд, это оправдано только в одном случае: автор предоставляет зарегистрированным пользователям бесплатно не все последующие версии, а только лишь minor updates, т. е. те обновления, номера версий которых изменяются в пределах цифр после точки. Например, если пользователь приобрел версию 1.2, то версии 1.3, 1.45, 1.6 и т. п. он получит бесплатно, а за версию 2.0 должен будет заплатить еще какую-то дополнительную сумму. По этой схеме распространяется, в частности, текстовый редактор UltraEdit (http://www.utlraedit.com). В этом случае при выходе версий 2.0, 3.0 и т. п. автор программы должен следить, чтобы эти версии по своим возможностям действительно сильно отличались от предыдущих, иначе пользователи будут очень недовольны тем, что их вынуждают платить за незначительные исправления.
Если же зарегистрированные пользователи получают все последующие обновления бесплатно, то не нужно опасаться смены номера версии. Конечно, выпускать версию 2.0, внеся в версию 1.0 лишь небольшие изменения, не стоит. Однако и тянуть с выходом версии 2.0 (или еще хуже, 1.0), выпуская один minor update за другим, тоже не нужно. Лично я практически отказался от использования в номере версии второй цифры после точки, чтобы сделать нумерацию версий простой для запоминания пользователями, а заодно увеличить скорость перехода на более солидные номера версий.
Среди известных программных продуктов много примеров довольно смелого обращения с номерами версий. Например, Dbase II появилась "с нуля": Dbase I не существовало (все из-за предубеждений пользователей относительно версий l.xx, которым якобы нельзя доверять); Microsoft Word с версии 2.0 перескочил сразу на 6.0, чтобы "унифицировать", свой номер с остальными программами пакета Microsoft Office; Netscape Navigator четвертой версии стал "шестым", чтобы хотя бы по этому параметру опередить почти вытеснившего его с рынка конкурента — Microsoft Internet Explorer. Как видите, крупные разработчики программного обеспечения в данном случае в первую очередь учитывали собственные маркетинговые интересы и не особенно комплексовали относительно предположительной реакции пользователей, что очень поучительно и для авторов shareware-программ.

Учебник по созданию shareware программ

Базы данных

Базы данных

В тарифные планы средней и высшей ценовых категорий обычно включается поддержка баз данных. Самым распространенным сервером баз данных на Web-серверах в настоящее время является MySQL (http://www.mysql.com). Менее распространены Postgres, Oracle, Interbase, Infomix и др. Эти серверы, в основном, используются для очень крупных специализированных проектов. Поэтому с MySQL работают, как правило, все хостинг-компании, а вот поддержка остальных серверов встречается в списках услуг хостеров достаточно редко.
Конечно, базы-данных на Web-сервере — это не та опция, без которой сайт shareware-программы никак не может обойтись. Но ситуация, в которой вам может очень сильно понадобиться поддержка MySQL, вполне вероятна. Например, хорошим тоном считается создание на сайте форума, где пользователи могут обсуждать различные темы, касающиеся работы программы, ее перспектив, другие сходные (и не очень) вопросы. На рынке существует множество очень мощных готовых программных пакетов для организации форума, некоторые из которых, например, phpBB (http://www.phpbb.com), к тому же, абсолютно бесплатны, так что заниматься самостоятельным написанием скриптов для форума не нужно. Но практически все они для своей работы используют базу данных MySQL, особенно скрипты, написанные на РНР, т. к. в этом языке программирования работа с серверами баз данных организована очень хорошо. Так что волей-неволей приходится заботиться о том, чтобы на Web-сайте поддержка баз данных была включена.

Доступ Telnet (SSH)

Доступ Telnet (SSH)

Эта опция позволяет подключаться к серверу по соответствующему протоколу — Telnet или SSH (последний имеет больше преимуществ с точки зрения безопасности), и выполнять на нем системные команды точно так же, как будто вы сидите за клавиатурой, непосредственно подключенной к серверу. Конечно, уровень прав доступа, выдаваемых абонентам виртуальных серверов, несколько ниже, чем у администратора сервера, однако владелец виртуального сервера все равно имеет достаточно широкие полномочия.
Имея Telnet или SSH-доступ, владелец Web-сайта может отлаживать сложные скрипты прямо на сервере или, например, самостоятельно настраивать различные серверные сервисы. В то же время Telnet/SSH является еще одной потенциальной лазейкой, через которую злоумышленник может взломать защиту сервера. Поэтому хостинг-провайдеры обычно включают Telnet/SSH-доступ в тарифные планы средней и высшей ценовых категорий.
Нужна ли эта возможность — зависит в основном от устройства сайта и потребностей его владельца. Например, если разработчик планирует запускать на своем виртуальном сервере различные дополнительные резидентные сервисы (в Unix-подобных операционных системах они называются "демонами"), устанавливать и запускать какие-то дополнительные утилиты, использовать CGI-скрипты, написанные не на интерпретируемом языке типа Perl, а на C/C++, которые требуют компиляции — для всего этого понадобится Telnet- или SSH-доступ.

Где и как разместить сайт

Где и как разместить сайт

Разместить Web-сайт в Интернете очень легко. Существует огромное число Web-серверов, которые абсолютно бесплатно размещают у себя сайты всех желающих. Достаточно зайти на один из таких серверов, заполнить небольшую анкету — и вы окажетесь обладателем 5—30 Мбайт дискового пространства, с адресом вида www.сервер.соm/~ваше_имя или даже ваше_имя.сервер.соm. Некоторые сервисы предоставляют набор дополнительных возможностей, например: ящик для почты, гостевую книгу или Web-конференцию (форум).
Перспектива получить хостинг абсолютно бесплатно, конечно, очень привлекательна для начинающего шароварщика. Но, к сожалению, по ряду причин бесплатный хостинг для shareware практически бесполезен. Дело в том, что размещение сайта shareware-программы предъявляет к хостингу совсем другие требования, чем, например, размещение домашней странички.
Главное требование к Web-серверу, на котором размещена shareware-программа, — это надежность. Сайт должен быть доступен посетителям 24 часа в сутки, 7 дней в неделю. Конечно, в работе серверов коммерческих хостинг-провайдеров также бывают перерывы (вы понимаете, что абсолютно надежного аппаратного и программного обеспечения не существует), но обычно все неполадки довольно быстро устраняются, т. к. за работоспособностью сервера следят специалисты компании, которая, к тому же, просто обязана обеспечить бесперебойную работу сервера — ведь клиенты платят ей именно за это. А вот то, что бесплатный сервер "лежит", не отвечая на запросы — вполне обычное дело: в России, например, имя старейшего бесплатного сервиса — chat.ru — даже стало нарицательным, обозначающим крайне ненадежный сервер. Частота и длительность перебоев в работе бесплатных хостингов обусловлена рядом причин. Во-первых, они имеют очень высокую нагрузку, ведь число страничек, размещенных на них, исчисляется сотнями тысяч и даже миллионами, тогда как коммерческие провайдеры обычно "довольствуются" гораздо меньшим числом клиентов — несколькими тысячами, реже — несколькими десятками тысяч. Во-вторых, т. к. денег от размещения страниц бесплатный сервис не получает, то и на его поддержку выделены значительно меньшие материальные и людские ресурсы.
В результате этого вполне возможно, что сервер, даже работая вроде бы нормально, из-за перегрузки будет "отфутболивать" запросы пользователей, желающих посмотреть размещенный Web-сайт. А уж то, что письма, отправленные в один из бесплатных почтовых адресов, возвращаются обратно с пометкой "адрес не существует" или другим сообщением об ошибке, хотя точно известно, что почтовый ящик в порядке — самое обычное дело. Потери регистрации из-за того, что потенциальный покупатель не смог "пробиться" на ваш сайт — это еще. пустяки. Гораздо хуже то, что пользователь, уже оплативший регистрацию, не получив от вас регистрационного кода или ответа на свой вопрос (из-за того, что бесплатный почтовый сервер не функционировал), скорее всего, потребует вернуть деньги, а за выполнение этой операции компания-регистратор обычно берет совсем не маленькую комиссию.
Другое требование к хостинг-провайдеру, на сервере которого планируется разместить сайт shareware-программы, — это гарантии предоставления сервиса. Любая коммерческая хостинг-компания работает по договорам и имеет определенные обязательства перед своими клиентами. Разработчик может быть уверен, что компания-хостер будет выполнять эти обязательства в течение длительного времени, а не закроет свой сервис буквально завтра, и "осиротевшему" автору придется в экстренном порядке искать место для размещения своих файлов. Конечно, бизнес есть бизнес: бывает, что фирмы-провайдеры по каким-то причинам меняют условия предоставления услуг или вообще перестают их оказывать. Но заботящаяся о своей репутации хостинг-компания (а таковых большинство) обязательно оповещает своих клиентов о готовящихся изменениях заранее, предоставляя клиентам спокойно перенести свои сайты на площадки других компаний, не допуская простоя, а также, в случае наличия соответствующих обстоятельств, получить свои деньги назад.
Бесплатный же сервер не имеет никаких обязательств перед людьми, размещающими на нем страницы. Это вполне естественно: "тот, кто платит, заказывает музыку". В данном случае за хостинг платит не клиент, а владелец бесплатного сервера, поэтому авторы страниц, размещенных на его площадке, не могут требовать от него выполнения каких-либо обязательств. Вследствие этого бесплатные хостёры меняют условия предоставления своего сервиса без каких-либо уведомлений. Порой эти изменения оказываются очень болезненными для разработчиков shareware-программ.
Например, некоторые бесплатные сервисы, столкнувшись с тем, что с их серверов качается очень много больших файлов, настраивают серверное программное обеспечение таким образом, чтобы файлы можно было скачивать, только щелкая по ссылкам на странице, размещенной на этом же сервере. Таким образом, становится невозможным скачать файл по ссылкам из многочисленных интернет-архивов программ. Самос обидное, что автор программы может этого и не заметить (ведь для него, щелкающего по ссылке на странице сайта своей программы, все будет выглядеть нормально), и долго теряться в догадках, почему и без того слабый ручеек регистрации его программы почти иссяк.
Впрочем, на такие "хлопоты" ради уменьшения своих расходов бесплатный хостер может и не пойти, остановившись на более радикальном способе решения этой проблемы — простом удалении файлов программы с сервера. Конечно, одним из важнейших требований к хостеру, на площадках которого планируется разместить Web-сайт (а сайт shareware-программы особенно) — это пакет предоставляемых услуг. Бесплатный сервер может предложить желающим разместить на нем свои страницы, как правило, только дисковое пространство определенного объема и ящик для электронной почты. Для серьезного же сайта нужно гораздо больше _— свой домен второго уровня (вида ваше_имя.сот), возможность выполнения любых CGI-скриптов, поддержку технологии SSI, языка программирования РНР, баз данных и многих других функций. Ничего подобного бесплатный хостер предложить не может, а вот многие коммерческие компании включают все это даже в относительно недорогие тарифы.
Сайт, использующий различные современные серверные технологии, а не просто являющийся совокупностью нескольких Web-страниц, -- это довольно сложный механизм. При его настройке или расширении его возможностей у владельца сайта неминуемо возникают вопросы к хостинг-провайдеру, без получения ответов на которые дальнейшее развитие сайта невозможно. Конечно же, любая уважающая себя коммерческая компания имеет в своем штате специалистов, отвечающих на вопросы пользователей и оказывающих другие виды технической поддержки — например, настройку Web-сервера, изменение паролей, создания файлов баз данных и т. п. Более того, оказание технической поддержки клиентов — одно из обязательств хостинг-компании, которое она принимает на себя при заключении договора с клиентом.
Наверное, излишне говорить о том, что письма, отправляемые в адрес бесплатного хостера, даже если он и заявляет о наличии у него службы технической поддержки, чаще всего остаются без ответа. Причины здесь те же, что и в случае с отсутствием гарантий предоставления сервиса: "Кто платит, тот и музыку заказывает".
Кто-то из читателей, возможно, скажет: "Все эти преимущества коммерческих хостеров понятны, но все-таки им нужно платить деньги, а это может оказаться слишком накладно!" К счастью, сейчас услуги коммерческого хостинга очень дешевы. В большинстве компаний можно купить тариф, включающий все необходимые для старта в shareware-бизнесе опции, всего за 10$. Если же популярность сайта и программных продуктов, которые размещены на нем, потребует перехода на более дорогостоящий тариф, то это не будет слишком разорительно: популярность shareware-продуктов означает, что доходы разработчика тоже сильно возросли. Доходы от продаж успешной программы во много раз превышают расходы на самый высококачественный хостинг. Во многих компаниях самые дорогие тарифы стоят 50—70$ — т. е. на их оплату нужно будет потратить всего 4—5 регистрации программы в месяц.
Итак, надеюсь, что я убедил своих читателей в необходимости использования коммерческого хостинга для размещения своих продуктов. Теперь нужно разобраться, по каким параметрам необходимо подбирать себе коммерческий хостинг.
В области коммерческого хостинга часто используется термин "виртуальный Web-сервер". Он означает, что Web-сайт размещен не на отдельном компьютере-сервере, а делит его с Web-сайтами других клиентов хостинг-компании. Однако, несмотря на это, управление виртуальным сервером для клиента выглядит точно так же, как если бы его сайт был размещен на отдельном компьютере. Для подавляющего большинства Web-сайтов shareware-программ возможностей виртуальных серверов хватает с избытком.
Примечание
Примечание


Многие компании предоставляют своим заказчикам аренду выделенных серверов, т. е. размещение Web-сайта клиента на отдельном компьютере. Такие серверы в основном востребованы создателями крупных корпоративных сайтов и небольшими хостинг-компаниями. Цена на такую услугу начинается от 100$ в месяц.
Большинство людей, впервые выбирающих платный сервис по размещению Web-сайтов и читающих предложения хостинг-провайдеров, сначала обращают внимание на объем предоставляемого дискового пространства. "50 Мбайт? Неплохо! 100 Мбайт? Замечательно! А может, где-то можно взять 200 Мбайт за 1$ в месяц?" Взять-то можно, но это почти наверняка будет обозначать, что, кроме этих двухсот мегабайтов за 1$, вы больше ничего не получите.
Но нужны ли- вам эти 200 Мбайт? В самом деле, попробуйте прикинуть, сколько вам понадобится места для размещения файлов своих программ. В большинстве случаев достаточно будет нескольких мегабайтов. Файлы HTML-страниц и графики занимают еще меньше — не более одного мегабайта, максимум — двух. Нужно оставить еще немного места для размещения файлов гостевой книги или форума (если вы планируете их завести). Место для log-файлов статистики обычно выделяется отдельно, к тому же они периодически "подчищаются" сервером, чтобы не занимать слишком много места на диске. Вот и получается, что для среднего Web-сайта с несколькими shareware-программами нужно всего около 10 Мбайт дискового пространства. Если вдруг вам понадобится больше дискового пространства, то его можно легко докупить по символической цене.
Гораздо более важными, чем дисковое пространство, являются совсем другие возможности, за которые, если вы погонитесь за мегабайтами, вам придется заплатить дополнительно, и это будут довольно приличные деньги. Поэтому лучше всего обратить свое внимание на другие параметры вашего будущего Web-сервера, чтобы приобрести оптимальный по функциональности тариф.

Лимит трафика

Лимит трафика

Это — самый важный из всех параметров вашего будущего хостинга. Пожалуй, только его несоответствие потребностям конкретного shareware-разработчика с 100%-ной вероятностью приводит к необходимости перенести сайт к другому провайдеру или пойти на дополнительные, и порой очень высокие расходы.
Когда с вашего сайта происходит чтение информации (например, просмотр Web-страниц или загрузка дистрибутивов программ), то хостинг-провайдер платит за этот трафик владельцу канала связи. Естественно, эту оплату он перекладывает на владельца соответствующего сайта, указывая, что в каждый тарифный план на хостинг включен какой-то объем оплаченного трафика — точно так же, как оператор сотовой связи заявляет, что абонентская плата по определенному тарифу включает определенное оплаченное число минут разговора.
Очень многие провайдеры в списке своих услуг объявляют о неограниченном трафике: любое количество загруженной с сайта информации не будет стоить ее владельцу ни цента.
Если вы видите, что хостер заявляет о неограниченном и (или) бесплатном трафике, то это очень серьезный повод насторожиться. Как вы знаете, бесплатный сыр — только в мышеловке. Существует правило: неограниченного трафика не бывает. Никогда, ни при каких обстоятельствах. Просто провайдер, говоря о бесплатном трафике, надеется, что слишком большой трафик одного клиента будет компенсирован за счет других, чей трафик не так велик. Но сегодня на площадках коммерческих хостинг-компаний уже почти не осталось сайтов с одной-двумя страницами, за которые можно "сдирать" такую же плату, как и за большой сайт. Вследствие этого компенсировать трафик одного клиента за счет других уже не получается, поэтому, как только с сайта shareware-разработчика начинают помногу качать большие файлы, владелец сайта получает от провайдера счет на кругленькую сумму. И приходится либо оплачивать его, либо убираться с сервера, причем очень быстро. Провайдеры в таких ситуациях очень нетерпеливы, т. к. они постоянно несут большие расходы: ведь с сайта качают файлы каждый день много раз.
Учитывая сказанное выше, если условия, предоставляемые хостинг-провайдером, вас устраивают, но есть заявление о неограниченном трафике, обязательно напишите письмо в службу поддержки и задайте вопрос относительно действительной неограниченности трафика. Неплохо было бы подсчитать требуемый объем трафика сайта (пусть он будет больше, чем окажется на самом деле) — это поможет специалистам провайдера более точно ответить на ваш вопрос и, возможно, ответ окажется для вас неприятным сюрпризом. А лучше всего пользоваться услугами тех компаний, которые честно заявляют о лимитах трафика. По крайней мере, это означает, что они не пытаются вас надуть или завлечь пустыми обещаниями.
Кстати, здесь проявляется еще один недостаток российских провайдеров, не имеющих своих серверов за рубежом: трафик иностранных пользователей им (а следовательно, и их клиентам) обходится очень дорого. Например, специалист одной из российских фирм, которая предлагала довольно выгодные условия размещения сайтов, в том числе и неограниченный трафик, в ответ на мое письмо сказал, что 1 Гбайт иностранного трафика будет стоить 60$ в месяц — а это (за такой объем трафика) просто астрономическая сумма.
Какие лимиты трафика обычно предлагают "честные" провайдеры? Для тарифов начального уровня — 5—10$ в месяц — типичной является цифра в 3—5 Гбайт в месяц. Для более дорогих тарифов лимит трафика, естественно, возрастает: так, для тарифов ценой 15—20$ трафик может ограничиваться объемами 10—20 Гбайт, а по еще более дорогостоящим тарифам он может быть 25 Гбайт и выше.
Каким же образом определить требуемый вам объем трафика и решить, подходит ли соответствующий тарифный план? С большой точностью предсказать будущий объем трафика нельзя, но кое-какие выкладки произвести все-таки можно. Предположим, что дистрибутив вашей программы "весит" 1 Мбайт. Провайдер предлагает вам тариф стоимостью 10$ в месяц и лимит трафика 5 Гбайт. Один гигабайт из этих пяти оставим "про запас" - - на долю чтения HTML-страниц посетителями, получения вами почты и т. п. Получается, что на оставшийся у вас лимит — 4 Гбайт, пользователи смогут скачать с Web-сайта примерно четыре тысячи экземпляров дистрибутива вашей программы. Так как в среднем программу регистрируют всего 0,5—1% от числа пользователей, скачавших ее, то получится, что это принесет вам, по самой пессимистичной оценке, около 20 регистрации, чего должно хватить не только на оплату десятидолларового хостинга, но и более дорогого тарифного плана, имеющего больший лимит трафика.
Правда, существуют факторы, которые могут негативно повлиять на оценку выгодности того или иного тарифа. Так, если вы предоставляете своим зарегистрированным пользователям последующие обновления программы бесплатно, то большое количество скачивании программы, а следовательно, и увеличение трафика после выхода новых версий может не приносить вам соответствующей материальной отдачи, т. к. значительная часть закачек инициируется уже зарегистрированными пользователями, которые за новые версии программы платить не должны. Другой пример — появление продукта на сайтах архивов программного обеспечения таких стран, как Россия или Китай, где программу покупает очень небольшой процент пользователей, скачавших ее. Несколько российских разработчиков shareware-программ даже просили меня убрать их программы из каталога SoftList.ru. Конечно, их просьбы я выполнял, но, думаю, хостинг-компанию они все-таки выбрали неправильно — лично у меня никаких проблем (при лимите трафика всего в 5 Гбайт) из-за пользователей, приходящих с российских каталогов программ, не возникало.

Организация почтового сервиса

Организация почтового сервиса

Заполучив в свое распоряжение сайт с адресом, например, http:// www.avsoftware.com, было бы неразумно предлагать своим пользователям писать письма по адресу e-mail типа avsoftware@mail.ru. Конечно же, почтовые адреса для обслуживания shareware-бизнеса должны быть в том же домене, что и Web-сайт.
Любой коммерческий провайдер включает в тарифные планы поддержку почтового сервера для соответствующего домена. Вопрос в том, как эта поддержка организована.
Как правило, самые дешевые тарифные планы, стоимостью 10$ и ниже, включают поддержку одного почтового ящика (mailbox) и неограниченное количество почтовых псевдонимов (unlimited e-mail aliases). Это означает, что все письма, приходящие в домен клиента (например, info@avsoftware.com, sales@avsoftware.com, support@avsoftware.com, ivan@avsoftware.com, petya@ avsoftware.com и т. д.) помещаются в один почтовый ящик, а владелец сайта при получении почты почтовым клиентом может обрабатывать эту почту по своему усмотрению — например, производить ее фильтрацию и сортировку с помощью встроенных в почтовый клиент фильтров. Как правило, в почтовом сервисе существует возможность автоматически пересылать сообщения из почтового ящика на другой адрес (e-mail forwarding), что может быть очень удобно для российских разработчиков shareware-программ, т. к. скорость получения почты из ящика у местного провайдера гораздо выше, чем скорость доступа к почтовому ящику на сервере, расположенном в США.
Если над shareware-программой работают несколько человек, например, создав небольшую фирму, то может возникнуть необходимость иметь отдельные почтовые адреса для каждого участника проекта. Поддержка нескольких почтовых ящиков входит в тарифные планы средней и высшей ценовой категории, при этом количество ящиков различается: по недорогим тарифным планам предоставляется 5—10 почтовых ящиков, по более дорогим — от нескольких десятков до сотен.
Впрочем, проблема эффективного разделения почты, приходящей на один ящик, может быть решена и при использовании тарифных планов начального уровня. Некоторые хостинг-провайдеры включают во все тарифные планы услугу "неограниченной пересылки почты" (unlimited e-mail forwarding). Она заключается в том, что владелец сайта может указать в настройках почтового сервиса, что сообщения, приходящие на определенный почтовый адрес (представленный почтовым псевдонимом), будут автоматически пересылаться на другой адрес e-mail. Например, можно указать, что письма, пришедшие на адрес support@avsoftware.com, будут перенаправляться на адрес ivanov@online.ru, а письма, отправленные по адресу webmaster@avsoftware.com, будут пересылаться на адрес petrov@cityline.ru. Таким образом, не смотря на то, что в домене avsoftware.com будет существовать всего один реальный почтовый ящик, почта людей, отвечающих соответственно за техническую поддержку пользователей и оформление сайта, будет изолирована друг от друга.
Будет очень хорошо, если хостинг-провайдер, обеспечивая доступ к почтовому ящику по протоколам POP3/IMAP4 и SMTP, также может предоставить доступ к почте через Web-интерфейс наподобие того, который имеют все серверы бесплатной почты типа mail.ru или mail.yahoo.com. Конечно, постоянно пользоваться таким интерфейсом менее удобно, чем почтовым клиентом, соединяющимся с сервером по протоколам POP3/IMAP4 и SMTP, однако он может очень пригодиться, например, при отъезде в отпуск или в командировку, где почту придется читать в интернет-кафе. Но самое главное -- такой Web-интерфейс позволяет настроить фильтры обработки почты прямо на сервере, без загрузки писем или их заголовков почтовым клиентом. Таким образом, например, можно эффективно бороться с различными почтовыми вирусами -"червями" и "спамом" (нежелательной рекламой): после соответствующей настройки нежелательные сообщения будут автоматически удаляться прямо на сервере.

Поддержка CGIскриптов

Поддержка CGI-скриптов

CGI — это Common Gateway Interface, стандартный шлюзовый интерфейс, определяющий спецификации, по которым осуществляется взаимодействие CGI-скиптов (сценариев) и серверов. Браузеры пользователей непосредственно не взаимодействуют с CGI.
CGI-скрипты, с точки зрения программистов, являются обычными программами. Они могут выполнять системные команды, производить чтение/запись файлов, взаимодействовать с протоколами связи и многое другое. По сложности они бывают самыми разными: от простого сценария в несколько строк до мощных комплексов из десятков программ, взаимодействующих между собой.
С помощью CGI-скриптов Web-сайты из набора статических HTML-страниц превращаются в интерактивные системы: CGI-скрипты позволяют организовать гостевые книги, форумы с обсуждениями, сбор и анализ статистики посещений, голосования, отправку сообщений и многое другое. CGI-программы могут быть написаны на любом языке программирования, который поддерживается Web-сервером; самыми распространенными из них являются Perl, PHP, С и C++.
CGI-скрипты, при всей их полезности, являются потенциальными источниками опасности для Web-сервера. Дело в том, что эти скрипты, как я уже говорил выше, представляют собой полноценные программы, и они могут выполнять на сервере различные системные команды, с их помощью можно взломать защиту сервера, а также производить другие деструктивные действия. Поэтому, в частности, на бесплатных серверах выполнение CGI-скриптов отключают. Коммерческие хостеры эту функцию включают во все свои тарифы, за исключением самых дешевых. В любом случае приобретать тариф без поддержки CGI-скриптов вряд ли стоит: даже если они не требуются владельцу сайта с самого начала, то вскоре все равно понадобятся — без CGI-скриптов серьезный сайт построить невозможно.
Примечание
Примечание


В списках услуг хостинг-провайдеров поддержка CGI-скриптов часто обозначается термином "cgi-bin". Так на Web-серверах традиционно называется каталог, в котором должны храниться и выполняться CGI-скрипты.
Для установки CGI-скриптов на своем сайте вовсе не обязательно уметь их писать. В Интернете доступны тысячи CGI-скриптов, большинство из которых можно использовать совершенно бесплатно. Например, зайдя на мой сайт "Субъективные заметки об интернет-дизайне" (http://www.e-notes.ru), со страницы www.e-notes.ru/guestbook вы можете скачать бесплатный и достаточно продвинутый по возможностям скрипт гостевой книги. Что касается специализированных каталогов CGI-скриптов, то один из самых известных и крупных из них — http://www.cgi-resources.com.

Поддержка доменов и поддоменов

Поддержка доменов и поддоменов

Конечно, любой серьезный сайт, в том числе и сайт shareware-программы, просто обязан иметь собственный домен второго уровня (т. е. домен вида мое_имя.сот, мое_имя.rи и т. п.). Естественно, все коммерческие провайдеры предлагают по всем своим тарифным планам поддержку как минимум одного домена для сайта.
Иногда бывает необходимо зарегистрировать еще один или несколько доменов для одного сайта. Это может потребоваться, когда сайт меняет название и требуется, чтобы все ссылки извне (например, с поисковых машин), указывающие на "старый" домен, продолжали работать. Еще один пример необходимости зарегистрировать несколько доменов на один сайт — когда название сайта включает слова, которые могут в разных странах записываться по-разному: например, слово "анализировать" в США пишется как "analyze", а в других странах - "analyse". Во избежание путаницы лучше всего зарегистрировать сразу несколько доменов, чтобы все варианты написания имени домена вели на один и тот же сайт.
Примечание
Примечание


Интересно, что существует даже такой метод увеличения посещаемости Web-сайтов — "type-in-traffic". Он заключается в том, чтобы зарегистрировать для рекламируемого ресурса один или несколько доменов, созвучных с названием домена какого-нибудь известного сайта. В результате те пользователи, которые при наборе в адресной строке браузера имени сайта допускают опечатку (а таких среди аудитории очень популярных сайтов немало), попадают на рекламируемый сайт. Один из самых ярких образцов сайта "type-in-traffic" — http:// www.altavisa.com — имел 2 500 посетителей в день до тех пор, пока "настоящая" Altavista (http://www.altavista.com) не выкупила этот домен.
Вопрос регистрации нескольких доменов на один сайт решается различными хостинг-провайдерами по-разному. Некоторые предлагают перейти на более дорогостоящий тариф, допускающий поддержку нескольких доменов, а некоторые — просто доплачивать небольшую сумму (2—3$ в месяц) за каждый дополнительный домен.
Иногда владельцу сайта также требуется создать в своем домене несколько доменов третьего уровня, или поддоменов, т. е. доменов вида поддомен.ваше_имя.сот. Причины здесь тоже могут быть_ самыми разными: например, кто-то делает большой сайт, где для каждого продукта хочется завести отдельный поддомен, а кому-то не нравится вид адреса страницы http://www.avsoftware.com/support, а хочется, чтобы он был support.avsoftware.com. Как и в случае с дополнительными доменами второго уровня, хостинг-компании ведут различную политику относительно поддоменов: кто-то допускает любое число доменов третьего уровня для любого тарифного плана, а кто-то требует за каждый домен доплату.

Поддержка РНР

Поддержка РНР

PHP (Personal Home Page, http://www.php.net) — язык программирования, вернее, целая система разработки приложений для WWW. В отличие от традиционных CGI-скриптов, которые представляют собой отдельные файлы с исходным кодом программы, директивы РНР вставляются прямо в HTML-страницу. Когда клиент запрашивает у сервера соответствующий HTML-документ, то сервер сначала "пропускает" файл через интерпретатор PHP, a затем уже отправляет страницу клиенту.
В отличие от традиционных CGI-программ, в РНР значительно проще разрабатывать программы для работы с протоколами HTTP, FTP, РОРЗ, IMAP и SMTP. В версию 4.0 РНР была встроена поддержка сервера баз данных MySQL (в третьей версии РНР это был подключаемый модуль). Кроме того, в отличие от широко распространенного скриптового языка Perl, код программы перед выполнением компилируется, что обеспечивает довольно высокую скорость работы.
Тарифы начального уровня большинства провайдеров не обеспечивают поддержку РНР, поэтому, возможно, вам придется поискать нужную хостинг-компанию, чтобы заполучить РНР при минимальных денежных затратах. Если же в начале вашей работы с Web-сервером РНР вы решили пока не использовать, то можете не сомневаться: рано или поздно он вам все равно понадобится. РНР имеет настолько обширные возможности и развивается так стремительно, что завоевывает все более значительную долю на рынке систем программирования для WWW.

Поддержка SSI

Поддержка SSI

SSI — это аббревиатура словосочетания Server Side Include, что с английского переводится как "включаемый на стороне сервера". Эта технология позволяет Web-серверу включать в текст ваших HTML-страниц любой другой текст: содержимое текстовых файлов или, например, результат работы CGI-скриптов, который обычно оформляется в виде HTML-текста. Достаточно вставить в текст страницы инструкцию вида

и сервер начнет при показе страниц посетителям сайта "на лету" (т. е. без модификации файла на диске сервера) включать в текст страниц содержимое файла sections.html.
Это позволяет, например, хранить описание дизайна страниц в отдельных файлах и значительно облегчить изменение оформления сайта: достаточно сделать какие-либо изменения в файле, содержащем дизайн, как это отобразится и в остальных страницах.
Подавляющее большинство из коммерческих хостинг-компаний включают поддержку SSI даже в самые дешевые тарифные планы. Если же вам все-таки попадется провайдер, отключающий SSI, то такой тариф приобретать не следует, т. к. без SSI обойтись очень трудно.

Подготовка скриншотов

Подготовка скриншотов

Почти на каждом из сайтов, посвященных программному обеспечению, существует раздел "Скриншоты" (Screenshots). Скриншот (дословно "снимок экрана") — это изображение-копия содержимого экрана компьютера. По скриншоту потенциальный пользователь программы может получить представление о ее внешнем виде.
Даже если дизайн сайта выполнен профессиональной студией, почти всегда скриншоты делают сами программисты — ведь новые версии программ выходят очень часто, и сделанные однажды скриншоты устаревают; приходится их время от времени обновлять. Естественно, у программистов есть гораздо более важные занятия, чем изучение тонкостей подготовки графики для WWW, но из-за этого качество публикуемых на Web-сайтах скриншотов сильно страдает: картинка то получается слишком большой и редкий пользователь дождется хотя бы половины ее загрузки, то оказывается размытой и выглядит плохо.
Однако скриншот — очень важная деталь для эффективного представления программного продукта в Интернете. Потенциальному пользователю зачастую гораздо приятнее и интереснее познакомиться с внешним видом программы, чем изучать длинный список функциональных возможностей. Например, мне на сайте каталога программ SoftList.ru пришлось сделать возможность показа скриншотов к опубликованным в каталоге программам во многом из-за многочисленных просьб посетителей. По статистике многих shareware-сайтов, страницы со скриншотами имеет один- из самых высоких уровней посещаемости. Поэтому долго загружающийся или некрасивый скриншот действует на потенциального пользователя программы отталкивающе.
То, что скриншоты на большинстве сайтов с shareware-программами имеют крайне низкий уровень исполнения, часто обусловлено тем, что авторы сайтов обращаются со скриншотами так, как будто это обычная картинка. Однако процесс создания скриншота программы несколько отличается от процесса подготовки обычной графики для Web-сайтов. В этом разделе я расскажу о том, как самостоятельно сделать качественный скриншот к программе.
Замечание 1
Замечание 1


Эти рекомендации относятся к процессу подготовки скриншотов только к программам, чей интерфейс выдержан в стиле оформления Windows-программ (стандартный вид окон и их элементов — заголовков, рамок, кнопок и т. п.). Подготовка скриншотов к программам, имеющим многокрасочный нестандартный интерфейс (например, к большим и сложным играм), мало чем отличается от обработки, скажем, полноцветных фотографий и оптимизации их для Интернета.
Сначала надо выбрать формат файла, в котором будет сохранен скриншот. Конечно, о сохранении файла до того, как создана картинка, говорить рано, но выбор формата файла во многом определяет действия по ее созданию и обработке.
Очень многие авторы совершают ошибку, сохраняя скриншоты в формате JPEG. Ведь интерфейс Windows (впрочем, как и интерфейсы Macintosh и графических оболочек Unix) построен на прямых линиях и довольно небольшом количестве цветов (не более 256, но обычно — от 8 до 32 цветов). А это означает, что для сохранения изображения компьютерных интерфейсов идеально подходит формат GIF: сжатие изображения без потерь качества, лучшая упаковка горизонтальных последовательностей точек (линий), максимум 256 цветов в одном файле. Если же сохранить скриншот в формате JPEG, то в результате используемой в этом формате компрессии изображения прямые линии и надписи на картинке будут сильно размыты, и она приобретет неприглядный вид. Конечно, можно сохранить скриншот в JPEG и без сжатия, но тогда объем получившегося файла будет слишком большим.
Как вы, вероятно, знаете, объем графического файла (формата GIF — особенно) в первую очередь зависит от количества цветов и размеров сохраненной в нем картинки. Вам также, скорее всего, известно, что в графическом редакторе при обработке загруженного файла можно установить любое количество цветов и любое разрешение (эти параметры могут быть ограничены ресурсами компьютера и возможностями конкретной программы). Но сопровождающее изменение размеров картинки незначительное ухудшение качества изображения (то же размытие линий и букв), почти незаметное при оптимизации фотографий, на скриншотах будет сразу бросаться в глаза — ведь все знают, как выглядит интерфейс Windows. Поэтому главная задача — сделать так, чтобы окно программы, с которого делается снимок, изначально содержало относительно небольшое количество цветов, и при этом было нужного размера, чтобы в графическом редакторе не потребовалось изменять эти параметры, ухудшая качество изображения.
Что касается цветов, то в первую очередь нужно обратить внимание на такую деталь. В Windows 98 и более поздних версиях систем семейства Windows фон заголовков окон не сплошной, а градиентный (т. е. в виде плавного перехода от одного цвета (синего) до другого (светло-голубого). В этом переходе "участвуют" несколько миллионов цветов — т. к. действительно плавным такой градиент выглядит в режиме минимум 24 битов (более двух миллионов цветов). Представляете, как сильно пострадает качество скриншота при его оптимизации до стандартных для формата GIF 256 цветов, не говоря уже о 16 цветах? И это при том, что никакой смысловой нагрузки этот градиент не несет, — это не более, чем украшение.
А вот если открыть диалоговое окно Свойства: Экран Windows, выбрать вкладку Оформление и установить для заголовка активного окна одинаковые значения полей Цвет и Цвет 2, то миллионы цветов, присутствующие в окне программы, заменятся всего одним.
Далее, если программа, с которой вы снимаете скриншот, может показывать полноцветную графику (например, это просмотрщик картинок или видеоплейер), то позаботьтесь о том, чтобы в момент, когда вы делаете снимок экрана, в программу было загружено какое-нибудь не очень пестрое, с небольшим количеством цветов изображение. Принцип тот же: чем меньше -тем лучше.
Теперь — о размере окна программы. На первый взгляд, не нужно особо задумываться над этим: проще простого сделать скриншот, а потом в графическом редакторе уменьшить изображение до нужного размера. Но в данном случае (когда речь идет не об изображении вообще, а о скриншоте) налицо два больших минуса. Во-первых, уменьшение снимка экрана отрицательно сказывается на качестве восприятия информации пользователем: на небольшом изображении трудно рассмотреть элементы интерфейса и оценить качество их исполнения. Во-вторых, и это самое неприятное, при масштабировании снимка экрана в графическом редакторе четкие линии оконного интерфейса Windows размываются, и теряется все преимущество формата GIF, который, как известно, лучше всего сжимает четкие и контрастные изображения. Например, если размеры рисунка (см. Рисунок 9.10) уменьшить в графическом редакторе в восемь раз, то получившийся в результате графический файл будет точно таким же, как файл исходного, большого изображения.

Пользовательский файл htaccess

Пользовательский файл .htaccess

Это специальный файл настройки Web-сервера Apache, устанавливаемого на площадках большинства хостинг-компаний, указывающего различные параметры доступа к серверу. Внося изменения в этот файл, можно, например,
закрыть паролем какие-либо каталоги своего Web-сайта, чтобы доступ к ним имели только отдельные пользователи; заменить стандартные малоинформативные сообщения об ошибках (например, "404 Файл не найден") на собственные, соответствующие дизайну сайта и рассказывающие пользователю о причинах и способах устранения ошибок; изменить или добавить способы обработки разных типов файлов (например, считать одни из них программами (скриптами), другие — текстовыми, третьи — двоичными).

Регистрация домена

Регистрация домена

Среди многочисленных опций, параметров и характеристик Web-сайта, о которых я говорил в предыдущем разделе, несколько особняком стоит доменное имя. Об этом я хотел бы рассказать поподробнее.
Доменное имя, или, для краткости, просто "домен" - непременный атрибут любого серьезного Web-сайта, свидетельствующий о том, что владелец бизнеса, который представлен этим сайтом, относится к своему делу ответственно. Конечно, 100% гарантии надежности бизнеса доменное имя не дает: в США во времена "бума Интернета" (1998—1999 гг.) открылись тысячи компаний, не имевших ничего, кроме домена .com. Они, выдавая себя за солидные и преуспевающие компании, брали на себя различные финансовые обязательства, а затем, так и не сумев наладить свою деятельность, закрывались, оставив своих партнеров и клиентов ни с чем.
Несмотря на то, что домен сайта еще не дает гарантии надежности и долгосрочных перспектив, его отсутствие почти со стопроцентной вероятностью свидетельствует о несерьезности намерений человека, открывшего этот сайт. Такой уж выработался стереотип у зарубежных пользователей: серьезные компании всегда заботятся о регистрации собственного доменного имени, а те, кто не удосуживается зарегистрировать его, чаще всего относятся к своему сайту недостаточно серьезно. При этом пользователи по инерции переносят отношение потенциального партнера к Интернету и на его бизнес: стоит ли доверять владельцу сайта свои деньги, если он не может потратить несколько долларов на регистрацию домена?
А можно ли получить доменное имя бесплатно? В Интернете сегодня раздают "на халяву" почти все что угодно, однако за домен второго уровня нужно будет обязательно заплатить, хотя и довольно скромную сумму.
Кто-то из читателей может возразить: "Как же так, ведь в Интернете существуют сервисы, позволяющие зарегистрировать домен бесплатно, например, www.namezero.com". Действительно, такие сервисы существуют. Однако при регистрации доменов через эти службы владельцем домена становится не пользователь, подавший заявку на регистрацию, а соответствующая служба, иными словами, она регистрирует домен не "на пользователя", а "на себя". А это означает, что распоряжается этим доменом служба (та же namezero.com), и она имеет полное право перенаправить домен на любой другой проект, а не на сайт пользователя, если это будет ей выгодно. Доменное имя популярного проекта может представлять собой большую ценность (хотя бы потому, что оно приводит на сайт много посетителей), которой захотят воспользоваться многие. А если пользователь захочет перерегистрировать домен "на себя", то его придется выкупать у соответствующей службы по бесплатной регистрации доменов — естественно, не по номинальной стоимости, а по той, которую назначит эта служба. Да, это еще одна яркая иллюстрация пословицы "Бесплатный сыр только в мышеловке".
И все-таки заполучить доменное имя бесплатно очень легко, хотя деньги заплатить все равно придется. Вы спросите, каким образом возможна такая парадоксальная ситуация: деньги уплачены, но домен все равно достается бесплатно? Все просто. Очень многие хостинг-провайдеры при оплате клиентом услуг хостинга сразу за год регистрируют для него домен бесплатно. Никакого подвоха здесь нет: домен регистрируется на имя клиента, и именно клиент становится его владельцем. Просто хостинг-провайдер, получив от клиента значительную сумму денег (а за 12 месяцев это будет минимум долларов 100), небольшую ее часть тратит на регистрацию домена.
Сколько же стоит домен в зоне .com? Себестоимость домена — 8,95$ в год. Это та сумма, которую придется заплатить, если осуществлять процедуру регистрации самостоятельно. Все хостинг-провайдеры регистрируют домены для своих клиентов и обычно они берут некоторую сумму за эту услугу, т. е. в графе "Регистрация домена .com" прайс-листа хостинг-компании указывается не 8,95$, а большая сумма. Если она составляет 10—15$ — это нормально, если больше — есть повод поискать другого провайдера: регистрация домена — не такая уж сложная процедура, чтобы требовать за нее десятки долларов.
Читатели, наверное, заметили, что я говорю о доменных именах в зоне .com, а не в какой-то другой зоне. Дело в том, что эта зона наиболее оптимальна для сайтов shareware-программ, да и вообще любого бизнес-сайта. Пользователи уже давно привыкли к тому, что Web-сайты большинства серьезных компаний располагаются именно в зоне .com. Впрочем, "родственные" доменные зоны - .net и .org тоже неплохи, но .com все-таки более "престижна", т. к. предназначается для доменов именно коммерческих сайтов.
А вот в российской зоне .ru домен для shareware-программы следует регистрировать только в том случае, если программа ориентирована на российский рынок. Иначе сайт с доменом .ru только отпугнет потенциальных посетителей из зарубежных стран. Увы, там до сих пор распространено мнение, что половина россиян, работающих в области информационных технологий, параллельно сотрудничают с КГБ. Да и имиджу нашей страны в глазах иностранцев не позавидуешь. У многих из них Россия ассоциируется со словами "терроризм", нарушения прав человека", "экономическая нестабильность", "хакеры" и т. п. Так что любому, кто собирается добиться успеха на мировом shareware-рынке, нужно наступить на горло собственной патриотической песне и зарегистрировать доменное имя в зоне .com.
Если вы планируете зарегистрировать доменное имя, созвучное с названием вашей программы, то очень важно сделать это как можно быстрее, по возможности еще до выхода вашей программы на рынок. Дело в том, что как только ваша программа станет заметна — например, получит хорошие рейтинги в интернет-каталогах программного обеспечения, о ней начнут говорить в конференции — обязательно найдутся люди, которые зарегистрируют название вашей программы в качестве доменного имени, чтобы затем перепродать его автору программы — естественно, не за девять долларов, а уже за сотни и тысячи долларов (наверное, вы слышали термин "киберсквот-тер" - он как раз и обозначает человека, регистрирующего домен для перепродажи). Среди российских разработчиков очень много пострадавших таким образом авторов. Поэтому доменное имя — одно из важнейших капиталовложений на самом раннем этапе деятельности на_рынке shareware — еще на стадии написания самой первой бета-версии. Пускай у вас пока не будет своего Web-сайта — это не помеха: многие хостинг-провайдеры предлагают услугу регистрации домена без подписки на услуги хостинга. И, конечно же, домен можно зарегистрировать самостоятельно, зайдя на сайт одного из регистраторов доменных имен (например, www.godaddy.com или www.nic.ru), указав свои данные, название желаемого домена и осуществив оплату регистрации.

Статистика посещений

Статистика посещений

Shareware-разработчику обязательно нужно иметь доступ к детальной статистике посещений своего сайта, сгруппированной и отсортированной по различным параметрам: дате, времени, стране (откуда пришел пользователь), ссылкам (т. н. referrer, т. е. информация о том, со ссылок на каких сайтах приходят посетители), объеме трафика и т. д. Это позволяет shareware-разработчику, помимо удовлетворения собственного любопытства, оценить эффективность своих действий по продвижению программы и сайта: например, из каких стран больше всего ходят пользователи на сайт; какие интернет-архивы программного обеспечения приводят на сайт посетителей; как изменилась динамика посещений после выхода новой версии программы и т. п.
Обычно хостинг-провайдер устанавливает на своем сервере специальную программу для анализа log-файлов (одна из самых известных называется Webalyzer, http://www.mrunix.net/webalizer), позволяющую просматривать статистику посещений прямо в окне браузера и представляющую ее в наглядной форме, например, в виде диаграмм.
Некоторые провайдеры, впрочем, все еще по старинке предоставляют только "доступ к логам". Это означает, что log-файлы с записями посещений пользователей располагаются в одном из подкаталогов на сервере, и владелец сайта должен сам заботиться о том, какими средствами эти файлы просмотреть.

Страна размещения Webсервера

Страна размещения Web-сервера

Если ваш shareware-продукт не ориентирован исключительно на Россию (например, бухгалтерская программа), значит, подавляющее большинство ее зарегистрированных пользователей будет из США, Канады, Западной Европы, Японии и Австралии. Поэтому сайт должен быть размещен на площадке зарубежного провайдера одной из этих стран, лучше всего — США, т. к. пользователи из США — наиболее активные потребители shareware. В этом случае большинство посетителей вашего сайта будут иметь максимально возможную для них скорость доступа к нему
Что же касается российских провайдеров, то даже у самых лучших из них скорость доступа к их серверам из-за границы заметно ниже, что для размещения shareware не подходит: зарубежные пользователи испытывают огромное раздражение, ведь им приходится скачивать большие файлы с дистрибутивами программ! Некоторые российские shareware-разработчики, пользовавшиеся услугами российских провайдеров, отмечали, что после переноса их сайтов на площадки зарубежных хостеров количество регистрации резко возросло.
В России пока существует только один провайдер, который имеет собственные серверы, находящиеся в США, — Мастак.Ру (http://www.mastak.ru), и поэтому только он может рассматриваться как реальная альтернатива зарубежным хостинг-провайдерам для размещения shareware-программ. Ранее некоторые другие российские хостеры тоже предлагали своим клиентам размещение виртуальных серверов в США, однако постепенно они отказались от этого.

Структура сайта

Структура сайта

Проектирование Web-сайтов и разработка их дизайна -- тема, конечно, очень обширная, которая сама по себе заслуживает отдельной книги. В этом разделе я расскажу только об основных аспектах проектирования Web-сайта для shareware-программы. Информацию о Web-дизайне, правилах HTML-верстки и графического дизайна, различных технологиях разработки Web-сайтов можно почерпнуть из многочисленных специализированных справочных пособий — как печатных, так и online-источников. Например, вы можете почитать мои "Субъективные заметки об интернет-дизайне", опубликованные по адресу http://www.e-notes.ru.
Особое внимание нужно уделять структуре сайта, т. е. разбивке содержания сайта на разделы и их компоновке. Главное требование к ней — разделы сайта должны быть организованы таким образом, чтобы пользователь мог легко получить доступ к нужной информации. Не менее важное требование к структуре сайта — она не должна состоять всего из пары-тройки разделов. Сайт с неразвитой структурой разделов производит впечатление не серьезного бизнес-ресурса, а любительской домашней странички.
Некоторые сайты, посвященные shareware-программам, в качестве списка основных разделов имеют список программ, представленных на нем. Пользователь выбирает интересующий его продукт, попадает на страницу с данными о соответствующей программе и читает описание программы, смотрит скриншоты ("снимок экрана"), нажимает ссылки "Download" или, если он хочет оплатить регистрацию программы - "Register" или "Order". Если при размещении всей этой информации на одной странице объем страницы получается слишком большим, то дополнительно создаются страницы для загрузки и регистрации соответствующей программы.
Более эффективной организацией сайта считается создание отдельных глобальных разделов Download и Order (Register, Purchase). Под словом "глобальный" здесь имеется в виду то, что в таком случае в разделе Download содержатся ссылки на загрузку файлов всех программ, имеющихся на сайте, а в разделе Order (Register), соответственно, ссылки на формы регистрации также всех программ.
Дело в том, что очень многие посетители заходят на сайт с намерением сразу скачать программу, без желания читать информацию о ней. Это, например, те пользователи, которые уже имеют одну из предыдущих версий программы и хотят обновить ее, или те, которым порекомендовали программу друзья, знакомые или собеседники в Web- или FIDO-конференции. По проведенным исследованиям, переход с главной страницы в раздел "Download" - один из самых популярных маршрутов посетителей сайта.
Размещение ссылок для загрузки файлов программ на одной странице дает еще один положительный эффект. Пользователь, зайдя на эту страницу, чтобы скачать какую-то одну программу, видит ссылки и на другие продукты. Очень часто эти ссылки вызывают его интерес: он скачивает, тестирует какие-то из этих программ и, вполне возможно, оплачивает и их регистрации.
Примечание
Примечание


Рекомендуется делать так, чтобы перечень продуктов компании (например, в виде раскрывающегося списка) был доступен на каждой странице сайта. Это поможет привлечь к продуктам, представленным на сайте, внимание тех пользователей, которые зашли на внутреннюю страницу сайта, например, из поисковой системы, не были на главной странице сайта и, следовательно, не видели список продуктов, размещенный там.
Назначение глобального раздела Order (Register) несколько другое. Если его название видно на главной странице, то пользователь сразу запоминает, что программы с этого сайта нужно будет зарегистрировать. Также наличие такого раздела, имеющего "глобальный" статус, как бы подчеркивает серьезность бизнеса, ведущегося на данном сайте.
Помимо разделов Download и Order (Register), хороший shareware-сайт должен содержать еще несколько секций.
Очень часто на сайтах shareware-программ встречается раздел под названием Awards, где размещаются логотипы всевозможных наград и рейтингов, полученных программой от различных online-архивов, обозрений и журналов -вид всех этих "регалий" производит хорошее впечатление на пользователей и потенциальных покупателей программных продуктов. У хороших и известных программ такие страницы напоминают целый иконостас.
Хорошим ходом является организация раздела "Ответы на частые вопросы" (Frequently Asked Questions, FAQ), где будут публиковаться ответы на вопросы пользователей, которые задают чаще всего. И пускай таких вопросов очень мало или их нет вообще (например, потому, что программа только появилась на рынке). Подавляющее большинство страниц FAQ составляется самими авторами программных продуктов. Они просто представляют себя на месте пользователей и пишут ответы на самые очевидные, по их мнению, вопросы. Конечно, по мере увеличения популярности shareware-программы пользователи начинают сами задавать вопросы, и страницы FAQ пополняются ответами уже на "настоящие" часто задаваемые вопросы.
Страницы FAQ позволяют одним махом убить двух зайцев. Во-первых, предоставить пользователям дополнительные разъяснения по работе с программой, облегчив ее освоение и улучшив впечатление о ней. Во-вторых, недвусмысленно намекнуть тем, кто впервые попал на сайт, что программы, представленные на нем, пользуются немалым вниманием людей (не даром же они так активно ей интересуются, задавая все эти вопросы), так что неплохо было бы присоединиться к числу пользователей этих программных продуктов.
Еще один раздел, который очень благоприятно повлияет на популярность Web-сайта и программ, размещенных на нем, — это организация форума, т. е. системы обсуждений различных тем. В нем пользователи могут задавать свои вопросы, обмениваться опытом использования программ и т. п. Конечно, в форуме обязательно должны участвовать разработчики программы, как минимум, отвечая на вопросы пользователей. Это привлечет внимание людей, использующих программу (каждому приятно пообщаться почти "в живую" с автором понравившейся программы), и продемонстрирует, что разработчикам интересны пользователи их программных продуктов. Возможно, вокруг сайта образуется своеобразное community (сообщество) пользователей, которое сможет оказать неоценимую помощь в деле развития и продвижения программы (см. разд. "Техническая поддержка"гл. 10).
Конечно, на сайте могут быть и другие разделы — со скриншотами (см. разд. "Подготовка скриншотов" данной главы), информацией о разработчике, новостями и пресс-релизами и т. д.

Свойства экрана Windows с измененными

Рисунок 9.3. Свойства экрана Windows с измененными параметрами заголовка окна


Учитывая это, лучше всего изменить размеры окна "снимаемой" программы до нужных вам (с некоторыми окнами, например окнами диалогов, это не удастся -- т. к. они имеют неизменяемую границу). При этом не нужно стесняться "оставить за кадром" часть кнопочных панелей инструментов или уменьшить рабочее поле (там, где, например, в MS Word набирается текст) — главное, чтобы зрителю было понятно их функциональное назначение.
Примечание
Примечание


Иногда бывает так, что уменьшить размеры окна программы нельзя, т. к. его содержимое должно быть показано "во всей красе". Тут ничего не поделаешь: такой скриншот приходится масштабировать в графическом редакторе и затем сохранять его в формате JPEG. Единственное, что радует — цветов в таких снимках экрана относительно немного, и можно применять высокий уровень сжатия JPEG (60-70%) — снижение качества почти незаметно.
Теперь нужно сделать непосредственно сам скриншот -- т. е. изображение окна программы. Для этого необходимо скопировать содержимое экрана компьютера в буфер обмена Windows.
Существует множество программ для создания скриншотов. С их помощью можно скопировать содержимое экрана или его часть в буфер, отредактировать его и записать на диск. Например, одна из самых известных программ такого типа — HyperSnap DX (http://www.hyperionics.com). Однако в большинстве случаев для копирования содержимого экрана или его части не требуется специальной программы.
Итак, чтобы скопировать содержимое экрана компьютера в буфер обмена, нажмите клавишу . Если вам нужно скопировать только содержимое активного окна, нажмите комбинацию клавиш +. При этом в буфер обмена не попадает курсор мыши. Если вам нужно, чтобы он присутствовал на снимке экрана, то необходимо воспользоваться упоминавшейся выше HyperSnap DX или любой другой аналогичной программой. Лично я пользуюсь для таких "съемок" замечательным просмотрщиком изображений IrfanView (http://www.irfanview.com), который отличается компактностью, высокой скоростью работы, статусом "freeware" и богатым набором возможностей, среди которых есть и Capture (Захват).
После того как содержимое экрана скопировано в буфер обмена, нужно открыть имеющийся у вас графический редактор. У многих из них в меню Edit (Правка) есть функция Paste As New Image (Вставить как новое изображение). В распространенном у нас Adobe Photoshop нужно сделать на два щелчка мыши больше: создать новый файл (размеры для него будут автоматически предложены равные размерам изображения, находящегося в буфере обмена) и нажать +. Результат — новый графический файл, содержащий сделанный вами снимок экрана.
Далее, если нужно, вы можете отредактировать картинку — например, выделить область изображения и скопировать ее в новый файл.
И, наконец, финальная стадия — сохранение файла. В зависимости от возможностей конкретного редактора, вам нужно выбрать цветовую палитру изображения. Поэкспериментируйте с палитрами 8, 16, 32, 64, 128, 256 цветов и остановитесь на той, при которой соотношение "качество картинки/объем файла" является оптимальным. После этого сохраните файл на диск в формате GIF — качественный скриншот готов.

Техническая поддержка

Техническая поддержка

Как уже говорилось выше, сравнивая бесплатный хостинг с коммерческим, техническая поддержка является одним из основных преимуществ последнего. Однако качество технической поддержки у разных коммерческих провайдеров различается, и порой очень сильно. Специалисты одних компаний работают семь дней в неделю и быстро отвечают на вопросы, а других -только по будням, да и то ответ от них идет два-три дня, а то и больше. Между тем, Web-сайт работает не только по будням, а всю неделю, и проблемы, возникшие при его функционировании, почти всегда требуют как можно более быстрого решения.
Помимо оперативности, специалисты хостинг-компаний должны быть вежливыми и обходительными. Было бы очень обидно, платя деньги за услугу, получать на свои вопросы ответы, тон которых демонстрирует недовольство и пренебрежение: "Как же мне надоели эти глупые юзеры с их дурацкими вопросами".
Чтобы по возможности уменьшить шансы "нарваться" на неоперативную и нелюбезную службу технической поддержки, можно написать письмо на соответствующий адрес того хостинг-провайдера, услуги которого вас заинтересовали. В нем можно задать несколько вопросов относительно их хостинга — например, о действительном объеме лимитов трафика. При этом не нужно упоминать, что вы собираетесь стать их клиентом — пускай ваше письмо будет казаться вопросом праздношатающегося. Если ответ на ваши вопросы будет быстрым и вежливым, то можно надеяться, что со своими клиентами служба технической поддержки будет еще более учтива.

Webсайт одной из sharewareкомпаний — SecureAction Research

Рисунок 9.1. Web-сайт одной из shareware-компаний — SecureAction Research


Такой способ организации "представительства" своей программы в Интернете не только неудобен и ненадежен, но и малоэффективен. Во-первых, отдельный Web-сайт разработчика (или его отдельной программы) имеет гораздо больше возможностей для размещения информации, чем одна страничка на сервере интернет-архива. Во-вторых, автор никогда не может быть уверен в том, что его программа будет доступна желающим ее попробовать и впредь: интернет-архив может по каким-то причинам убрать программу со своего сервера или вообще прекратить практику физического размещения файлов. Например, в 2001 году, в разгар кризиса интернет-компаний, несколько крупных каталогов программ закрыли свои файловые архивы из-за высокой стоимости исходящего трафика. И, наконец, собственный Web-сайт shareware-разработчика — одно из свидетельств того, что автор намерен серьезно заниматься этим бизнесом и дальше (a shareware — это бизнес), что помогает оставить хорошее впечатление у потенциальных пользователей и увеличить число регистрации. Откровенно говоря, я не представляю, как можно добиться хоть каких-то успехов на рынке shareware, не имея собственного Web-сайта.

Зачем программе собственный Webсайт

Зачем программе собственный Web-сайт

Как уже говорилось в гл. 1, сегодня Интернет — основной путь распространения shareware-программ, поэтому shareware-продукт обязательно должен быть доступен для пользователей Интернета.
Самый распространенный способ представления программы в Интернете -ее размещение на Web-сайте разработчика. Автор программы регистрируется на одном из многочисленных сервисов (платном или бесплатном), предоставляющих хостинг (т. е. размещение) Web-сайтов в Интернете, получает для него имя по своему желанию, создает на сайте страницы с информацией о своих программах и, наконец, загружает на сервер дистрибутивы. После этого интернет-пользователи могут заходить на сайт программы, читать подробности о ней, скачивать ее для тестирования, оплачивать регистрации и т. д.
Но некоторые shareware-разработчики, судя по специализированным интернет-конференциям по shareware, без энтузиазма и, более того, даже с опаской относятся к вопросу создания собственного Web-сайта. Регистрация у хостинг-провайдера, разработка HTML-страниц и обновление, копирование файлов на сервер по FTP-протоколу — все это кажется им слишком сложным и запутанным. По их мнению, лучше закачать файл программы на сервер одного из тех архивов программного обеспечения, которые размещают дистрибутивы непосредственно на диске своего сервера (а не ограничиваются ссылкой на файл, лежащий на сайте разработчика). После этого online-архив автоматически создаст необходимую страницу с информацией о программе и ее авторе, и можно будет указывать ее в качестве домашней страницы программы, а желающим скачать программу давать URL файла на сервере архива.

Запрос пароля для доступа к защищенному каталогу

Рисунок 9.2. Запрос пароля для доступа к защищенному каталогу


Возможность настройки Web-сервера с помощью пользовательского файла .htaccess обычно не относится к услуге, за которую нужно много платить. Однако часто провайдеры отключают обработку некоторых параметров, указываемых в .htaccess, в зависимости от стоимости тарифного плана. Например, по наиболее дешевым тарифам обычно не допускается установка пароля каталогов — эта возможность традиционно относится к разряду "продвинутых", не предоставляемых для виртуальных серверов начального уровня. Другой случай — запрет исполнения CGI-скриптов где-либо, кроме каталога cgi-bin: .это делается в целях обеспечения безопасности сервера.
Учитывая сказанное выше, в ситуации, когда в списке услуг хостинг-компании по тому или иному тарифному плану нельзя понять, какие опции .htaccess разрешены, то лучше всего перед выбором тарифа обратиться в службу технической поддержки провайдера с соответствующим вопросом.
Итак, я перечислил все основные возможности хостинга, предлагаемые большинством провайдеров и требуемые для построения эффективного Web-сайта для shareware-программы. Конечно, существуют и другие опции, которые могут быть востребованы в зависимости от личных потребностей разработчика и его квалификации: crontab (запуск программ, скриптов, на сервере по расписанию), поддержка FrontPage Extensions (серверные модули для автоматизации сайта и работы с ним); анонимный FTP-сервер (виртуальный FTP-сервер с адресом вида ftp://ftр.ваше_имя.соm — скорее престижный атрибут, чем действительно полезная опция); WAP (просмотр сайта с помощью сотовых телефонов и тому подобных устройств), возможность заведения на сервере собственных пользователей с отдельными каталогами и почтовыми ящиками и т. д.

Учебник по созданию shareware программ

Ассоциация профессионалов shareware

Ассоциация профессионалов shareware

В разд. "Профессионалы shareware" гл. 1 рассказывалось о создании самого крупного, известного и влиятельного объединения shareware-разработчиков -Ассоциации профессионалов shareware (Association of Shareware Professionals, ASP). В этом разделе я расскажу о том, какие преимущества получают разработчики, вступившие в ASP.
Примечание
Примечание


Членство в ASP платное — 100$ в год. Однако подсчитать, сколько денег принесет вступление в ASP и какова будет прибыль, вряд ли возможно. Членство в ASP увеличивает общий уровень разработчика и его проекта, а вследствие этого — вызывает рост продаж, но выразить в цифрах это преимущество нельзя.
Одно из основных преимуществ ASP, которое, впрочем, имеет несколько абстрактный характер, — это престиж и уважение со стороны сотрудников многих компаний, работающих в области shareware. Обычно достаточно одного упоминания о том, что ты — член ASP, чтобы решить проблемы с сабмитом на shareware-архивы или переводом денег от регистратора.
А вот с пользователями, увы, все не так однозначно. Многие пользователи "старой закалки", которые до сих пор работают с BBS и еще помнят, кто такой Джим Кнопка, с большим уважением относятся к продуктам, на Web-сайтах которых стоит логотип ASP. А некоторые, не доверяющие shareware-продуктам, наоборот, избегают регистрировать программы, авторы которых говорят о своем членстве в ASP. Из-за этого некоторые члены ASP даже выступали за переименование организации в "Association of Software Professionals", но эта инициатива не была поддержана остальными.
Второе преимущество ASP — секция "Member Only" на Web-сайте ASP (http:// www.asp-shareware.org), предназначенная только для членов организации. В ней замечательный раздел "Shareware Guide", где освещаются практически все вопросы shareware: какую программу писать, как составлять документацию, как реализовывать защиту, в каких shareware-архивах регистрировать программу и т. д. Написаны эти материалы в основном "монстрами" shareware, постоянно обновляются и очень полезны — и для новичков, и для профессионалов.
Также -очень полезными, по отзывам членов ASP, являются "закрытые" news-конференции. На вопрос по практически любой теме (техническая реализация, и маркетинг) можно получить большое количество ответов от опытных и авторитетных shareware-разработчиков. Кроме того, в этих конференциях нет никакого спама, т. е. нежелательной, "мусорной" рекламы.
Кроме того, на сайте ASP есть раздел "Special Offers", в котором члены ASP предлагают своим коллегам специальные предложения, например значительные скидки на shareware-продукты и услуги.
Наконец, не стоит сбрасывать со счетов и награды, вручаемые на Shareware Industry Conference (см. разд. "Профессионалы shareware" гл. 1). Стать лауреатом не просто, но, по крайней мере, получить номинацию вполне реально. Например, в 2001 году на награды SIC выдвигались и российские shareware-продукты — The Bat! и ReGet.
В общем, все shareware-разработчики, вступившие в ASP, отмечают, что 100$, потраченные на оплату членства в этой организации, являются одним из самых выгодных вложений в собственный shareware-проект.

Банковский чек

Банковский чек

Чек — это выраженное в письменной форме поручение, выданное в данном случае регистратором "своему" банку выплатить определенную сумму. Чек представляет собой красиво оформленную бумагу, в которой указывается плательщик, получатель платежа, сумма, которая должны быть выплачена, а также другие реквизиты. Регистратор высылает shareware-разработчику чек в обычном "международном" конверте.
Для того чтобы получить деньги по полученному чеку, разработчик должен сдать его в местный банк, который проверит подлинность чека и предъявит его в банк, который должен обналичить чек (эта операция называется инкассо). После этого разработчик получит в местном банке наличные за вычетом комиссии банка.
Чек — достаточно надежный способ получения денег. Объясняется это, в частности, тем, что чек — это еще не непосредственно платеж, а только обещание заплатить. При предъявлении чека банк, обязанный выдать деньги, запросит подтверждение чекодателя. Кроме того, для выдачи денег обязательно предъявление паспорта. Вследствие этих двух причин, например, не страшна потеря чека при его пересылке из США в Россию: если чек попал в руки злоумышленника, то он не сможет получить по нему деньги. А разработчик, недождавшись чека, может попросить регистратора заново выслать чек, что и будет сделано без каких-либо дополнительных вопросов. Регистратор не рискует пострадать от возможного мошенничества: банк запросит подтверждение платежа, и получить деньги повторно, по дубликату чека, будет невозможно.
Еще одно достоинство чеков — в некоторых коммерческих банках получить деньги по чеку легче, чем на валютный счет. Чек обналичивается без каких-либо вопросов, а вот при попытке получить валютный перевод банк может потребовать предъявить письменный договор с регистратором или, что еще хуже, потребовать доказать, что получение денег не связано с предпринимательской деятельностью.
Недостатков у этого способа получения денег два. Во-первых, процедура обналичивания чека занимает довольно продолжительное время — от одного месяца до трех, в зависимости от банка, производящего инкассо. Неудобство это очень ощутимо по сравнению с переводом на валютный счет, деньги с которого можно снять сразу после получения их банком. Да и скорость прохождения платежей у валютного счета выше — из США в Россию перевод идет около недели, тогда как скорость работы "обычной" почты оставляет желать лучшего. Во-вторых, банки, принимающие чеки иностранных банков на инкассо, обычное явление только в крупных российских городах. На периферии с обналичиванием чеков, по отзывам живущих там шаровар-щиков, большие проблемы. Кроме того, банки, принимающие чеки, пришедшие из-за рубежа, очень не любят с ними связываться и частенько меняют свою политику по отношению к ним. Например, зайдя как-то по своим делам в местное отделение Сбербанка, я заметил на двери валютного отдела объявление о том, что прием на инкассо чеков иностранных банков прекращен "на неопределенный срок"...

Блокировка покупок с бесплатных почтовых ящиков

Блокировка покупок с бесплатных почтовых ящиков

Большинство заказов на регистрацию программы, в графе "E-mail" которых указан адрес на бесплатном почтовом сервере типа hotmail.com или yahoo.com, — это фрауды. Бесплатный почтовый адрес характеризуется анонимностью владельца, т. к. по нему практически невозможно "вычислить" фамилию и другие личные данные человека, который пользуется им. А вот если в качестве e-mail указан адрес, выданный интернет-провайдером или корпоративный почтовый ящик, то в случае фальшивости сделанной покупки предъявить претензии такому "покупателю" будет очень легко. Именно поэтому почтовые ящики на бесплатных серверах облюбовали любители получить регистрационный ключ "на халяву". И поэтому возможность со стороны регистратора запретить указывать в форме заказа бесплатные почтовые адреса будет совсем не лишней.
Замечание 1
Замечание 1


Нужно сказать, что эта мера не дает 100% защиты от фраудов и, кроме того, не каждый покупатель с бесплатным почтовым адресом — это "халявщик". И у меня, и у других shareware-разработчиков были вполне нормальные покупатели с почтовыми ящиками, например, на hotmail.com.

Большой выбор способов оплаты регистрации

Большой выбор способов оплаты регистрации

Многие пользователи, напуганные частыми сообщениями о хакерах, крадущих номера кредитных карточек или перехватывающих передачу другой ценной информации, опасаются доверять номер своей кредитки Интернету. Поэтому хороший регистратор должен принимать кредитки не только online, но и по телефону (желательно — "800", т. е. бесплатному для звонящего), по факсу и по e-mail. Также желателен прием регистратором к оплате чеков (хотя бы американских банков), а также дорожных чеков на предъявителя (Рисунок 10.2).

Ценообразование

Ценообразование

Что такое "регистратор"

Что такое "регистратор"

Регистратор — специальная служба, которая принимает от конечного покупателя деньги и переводит их автору shareware-программы. Таким образом, регистратор помогает программистам-одиночкам, небольшим фирмам и даже крупным компаниям получать платежи от пользователей по всему миру.
Первым регистратором стала существующая ныне компания PsL (Public Software Library, http://www.pslweb.com). Основанная в 1984 году (см. разд. "Распространение shareware-программ" гл. 1) фирма открыла в 1989 году первый в мире процессинговый центр по приему и обработке платежей по кредитным картам и заказов, сделанных по телефону, факсу, электронной и обычной почте.
В настоящее время на shareware-рынке регистраторов работает очень много. Жестокая конкуренция заставляет их постоянно расширять ассортимент предоставляемых услуг и улучшать их качество. Сегодня многие регистраторы не только принимают платежи, но и рассылают регистрационные коды к программам, составляют и продают сборники программного обеспечения на CD-ROM, создают собственные online-каталоги программ, ведут рекламу продуктов, создают целые интернет-магазины по продаже программ (Рисунок 10.1). Несмотря на то, что регистратор является посредником между продавцом программы и покупателем, а к посредникам у большинства людей традиционно существует негативное отношение, регистраторы — это одна из основ shareware-рынка, и без них подавляющее большинство shareware-авторов просто не смогли бы продать свои программы.

Делать ли первую версию бесплатной

Делать ли первую версию бесплатной

Многие новички на рынке shareware пробуют привлечь внимание пользователей к своей программе, распространяя ее первые версии бесплатно. Одни стыдятся "сырой", по их мнению, версии, с ошибками, и считают, что брать за нее деньги - "некрасиво". Вторые опасаются того, как примут пользователи программу, и хотят сначала посмотреть на их реакцию, для улучшения которой первая версия и делается бесплатной. Другие просто хотят отложить "на потом" заключение договора с регистратором, открытие валютного счета в банке, а также иные процедуры, связанные с началом работы на shareware-рынке. А кто-то берет пример с популярных программ, получивших большое распространение во многом благодаря своему бесплатному статусу.
Между тем, тот, кто пытается "заманить" пользователей бесплатной версией, вредит сам себе. Зачастую бывает, что именно при появлении первой версии программы она попадает в обзоры журналов и shareware-сайтов, получает рейтинги и награды. Именно в этот момент ее качает максимальное количество людей, и максимальное количество людей готово ее оплатить. И если программа попала один раз в обзор в журнале — все, второй раз она в этот обзор не попадет, или, в лучшем случае, попадет, но очень нескоро. Если же она в этот момент была бесплатной — автор потерял много денег.
Выпуск бесплатных версий программы на том основании, что, по мнению автора, она еще слишком маломощная и "сырая" - тоже ошибка. Даже бета-версии нужно продавать за деньги, естественно, не очень большие. Специально подчеркните на самом видном месте Web-сайта или в nag-screen ("экране ворчания"), что "релиз" будет стоить на 50—100 процентов больше — это очень хороший стимул для пользователей. Уже на стадии бета-тестирования можно "одним выстрелом убить двух зайцев": довести программу "до ума" и заработать неплохие деньги. В конференции SwRus я даже читал шутливую рекомендацию брать пример с Microsoft: "Продавайте даже беты за деньги, а к первому же релизу сразу выпускайте патчи и сервис-паки, и за них тоже требуйте деньги". В каждой шутке есть доля правды, и мне кажется, что в этой шутке доля правды довольно велика.
Замечание 2
Замечание 2


Относительно эффективности бесплатности программы как фактора, привлекающего посетителей, на мой взгляд, показательны примеры, приведенные в разд. "Изменения ценовой политики" этой главы, свидетельствующие о том, что, наоборот, увеличение цены вызывает рост продаж — главную цель shareware-бизнеса.

Доменное имя

Доменное имя

Если пользователь проводит поиск по определенным словам, то некоторые поисковые системы в первую очередь в ответах на запросы показывают те сайты, доменные адреса которых включают эти слова. Такой особенностью характеризуются Altavista и Lycos.

Главная страница сайта регистратора RegNow

Рисунок 10.1. Главная страница сайта регистратора RegNow


В общих чертах принцип работы регистратора состоит в следующем. Автор, желающий распространять свою программу на shareware-рынке, заходит на Web-сайт регистратора и заполняет анкету со своими данными и данными о своих программах. Регистратор открывает ему аккаунт (от англ, account, что означает "счет"), а также выдает автору адреса страниц, сгенерированных регистратором, па которых располагаются формы регистрации программ. Автор ставит ссылки на эти страницы в документации программы, на своем Web-сайте и т. п., кроме того, регистратор размещает эти ссылки на своих ресурсах (например, в принадлежащем ему online-каталоге программ или выпускаемом CD-ROM).
Пользователь, желающий оплатить регистрацию программы, щелкает по этим ссылкам и попадает на соответствующую страницу, где заполняет Web-форму информацией о себе (имя, фамилия, почтовый адрес, телефон, e-mail и т. д.) и, главное, указывает номер своей кредитной карточки. После этого регистратор проверяет заказ и, если все нормально, дает поручение банку снять деньги с карточки клиента и зачислить на свой счет. После прихода денег на счет регистратора он начисляет на "внутренний" счет автора соответствующую сумму, вычтя свои комиссионные. Непосредственно автору деньги высылаются не сразу, а по мере накопления такой суммы, которая сделает банковский перевод или отправку чека выгодной — ведь сумму, например, в тридцать долларов переводить нет смысла, т. к. банковская комиссия, как уже говорилось в разд. "Самостоятельный прием платежей" этой главы, "съест" почти всю сумму перевода. То, что маленькие платежи за программу копятся на счету регистратора, является одним из главных преимуществ работы с регистратором по сравнению с самостоятельным приемом платежей от конечных пользователей.
После того, как заказ проверен, регистратор высылает автору программы уведомление о сделанном заказе, включив в него данные о пользователе (за исключением, конечно же, номера кредитной карты) и параметрах заказа (название программы, количество заказанных копий и т. п.). Если автор поручил регистратору рассылку регистрационных ключей, то регистратор высылает пользователю ключ; если автор оставил рассылку ключей для себя, то он должен выслать регистрационный номер самостоятельно.
На этом процесс регистрации заканчивается. Автор заносит в свою базу данных пользователей информацию о новом зарегистрированном пользователе и не без удовольствия подсчитывает, на какую сумму увеличился его счет у регистратора.

Главная страница сайта российского регистратора Shareg com

Рисунок 10.10. Главная страница сайта российского регистратора Shareg.com


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


Попасть в российские компьютерные offline-журналы, в отличие от западных, очень легко. Почти все они регулярно публикуют обзоры программных продуктов, особое внимание уделяя программам российских авторов, многие прикладывают к номеру журнала CD-ROM с подборкой программ. Обычно редакторы этих журналов охотно откликаются на предложения авторов включить в обзор их программу.

Изменения ценовой политики

Изменения ценовой политики

Трудно установить оптимальную цену на программу сразу после выхода первой версии и сохранять ее такой на весь период развития. Под воздействием многих факторов — например, появлением у автора новых программ, изменением ситуации на рынке, маркетинговыми ходами, — у разработчика возникает потребность изменить цену на свою программу.
Однако некоторых авторов терзают сомнения — как отреагируют пользователи на эти изменения? Не будут ли разочарованы те, кто купил программу по высокой цене, увидев, что теперь она стоит дешевле? Не огорчатся ли те, кто подумывал о регистрации программы и обнаружил, что она подорожала? Не обвинят ли они автора в обмане или недобросовестности?
На мой взгляд, говорить о какой-либо нечестности или недобросовестности здесь не уместно. Каждый автор имеет право по своему разумению назначать цену на свою программу, менять ее, объявлять программу платной или бесплатной. Автор вполне может считать, что в данный момент программа еще не доделана, еще не имеет всех планируемых функций— и продавать ее по низкой цене или вообще распространять бесплатно. А после того, когда продукт усовершенствован и доработан — повысить цену.
В конце концов, колебания цен — вполне обычное явление для рыночной экономики. Иностранные пользователи отлично знакомы с так называемым market-skimming pricing (буквально -"снятие сливок"), когда производитель (продавец) устанавливает на новые продукты завышенные цены, чтобы охватить потребителей, готовых платить такие деньги. Позже он снижает цены, чтобы привлечь следующий слой потребителей своего сегмента и так до тех пор, пока цена продукта не опустится на уровень себестоимости. Личное дело пользователя — использовать программу или нет, оплачивать ее или нет. Ведь от пользователя тоже никто не требует дать гарантию, что он будет пользоваться только данной программой данного автора, а не "перебежит" к конкуренту.
Однако у этой свободы изменения ценовой политики есть некоторые ограничения:

если данная версия программы стоит определенную сумму (или вообще бесплатна), то эта цена (или статус "freeware") на данную версию (именно данную версию!) должна сохраняться неизменной.. Иначе автор должен явно объявить, что с такой-то даты цена программы или ее статус будут такими-то. Исключение составляют скидки, объявляемые к праздникам, например к Рождеству: о них всегда объявляется не заранее, а сразу после введения скидок;

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

Изменения цены, как показывает практика, — удачный маркетинговый ход, позволяющий значительно увеличить продажи программы. Например, известный продукт FolderGuard (http://www.winability.com), дающий возможность ограничивать доступ к ресурсам компьютера, продавался очень плохо, стоя всего 20$. После того как автор просто увеличил цену до 35$, количество регистрации значительно увеличилось. А вспомните, например, "историю успеха" программы Chameleon Clock, рассказанную в гл. 1: увеличение цены с 14,95 до 24,95$ также вызвало скачок регистрации!
Как вы, наверное, заметили, хороший момент для изменения цены на программу — выход новой версии. Однако можно пойти еще дальше: создать на основе своей программы целую линейку продуктов (например, варианты Pro и Standard), установив на них цену в зависимости от функциональных возможностей. Вот, например, рассказ одного из shareware-авторов о таком опыте изменения ценовой политики: "У меня была программа за 15$. Многие пользователи хотели новых функций. Нате — получите. Только я поступил так: сделал новую версию с несколькими достаточно важными новыми функциями и поставил продавать за 24,95$. А старую, не изменяя, поставил за 17,95$. Плюс сильно "кастрировал" старую и сделал Freeware. Результат — берут Pro больше всего, не взирая на цену (а я сомневался), a Standard берут в основном те, кто старую версию закачал и не подозревал о существовании Pro. А некоторые Freeware пользуют и счастливы. [...] Финансовая отдача увеличилась в 2 раза".

Качественная защита от фраудов

Качественная защита от фраудов

Фрауд ("fraud" - обман; мошенничество, жульничество; подделка) - это заведомо фальшивая покупка, т. е. покупка, денег за которую автор не получит, или получит, но они затем будут отозваны банком (см. разд. "Возврат денег" данной главы). Обычно фрауды осуществляются пользователями, желающими получить регистрацию программы бесплатно и, чаще всего — намеревающимися выложить "халявный" регистрационный код в Интернете для всеобщего доступа. В качестве номера кредитной карты при фрауде указывается номер украденной кредитной карты (и, естественно, украденные данные владельца) или номер, сгенерированный специальной программой (кодогенератором). Хороший регистратор должен проводить качественную проверку номеров кредитных карточек, как минимум — не пропускать кодогенераторы, но лучше всего — иметь online-связь с карточными системами. Сотрудники некоторых регистраторов даже проверяют наиболее подозрительные заказы вручную, звоня по указанному в регистрационной форме телефону и запрашивая подтверждение заказа.

Качественный подбор текста для страницы сайта

Рисунок 10.6. Качественный подбор текста для страницы сайта


Submass.com названия программ-конкурентов также заносятся в базу данных, и когда пользователи ищут в поисковых системах AddSoft или SiteTrack, то в ответах на запросы выдаются и ссылки на Submass.com. Например, при поиске в Altavista по образцу "AddSoft" ссылка на Submass находится на втором месте в результатах запроса, а по "SiteTrack" - на первом месте, обогнав даже официальный сайт SiteTrack! В результатах запросов к другим поисковым системам рейтинг SubMass.com не так впечатляющ, но тоже очень высок: ссылки на сайт находятся на первых страницах результатов запросов.
Примечание
Примечание


Использование торговых марок конкурентов для "раскрутки" собственного сайта не является корректным. Например, существует прецедент предъявления судебных исков к компаниям, которые на своих сайтах в теги <МЕТА> включали официальные наименования конкурентов. Но в случае с Submass речь идет всего лишь о цитатах высказываний пользователей.
Авторов Web-страниц, старающихся непременно привлечь на свои сайты как можно больше посетителей, такой "интеллектуальный" способ оптимизации своих страниц не привлекает. Ведь нужно не только отлично знать язык, на котором пишется текст, но и разбираться в психологии пользователей, чтобы составить текст, одинаково хорошо воспринимаемый и посетителями, и поисковыми системами. В конце концов, нужно тратить на это время! А ведь гораздо проще просто указать список ключевых слов, который был бы виден для поисковых систем — да вот незадача, теги <МЕТА> поисковыми роботами чаще всего игнорируются или имеют невысокий приоритет.
Для решения этой "проблемы" были придуманы различные хитрости. Например, для включения в страницу ключевых слов их текст делается "невидимым" (т. е. цвет текста устанавливается таким же, как и цвет фона), или набирается очень мелким шрифтом, при котором текст выглядит как пунктирная линия. В этом случае текст, невидимый для пользователей, доступен для индексации поисковыми системами.
Конечно, разработчики программного обеспечения поисковых систем быстро разобрались с этим приемом изобретательных Web-мастеров и срочно внедрили в индексирующие механизмы соответствующие ограничения. Например, только поисковая машина Excite индексирует и невидимый, и мелкий текст. Остальные поисковые системы умеют определять невидимый и мелкий текст и отказываются индексировать его.
Другая крайность, в которую бросаются авторы страниц, — включение списка ключевых слов прямо в заголовок страницы. Поисковые системы, конечно, индексируют такие заголовки, ведь они не могут распознать, является ли заголовок "нормальным" или это список ключевых слов для привлечения посетителей. Однако в этом случае автор вредит сам себе: список ключевых слов виден всем посетителям и из-за этого сайт производит впечатление несерьезного ресурса, т. к. этим приемом чаще всего пользуются владельцы развлекательных и эротических сайтов. Лучше всего подходить к составлению текста заголовков точно так же, как и при составлении основного текста страниц — подбирать для них не список слов, а осмысленные фразы, включающие основные ключевые слова.

Как определить цену на программу

Как определить цену на программу

Ценообразование — весьма непростой вопрос для shareware-разработчика: трудно сразу установить на продукт оптимальную цену, которая устроит и продавца, и покупателя, и при этом благополучно повлияет на имидж продукта.
Многие начинающие авторы программ считают, что чем меньше стоимость программы, тем лучше она будет продаваться, ведь цена почти всегда является самым главным параметром, на который обращает внимание пользователь при выборе товара. Кроме того, низкая цена позволит получить преимущество перед конкурентами, имеющими более дорогостоящие продукты. Исходя из этих соображений, новички в shareware часто совершают ошибку — назначают на свои программы цены в пределах 3—10$.
Дело в том, что компания-регистратор, принимающая платежи за программу, возьмет свою комиссию, которая для такой недорогой программы окажется слишком большой. Например, RegSoft взимает за программы дешевле 30$ не менее 3$ комиссии, т. е. для дешевой программы комиссионные регистратора окажутся от 30 до J00% ее стоимости.
Еще один недостаток слишком низкой цены — недоверие пользователей к дешевым программам. По распространенному мнению, хорошая программа не может стоить несколько долларов.
Самый надежный способ определения оптимальной цены - сравнение программы с продуктами конкурентов и рассмотрение диапазона цен на них. В большой степени цена зависит от того, как вы планируете позицию вашего продукта по отношению к конкурентам (в маркетинге это называется "positioning"). Если ваш продукт проще чем большинство его конкурентов, то вы можете ориентировать его на "домашнего пользователя" и цену установить ближе к нижнему пределу. Если продукт имеет несколько уникальных функций, которые могут заинтересовать только узкий круг пользователей, то его можно ориентировать на "business customers" (т. е. деловых людей, сотрудников компаний и т. д.), и цену тогда нужно устанавливать повыше (поскольку цена ниже ожидаемой может вызвать сомнение в его качестве). С другой стороны, от более дорогих продуктов ожидают предоставления всяких вспомогательных услуг, например: телефонную поддержку, доставку продукта в красивой коробке и т. д.
Два самых важных фактора ценообразования, не только для shareware-программ, но и любого продукта, продающегося в розницу, — это номинал наиболее распространенных купюр в стране и способ оплаты (наличный или безналичный). Например, 19,95$ кажется американцу значительно меньше 20$, потому что во втором случае ему придется отдать целую "двадцатку" (любимая американская купюра), а в первом он попытается наскрести эту сумму мелкими купюрами и монетами. А вот большинство россиян не видят никакой разницы между 34,95$ и 35,00$ во многом потому, что в России принято считать доллары сотнями, а центы можно встретить только у тех, кто недавно приехал из США и у кого в кошельке завалялось несколько монет.
Не смотря на то, что при оплате регистрации shareware-программ пользователь чаще всего не имеет дела с наличными деньгами, а расплачивается кредитной карточкой, прием "уменьшенных" цен все равно работает, т. к. решение о покупке принимается до того, как человек решит, как он будет платить. Чтобы убедиться в этом, достаточно посетить сайты иностранных shareware-компаний: на большинстве из них указываются именно "уменьшенные" цены —24,95$; 39,85$ и т. п.
Есть более интересный способ ценообразования, одинаково эффективный и для наличных, и для безналичных форм оплаты — вводить скидку в виде "дней оставшихся до конца месяца". Например, 20 числа объявляете, что начиная с сегодняшнего дня вы устанавливаете скидку в размере количества дней, оставшихся до конца месяца. То есть, 20 числа — 10%, 21 — 9%, 22 — 8% и т. д. Это приводит к росту продаж даже несмотря на то, что скидка 1% ничтожна в денежном выражении — дело в том, что не все в состоянии это подсчитать.

Каталоги программ

Каталоги программ

Online-каталоги (архивы) программ очень похожи на каталоги Web-сайтов, подобных Yahoo!: разница состоит лишь в том, что в каталоге программ представлены в первую очередь ссылки на файлы с дистрибутивами соответствующих программ. А в остальном все то же: иерархическая структура, поиск, всевозможные дополнительные сервисы и службы (магазины, разделы новостей, обзоры, рекламные агентства и т. п.).
Архивы программ, наряду с поисковыми системами и "обычными" каталогами, являются одним из важнейших источников расширения аудитории сайта, порой превосходя их по эффективности. Так как, в отличие от общетематических каталогов, содержащих ссылки на Web-сайты различной тематики, каталог программ содержит ссылки на файлы программ (впрочем, ссылка на Web-сайт программы тоже присутствует), у программы в таком каталоге шансы быть замеченной гораздо выше. Во-первых, программа не теряется в сотнях тысяч ссылок на Web-сайты других тем, а, во-вторых, пользователь может скачать файл программы непосредственно со страницы каталога, не блуждая по сайту разработчика.

Комментарии и текст ALT

Комментарии и текст ALT

Текстовая информация, которая может повлиять на рейтинг программы, может быть размещена не только непосредственно в тексте и заголовке страницы. Можно использовать также комментарии и атрибут ALT HTML-тега .
Первый вариант — комментарии — не очень распространен. А вот текст, размещенный в атрибуте ALT, индексируется гораздо большим числом поисковых машин, среди которых — Altavista и Lycos.

Конференции

Конференции


Одно из самых эффективных мест рекламы shareware-продуктов — зарубежные news-конференции (Usenet). По отзывам некоторых разработчиков программ, Usenet для продвижения shareware даже более эффективен, чем поисковые системы или интернет-каталоги. Лично мой опыт это подтверждает: один из основных источников посещаемости моего сайта http:// www.actualsystem.com — всевозможные Web-интерфейсы для поиска и просмотра информации в Usenet, например, http://www.google.com/grphp?hl=ru. И это без учета тех пользователей, которые читают news-конференции при помощи специальных программ (например, Microsoft Outlook Express или Netscape Messenger), т. к. переходы из таких программ системы сбора статистики Web-серверов распознать не могут.
Высокая эффективность конференций обусловлена тем, что рекомендация использовать ту или иную программу, высказанная во время обсуждения или в ответе на вопрос, не воспринимается как реклама, и пользователь доверяет этой информации в большей степени.
Для продвижения своей программы можно использовать следующие группы:

специальные группы, название которых содержит слово announce. Они, как легко догадаться, предназначены для анонсов новых разработок. Например, сотр. lang.pascal.delphi. announce можно использовать для анонсов VCL-компонентов и инструментов для Borland Delphi, a сотр.archives.ms-windows.announce и comp.shareware.announce — для объявлений о выпуске продуктов любой тематики;

в обычных группах, в которых возможен интерес к распространяемому вами продукту. Если видите вопрос, решить который поможет ваша shareware-программа — смело пишите: "Take a look at my great tool at http://... ". Также хорошо будет поставить краткое описание продукта и URL сайта в подпись, вставляемую в каждое ваше сообщение, отсылаемое в конференцию. Тогда можно рекламировать свою программу, участвуя в любых обсуждениях, пусть даже не связанных напрямую с вашей программой. Главное — люди будут читать ваши сообщения, видеть подпись с описанием программы, и многих продукт обязательно заинтересует!

Замечание 5
Замечание 5


Важно помнить, что к конференции второй группы слать анонсы своих программ ни в коем случае нельзя — это обычно прямо запрещается правилами, и модератор, отвечающий за порядок в соответствующей конференции, либо не пропустит сообщение с анонсом, либо (особенно при повторном нарушении) вообще отключит автора сообщения от конференции.
Если программа действительно интересна многим пользователям, то из Usenet она распространится очень широко. Многие пользователи поместят ее в свои коллекции файлов, поставят на нее ссылку в разделах "Мои любимые программы" своих домашних страничек. Несмотря на "несерьезность" таких мест, посетители очень доверяют информации, опубликованной в них, и многие делают свой выбор в пользу именно той программы, о которой так тепло отозвался какой-нибудь Джон Смит из Огайо.
Кроме того, архив всех конференций доступен в Интернете, поиск по нему можно осуществлять не только со специального сервера www.dejanews.com, но и некоторых поисковых систем, например, www.altavista.com или www.google.com. Из-за широчайшего тематического охвата и огромного количества ценнейшей информации (людям всегда особенно интересно читать не рекламные тексты, а мнения других людей), архивы конференций Usenet пользуются большой популярностью у пользователей. Информация, размещенная в сообщениях конференций (в том числе и описание программы и адрес ее сайта), будет привлекать внимание значительного числа людей.

Текст CGIскрипта

Листинг 10.1. Текст CGI-скрипта, осуществляющего переадресацию пользователя

# ! /usr/local/bin/perl
# Получение параметров, передаваемых скрипту
@pairs = split (/&/, $ENV{ ' QUERY_STRING ' )) ;
foreach $pair (Opairs)
{
($name, $value) = split (/=/, $pair) ;
$PARAMS{$name} = $ value;
}
$product = $PARAMS{ 'product' };
$registar = $PARAMS{ ' register '};
# Объявление переменной (хотя в Perl оно не нужно) ;
$redir = "";
# Адрес, на который пользователь переадресовывается по умолчанию
$default = "http://www.regnow.com/.../";
# Адреса для переадресации
# Первая цифра в названии переменной
# обозначает продукт, вторая — регистратора
$redir_l_l = "http: //www. regnow. com/ ... /product1";
$redir_l_2 = "http: //www. regsoft. com/ ... /product1";
$redir_2_l = "http: //www. regnow. com/ ... /product2";
$redir_2_2 = "http: //www. regsoft. com/ ... /product2";
}
$redir_3_1 = "http://www.regnow.com/.../products";
$redir_3_2 = "http://www.regsoft.com/.../products";
# Анализ параметров if ($product == 1)
if (registar == 1) {$redir = $redir_1_1;
}
if (registar == 2) {$redir = $redir_1_2;
}
if ($product == 2)
if (registar == 1) {$redir = $redir_2_1;
}
if (registar == 2) {$redir = $redir_2_2;
}
if ($product == 3)
if (registar == 1) {'$redir = $redir_3_1;}
if (registar == 2) {$redir = $redir_3_2;}
# Переадресация
if ($redir ne "")
print "Location: $redir\n\n";
exit;
}
print "Location: $default\n\n";
exit;
Как видите, структура программы очень проста. В ней, для примера, приводится переадресация для трех различных программ, платежи за которые принимаются двумя регистраторами. С помощью комбинации клавиш
+
и несложных модификаций текста можно расширить количество программ и регистраторов, которые учитывает скрипт, до требуемого числа. Сохранив получившийся текстовый файл под именем, например register.cgi, и скопировав его в каталог cgi-bin вашего виртуального Web-сервера, можно прямые ссылки на страницу регистратора в документации программы поменять на ссылки на register.cgi. Например, для переадресации пользователя на страницу регистрации, созданную первым регистратором для первой программы из списка, нужно поставить ссылку на http:// www.Bam_caйт.com/cgi-bin/register.cgi?product=l®istar=l, а если требуется перенаправить пользователя для регистрации третьего продукта через второго регистратора, то ссылка должна вести на httр://Ваш.ваш_сайт.соm /cgi-bin/register.cgi?product=3®istar=2.
Помимо документации, эти ссылки можно поставить и в разделб "Регистрация" Web-сайта программы. Тогда при смене регистратора нужно будет поменять адреса страниц регистрации только в исходном тексте скрипта, не редактируя текст Web-страницы раздела "Регистрация".
Этот скрипт может пригодиться и в том случае, если вы, например, уезжаете в отпуск и не нашли кого-то, кто будет рассылать регистрационные ключи вместо вас, а регистратору по каким-то причинам рассылку ключей поручить нельзя. Достаточно заменить в скрипте адреса регистраторов на адрес страницы на вашем сайте, где сообщить, что регистрация по техническим причинам временно не доступна и объявить дату возобновления работы. Конечно, это не назовешь идеальным решением проблемы, однако это наименьшее зло по сравнению с претензиями пользователей, оплативших регистрацию, но не дождавшихся ключа.
Модифицировав исходный текст скрипта по своему усмотрению (для этого, конечно, вам понадобится знание языка Perl), можно существенно расширить функциональность скрипта, например, "перебрасывать" пользователей на разные страницы в зависимости от страны их проживания, собирать различную статистику и т. д.

Локализация программы и Webсайта

Локализация программы и Web-сайта

Как всем известно, основной язык в shareware — английский, и для продаж на западном shareware-рынке интерфейс программы и Web-сайт должны быть на этом языке. По статистике, англоязычные пользователи составляют 50—60% от общего числа покупателей. Но устраивает ли остальные 40% то, что программа, которую они тестируют, имеет интерфейс на неродном для них языке? И нужно ли переводить на другие языки страницы Web-сайта программы?
С переводом Web-сайта ситуация достаточно сложная. Конечно, Web-страницы на других языках помогут увеличить количество регистрации, однако затраты на перевод нескольких языковых версий сайта и, самое главное, их поддержку могут и не окупиться. А вот если продукт в какой-то из стран, что называется, "пошел", то за версию сайта на языке этой страны вполне можно взяться. Например, японская версия сайта ReGet (http://www.reget.com) имеет посещаемость несколько тысяч человек в день!
Примечание
Примечание


Оплата труда профессионального переводчика, производящего перевод сайта на иностранные языки, может быть довольно высокой — около 10 — 12$ за 1 Кбайт текста. Однако я читал совет по существенной экономии средств при локализации сайта: можно перевести русский текст на иностранные языки программой-переводчиком наподобие Stylus, а затем попросить пользователей из соответствующих стран довести перевод "до ума" в обмен на бесплатную регистрацию программы.
А вот локализация интерфейса программы - совсем другое дело. Здесь shareware-разработчики единодушны: переводить интерфейс на разные языки нужно обязательно! В некоторых богатых и развитых странах английский язык не очень распространен. Всем известный пример — Франция, где даже законодательно преследуется применение иностранных языков вместо французского. Или, например, Тайвань: там практически никто не говорит по-английски — даже сотрудники компьютерных компаний. Кроме того, даже если в стране широко распространен английский язык, и большинство населения свободно владеет им (например, Германия, Нидерланды, Бельгия), пользователям гораздо приятнее работать с программой, интерфейс которой переведен на их родной язык. Так или иначе, но после выпуска локализаций всегда наблюдается увеличение интереса к программе со стороны покупателей из соответствующих стран.
Важно то, что локализация программ не требует таких затрат времени и сил, как при создании различных языковых версий Web-сайта. Технически реализовать локализацию очень просто. Перевод может быть выполнен любым пользователем из соответствующей страны, достаточно разместить на Web-сайте и в документации программы объявление о том, что каждый, кто сделает перевод интерфейса на свой родной язык, получит бесплатную регистрацию. Как показывает практика, очень быстро программа обзаведется переводами на десятки языков почти без всяких усилий со стороны разработчика программы.
Самая сложная проблема при локализации программ — необходимость добавления новых строк в языковые файлы, содержащие перевод элементов интерфейса, в связи с выходом новых версий программы и появлением новых пунктов меню, кнопок, сообщений. В этом случае приходится связываться с каждым из тех пользователей, которые переводили языковые файлы, а если те не откликаются — просить перевести других пользователей. Если же все-таки дополнить перевод не получается — это не так страшно, ведь "новые" строки будут отображаться на английском языке (английский перевод интерфейса должен быть "прошит" прямо в файл программы). Рано или поздно, но кому-то из пользователей, работающих с такой локализацией, надоест смотреть на 3—4 фразы на английском среди надписей на его родном языке. Он переведет их на свой язык и пришлет дополненный языковой файл автору программы.

Настройка дизайна формы регистрации

Настройка дизайна формы регистрации

Очень полезной является возможность настройки оформления страницы с Web-формой регистрации, чтобы ее дизайн был в одном стиле с оформлением всего сайта программы.
Также хорошо влияет на успех продаж многоязычность этой страницы -т. е. генерация регистратором страницы регистрации на нескольких языках. Это помогает сделать интерфейс оnline-платежей более прозрачным для пользователей из тех стран, где английский язык среди пользователей не очень распространен (например, из Франции).

Нужно ли продавать shareware в России

Нужно ли продавать shareware в России

В разд. "Продвижение программ" данной главы я рассказал о продвижении программ на западных рынках. А нужно ли продавать свои программы в России? Можно ли вообще продавать shareware-программы, цены на которые составляют минимум 15$, в стране, где весь комплект необходимых для пользователя программ можно купить на одном компакт-диске стоимостью всего 2—3$?
У российских авторов shareware отношение к российскому рынку, конечно, особое. Их тоже волнует вопрос: продавать свои программы в России или нет? Об этом часто говорят разработчики shareware в online-конференциях и форумах.
Большинство из опытных российских шароварщиков, успешно продающих свои продукты на западных рынках и имеющие месячный оборот в тысячи долларов, считают российский рынок недостойным внимания. Да, на российском рынке получать такие деньги пока невозможно, и добившимся успеха российским разработчикам проще тратить усилия на продвижение своих программ на западе, получая в десятки раз больше, чем они получили бы в России, потратив столько же времени и сил. Впрочем, и среди опытных разработчиков достаточно тех, кто заинтересован в российском рынке.
А вот авторы "среднего звена" относятся к shareware-рынку России гораздо более благосклонно. По их отзывам, в России с продаж одной программы вполне можно получать неплохой доход, исчисляющийся сотнями долларов в месяц — вполне достойная сумма для нашей страны. То, что прибыль от регистрации российских пользователей меньше, чем получаемая на Западе, их не особенно смущает. В конце концов, кому, как не российским авторам, развивать рынок shareware-программ в их родной стране?

Нужно ли создавать свою компанию

Нужно ли создавать свою компанию

Над этим вопросом задумываются многие shareware-авторы. Все-таки на рынке программного обеспечения от имени фирм продаются не только известные и популярные "коробочные" продукты, но и относительно скромные shareware-программы. Стоит прогуляться по страницам любого интернет-архива программ — для подавляющего большинства продуктов в качестве разработчиков или распространителей указываются не имена людей, а названия компаний.
В большинстве случаев работать на shareware-рынке можно и без образования собственной фирмы. Более того, подавляющее большинство авторов, начинающих свое дело в одиночку, фактически не имеют возможности зарегистрировать свою компанию, т. к. требуется оплатить процедуру регистрации, вести бухгалтерию, отчетность и т. п. По опыту авторов, давно работающих на shareware-рынке, регистрация собственной фирмы нужна тогда, когда автор выходит на качественно новый уровень работы, например участвует в компьютерных выставках, ведет переговоры с другими компаниями, и денежный оборот дела по разработке и распространению программ имеет довольно большой объем (от 5 000$). Создание собственной компании может понадобиться и тогда, когда над shareware-проектом работают несколько человек и требуется упорядочить отношения между партнерами. А вот человеку, который самостоятельно осуществляет разработку и поддержку собственной программы и при этом имеет доход до нескольких тысяч долларов в месяц, собственная компания, как правило, не нужна.
Другой вопрос: от чьего имени нужно продавать свои программы — от собственного имени или имени придуманной компании? Общее правило -шансов на успех гораздо больше, если вести дела от имени фирмы, а не частного лица. Пользователи, делающие выбор между несколькими shareware-программами, гораздо больше доверяют именно тем, за которыми стоят компании. Последние, как известно, свидетельствуют о большей надежности и лучшем уровне технической поддержки — ведь для человека, собирающегося не просто скачать программу, а заплатить за нее собственные деньги, — это самое важное. А вот к "частнику" обычно доверия немного. Более того, программы некоторых категорий, в первую очередь тех, которые рассчитаны на корпоративных пользователей, например, сетевые приложения или бизнес-пакеты, практически невозможно продавать от имени частного лица.
Продажа собственных программ от имени несуществующей компании -очень распространенное явление. Многие из фирм, которые указаны в качестве разработчиков программ, опубликованных на мировых интернет-архивах программного обеспечения, на самом деле нигде не зарегистрированы. Опытные специалисты это прекрасно понимают и уже привыкли к этому. Например, на известном сервере Zdnet (http://www.zdnet.com), в статье, объяснявшей систему выставления оценок обозревателями каталога Zdnet, говорилось: "Обозреватели понимают, что хорошую программу очень часто может написать один хороший программист-одиночка, и что название компании никак не влияет на оценку". К этому можно добавить — имя компании не повлияет на оценку программы обозревателем каталога, но сильно повлияет на продажи!
А безопасно ли это — использовать имя несуществующей компании? У нас в стране до разработчиков shareware-программ, распространяющих свои программы по Интернету, никому нет дела. В США, например, есть закон, по которому дают до года тюрьмы за ведение бизнеса под несуществующим именем. Но так же никто не будет проверять, где на самом деле зарегистрирована компания AV Software и зарегистрирована ли она вообще. По отзывам разработчиков, ведущих свои дела от имени несуществующих компаний, в США считают, что фирма, чьи программы их заинтересовали, — это русская компания, и она зарегистрирована в России, в России считают, что она зарегистрирована где-нибудь на Кипре. При этом иностранные партнеры даже заключают с разработчиками, выступающими под видом компании, договоры - например, OEM-соглашения, т. е. договоры на включение программы в комплект поставки производимых партнером компьютерных комплектующих.
Замечание 3
Замечание 3


Нужно быть очень внимательным, указывая название вымышленной компании при регистрации в различных online-сервисах (по хостингу, рекламе, продаже программ и т. п.). Как правило, персоналу таких сервисов абсолютно все равно, кто подписывается на их услуги — частное лицо или "компания", и, во избежание недоразумений, лучше указывать при регистрации собственное имя. Например, российский банк никогда не выдаст частному лицу денежный перевод, пришедший от компании-регистратора на имя "фирмы".
Из правила "продавать от имени компании", как и из любого другого правила, бывают исключения. Например, неплохо "от себя" продаются программы для индивидуальных пользователей — скринсейверы, забавные программки типа "скинмейтов" (screenmate, т. е. забавное существо (котенок, барашек, инопланетянин), "живущее" на Рабочем столе), часы и т. п. Продажа таких продуктов может придать проекту некоторую официальность, тогда как автор, представляя программы от своего лица, имеет возможность создать имидж веселого и "прикольного" сайта. Кроме того, автор может выступать в роли "своего парня", и пользователям таких программ будет очень приятно общаться непосредственно с создателем продукта.

Обработка заказов

Обработка заказов

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

Человек купил программу себе и хочет одну копию подарить своему другу или родственнику. Со стороны автора программы, естественно, не должно быть никаких возражений — необходимо лишь уточнить второй адрес e-mail, на который нужно выслать ключ.

Человек просто хочет использовать программу и дома, и на работе, поэтому, как честный человек, он заказывает две лицензии. Если же разработчик предоставляет лицензию не на компьютер, а на пользователя (это самый распространенный вариант), то пользователю нужно объяснить это и сказать, что он может спокойно пользоваться программой и на работе, и дома. После этого деньги за "лишнюю" лицензию пользователю нужно вернуть, т.е. сделать "рефанд" (см. разд. "Возврат денег" данной главы).

Может быть и такая ситуация: в форме заказа в графе Имя указано название компании. Нужно также связаться по указанному в форме адресу e-mail с заказчиком и спросить у него, для кого он хочет приобрести регистрацию. Здесь также возможны два варианта.

Человек купил программу для себя, а название компании указал для солидности или из гордости — например, если это его собственная компания. В этом случае нужно объяснить ему, что лицензия приобретается на пользователя, и спросить у него имя, по которому нужно сгенерировать ключ. Если же выдать ему лицензию на имя компании, то он получит возможность установить программу на всех компьютерах компании, чтобы с ней могли работать много пользователей.

Человек хочет приобрести лицензию на использование программы на компьютерах компании. В этом случае надо объяснить, что лицензия за обычную цену действительна только на одного пользователя, а для получения права использовать программу на всех компьютерах компании нужно приобрести так называемую site license.

Примечание
Примечание


Site license, в дословном переводе с английского — "лицензия на офис". Так называется лицензия на использование программы в пределах одного месторасположения какой-либо компании. Принято считать, что site license дает право использовать данную программу любому сотруднику компании, находящемуся в пределах 100 миль от этого самого site. Часто бывают различные исключения, зависящие от способа лицензирования продукта: per seat (на каждое рабочее место), per user (на каждого пользователя), per computer (на каждый компьютер), per server (на каждый сервер) и т. д. Цена такого вида лицензий зависит от цены одиночной лицензии, типа продукта и количества компьютеров в компании.
При рассылке регистрационных кодов по заказам, в которых были приобретены более чем одна лицензия, автор может задуматься: выслать ли покупателю один код или несколько, т. е. по количеству заказанных копий. Здесь можно попытаться представить; какой вариант будет наиболее удобен для заказчика. Например, при заказе 2—5 лицензий ему будет приятнее получить соответствующее количество регистрационных ключей. Если он заказал большее количество (особенно — если несколько десятков и сотен) копий, то ему будет удобнее получить один регистрационный номер и быстро активизировать его на всех компьютерах. А вот если заказчик получит много номеров, то он явно будет этому не рад — например, возникнут проблемы с учетом регистрационных ключей.
Иногда пришедшее разработчику уведомление о новой регистрации программы заставляет задуматься — а не фрауд ли это? Имя заказчика, его адрес e-mail, "обычный" адрес — все это у российского разработчика может вызвать сомнения в целесообразности отсылки кода, который прямиком попадет в интернет-архивы серийных номеров и кряков.
Часто впечатление, возникающее у российского автора, обманчиво. То, что, по его мнению, является откровенным издевательством со стороны анонимного пользователя-"халявщика", может быть вполне естественным явлением за рубежом. Например, фамилия Hacker, которая действует на российских авторов, как красная тряпка на быка, в США является вполне нормальной, примерно соответствующей русской фамилии Крестьянинов. Название "Lilli Pilli", указанное в поле Адрес заказа — реально существующий район в австралийском Сиднее, где находится улица Port Hacking Road. Почтовые адреса на почтовом сервере Hotmail.com используются не только хакерами, но и вполне респектабельными людьми — например, чтобы иметь доступ к своей почте и из дома, и с работы.
Конечно, далеко не каждый разработчик программ обладает настолько глубокими знаниями культуры зарубежных стран, чтобы с первого взгляда определить, не являются ли введенные в форум заказа данные фальшивыми и не фрауд ли этот заказ. Поэтому всем разработчикам программ рано или поздно приходится проверять "подозрительные" заказы.
Примечание
Примечание


Чтобы проводить такие проверки как можно реже, нужно постараться выбрать компанию-регистратора, которая имеет эффективную проверку заказов. Тогда большинство фальшивых заказов будет блокироваться самим регистратором. Например, своей надежной и эффективной антифраудной системой славится компания RegSoft.
Сначала узнайте, из какой страны пользователь, сделавший заказ. Для этого нужно проверить IP-адрес заказчика, указанный в уведомлении о регистрации, с помощью соответствующего online-сервиса, например, http:// www.checkdomain.com. Если пользователь из России или другой бывшей республики СССР (откуда традиционно поступает очень много фраудов), то это серьезный повод насторожиться; если же дополнительно к этому в форме указан и бесплатный адрес с Hotmail.com, то можно сразу делать рафанд.
Если IP-адрес не указывает на пространство СНГ, однако какие-то сомнения остаются (например, тот же бесплатный адрес с Hotmail.com), то можно написать пользователю следующее письмо:
"Уважаемый Mr. xxx:
Спасибо за заказ. Поскольку Ваш e-mail бесплатный, политика нашей фирмы требует верификации заказа по телефону. Когда вам можно позвонить по тому номеру, что вы указали в заказе?
Извините за задержку, благодарим за понимание".
Если ответа на это письмо нет — можно делать рефанд, и, при большом желании и наличии времени, можно пожаловаться системному администратору, ответственному за сервер, которому принадлежит указанный в уведомлении IP-адрес. Если ответ есть - естественно, звоним по телефону: "Здравствуйте, извините за беспокойство Mr. xxx. Вы можете подтвердить вчерашний заказ программы YYY по Интернету?". Если в трубке слышится возглас "What???" или что-то вроде этого, то можно поступать так же, как и при отсутствии ответа.
Замечание 4
Замечание 4


Многие авторы, отославшие регистрационный код по заказу, который потом оказался фраудом (деньги были возвращены в порядке рефанда или чарджбэ-ка), публикуют данные, которые были указаны в форме заказа (имя и фамилия пользователя, его e-mail, адрес и т. п.), в интернет-конференциях, чтобы другие авторы занесли его в свои "черные списки". Вряд ли можно сказать, что это правильная политика. Чаще всего в форме заказа указываются данные человека, чей номер кредитной карты был украден, т. е. это такая же невинная жертва мошенников, как и сам автор программы. И наказывать его за это, конечно, несправедливо.

Образец РАDфайла

Рисунок 10.7. Образец РАD-файла


Основное применение PAD-файлов — это более удобный сабмит программ в online-каталоги. Если каталог поддерживает PAD (список таких архивов смотрите по адресу http://www.asp-shareware.org/pad/padsites.asp), то автору для регистрации своей программы не нужно заполнять Web-форму, с добрым десятком полей. Достаточно просто ввести один-единственный параметр -URL PAD-файла, лежащего на сервере разработчика программы, и архив (точнее, программное обеспечение, установленное на сервере архива) самостоятельно загрузит его и извлечет всю необходимую информацию (Рисунок 10.8). Более того, некоторые архивы даже не требуют, чтобы для обновления информации о программе (например, при выходе новой версии) ее автор уведомлял об этом: архив самостоятельно проверяет PAD-файлы на серверах разработчиков на обновление и обновляет информацию в своей базе данных.
Некоторые авторы включают PAD-файлы в дистрибутивы своих программ, а также ставят ссылки на них на своих сайтах. Это делается для того, чтобы любой заинтересующийся информацией о программе (например, обозреватель журнала или производитель компьютерных комплектующих, занимающийся подбором OEM-программ для своих продуктов), мог быстро получить подробную информацию о программе в удобной ему форме.

Один из лидеров среди регистраторов

Рисунок 10.3. Один из лидеров среди регистраторов — RegNow — не берет штрафы за chargeback

Onlineдоступ к аккаунту

Online-доступ к аккаунту

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

Оперативность службы технической поддержки

Оперативность службы технической поддержки

Как и при работе с любым сервисом, от которого зависит стабильность бизнеса и операций с деньгами других людей, оперативность службы технической поддержки имеет важнейшее значение. У авторов в процессе работы на shareware-рынке возникает много вопросов к регистраторам: например, просьбы разъяснить порядок оказания тех или иных услуг, уточнить детали относительно недавнего перевода денег, проверить еще раз подозрительный заказ и т. п.
От многих компаний, озабоченных только сбором денег, по отзывам людей, контактировавших с ними, ответов приходится ждать месяцами. Службы технической поддержки некоторых регистраторов имеют различное отношение к авторам в зависимости от их оборота: если автор продает не очень много программ, то его письма игнорируются; но, как только продажи увеличиваются, служба поддержки начинает проявлять невиданную оперативность и учтивость. Некоторые авторы терпят такую "дискриминацию", надеясь, что они скоро "дорастут" до нужного уровня и их примут в "клуб" имеющих право на своевременную техническую поддержку. Я с таким подходом категорически не согласен: в конце концов, даже с "маленькими" авторами регистраторы работают не бесплатно, а за комиссионные отчисления. Оперативная техническая поддержка должна оказываться всем.
Итак, я перечислил основные критерии, по которым следует выбирать регистратора. Однако вполне может получиться наоборот - регистратор будет выбирать вас. Точнее, он будет настойчиво предлагать свои услуги.
Как только программа появляется на сайтах крупных shareware-архивов, в почтовый ящик автора начинают валиться письма от различных регистраторов. Предлагают выгодные проценты, продажи через online-магазины и т. п. Тем авторам, чьи программы завоевали уже некоторый авторитет, приходят поздравительные открытки и проспекты.
К сожалению, чем настойчивее ведет себя представитель компании, называющей себя "регистратором", тем меньше шансов на то, что все заявляемые им услуги действительно оказываются и, что самое главное, приносят заметную пользу. Например, компания заявляет, что имеет множество ката-
логов для распространения программ, online-магазины, будет оказывать рекламную поддержку и т. п. Однако при этом требуют внести авансовый платеж в несколько сотен долларов, совершенно не гарантируя, что даже сотня таких свежесозданных "каталогов" и "магазинов" может принести доход, сравнимый с простым появлением программы на сайте Download.com.
По результатам многочисленных обсуждений в конференции SwRus можно составить список надежных, проверенных временем регистраторов, услугами которых пользуются большинство российских разработчиков shareware-программ. Это — RegNow (http://www.regnow.com), RegSoft (http://www.regsoft.com), ShareIt! (http://www.shareit.com), Virtual Software Store (VSS, http:// www.virtualsoftware.com) и Kagi Shareware (http://www.kagi.com). Каждый из авторов программ выбирает "своего" регистратора исходя из собственных привычек и предпочтений.
Сравнив предложения различных регистраторов и почитав отзывы о них, лично я остановил свой выбор на RegSoft, который, по словам других shareware-разработчиков, имеет очень эффективную систему проверки заказов, благодаря чему случаи возврата денег покупателям единичны и не превышают одного процента от общего числа. Кроме того, RegSoft славится оперативной службой поддержки. В этом я мог не раз убедиться лично: ответы на мои письма приходили в течение нескольких часов, причем даже в воскресенье! Набор услуг этой службы вполне соответствует требованиям к "идеальному регистратору": online-доступ к аккаунту, все варианты рассылки ключей, создание и отправка заказчику CD-ROM с копией программы, различные варианты оплаты заказа, перечисление денег банковским переводом или чеком, всевозможные отчеты, настраиваемый дизайн формы регистрации, уведомления по e-mail и т. д. При этом взимаемая комиссия — одна из самых низких на рынке: 3$ при цене программы до 30$ и 10% — в остальных случаях.
Недостатком RegSoft можно признать почти полное отсутствие рекламной поддержки: хотя регистратор и владеет каталогом программ HotDownloads.com, но заметного эффекта это не дает, т. к. посетителей каталог приводит единицы, не говоря уже о покупателях.
Отдельный разговор — так называемые "национальные" регистраторы, т. е. компании, которые имеют возможность обслуживать рынки отдельных стран и принимать платежи, сделанные в специфических для данной страны формах и валютах. Интересно, что среди стран, имеющих проблемы с традиционными для shareware кредитными картами есть экономически развитые, в том числе с очень вместительным рынком программного обеспечения. Например, из Германии часто поступают жалобы на то, что кредиток нет, а банковский перевод или чек в США стоит 20—25$. Здесь может помочь популярный регистратор Sharelt!, который находится в Германии. В Австралии рынок shareware очень большой (оценивается третьим после США и Европы), но с платежными средствами плохо. Основное средство расчетов — чеки местных банков, которые регистраторами типа RegNow или RegSoft, естественно, не принимаются. А в таких странах, как Китай, Северная Корея, Иран денежные переводы в США затруднены уже по политическим причинам.
Пользоваться услугами национальных регистраторов или нет — не самый простой вопрос. С одной стороны, выход на новый рынок должен принести увеличение количества регистрации пользователей из этой страны (или стран). С другой стороны, это увеличение вовсе не гарантировано. Вот, например, цитата из одного сообщения в конференции SwRus: "Ожидаемого притока европейских пользователей не случилось! То есть, процент их после появления переводов на немецкий, французский и другие языки возрос заметно, только регистрироваться они шли через RegSoft. За два месяца через Yaskifo1 зарегистрировалось 9 человек. При том, что линк был и на сайте, и в европейских версиях самой программы. Так что идея европейских валют потерпела полный крах. Доллар он и в Африке доллар. Сейчас я Yaskifo закрываю и убираю отовсюду. Game over".

Организация продаж

Организация продаж

Особенности русского национального shareware

Особенности русского национального shareware

Главная особенность России применительно к распространению программ состоит в том, что большинство потребителей не воспринимают программное обеспечение как продукт, имеющий реальную ценность. Для человека, купившего за 2$ на одном диске несколько версий Windows, Microsoft Office, Adobe Photoshop и еще десяток программ, стоимость софта измеряется копейками. Он не представляет себе, что стоимость разработки программы даже в России как минимум несколько сотен долларов, и цена программы 20$ вполне разумна.
Поэтому пока основная цель продаж shareware продуктов в России — не получить прибыль, сравнимую с прибылью от продаж программ на западе (хотя для продуктов, рассчитанных на корпоративный сектор рынка, это возможно), а приучить пользователей платить за shareware-продукты, воспринимать программное обеспечение как товар, имеющий реальную ценность. С этой точки зрения, выпускать бесплатные русские версии программ — неправильный шаг. Бесплатная версия нисколько не воспитывает в пользователях отношение к программе как к чему-то ценному, а наоборот, укрепляет уверенность человека в том, что софт стоит копейки, а за скачанный из Интернета продукт не нужно платить даже стоимость носителя. Каждая сделанная бесплатной русская версия наносит вред другим российским разработчикам shareware, которые пытаются продавать россиянам свои программы, и затормаживает развитие рынка российских программных продуктов.
Конечно, при назначении цены на свои программы в России, как и при ценообразовании для зарубежных рынков, нужно учитывать уровень доходов целевой аудитории, на которую рассчитана соответствующая программа. Например, программы для индивидуальных пользователей вряд ли можно продавать дороже, чем за $10, а вот продукты для бизнес-применения или рассчитанные на использование в организациях можно продавать по тем же ценам, что и за рубежом.

Отправка программы на физическом носителе

Отправка программы на физическом носителе

Некоторые покупатели, даже имя выход в Интернет и оплачивая программу online, предпочитают получить копию программы на CD-ROM. Некоторые регистраторы учитывают это и позволяют пользователю включить в заказ и доставку программы на CD-ROM — конечно же, за счет пользователя. При этом все хлопоты по созданию записи диска и отправке его заказчику берет на себя регистратор. И, что самое приятное, часть платы, внесенной пользователем при заказе CD-ROM, регистратор зачислит на счет автора, т. е. последний получит несколько дополнительных долларов к сумме регистрации без каких-либо действий со своей стороны.
Примечание
Примечание


Если регистратор, которого вы решили выбрать, не осуществляет доставку программ на физическом носителе, вы можете воспользоваться для этого услугами специализированных сервисов, например, http://www.swiftcd.com.

Отсутствие начального взноса

Отсутствие начального взноса

Нормальная практика среди солидных компаний, работающих в области приема платежей на shareware-рынке — отсутствие каких-либо выплат регистратору со стороны автора. Более того, стараясь получить дополнительные козыри перед своими конкурентами, некоторые регистраторы предоставляют новичкам льготные условия, например сниженную комиссию на несколько первых месяцев работы. А вот если некая компания, обещающая вроде бы выгодные условия, при этом требует сначала заплатить какую-то сумму денег — это очень серьезный повод насторожиться.

Отсутствие штрафов за chargeback и неподтвержденные платежи

Отсутствие штрафов за chargeback и неподтвержденные платежи

Chargeback — это возврат денег, уже снятых с кредитной карточки клиента (см. разд. "Возврат денег" данной главы). Чаще всего он случается после фрауда, т. е. фальшивой покупки, которая не была "отловлена" на этапе проверки заказа. Возврат денег всегда не бесплатен — банк, осуществляющий эту операцию, обязательно взимает свою комиссию, которая может быть очень серьезной — например, некоторые американские банки берут 15$! Но при этом хороший регистратор не перекладывает на плечи "своих" авторов штрафы, компенсируя их из общего оборота, или, в крайнем случае, берет очень небольшую комиссию (Рисунок 10.3). А вот новички среди регистраторов, считающие каждую копейку или старающиеся непременно свалить собственные расходы на счет своих партнеров-авторов, берут за каждый возврат денег большой штраф.

Перевод денег между аккаунтами

Перевод денег между аккаунтами

Очень полезная функция, позволяющая авторам переводить деньги с одного аккаунта на другой "внутри" регистратора. Например, можно оплачивать регистрации программ, авторы которых пользуются услугами того же регистратора. Например, я приобрел лицензионную копию ПО для защиты программ ASProtect (см. "ASProtect: взломщики отдыхают" гл. 6) именно таким способом. Более того, регистраторы открывают аккаунты специально для перевода денег от shareware-авторов, например, для хостинг-компаний, благодаря чему можно оплачивать услуги без пересылки денег из США в Россию и обратно, избегая уплаты банковских комиссий.

Перевод на валютный счет

Перевод на валютный счет

Регистратор может пересылать деньги разработчиком и посредством обычного банковского перевода. Для этого нужно открыть в любом банке валютный счет и сообщить реквизиты того счета регистратору.
Открытие валютного счета — простая и доступная для каждого операция. В российском Сбербанке, например, открытие счета "до востребования" (как и других счетов) бесплатно, при открытии счета на него нужно положить всего лишь 5$.
При открытии счета необходимо попросить работника банка, открывающего счет, выдать реквизиты этого счета, чтобы на него можно было переводить деньги из-за рубежа. При этом нужно обязательно проследить, чтобы в реквизитах был указан номер корреспондентского счета российского банка в зарубежном банке.
Примечание
Примечание


Что такое "корреспондентский счет"? Российские банки редко имеют свои филиалы за рубежом. Для обслуживания зарубежных переводов своих клиентов российский банк А, заключает договоры и открывает счета в зарубежных банках В, С, D, которые и называются корреспондентскими и предназначены для взаиморасчетов с зарубежными банками, где гарантом платежеспособности российского банка выступает зарубежный банк, у которого эти счета находятся. Расчет банка происходит не напрямую с зарубежными банками, а через банк-гарант (корреспондентский банк) — в этом отличие от зарубежных банков.
Дело в том, что многим регистраторам гораздо проще переводить деньги в зарубежный банк (а затем этот банк переведет эти деньги на счет российского банка-корреспондента), чем непосредственно в Россию.
Работники российского банка, открывающие вам счет, вполне могут не указать в реквизитах номер корреспондентского счета. Например, когда я открывал валютный счет в Сбербанке, выданные мне реквизиты счета имели такой вид:
S.W.I.F.T. SABR RU MM NA1
SAVINGS BANK OF THE RUSSIAN FEDERATION
BR.1647 MOSCOW A/c 3030231734510935277908
Как видите, номера корреспондентского счета здесь не наблюдается. Никакого криминала в этом нет: данных реквизитов вполне достаточно, чтобы перевести деньги на этот счет из-за границы. Корреспондентский счет необходим исключительно из-за того, что его требуют некоторые компании-регистраторы. Поэтому нужно дополнительно попросить у работников банка сообщить номер корреспондентского счета в зарубежном банке.
Примечание
Примечание


Обратите внимание, что только название банка-корреспондента не помогает ускорить прохождение платежа — нужен номер счета банка-получателя в банке-корреспонденте. Также, естественно, одного номера корреспондентского счета для получения перевода в России недостаточно — нужны еще и "внутренние" реквизиты, пример которых приводился чуть ранее — "S.W.I.F.T. SABR RU MM NA1, BANK... BR.1647..."
У Сбербанка, например, корреспондентских счетов довольно много (их список занимает две страницы формата А4) — в банках разных стран, для разных валют. В частности, если регистратор находится на территории США, то в качестве номера корреспондентского счета можно указать следующий номер:
#890-0057-610 with BANK OF NEW YORK, N/Y, USA
Примечание
Примечание


При открытии валютного счета в Сбербанке имейте в виду, что указанный выше номер корреспондентского счета к тому моменту может стать не действительным. Поэтому не переписывайте номер счета со страниц книги, а попросите работников банка предоставить действительный список корреспондентских счетов.
Еще несколько лет назад получение денег на валютный счет разработчиком shareware-программ, работавшим как частное лицо, было очень затруднено. В России действовала инструкция Центробанка, разрешающая получать деньги на счет только в виде зарплаты по подписанным и нотариально заверенным контрактам, или в виде благотворительных пожертвований (опять же — подтвержденных документально). Разумеется, таких документов авторам взять было неоткуда и поступающие деньги банки отправляли обратно.
Сейчас ситуация изменилась в лучшую сторону. Банки уже не обязаны требовать документы, подтверждающие происхождение денег, от физического лица, получившего относительно небольшой (несколько сотен долларов) перевод из-за рубежа. Конечно, бывают досадные исключения, когда какой-то банк по своей инициативе заявляет, что полученный перевод, по его мнению, является предпринимательской деятельностью и нужно предоставить какие-то документы. В этом случае рекомендуется, не предоставляя никаких документов, просто дать согласие на отправку денег обратно регистратору, закрыть счет, открыть счет в другом банке и сообщить новые реквизиты регистратору. Деньги будут переведены снова, конечно, с удержанием комиссии за переводы туда и обратно, однако это гораздо дешевле, чем "воевать" с банком, который отказывается выдать деньги.
Кроме того, теперь многие банки открывают для своих клиентов международные карты (например, VISA) и позволяют "привязывать" их к валютным счетам. По отзывам разработчиков shareware-программ, воспользовавшихся этой услугой, для получения денег даже не нужно заходить в банк и заполнять расходный ордер — деньги со счета можно снимать в уличном банкомате.
В общем, в настоящее время переводы на валютный счет для shareware-разработчиков являются наиболее предпочтительным способом получения денег от компаний-регистраторов: по сравнению с чеками банковские переводы более удобны и осуществляются гораздо быстрее, чем инкассо чеков.

Поддержка незарегистрированных пользователей

Поддержка незарегистрированных пользователей

Многие авторы shareware-программ на своих Web-сайтах и в документации декларируют предоставление неограниченной технической поддержки для зарегистрированных пользователей. Однако при этом возникает вопрос — какой же должна быть поддержка незарегистрированных пользователей?
На вопросы тех, кто не является зарегистрированным пользователем, нужно отвечать, как ни в чем не бывало. Ни в коем случае нельзя заявлять о том, что на этот вопрос автор ответит, если пользователь зарегистрируется. Хотя некоторые пользователи готовы к такой реакции и даже специально покупают одну лицензию программы, чтобы всего лишь задать какой-нибудь вопрос, но большую часть людей такой ответ только обидит.
Например, довольно часто приходят письма примерно такого содержания: "Программа неплохая, но в ней не хватает таких-то функций. Вот если peaлизуете их, то, возможно, я ее куплю". Я подробно отвечаю на такие письма, рассказываю, над какими функциями я уже работаю, какие будут реализованы, а какие — нет. После этого большинство пользователей отвечают: "Вот это да, не ожидал такого хорошего отношения!" - и покупают программу.
Более того, некоторые пользователи, попав на мой сайт ActualSystem.com, что в переводе означает "Система, какая она есть", задают даже вопросы, не касающиеся непосредственно самих моих программ — спрашивают, например, об особенностях работы операционной системы. Я очень вежливо отвечаю и на такие вопросы, в силу своих возможностей стараясь помочь пользователю решить его проблему. Даже если человек после этого и не покупает у меня программу, он обязательно запоминает мой сайт и рекомендует его своим друзьям и знакомым.
Единственное, в чем, пожалуй, можно ограничить ответы на вопросы незарегистрированных пользователей — если человек задает вопрос, ответ на который уже есть в документации, то можно ответить ему просто: "Посмотрите, пожалуйста, справочную систему программы, раздел такой-то". В этом и будет заключаться "ограниченность" технической поддержки, предоставляемой незарегистрированным пользователям.

Поисковые системы и каталоги

Поисковые системы и каталоги

Поисковые системы и каталоги интернет-ресурсов — один из важнейших источников трафика любого Web-сайта. Для shareware, как и любого бизнеса, поисковые системы хороши тем, что привлекают к продукту внимание не просто посетителей, а потенциальных покупателей. Например, по наблюдениям разработчиков shareware-программ, предназначенных для корпоративного рынка, наибольшая часть аудитории узнает об их продуктах не из других традиционных для рынка shareware-программ источников, (например, специализированных каталогов программ), а именно из поисковых систем.
Из сотен существующих в мире поисковых систем самыми популярными и, следовательно, приводящими наибольшее количество посетителей, являются следующие: www.excite.com, www.google.com, www.hotbot.com, www.lvcos.com, www.northernlight.com, www.overture.com, www.yahoo.com.
Примечание
Примечание


Список популярных поисковых систем еще недавно был гораздо шире и включал lnfoseek.com, Snap.com, WebCrawler.com. Сегодня некоторые из известных когда-то поисковых серверов представляют собой всего лишь оболочки поисковых механизмов других компаний, например Overture или Excite.
Попасть в базы данных этих серверов очень легко — как известно, роботы поисковых систем самостоятельно "прочесывают" Всемирную паутину и индексируют страницы Web-сайтов. Через несколько месяцев, а иногда даже недель после появления нового сайта в Сети он попадает в поисковые системы. Впрочем, если не хочется ждать, то можно самостоятельно посетить эти поисковые серверы и заполнить Web-формы с информацией о сайте. Это заставит поисковых роботов проиндексировать страницы сайта "вне очереди". Также заполнение формы на сайте помогает не только при необходимости добавить сайт в базу данных поисковой системы, но и в том случае, если требуется специально проиндексировать страницы сайта — например, при появлении на нем новых разделов, которые могут представлять заметный интерес для посетителей.
Исключение, пожалуй, составляет только последний в списке сайт — Yahoo! (http://www.yahoo.com). Основа портала Yahoo! — не поисковая система, а каталог — самый старый из ныне существующих, впервые воплотивший заимствованную сейчас на тысячах аналогичных сайтов концепцию каталога — иерархическую систему разделов и расположение ссылок на разделы на главной странице в две колонки.
Yahoo! является одним из самых посещаемых интернет-ресурсов в мире, однако основная ценность для сайтов, опубликованных в каталоге, заключается в другом. Когда пользователь начинает что-то искать (введя ключевое слово и нажав кнопку Search), то Yahoo! пытается сначала найти вхождения в каталоге, и, если находит хотя бы одно, то в результатах поиска пользователь увидит только ссылки из каталога (Рисунок 10.5). Даже если найдена всего одна ссылка! А раньше по запросам пользователей Yahoo! выдавал множество ссылок на разные сайты (это был результат работы поисковой машины Inktomi). Теперь же эти многочисленные ссылки, найденные поисковиком (используется механизм Google), можно получить, только дополнительно щекнув по специальной ссылке. Естественно, большинство пользователей этого не делает, а идет сразу по предложенной единственной ссылке. То есть, ценность именно в попадании в каталог, т. к. это дает сайту привилегии при поиске по ключевым словам, и, учитывая огромную популярность каталога Yahoo! — значительный приток посетителей. Причем, по отзывам shareware-разработчиков, довольно "качественных" как покупателей.
К сожалению, попасть в Yahoo! довольно сложно. Заявки на публикацию в каталоге, подаваемые владельцами сайтов, рассматриваются очень долго (1—2 месяца), и лишь немногие из сайтов-претендентов попадают в каталог, причем нередко — далеко не с первого раза. Правда, можно воспользоваться услугой Yahoo! Express (http://docs.yahoo.com/info/suggest/busexpress.html) за 299$ сайт точно будет рассмотрен сотрудниками Yahoo! и, возможно (но не обязательно!) включен в каталог. Но это не останавливает владельцев сайтов: попадание в каталог быстро окупит потраченные 299$. По отзывам воспользовавшихся услугой Yahoo! Express, подавляющее большинство из рассмотренных за плату сайтов все-таки включается в каталог.

Полная статистика продаж

Полная статистика продаж

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

Получение денег чеком или на счет?

Получение денег: чеком или на счет?

Как уже упоминалось в разд. "Регистраторы" этой главы, компании, осуществляющие прием платежей за shareware-программы, переводят деньги разработчикам двумя способами: банковским чеком и переводом на валютный счет — по выбору каждого конкретного автора. В данном разделе я подробнее расскажу об этих способах и их преимуществах и недостатках.

Продажи в России

Продажи в России

Для продажи программы на российском рынке совершенно необходим перевод ее интерфейса и Web-сайта на русский язык. Российские пользователи настолько привыкли к русским интерфейсам программ, что меню и диалоги на английском языке вызывают у них дискомфорт. Например, когда я стал распространять свою программу Actual Startup (http://www.actualsystem.com /products/startup), имевшую тогда только английский интерфейс, каждое (!) из писем пользователей содержало не только отзывы и предложения по улучшению программы в будущем, но и просьбы сделать в программе русский язык. И это притом, что Actual Startup (менеджер автозагрузки Windows) предназначается для опытных пользователей и имеет достаточно простой интерфейс.
К счастью, для того чтобы создать русскую версию интерфейса и Web-сайта программы, российскому разработчику не нужно пользоваться услугами переводчика. Правда, при взгляде на некоторые Web-сайты начинающих программистов сразу возникает ощущение, что помощь специалиста, по крайней мере, корректора, здесь все-таки необходима — настолько много встречается грамматических и орфографических ошибок.
Большинство российских shareware-авторов продают свои программы в России через Shareg.com (http://www.shareg.com) — российского регистратора, осуществляющего прием платежей из России и республик бывшего СССР всеми доступными способами — квитанциями Сбербанка, почтовыми и телеграфными переводами, банковскими переводами, переводами через платежные интернет-системы (например, Webmoney), кредитными картами, наличным платежом (Рисунок 10.10).
Услуги Shareg.com, в которые входит размещение программы на Shareg.com, обработка платежей от клиентов, предоставление авторам отчетов по платежам, стоит 20% от конечной цены программы.

Продвижение программ

Продвижение программ

Программу можно оплатить пятью способами

Рисунок 10.2. Программу можно оплатить пятью способами

Рассылка прессрелизов

Рассылка пресс-релизов

Популярный способ продвижения собственного shareware-продукта — рассылка пресс-релизов в различные компьютерные издания. Способ этот не бесплатен, поэтому к нему прибегают обычно те авторы, которые уже заработали на рынке shareware некоторое количество денег и собираются вложить их в новые рекламные акции, которые недоступны тем, кто не хочет тратить деньги на продвижение своих продуктов и довольствуется бесплатной рекламой наподобие сабмита в каталогах программ.
Пресс-релиз (press-release) — это небольшая по объему статья, предназначенная для публикации в средствах массовой информации, рассказывающая о событиях в компании, анонсирующая выпуск нового продукта и т. п. Помимо того, что пресс-релизы рассылаются в издания, подходящие по тематике пресс-релиза, они также публикуются на сайте компании, выпустившей пресс-релиз, в разделе "Для прессы". Чтобы увидеть наглядные примеры того, как должен выглядеть "правильный" пресс-релиз, достаточно зайти па сайт какой-нибудь солидной компании и посмотреть соответствующий раздел.
Отзывы об эффективности рассылки пресс-релизов у разработчиков разные. Кто-то из авторов доволен: даже учитывая то, что пресс-релиз был опубликован всего в 3—4 журналах, а рассылка была проведена более чем по 1 500 адресов, акция окупилась сполна. Немногочисленные, но качественные обзоры (внимание редакторов было привлечено как раз пресс-релизами) в популярных журналах вызвали скачок регистрации, и доход от них многократно превысил затраты на подготовку и рассылку пресс-релиза. А кто-то, воспользовавшись рассылкой пресс-релизов, остался разочарован: в ответ пришли в основном только письма типа "Адрес не найден", "Я в отпуске", просьбы ничего больше не высылать по этому адресу, и лишь несколько запросов дополнительной информации.
И все-таки опытные shareware-разработчики рекомендуют воспользоваться рассылкой пресс-релизов. Только подходить к этому надо очень тщательно, соблюдая определенные правила.

Если для рассылки пресс-релизов планируется воспользоваться услугами специализирующейся на этом фирмы, то лучше всего доверять той, о которой существуют положительные отзывы других shareware-разработчиков. Например, хорошо отзываются о DPDirectory (http:// www.dpdirectory.com): при нормальной для такой услуги цене (99$) эффект от рассылки вполне удовлетворителен (обзоры программы в различных престижных журналах), кроме того, фирма ведет мониторинг -т. е. отслеживает публикации о рекламируемом продукте и даже присылает вырезки с их текстами. Если рекламные обещания какой-то незнакомой вам фирмы кажутся .заманчивыми, и никто из ваших знакомых тоже ничего о ней не слышал, попробуйте провести поиск по ее названию в Usenet — наверняка вы обнаружите отзывы других людей об этой компании.

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

краткое изложение новости;

текст, в котором формулируется проблема, для решения которой предназначен продукт;

описание продукта.

Таким образом, редактор вполне может опубликовать пресс-релиз полностью. Если он уберет из пресс-релиза какие-то части, то получится тоже неплохо: например, только части 2 и 3 образуют что-то наподобие проблемной статьи; части 1—3 четкое сообщение о выходе нового продукта; и даже часть 1, опубликованная в виде краткой новости, привлечет немалое внимание публики.
Текст пресс-релиза, конечно же, должен быть написан безукоризненным английским языком (за это, если у вас нет знакомого профессионального переводчика, придется хорошо заплатить).
Самостоятельная рассылка пресс-релизов считается более выгодной, т. к. в этом случае у shareware-разработчика существует больше возможностей для контроля хода и результатов рассылки. Правда, список адресов все равно придется купить. Но делать это нужно очень осторожно. Фирма-продавец должна быть надежной — о ее надежности можно судить, как и в случае с подбором компании для рассылки пресс-релизов, по отзывам других пользователей. Списки никогда нельзя покупать "вслепую" (просто "список для рассылки пресс-релизов") — вам вполне могут умышленно или неумышленно "подсунуть" список главных редакторов периодических изданий штата Небраска. В худшем случае берите "список адресов редакций компьютерных журналов". Поинтересуйтесь географией, хотя бы приблизительно: только ли это американские издания, или и европейские тоже. Поинтересуйтесь также, offline ли это журналы или среди них есть и online-издания. Если online-журналы в списке присутствуют, то выясните хотя бы соотношение изданий online и offline. Покупать списки, в которых много online-журналов, не рекомендуется -- такие журналы растут как грибы и так же быстро закрываются. Ведутся они зачастую студентами, которые по окончании университета бросают это дело — т. е. большинство таких адресов может оказаться нерабочими.
При рассылке пресс-релизов большое значение имеют личные связи в редакциях журналов: важно построить хорошие отношения с людьми, которые там работают. Если присланный пресс-релиз или обзор на его основе не публикуется (хотя вроде бы редактор сначала согласился его опубликовать) — не нужно беспокоить человека письмами и даже звонками с вопросами о том, почему не опубликован пресс-релиз — этим ничего, кроме ухудшения отношений, добиться нельзя. Если пресс-релиз был опубликован хотя бы частично или был использован для подготовки статьи — нужно поблагодарить редактора за сотрудничество и выразить восхищение его замечательным материалом. А если в статье ваш продукт подвергся жесткой критике — не спорьте, даже если журналист написал явную чушь. Просто при выходе следующей версии пошлите ему письмо с благодарностью за критику, напишите, что постарались учесть все его замечания (а те, которые не учли, учтете в следующей версии). Можно даже попросить разрешения внести его имя в раздел "Благодарности" документации программы — он наверняка будет польщен этим, и станет публиковать ваши новые пресс-релизы.
Во многом успех рассылки пресс-релизов зависит от везения: удачного сочетания тематики программы, текущих планов периодических изданий, и даже расположения духа их редакторов. Но при качественной проработке всех вопросов, связанных с рассылкой пресс-релизов, шансы на успех многократно повышаются.

Рассылка регистрационных ключей

Рассылка регистрационных ключей

В конференциях, посвященных shareware, часто задают вопрос — как лучше всего рассылать регистрационные ключи: самостоятельно или поручить это регистраторам?
Многие разработчики рекомендуют возложить рассылку ключей на регистратора. Такой способ организации дела обладает следующими преимуществами. Во-первых, при большом объеме продаж рассылка ключей регистратором может сэкономить немало времени: автору не нужно самому составлять письма о регистрации, вставлять в них нужный ключ и т. д.; во-вторых, регистратор практически всегда высылает ключ быстрее, чем это может сделать автор (а задержки с получением ключа могут вызывать недовольство покупателей); наконец, ключ высылается всегда, а вот автор иногда не может этого сделать, например, из-за отъезда в отпуск или проблем с доступом в Интернет.
Однако возможности регистраторов по рассылке ключей устраивают далеко не всех авторов. Например, для эффективной работы shareware-проекта регистратор должен:

принять список из ключей (он может быть довольно объемным — из сотен регистрационных номеров);

высылать каждому зарегистрировавшемуся пользователю письмо, текст которого предоставляется автором;

включать в определенное место этого письма регистрационный номер из списка, который был прислан автором;

отсылать письма от имени и с указанием обратного адреса автора, а не своего (регистратора) собственного;

высылать каждому пользователю уникальный регистрационный номер из списка, т. е. вести учет номеров — кому какой номер выдан — и не допускать, чтобы один и тот же номер был выслан более, чем одному пользователю;

присылать автору вместе с информацией о зарегистрировавшемся пользователе информацию о том, какой ему номер выслан.

Как показывает практика, не каждый регистратор обладает такими возможностями по рассылке номеров. Кто-то не умеет рассылать письма, текст которых определен автором, кто-то не отслеживает, какой именно номер был выслан конкретному пользователю и т. д.
Если же автору shareware-продукта нужно, чтобы ключи высылались не из статического списка, а генерировались по имени пользователя, которое было указано при заказе, то, если регистратор поддерживает такую возможность, ее реализация тоже может устраивать не всех. Например, начинающему разработчику, программирующему на Visual Basic, не подойдет предложение предоставить кодогенератор в виде DLL-библиотеки (функция получает имя пользователя, возвращает код) или консольной программы под DOS (имя передается как параметр, код отправляется в текстовый файл или стандартный output) — так, в частности, организована поддержка кодогенераторов на RegSoft и Sharelt!. Скорее всего, рассылка регистратором ключей, генерируемых по имени пользователя, не устроит и тех shareware-разработчиков, которые для защиты своих программ используют специализированные пакеты третьих фирм, ведь алгоритм генерации регистрационных ключей в данном случае закрыт.
Но основной недостаток рассылки ключей регистратором заключается в следующем: если антифраудная система регистратора работает неэффективно, то довольно большое число ключей будет попадать в руки злоумышленников. Главная слабость любой автоматической проверки правильности заказа — если номер кредитной карты был украден, то деньги с этой карты зачисляются на счет регистратора и он высылает ключ на адрес e-mail (как правило, анонимный) злоумышленника. Однако через некоторое время настоящий владелец кредитной карты обнаружит несанкционированное снятие денег со своей карточки и попросит свой банк отменить платеж — что и будет сделано банком без лишних вопросов ("chargeback", см. разд. "Возврат денег" данной главы). Вот пример пропущенного системой регистратора заказа:
First Name: Great Last Name: Satan
Address 1: 666 hell drive
City: Hell
Country: USA
Phone: 666-6666-666
Email Address: hzds@hotmail.com
Деньги по этому заказу были зачислены на счет, и система рассылки ключей регистратора отправила серийный номер на указанный в форме заказа анонимный почтовый адрес. Но, если бы заказы проверялись не программой, а вручную, т. е. хотя бы просматривались сотрудником компании-регистратора, то заказ был бы заблокирован, т. к. очевидно, что это — потенциальный "chargeback" (см. разд. "Возврат денег" данной главы).
Некоторые регистраторы преподносят разработчикам еще один "сюрприз". Они не высылают покупателю регистрационный номер, а просто показывают его на странице. Если регистратор работает именно так — лучше посылать номер самостоятельно или выбрать другого регистратора. Многие покупатели этот номер просто не замечают, не записывают или записывают, но с ошибками. Это доставляет разработчику много хлопот и неприятностей - пользователи начинают сердиться, предъявлять автору претензии, обвинять в обмане, требовать вернуть деньги.
После описания всех этих недостатков в реализации рассылки регистрационных ключей различными компаниями-регистраторами может создаться впечатление, что найти регистратора, имеющего удовлетворительный сервис по рассылке ключей, невозможно. Конечно, это не так. Например, известнейшая компания RegNow (http://www.regnow.com), по отзывам, замечательно справляется с рассылкой ключей, в том числе и при довольно больших объемах продаж (несколько десятков регистрации в день), выполняя требования, указанные ранее (большие списки номеров, каждый покупатель получает уникальный ключ, отправка писем, текст которых определен разработчиком и т. д.). Проверка на фрауды при этом проводится довольно поверхностная, однако, если ее ужесточить, это вызывает недовольство клиентов. Но даже при такой простой проверке на фрауды число последних относительно невелико — 2—3% от общего числа регистрации. Если "прошивать" ключи, полученные по фраудам, внутри ЕХЕ-файла программы, чтобы эти ключи не могли разблокировать закрытые в незарегистрированной версии функции, и менять дистрибутив на сервере программы, то фрауды не приносят ощутимого ущерба продажам продукта.
А что же ручная рассылка ключей, т. е. рассылка, осуществляемая разработчиком программы. Все недостатки рассылки ключей регистратором в данном случае трансформируются в достоинства, и наоборот. Так, достоинства ручной рассылки ключей таковы:

более высокая степень антифраудной защиты: заказы, которые не были блокированы регистратором, дополнительно проверяются автором;

не надо беспокоиться о том, как будут генерироваться ключи: разработчику не нужно писать специальный кодогенератор для установки его на сервере провайдера, автор может использовать те средства, которые удобны именно для него;

автор имеет полный контроль над процессом рассылки писем с регистрационными номерами.

Соответственно, недостатки ручной рассылки ключей состоят в следующем:

обработка уведомлений о заказах и подготовка писем с регистрационными ключами занимает дополнительное время, что может быть очень существенно при большом объеме продаж;

автор программы не может высылать ключи так же быстро, как регистратор;

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

Различные варианты перечисления денег

Различные варианты перечисления денег

Регистратор должен уметь высылать деньги автору в зависимости от суммы, накопленной на счету автора у регистратора, или по графику — по выбору автора. При этом нормальной практикой считается установление определенной минимальной суммы, которая может быть выслана. Например, автор желает получать деньги раз в месяц, однако регистратор переводит минимум 200$ за один раз. Следовательно, если за месяц на счету автора накоплено 150$, то они не высылаются, а остаются на счету и могут быть перечислены в следующем месяце — когда сумма на счету достигнет отметки 200$.
Кроме этого, хороший регистратор имеет возможность пересылать деньги как минимум двумя способами: банковским переводом на валютный счет (wire transfer) и чеком (check).

Различные варианты рассылки регистрационных ключей

Различные варианты рассылки регистрационных ключей

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

ключ высылается автором программы;

ключ высылает регистратор, при этом ключи выбираются из списка, предоставленного автором программы;

ключ высылает регистратор, генерируя его предоставленной автором программы утилитой-кодогенератором.

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

Различные варианты стоимости копий

Различные варианты стоимости копий

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

Регистрация в каталогах

Регистрация в каталогах

Процесс регистрации программы в каталоге (как, впрочем, и в поисковой системе или online-сервисе) называется по-английски submit, что в переводе означает "предлагать", "представлять на рассмотрение". Как и в случае с терминами chargeback и refund (см. разд. "Возврат денег" данной главы), русского перевода этого термина, столь же краткого и поэтому удобного для применения, как оригинал, не нашлось, и среди русскоязычных разработчиков используется его русскоязычная транскрипция — "сабмит".
Каталоги программ принимают регистрации новых продуктов тремя способами:

E-mail — описание программы высылается письмом. Сейчас используется очень редко.

HTTP — на сайте архива заполняется Web-форма с информацией о программе. Это — самый распространенный способ, он используется на подавляющем большинстве Web-сайтов.

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

Различают три основных вида сабмита:

Ручной — при котором автор программы (или другое лицо, ответственное за сабмит) самостоятельно посещает Web-страницы каталогов программ с формами добавления новой программы, заполняет все поля вручную (значения полей либо вводятся с клавиатуры, либо копируются через буфер обмена). Этот вариант приносит максимальный эффект (т. е. программа появляется на максимально возможном числе архивов программ), но при этом требует и максимальных затрат времени.

Автоматический — с помощью специальной программы для регистрации программных продуктов в каталогах (так называемый "сабмиттер"). Для этого требуется в сабмиттере один раз заполнить форму с информацией о программе,, нажать кнопку — и данные будут отосланы в каталоги программ, имеющиеся в базе данных сабмиттера. Затраты времени минимальны, однако и результат обычно неважный — программа появляется самое большее лишь на трети архивов, на которые отправлялись данные. Происходит это по следующим причинам. Во-первых, механизмы регистрации программ в каждом конкретном каталоге время от времени меняются (к примеру, дабавляются новые поля Web-формы), и запросы, посылаемые сабмиттером, не принимаются. Во-вторых, иногда при регистрации программы в архиве возникают некоторые трудности (скажем, архив требует предоставление какой-то специфической информации о программе, например, регистрационный ключ для полноценного тестирования продукта), которые программа-сабмиттер не может отследить. Не удивительно, что автоматических сабмиттеров на рынке сейчас очень мало, и ими практически никто не пользуется. Даже признанный лидер среди программ такого рода - AddSoft (http://www.cyberspacehq.com) больше не поддерживается разработчиками.

Полуавтоматический - "золотая середина". Для такого сабмита также используется программа-сабмиттер, но несколько иного плана. Она, как и автоматические сабмиттеры, содержит базу данных сайтов и базу данных программ, которую пользователь заполняет информацией о своих продуктах. После нажатия на кнопку Submit, программа поочередно открывает страницы каталогов программ, содержащих Web-формы регистрации. После того как очередная страница загрузилась, программа автоматически заполняет поля формы нужной информацией. Пользователю остается только подтвердить правильность заполнения формы и нажать кнопку подтверждения регистрации. Полуавтоматический сабмит характеризуется наилучшим соотношением временных затрат и полученного результата, т. к. сабмиттер не отправляет информацию на сайт программы (этот процесс часто проходит неудачно из-за изменений в механизме регистрации программ и политики архивов), а лишь помогает пользователю заполнять Web-формы на сайтах архивов программ. Среди программ-сабмиттеров этой категории можно назвать RoboSoft (http://www.rudenko.com), SubMass (http://www.submass.com), Submitus (http://www.officetune.com/).
Однако даже полуавтоматического сабмита недостаточно для того, чтобы программа появилась на всех сайтах, куда была отправлена информация. В некоторые каталоги программ (в основном это крупные и популярные архивы, персонал которых очень загружен) нужно делать сабмит несколько раз, т. к. заявка на публикацию может отклоняться по каким-то причинам или без них — например, у редактора архива было плохое настроение. Поэтому примерно через неделю обычно проверяют, опубликована ли программа на сайтах каталогов. Может быть три варианта:

Программа появилась на сайте.

Программа не появилась на сайте.

Программа появилась на сайте, однако информация для нее указана неверная.

При первом варианте, конечно же, ничего делать не нужно. Если же программа на каких-то сайтах появилась, то производится повторный сабмит; если же программа опубликована, но информация указана с ошибкой, то администратору соответствующего каталога пишется письмо с просьбой исправить информацию о программе. Благодаря этому можно добиться того, что программа появится на большинстве сайтов, за исключением разве что тех, кто принципиально против программ этой категории.
Для хорошей "раскрутки" своей программы, если только это не гениальное произведение, о котором тут же напишут на первой странице нескольких самых крупных и популярных каталогов, сегодня необходимо регистрировать свою программу на 120—150 архивах. Естественно, вести такую деятельность, учитывая необходимость делать проверки правильности регистрации и повторные сабмйты, программисту, на котором также лежит разработка новых версий программы и техническая поддержка пользователей, очень не просто. Поэтому многие shareware-разработчики прибегают к услугам компаний, осуществляющих сабмит программ за плату (цены начинаются от 50$ за сабмит одного программного продукта на 120 и более каталогов программ, проверку результатов и повторный сабмит). А те, кто уже имеет постоянный и достаточно высокий уровень дохода от продаж своих продуктов, нанимают на работу сотрудников, занимающихся только сабмитом.
РАD-файлы
PAD — это аббревиатура Portable Application Description, что переводится как "переносимое описание приложения". PAD - специальный формат файлов, содержащих детальное описание программы.
PAD был разработан в Ассоциации профессионалов shareware (ASP) для того, чтобы облегчить обмен информацией о программных продуктах между авторами и потребителями. PAD избавляет автора программы от заполнения формы или составления электронного письма с описанием программы, когда ему нужно предоставить информацию потенциальному партнеру или покупателю. С использованием технологии PAD в ответ на запрос ему нужно просто отослать файл в формате PAD, а получатель с помощью специальной программы извлекает из файла информацию в том виде, в котором она ему нужна.
С технической точки зрения, PAD представляет собой текстовый файл с именем pad_file.xml, размеченный с помощью тегов XML (Extended Markup Language, расширенный язык разметки). Теги XML служат для выделения соответствующих полей: например, тег служит для обозначения названия программы, a указывает на предпочтительный адрес для закачки файла с дистрибутивом продукта (Рисунок 10.7).

Регистраторы

Регистраторы

Реклама продуктов

Реклама продуктов

Если регистратор, помимо приема платежей, осуществляет и рекламу продуктов, которые продаются через него, то это является очень большим плюсом, т. к. обеспечивает дополнительный и при этом довольно солидный приток покупателей. Самый распространенный способ рекламы продукта, который может вести регистратор, — это публикация информации о программе в каком-нибудь крупном и популярном каталоге программ, куда "обычному" автору не так уж легко попасть, и размещение рядом с описанием программы ссылок "Зарегистрировать". По таким ссылкам на страницы регистрации программ приходит довольно приличное число покупателей. Например, многие shareware-авторы пользовались услугами регистратора RegNow (http://www.regnow.com) до 2000 года в основном из-за того, что их программы при этом размещались в одном из самых популярных shareware-архивов WinFiles (http://www.winfiles.com, в настоящее время он закрыт), а по веселым ярко-зеленым кнопочкам Register Now! щелкало довольно большое число покупателей. Впрочем, сейчас ссылки на RegNow стоят в другом популярнейшем каталоге - Download.com: щелкнув по красной кнопке Click to buy!, посетитель может сразу приобрести программу.
Другим способом рекламы продуктов из каталога компании-регистратора является выпуск и распространение сборников программ на CD-ROM. В нем, помимо описаний и файлов программ, размещается информация о том, как зарегистрировать ту или иную программу. Очень важно и то, что такие сборники попадают в руки пользователей, по каким-то причинам не имеющих доступ в Интернет, но которые, тем не менее, имеют возможность зарегистрировать программу по телефону или факсу.

Результат поиска в Yahoo! сайту

Рисунок 10.5. Результат поиска в Yahoo!: сайту, размещенному в этом каталоге, обеспечено повышенное внимание посетителей


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

Российский рынок shareware

Российский рынок shareware

Российский sharewareрынок

Российский shareware-рынок

И все-таки, что это за рынок shareware-программ в стране, где в любом городе в киоске за 2—3$ можно купить пиратский компакт-диск с полным набором программ?
Распространено мнение, что у нас в стране программы законно покупают в основном организации, и при этом не shareware-продукты, а коммерческие пакеты наподобие серверного программного обеспечения, операционных систем, бухгалтерских программ... "Домашние" пользователи якобы покупают программы очень редко. Если же shareware-программу приобретает частное лицо, то этот пользователь обычно живет в Москве или Санкт-Петербурге, где и доходы населения гораздо выше, чем в среднем по России, и пластиковые карточки распространены шире.
Как свидетельствует статистика продаж на российском рынке, все это, к счастью, не соответствует действительности.
Частные пользователи приобретают shareware-программы в России довольно неплохо — это видно по динамике продаж продуктов, рассчитанных на индивидуальных пользователей, а также использование в личных целях — например, часов, органайзеров, dial-up-звонилок и, конечно же, игр. Да, игру никогда не купит организация (если, конечно, ее профессиональные интересы не лежат в области игровой индустрии), однако продаются они очень хорошо.
Неплатежеспособность российских частных пользователей — тоже миф. Покупатели из России, вопреки распространенному мнению, готовы платить за shareware-программы много больше, чем стоимость одного пиратского компакт-диска. Например, часы Chameleon Clock (http://www.softshape.com) стоят 100 рублей, GoldenSection Organizer (http://www.tgslabs.com) - 250 рублей, а "звонилка" FlexibleSoft Dialer (http://www.flexiblesoft.com), продукт из категории традиционно бесплатных в нашей стране, продается даже за 300 рублей. Получить плату за действительно качественный и мощный продукт даже при наличии бесплатных конкурентов — не проблема.
Говоря о якобы неплатежеспособности российских пользователей, показателен пример с продажами программы просмотра изображений ACDSee (http://www.acdsystems.com). Взломанная версия этой программы установлена чуть ли не на каждом третьем компьютере в России, тем не менее ACDSee довольно хорошо продается и через российского реселлера по цене 60$, причем покупают этот продукт как организации, так и частные пользователи.
Да, ценность российского рынка, небольшого сейчас, но имеющего хорошие перспективы, осознают и зарубежные разработчики shareware-программ. Например, в каталоге программ SoftList (http://www.softlist.ru), администратором которого я являюсь, зарегистрировали свои программы уже больше тысячи зарубежных авторов. Многие, опубликовав программу в каталоге, пишут, что не ожидали такого большого интереса к своим программам со стороны русских пользователей и готовы продавать русские версии своих программ в России. При этом они готовы пойти на снижение цены до приемлемого для России уровня — не больше 10$. И оказывается, что они прекрасно понимают, — в России пока нельзя надеяться на большую прибыль, нужно сначала приучать россиян платить за программы.
А один француз, автор мощного каталогизатора изображений (цена для зарубежных пользователей —29$), готов был продавать свой продукт в России вообще всего лишь за 4$ (!), при этом он предполагал 75% отдавать российскому дистрибьютору за представление программы в России (перевод интерфейса, Web-сайта и прием платежей). Удивительно: человек готов отдавать свою программу почти бесплатно — за 1$! Вот вам пример того, на что готовы пойти иностранцы для захвата нашего рынка.
Утверждать, что, якобы, нигде, кроме Москвы и Санкт-Петербурга, легально программы не покупают — тоже не верно. Конечно, больше всего покупателей именно из этих двух городов (что, действительно, объясняется большой численностью населения, высоким уровнем доходов и развитой технологической инфраструктурой), однако из других регионов России приходит достаточное количество регистрации, чтобы принимать "провинциальный" shareware-рынок всерьез.

Самостоятельный прием платежей

Самостоятельный прием платежей

Итак, первая версия вашей shareware-программы создана, к ней написана справочная система, дистрибутив загружен на виртуальный сервер, специально зарегистрированный у надежного коммерческого хостинг-провайдера. Словом, ваша программа готова к продажам на мировом shareware-рынке. Однако остается еще один важный вопрос — как же будет происходить процедура поступления денег от покупателей программы к автору shareware-программы?
На заре shareware отец-основатель индустрии Джим Кнопф (см. разд. "История shareware" гл. 1) получал деньги в конвертах писем от пользователей, желавших подписаться на рассылку уведомлений о выходе новых версий программы. Так же поступали и другие авторы, перенявшие придуманный Кнопфом и Эндрю Флюгльманом способ распространения программ.
Сегодня, по истечении двадцати лет, некоторые авторы, в том числе и российские, все еще пытаются получать платежи за свои программы по той схеме — в конверте. Вот, например, цитата с сайта одного из начинающих разработчиков shareware-программ:
Правила получения платной версии.
Вы высылаете деньги в конверте на адрес: 420 111, г. Казань, а/я XXX, приложив с ними свои контактные данные: [...]
Правила отсылки денег в конверте.
Чтобы ваши деньги не стали достоянием недобросовестных работников почты и дошли до нас, соблюдайте следующие простые правила:

Вырежьте два газетных или исписанных листа, в два раза больше конверта, сложите их пополам по длине конверта.

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

Все вместе положите в конверт.

Проверьте, не просвечивают ли деньги на свету. Если просвечивают, возьмите еще один лист бумаги и оберните деньги".

Конечно, прочтение таких инструкций вызовет у потенциального покупателя скорее улыбку, чем желание действительно отослать деньги. Описание того, как нужно упаковывать деньги в конверт, однозначно указывает на несерьезную организацию бизнеса, ведь даже простые граждане переводят своим родственникам деньги почтовым или телеграфным переводом, а не пересылают их в конверте почтового отправления.
Да, программист-одиночка, не зарегистрированный в качестве юридического лица или частного предпринимателя, имеет очень ограниченные возможности самостоятельного получения денег от покупателей своих программ. При этом практически "отсекаются" российские организации и все зарубежные пользователи, т. е. подавляющее большинство из платежеспособной аудитории shareware-программ. Дело в том, что для таких потребителей перевод денег российскому физическому лицу (т. е. гражданину, частному лицу) сопряжен с обременительными хлопотами, и для них проще выбрать продукт, процедура регистрации которого более дружественна.
Есть еще одна причина, из-за которой самостоятельно принимать платежи из-за границы в России не имеет практически никакого смысла. Дело в том, что за каждый перевод банк, осуществляющий пересылку денег, берет определенную плату, составляющую определенный процент от суммы перевода, но которая при этом не может быть ниже определенного минимума. Так вот, почти всегда этот минимум составляет 20—30 долларов, т. е... среднюю цену shareware-программы! Это означает, что банковская комиссия будет "съедать" почти всю сумму платежей, осуществляемых пользователями в качестве оплаты регистрации программы.
Но, т. к. я в предыдущих главах книги неоднократно упоминал об успешной работе на shareware-рынке авторов-одиночек, должно существовать какое-то решение этой проблемы. Таким решением являются так называемые регистраторы.

Сколько должно быть регистраторов

Сколько должно быть регистраторов

Если почитать статьи о shareware в журналах, просмотреть архивы конференций, то можно заметить, что преобладает точка зрения о том, что для приема платежей нужно пользоваться услугами одновременно двух регистраторов. Не одного, не трех-четырех и больше, а именно двух. Эта точка зрения основывается на следующих соображениях.
Если предлагать пользователям только одного регистратора, то может случиться, что по каким-то причинам (например, локальные настройки или временная недоступность сервера регистратора) они не смогут через него зарегистрироваться. В этом случае как раз и пригодится второй регистратор — шансов, что серверы обоих служб окажутся недоступны одновременно, все-таки очень немного.
Два регистратора, за счет различий в предоставляемых услугах, могут обеспечить и большую гибкость при ведении дел. Предположим, разработчик пользуется услугами двух регистраторов, один из которых берет высокую комиссию, но зато имеет эффективную защиту от фраудов, а второй, хотя и не так тщательно проверяет заказы, но взимает меньшую комиссию. Через первого регистратора можно предлагать зарегистрироваться пользователям-одиночкам, среди которых много желающих получить ключ бесплатно за счет предоставления фальшивых или украденных данных: эффективная ан-тифраудная защита будет отсекать почти все попытки злоумышленников. А вот второго регистратора можно использовать для обработки крупных заказов, например, покупок корпоративными клиентами многопользовательских лицензий. Фраудов в таких случаях практически не бывает, а более низкий процент комиссии регистратора позволит автору сэкономить значительные суммы.
Если же shareware-разработчик пользуется услугами более чем двух регистраторов, это, как показывает практика, не прибавляет покупателей, однако создает проблемы при получении денег автором. Большая часть пользователей регистрируется через того регистратора, который стоит в списке первым, что подтверждается опытом тех разработчиков программ, которые имеют не статический список регистраторов, а периодически "тасуют" его. Деньги с покупок остальных пользователей, составляя довольно приличную сумму, будут "распылены" по оставшимся в списке регистраторам, а из-за того, что на счетах каждого конкретного регистратора будет относительно небольшая сумма денег, регистратор не будет ее высылать. Например, если разработчик использует услуги пяти "лишних" регистраторов, то на их счетах могут "зависнуть" денежные средства объемом до тысячи долларов!
Примечание
Примечание


К "лишним" регистраторам не относятся национальные регистраторы (с/и. разд. "Выбираем регистратора" данной главы). Считается вполне нормальным иметь несколько дополнительных национальных регистраторов — ведь каждый из них обслуживает shareware-рынок определенной страны или региона, и их покупательские аудитории почти никогда не пересекаются.
Однако существует еще одна точка зрения на вопрос об оптимальном количестве регистраторов, которых может использовать один разработчик, и лично я ее разделяю. Она состоит в том, что при относительно небольшом объеме продаж, например до тысячи долларов в месяц, иметь более одного регистратора слишком дорого. Дело в том, что регистраторы очень трепетно относятся к тем разработчикам, которые имеют солидные объемы продаж и, таким образом, приносят регистраторам большой доход. Поэтому такие разработчики могут смело торговаться с регистратором относительно более выгодных условий, дополнительной рекламной поддержки и т. п. А вот shareware-автор с приличным, но не самым большим объемом продаж, разделенным между двумя регистраторами, для каждого из них будет обычным мелким разработчиком.

Скорость работы регистратора

Скорость работы регистратора

После того как заказ принят, проходит некоторое время, пока регистратор проверяет данные, указанные в форме регистрации. Важно, чтобы это время не было неоправданно большим, иначе покупатель, оплативший программу, будет проявлять недовольство.
Если уведомление о заказе приходит автору практически сразу после того, как заказ был сделан, то это не всегда является показателем высокого качества работы регистратора. Обычно это означает, что заказ регистратором проверяется поверхностно и автору самому нужно тщательно проверить информацию, введенную пользователем при оформлении покупки, чтобы убедиться, что это не фрауд. Например, уведомления от регистратора RegNow приходят очень быстро, однако при этом "проходят" даже заказы, в которых, скажем, в качестве имени пользователя указывается "Devil", а в графе "номер телефона" - 666-66-66, т. е. явные фрауды.

Составление регистрационных писем

Составление регистрационных писем

Пользователь, оплативший регистрацию программы, в ответ получает письмо с подтверждением заказа и, если заказ успешно прошел проверку -письмо с регистрационным кодом. Есть некоторые особенности составления текста таких писем, которые нужно обязательно учитывать при работе над собственным shareware-проектом.
Как уже говорилось ранее, приемом платежей за регистрации shareware-программ занимаются специальные компании-регистраторы. От их же имени банк снимает деньги со счетов пользователей. Однако многие пользователи, оплачивающие регистрацию, не обращают внимания на то, что покупали-то они программу разработчика, например "AV Software", а форму регистрации заполняли на сайте регистратора. В результате пользователь, просматривая выписку по операциям по своему счету, обнаружив, что деньги были сняты каким-то RegNow или RegSoft. Помня, что у них он точно ничего не покупал, пользователь обращается в банк с требованием отменить снятие денег (т.н. "chargeback", см. разд. "Возврат денег" данной главы). Такой невнимательностью, оборачивающейся для авторов программ
убытками, как свидетельствует практика, грешат не только частные пользователи, но и работники солидных компаний и государственных учреждений.
Учитывая это, нужно обязательно внести в регистрационные письма информацию о том, от чьего имени будут сняты деньги с карточного счета пользователя. Например, так сделано и в письмах, приходящих в ответ на регистрацию таких известных shareware-программ, как, WinZip (http://www.winzip.com) и UltraEdit (http://www.ultraedit.com).
Еще один элемент регистрационных писем, вызывающий у пользователей затруднения, это... регистрационный ключ. Да, не у всех получается активизировать полученный за свои кровные ключ, открывающий закрытые в незарегистрированной версии функции.
Как это ни удивительно, многие пользователи не догадываются просто скопировать указанный в письме код в буфер обмена и вставить его в соответствующее текстовое поле в окне Регистрация программы. Они прилежно набирают буквы и цифры кода, который часто бывает очень длинным и сложным. Во время этой операции, конечно, очень легко ошибиться, например, набрав вместо прописной буквы "О" цифру "О" или вместо строчной буквы "1" - - единицу. После нескольких неудачных попыток раздосадованный и раздраженный пользователь предъявляет претензии автору, упрекает в недобросовестности, распространении некачественной программы и требует вернуть деньги.
Чтобы избежать этих неприятностей и не терять зря времени на выяснение причины возникшей проблемы, в регистрационном письме рядом с текстом ключа нужно подробно объяснить, как необходимо активизировать его, в том числе и не забыть напомнить о функции Копировать/Вставить, чтобы неопытные пользователи не набирали длинные последовательности цифр и букв ключа вручную.

Ссылки на регистратора

Ссылки на регистратора

Многие начинающие shareware-авторы, заключив договор с регистратором, удивляются, почему через этого регистратора нет ни одной покупки. После этого разработчик делает вывод, что выбранный регистратор работает неэффективно. Дело в том, что непосредственно регистраторы, за исключением отдельных компаний, оказывающих рекламную поддержку (см. разд. "Выбираем регистратора" данной главы), сами пользователей не приводят. Представители регистраторов признаются, что через них напрямую регистрации почти не идут, и основную роль в этом играет то, как shareware-автор дал ссылку на страницу регистрации.
Конечно, здесь возможны нюансы. Например, если регистратор грамотно организовал каталог с программами, которые он обслуживает, то страницы этого каталога будут эффективно проиндексированы поисковыми системами и, возможно, ссылки на страницу с описанием программы (рядом с которым находится и линк на страницу регистрации) появятся на видных местах в ответах на запросы пользователей к поисковым системам. Но, как можно догадаться, шансы получить заметный приток покупателей, надеясь на индексацию страниц регистратора поисковиками, не очень велики.
Основной источник потока покупателей, заходящих на страницу регистрации программы, — это ссылки в документации и на Web-сайте программы. Также автор может поставить эти ссылки и в окне О программе (About) своего продукта и (или) привязать их к пункту меню или командной кнопке. Именно по этим ссылкам подавляющее большинство покупателей попадает на страницу регистрации и оплачивает приобретение лицензии на программу.
При установке ссылок на страницу регистрации нужно не забывать о том, что регистратор, с которым вы работаете сейчас, в будущем, возможно, перестанет вас устраивать, и вы решите отказаться от его услуг. Вследствие этого установленные ссылки на страницу регистрации устареют.
В случае с установкой ссылок на Web-сайте программы никаких проблем не возникает: HTML-код ссылок модифицируется, чтобы они указывали на сайт нового регистратора. А вот ссылки в документации... Конечно, их можно поменять, но ведь предыдущие версии программы "расползлись" по всему Интернету и "осели" на множестве FTP-серверов, в частных online- и локальных коллекциях программного обеспечения. Время от времени они будут попадать в руки новых пользователей, которые, желая зарегистрировать программу, будут нажимать на ссылки, указанные в документации (увы, немногие пользователи, получив файл программы не с официального сайта разработчика, не удосуживаются проверить, новейшая у них версия или нет). И, столкнувшись с трудностями на таком ответственном этапе, как регистрация (ведь дело касается личных денег пользователя), вполне вероятно, что человек испугается и решит отказаться от использования программы.
Для решения этой проблемы можно применить два способа. Во-первых, в документации программы указывать не прямые ссылки на страницу регистрации, а ссылку на раздел "Регистрация" Web-сайта программы, где уже стоят прямые ссылки на регистратора. Меняя, при необходимости, ссылки на странице "Регистрация" Web-сайта программы, можно добиться того, что пользователи, щелкающие по ссылкам в документации программы, даже при смене регистратора могут продолжить процесс регистрации. Однако в данном случае существует небольшой недостаток: для пользователя процесс регистрации усложняется, т. к. после нажатия на ссылку в документации программы пользователь попадает сначала не на страницу регистрации, а в раздел "Регистрация" Web-сайта программы. В результате существует вероятность, что пользователь окажется сбит с толку — например, решит, что именно на этой странице нужно производить регистрацию.
Чтобы этого не произошло, можно использовать второй способ — переадресацию пользователя, нажавшего на ссылку в документации, при помощи CGI-скрипта. Он осуществим, если вы последовали моим советам по выбору хостинга в гл. 9 и разместили свой Web-сайт на тарифном плане с поддержкой CGI.
Вот как может выглядеть исходный текст простого CGI-скрипта на языке Perl, осуществляющего переадресацию на страницы регистрации различных программ и различных регистраторов.

Ссылки на сайт

Ссылки на сайт

Многие поисковые системы (например, Google, Excite, Lycos) определяют рейтинг сайтов, проиндексированных ими, исходя из того, как много других сайтов поставили ссылки на этот сайт. Google имеет более сложную систему оценки рейтинга: они учитывают не только количество, но и качество ссылающихся на индексируемый ресурс Web-сайтов. Например, ссылка с CNN.com ценится гораздо больше, чем ссылка с какой-нибудь домашней странички на бесплатном сервере.
Так как на сайты shareware-продуктов ставится очень много ссылок в online-каталогах программ, имеющих хороший качественный уровень и высоко оценивающихся поисковыми механизмами, то у shareware-разработчиков есть шанс получить неплохой рейтинг в поисковых системах, основанных на механизме Google (например, http://google.yahoo.com, http://www.google.de).

Стоимость обновлений программы

Стоимость обновлений программы

Как вы, вероятно, знаете, подавляющее большинство "коробочных" коммерческих продуктов продается по такой схеме: пользователь приобретает за определенную цену текущую версию, а будущие версии получает не бесплатно, а за деньги, правда, со скидкой.
На shareware-рынке многие авторы, стремясь привлечь пользователей и получить преимущество перед конкурентами, объявляют о том, что после регистрации программы все последующие версии пользователь может получать бесплатно. По мнению проводящих такую политику разработчиков, это хороший стимул для покупателей: в отличие от большинства фирм, которые продают новые версии со скидками и заставляют платить опять и опять, пользователей просят заплатить только раз на всю жизнь, и, тем самым, shareware-программа выгодно отличается от продукции "традиционных" компаний.
Тем не менее практика показывает, что бесплатность обновлений не является настолько важным фактором развития shareware-программы, чтобы из-за него пренебрегать дополнительными 30—50% дохода, который генерируется за счет продажи обновленных версий. Конечно, на некоторых покупателей возможность бесплатного обновления оказала бы решающее влияние, но процент таких покупателей мал: большинство привыкло к тому, что за обновленные версии нужно платить, и это не является значительным тормозящим продажи фактором. Вот, например, цитата из письма одного пользователя (естественно, в переводе с английского), опубликованная в конференции SwRus: "Пожалуйста, взимайте плату за эту новую версию. Предыдущие обновления Вашей программы были бесплатными, и плата за обновления программы для поддержки Ваших усилий будет воспринята с пониманием и внесена без колебаний".
Да, распространение новых версий программы за плату — привычный и логичный с точки зрения пользователей ход. Автор продукта тратит много времени, сил и средств па создание, отладку и продвижение новой версии. Довольно большой объем дорогого трафика, вызванный массовыми скачи-ваниями новой версии программы, также нужно компенсировать, а при бесплатных обновлениях добиться этого, конечно, нельзя.
Очевидно, не все новые версии должны быть платными. Общепринятая практика состоит в том, что так называемые "минорные" обновления — например, с версии 1.2 до 1.3 — распространять все-таки бесплатно. А вот версии 2.0, 3.0 и выше должны быть платными — при этом, естественно, эти версии должны включать действительно реальные серьезные изменения, а не мелкие улучшения да новый номер версии в окне О программе (About), иначе пользователь будет чувствовать себя обманутым. Также желательно следить, чтобы версии, за которые уже зарегистрированные пользователи должны снова заплатить, выходили не чаще одного раза в год. Интервал в один год для платных обновлений является привычным для пользователей, потому что многие коммерческие и даже shareware-продукты продаются по такой схеме: зарегистрировавшись, пользователь получает все новые версии, выходящие в течение одного года со дня его регистрации, а за версию, вышедшую по истечении этого года, он должен заплатить. Пример тому популярный текстовый редактор UltraEdit. В крайнем случае, можно выпускать платные обновления раз в полгода.
Некоторые авторы считают, что продавать новые версии зарегистрированным пользователям не эффективно по причине того, что новая версия в этом случае должна стоить небольшие деньги —3—5$, которые все равно "съест" комиссия регистратора. Однако стоимость обновленных версий можно устанавливать на довольно высоком уровне — 30—70% от цены регистрации для новых пользователей. Конечно, чем дороже программа, тем больше должна быть скидка для зарегистрированных пользователей, т. к. платить 150$ за покупку новой версии двухсотдолларового продукта раз в год или полгода довольно накладно. А вот 15$ за обновление программы стоимостью 25$ — вполне нормальная цена: раз в полгода или год заплатить 15$ не так уж сложно.

Теги <МЕТА>

Теги <МЕТА>

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

Техническая поддержка

Техническая поддержка

Уведомления по email

Уведомления по e-mail

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

Вход в базу данных online регистратора

Рисунок 10.4. Вход в базу данных online регистратора по безопасному протоколу HTTPS


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

Виды каталогов программ

Виды каталогов программ

Каталоги программ, существующие в Интернете, можно разделить, на несколько групп.
Крупные архивы
К этой группе относятся старейшие каталоги, в базах данных которых находятся десятки тысяч программ, имеющие посещаемость в сотни тысяч и даже миллионы человек в день. Еще совсем недавно таких было довольно много — Download.com (http://www.download.com), Tucows (http://www.tucows.com), WinFiles.com (http://www.winffles.com), ZDNet (http://ww.zdnet.com/downloads), SoftSeek (http://www.softseek.com), WinSite (http://www.winsite.com), Simtel.net (http://www.simtel.net)... К сожалению, WinFiles.com и SoftSeek были закрыты компанией С net (владелец Download.com), которая приобрела их в 1999— 2000 годах. ZDNet, также приобретенный diet, не закрылся, однако качество этого каталога сильно упало: исчезли знаменитые обзоры программ, база данных была объединена с базой Download.com, после чего процедуры регистрации новых программ и обновления информации об уже присутствующих в каталоге стали работать очень плохо. Фактически сейчас из всех крупных архивов остались только Download.com, Tucows и WinSite.
Колоссальные объемы баз данных и огромная посещаемость этих каталогов — одновременно и плюс, и минус. В такие архивы поступает несколько десятков продуктов в день, и ваша программа имеет шансы быть замеченной только первые два-три дня, когда она размещается на странице "Что нового?". Но, если программа действительно актуальна, то относительно большое число пользователей (ведь посещаемость таких архивов, как уже упоминалось, огромна) будет находить ее в тематических категориях каталога, что обеспечит стабильный приток новых пользователей вашей программы. А уж если программа настолько понравится обозревателям архива, что они напишут хвалебный обзор, дадут ей значок-награду или хороший рейтинг (например, "5 звезд") или даже поместят в почтовую рассылку с лучшими программами каталога, то это может предопределить дальнейший успех всего shareware-проекта в целом.
Основной минус крупных архивов, обусловленный их большой популярностью — нестабильная работа сотрудников архива по добавлению и обновлению информации в каталоге. Например, одни из самых часто обсуждаемых вопросов в конференциях shareware-разработчиков — почему заявка на публикацию программы остается без рассмотрения уже несколько месяцев, как "достучаться" до администратора shareware-архива, чтобы он исправил неверное описание программы, что делать и т. п. При этом писать на почтовые адреса, указанные непосредственно на сайте архива, практически бесполезно — письма чаще всего остаются без ответа.
С одной стороны, сотрудников крупных архивов можно понять: в каталогах присутствуют тысячи программ, ежедневно им приходится рассматривать десятки новых заявок, поэтому уследить за всеми программами и отвечать каждому автору по отдельности они не могут. Но для shareware-разработчика самая ничтожная неточность может обернуться большими убытками — например, неверное описание будет отпугивать пользователей. Поэтому не нужно смиряться с тем, что заявка на публикацию программы была проигнорирована или отклонена. Нужно повторять попытки еще и еще — например, еженедельно. Как показывает практика, рано или поздно архив сдастся и опубликует вашу программу. А некоторые авторы не без удовольствия рассказывают, что после такой "атаки" другие их программы добавляются в каталог мгновенно. Создается впечатление, что сотрудники архива уже боятся и, едва увидев в заявке знакомое имя, тут же публикуют программу.
Средние и мелкие архивы
Помимо крупных архивов, число которых относительно невелико, в Интернете существуют сотни средних и мелких архивов, число программ в которых составляет обычно несколько тысяч, а посещаемость — от тысячи до нескольких десятков тысяч человек в день. Появляются эти каталоги как грибы после дождя, и многие "умирают" буквально через несколько месяцев, т. к. их создатели, надеясь легко достичь уровня Download.com, быстро разочаровываются в этом деле и теряют к нему интерес.
Конечно, существует достаточно много и вполне качественных архивов, которые работают уже несколько лет. Все их перечислить невозможно, а в качестве примера стоит привести сайты Rocket Download (http://www.rocketdownload.com), SuperShareware.com (http://www.supershareware.com), Quality Shareware (http://www.quality-shareware.com), SoftPile.com (http://www.softpile.com). Хотя посещаемость их значительно ниже, чем тех же Download.com и Tucows, но за счет сравнительно небольшого количества программ, зарегистрированный в каталоге shareware-продукт имеет шансы быть замеченным тем же числом пользователей, что и на крупных архивах.
Да и вообще, по отзывам авторов программ, со средних и мелких архивов идет довольно качественный трафик, т. е. покупателей они приводят достаточно много. Например, один из зарубежных авторов, опубликовавших свою программу в каталоге Soft-List (http://www.softlist.ru), в личной переписке со мной как-то заметил: "Некоторые из наших лучших пользователей пришли с SoftList". Я подумал, что неправильно его понял и переспросил, действительно ли это так, на что получил подтверждение: "We really do have our best users from SoftList".
Правда, нужно оговориться, что большинство средних и мелких каталогов, судя по статистике посещений моего сайта http://www.actualsystem.com, подтвержденной свидетельствами других shareware-разработчиков, приводят большую часть посетителей только в первые несколько дней после того, как новая версия программы появилась в каталоге. Затем же с Web-сайтов этих архивов приходят всего по несколько человек в день. Но за счет того, что программа обычно регистрируется минимум в сотне средних и мелких архивов (см. разд. "Регистрация в каталогах" данной главы), суммарный трафик получается довольно ощутимый.
Кроме того, мелкие и средние архивы имеют еще одно преимущество перед крупными каталогами. Вследствие своей меньшей загруженности они гораздо более оперативны при добавлении и обновлении информации о программах. Механизмы обновления многих архивов поддерживают стандарт PAD (см. разд. "РАО-файлы" данной главы), имеют online-базы данных с возможностью для авторов самостоятельно обновлять информацию о своих программах.
Национальные архивы
Это — архивы, которые существуют не на английском языке. С их помощью можно увеличить число покупателей программы в тех странах, где английский язык не очень распространен. На первый взгляд, зарегистрировать программу в таких каталогах непросто — ведь страницы сайта архива обычно не имеют английской версии. С другой стороны, можно .воспользоваться программой-переводчиком или online-сервисом для перевода Web-страниц, или даже догадаться о назначении полей в Web-форме.
Конечно, очень желательно, чтобы интерфейс программы, заявка на публикацию которой отсылается на национальный архив, был переведен на язык той страны, которой принадлежит соответствующий архив (см. разд. "Локализация программы и Web-сайта"данной главы).

Виды технической поддержки

Виды технической поддержки

Основной вид технической поддержки, которым приходится заниматься авторам shareware-программ, — это ответы на вопросы, приходящие от пользователей по e-mail. Письма, присылаемые пользователями, чаще всего содержат всевозможные вопросы относительно работы с программой и ее приобретения, просьбы выслать потерянный регистрационный ключ (по словам shareware-авторов, такие письма их наиболее раздражают).
В зависимости от особенностей программы, которую распространяет автор, пользователи могут обращаться к нему и с другими вопросами. Например, если программа хранит пользовательскую информацию в файлах специфического формата, то разработчик может по заказам пользователей восстанавливать поврежденные файлы.
Те разработчики, которые получают высокие доходы от продажи своих программ, устанавливают в своих офисах так называемые "800-е" телефоны (их номера начинаются на "800"). Звонки по этому телефону для пользователей бесплатны, и такие "800-е" телефоны традиционно используются в службах технической поддержки серьезных компаний. Поэтому указанный на сайте и в документации программы, в разделе "Technical Support", номер телефона производит благоприятное впечатление на пользователей, убеждая их в том, что они имеют дело с солидной фирмой. Пользователи из зарубежных стран вообще очень любят использовать телефон для общения с компаниями, и если у них есть выбор между e-mail и телефоном, они выбирают последний.
Дополнительным видом технической поддержки являются форумы, в которых пользователи программы, обсуждают различные аспекты работы с ней, задают вопросы и т. п. (такие форумы так и называются — Support Forums, "форумы поддержки"). Автор, конечно же, должен участвовать в них, общаясь с пользователями и отвечая на их вопросы. Это позволит несколько разгрузить разработчика, т. к. некоторые пользователи (к сожалению, не все), прежде чем задать вопрос автору, будут предварительно просматривать форум и, возможно, находить нужную информацию. Кроме того, вокруг хорошо посещаемого и оживленного форума может сформироваться так называемое Community — сообщество активных пользователей, которые принимают деятельное участие в развитии shareware-программы: участвуют в бета-тестировании, помогают переводить интерфейс и документацию программы на другие языки, рисуют графику для оформления программы и Web-сайта. Вообще, Community — это главное, что может быть у проекта, и будет просто замечательно, если оно сложится вокруг ваших программ.

Возврат денег

Возврат денег

Да, при покупке пользователями shareware-программ деньги, к сожалению, не всегда движутся в одном направлении. Увы, иногда приходится возвращать пользователям деньги, которые уже были уплачены за программу.
Примечание
Примечание


Конечно, непосредственно переводом денег пользователю занимаются не авторы, а банк, который сотрудничает с компанией-регистратором. Сумма, которая подлежит возврату, снимается со счета автора у регистратора.
Говоря о возврате денег, обычно употребляют два термина — chargeback и refund, которые обозначают различные виды операций по возврату денег покупателем. Русских переводов этих терминов, столь же кратких и поэтому удобных для применения, не нашлось, и поэтому используются английские транскрипции: "чарджбэк" и "рефанд".
Чарджбэк — операция, которая инициируется покупателем, который либо разочаровался в покупке, либо номер кредитки был у него украден и покупка была сделана злоумышленниками без его ведома. В последнем случае действительный владелец карточки просмотрел выписку по операциям за месяц, заметил покупку, которую он не совершал, и обратился в свой банк с соответствующим заявлением вернуть деньги. Чарджбэк плох для всех:

для покупателя - потому что ему пришлось нервничать, идти в банк, писать заявление и т. д. Кроме того, этот инцидент может плохо сказаться на его кредитной истории;

для регистратора, который принимает платежи в online — потому что за чарджбэки его штрафуют, и за большое количество чарджбэков банк может разорвать с ним договор на обслуживание;

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

Рефанд — операция, которую осуществляет продавец (т. е. в данном случае — разработчик shareware-программы), если покупатель по каким-либо причинам хочет отказаться от покупки, и продавца эти причины устраивают. Например, соответствуют его политике возврата денег. Отдавать или не отдавать деньги — это личное дело каждого продавца. Рефанд по обоснованному желанию пользователя — абсолютно нормальная практика, которая вызывает большее доверие у потенциальных покупателей.
Большинство регистрации shareware-программ оплачиваются кредитной картой. В США существуют очень строгие законы, защищающие права покупателей, делающих платежи при помощи кредитных карт. Основной смысл этих законов состоит в том, что если покупатель не получил свои деньги обратно от продавца (т. е. продавец отказывается сделать рефанд), то он может обратиться в свой банк с требованием осуществить чарджбэк. Некоторые банки вообще заключают договоры на обслуживание компаний-регистраторов только при условии, что деньги будут возвращаться по первому требованию владельца карточки без каких-либо вопросов: клиент даже может просто написать: "Передумал".
Внимательные читатели, наверное, заметили, что участники рынка shareware попадают в двусмысленное положение. Получается, что покупатель всегда может получить свои деньги обратно, потребовав сделать чарджбэк, и, следовательно, просить продавца сделать рефанд, не приводя каких-либо обоснований своего желания. Однако пользователи все-таки предпочитают обращаться за возвратом денег именно к продавцам (т. е. авторам программ), т. к. в этом случае не нужно писать заявление в банк и подвергаться риску подпортить свою кредитную историю. А авторы, помня, что покупатель может сделать чарджбэк всегда, в любом случае (банк вернет деньги независимо от политики продавца), покорно возвращают деньги, не желая конфликтовать с кем-либо и не рисковать получить какую-нибудь антирекламу.
Такой прием наиболее "сообразительные" пользователи активно практикуют, желая получить регистрационный ключ бесплатно. Например, после оплаты регистрации и получения ключа начинают предъявлять претензии, что программа не работает или работает не правильно — что вряд ли возможно, учитывая то, что девиз shareware — "Попробуй, прежде чем купить", и у пользователя было 30 дней на тестирование программы. Кто-то, увидев в письме с регистрационным ключом русскую фамилию и определив, что сообщение пришло из России, требует вернуть деньги только потому, что ему не хочется заказывать что-то в России (попробуйте себе представить реакцию российского разработчика программ, который читает письмо о такой "уважительной" причине). А кто-то откровенно наглеет и заявляет, что он ничего не покупал — хотя сам по себе факт, что с требованием вернуть деньги по этому основанию пользователь обращается не в банк, как обычно, а к разработчику, указывает на то, что дело здесь не чисто и покупатель, скорее всего, пытается автора "надуть".
Такие нечестные пользователи могут стать серьезной проблемой для разработчиков shareware-программ, особенно тех, чьи продукты пользуются известностью. К счастью, не все авторы согласны мириться с тем, что пользователь может в этой ситуации сделать все, что ему захочется. Вот, например, какова политика компании ElcomSoft (http://www.elcomsoft.com) относительно возврата денег:
"Каждому, кто просит рефанда, мы отсылаем документ, который он должен заполнить, расписаться и выслать нам по факсу. Расписывается он также и в том, что эту программу обязуется стереть и больше не использовать, что он понимает, — в противном случае он подлежит уголовной ответственности и т. д. и т. п. Половина отпадает сразу, половина от оставшихся отпадает, попытавшись "покачать права" (в ответ на это мы посылаем их в банк), четверть доходит до конца, и мы им деньги возвращаем. Что любопытно -многие из тех, кто утверждает, что он ничего не покупал — тоже отпадают".

Выбираем регистратора

Выбираем регистратора

Как уже говорилось в предыдущем разделе, регистраторов на shareware-рынке присутствует очень много, и предоставляемый ими спектр услуг довольно обширен и, самое главное, различается при переходе от одного регистратора к другому.
Как же выбрать из всего многообразия компаний-регистраторов того, который обеспечит наиболее эффективное обслуживание платежей пользователей и, таким образом, поможет успеху shareware-проекта? Новички в первую очередь обращают на размер комиссии, взимаемой регистраторами с каждого платежа: конечно, чем он меньше, тем лучше. Здесь ситуация очень похожа на выбор хостинга (см. разд. "Где и как разместить сайт" гл. 9): начинающие владельцы сайтов выбирают в первую очередь те тарифы, которые предлагают наибольшее дисковое пространство, нисколько не обращая внимание на набор предоставляемых услуг. Да, при выборе регистратора, как и при выборе хостера, главное — пакет предоставляемых услуг. Если регистратор оказывает небольшой ассортимент услуг, то, скорее всего, вся экономия на проценте комиссионных может сойти на нет из-за, например, больших штрафов за возврат денег покупателям при отказе от покупки или плохой проверки заказов. Более того, вполне возможно, что с таким регистратором shareware-автор заработает гораздо меньше денег, чем с регистратором, берущим более высокую комиссию, но предоставляющим качественный сервис. Бесплатный сыр бывает только в мышеловке: снижение процента комиссии регистратора обычно достигается как раз за счет снижения количества и качества предоставляемых услуг. Итак, хороший регистратор, которому можно доверить обслуживание платежей по своим программам, должен оказывать большую часть из следующих услуг.

Заголовок и текст страницы

Заголовок и текст страницы

Игнорируя теги <МЕТА>, роботы поисковых систем обращают большое внимание на заголовок и текст страницы. Ведь именно эта информация обычно дает наиболее точное представление о содержании страницы. Учитывая это, следует подходить к написанию текста на Web-странице с особой тщательностью. Нужно составить текст таким образом, чтобы в нем встречались те ключевые слова, по которым пользователи будут искать информацию по теме, которой посвящен сайт, в поисковых системах. И, конечно, не нужно оставлять в заголовке страниц только название сайта — можно поместить там краткую аннотацию ресурса.
Очень удачный пример составления текста страниц, эффективно индексируемого поисковыми системами, я встретил на сайте http://www.submass.com, посвященном мощной программе для регистрации программных продуктов в online-каталогах программ. На первой странице сайта цитируются высказывания пользователей SubMass, которые сравнивают его с конкурентами -AddSoft, SiteTrack и SubmitWolf (Рисунок 10.6). В результате при индексации

Значение рекламы для shareware

Значение рекламы для shareware

Как известно, реклама — двигатель торговли. Это на сто процентов справедливо и по отношению к shareware. Главное в этом бизнесе — продать свою программу наибольшему числу пользователей, и самая совершенная по возможностям программа будет прозябать в безвестности, если ее не рекламировать.
Именно рекламе своего продукта нужно уделять особое внимание первые полгода после выпуска первой версии своей программы. Дальше программу будут рекламировать пользователи, рекомендуя ее друг другу в Web- и news-конференциях. И в уведомлениях о новой регистрации будут все чаще и чаще встречаться слова вроде таких: "A friend of mine gave me a copy for a try, just great..." ("Приятель дал мне копию на пробу..."). Автору программы останется только иногда делать целенаправленные рекламные акции, приуроченные к выходу новой версии или другим значительным событиям в истории развития своего продукта. Впрочем, никто не запрещает продолжать активно рекламировать свою программу и после того, как она станет достаточно популярной — это позволит добиться еще больших успехов на рынке shareware.
В отличие от рекламы развлекательных или новостных сайтов, реклама бизнес-сайтов, в том числе и сайтов shareware-программ, не ставит своей целью привлечение как можно большего числа посетителей. Важен качественный состав аудитории сайта: пользователи не только должны приходить на сайт, но и что-то на нем покупать. "Главное — не количество, а качество" - основной принцип продвижения shareware-программ.

Значение технической поддержки

Значение технической поддержки

Техническая поддержка — одна из важнейших (возможно, самая важная) частей любого shareware-проекта. Для многих пользователей основной фактор, влияющий на выбор той или иной программы и оплату ее регистрации — именно наличие службы поддержки, гарантия того, что на любой вопрос будет получен подробный, вежливый, и, главное, быстрый ответ. Известное правило shareware — вести свою деятельность не от своего имени, а от имени компании (пуская и придуманной), обусловлен как раз тем, что пользователи привыкли к тому, что у компании больше возможностей обеспечить качественную техническую поддержку, чем у частного лица.
Подробный, вежливый быстрый ответ стимулирует пользователей зарегистрироваться эффективнее, чем различные ограничения, встраиваемые в программу, т. к. пользователи очень ценят внимание к себе. Например, если ответить на вопрос пользователя в течение одного дня, то практически всегда в ответ приходит письмо с благодарностью за быстрый ответ.
Многие популярные shareware-продукты, например WinZip (http://www.winzip.com), взломаны уже очень давно и серийный код к ним можно за минуту найти в Интернете. Однако продаются они на сотни тысяч долларов в месяц. Почему? Именно из-за технической поддержки. Если программа является достаточно сложной по своим функциям, то пользователь все равно заплатит за нее, чтобы иметь право на техническую поддержку.
Кроме того, есть пользователи, которые, прежде чем купить, "прощупывают" разработчика - "А есть там кто живой?", т. е. прежде, чем приобрести программу, шлют письмо с каким-нибудь вопросом. Я же сам рекомендовал вам (см. разд. "Где и как разместить сайт" гл.9), при выборе хостинг-провайдера сначала написать письмо в службу поддержки с каким-нибудь вопросом поглупее, чтобы проверить оперативность, вежливость и учтивость ее специалистов.
Если же на вопросы никто не отвечает — пользователи не только не будут покупать программы этого автора, но и станут говорить об этом в конференциях - "Не имейте с ним дел". А если зарегистрированный пользователь не дождался ответа на свой вопрос, он вполне может потребовать вернуть деньги, т. к. техническая поддержка обычно указывается на видном месте Web-сайта и документации среди преимуществ регистрации программы. Непредоставление поддержки будет нарушением обязательств автора перед пользователем.



    Программирование: Языки - Технологии - Разработка

• Программирование
  
• Технологии программирования
  
• Разработка программ
  
• Работа с данными
  
• Методы программирования
  
  
• IDE интерфейс
  
• Графический интерфейс
  
• Программирование интерфейсов
  
• Отладка программ
  
• Тестирование программ
  
  
• Программирование на Delphi
  
• Программирование в ActionScript
  
• Assembler
  
• Basic
  
• Pascal
  
  
• Perl
  
• VBA
  
• VRML
  
• XML
  
• Ada
  
  
• Lisp
  
• Python
  
• UML
  
• Форт
  
• Языки программирования