Руководство (инструкция) по созданию Shareware-программ
Содержание
Введение
Глава 1. Что такое shareware?
Глава 2. С чего начинать
Глава 3. Немного об авторском нраве
Глава 4. Как работает правильная программа
Глава 5. Пользовательский интерфейс
Глава 6. Защита программ
Глава 7. Документация
Руководство (инструкция) по созданию Shareware-программ
Содержание
Введение
Глава 1. Что такое shareware?
Глава 2. С чего начинать
Глава 3. Немного об авторском нраве
Глава 4. Как работает правильная программа
Глава 5. Пользовательский интерфейс
Глава 6. Защита программ
Глава 7. Документация
Администратор
Сообщений: 484
Нет на сайте
Введение
О чем эта книга
Говорят, что в нашей стране — самые лучшие программисты в мире. С этим трудно не согласиться. Я, по крайней мере, вижу подтверждение этому каждый день.
Ежедневно, отбирая новые программы для интернет-каталога, я просматриваю десятки программных продуктов, созданных российскими программистами. Каких только программ среди них нет! Почтовые клиенты, графические редакторы, мультимедиа-декодеры, системные утилиты, бизнес-пакеты и многое, многое другое. Иногда, читая описание той или иной программы, даже начинаешь сомневаться: а правда ли все это? Неужели может один-единственный никому не известный человек написать программу, не уступающую по своим возможностям мировым лидерам?
Загружая эти программы и устанавливая их, я убеждаюсь: действительно, это возможно. Программы, как и заявляют их авторы, принимают почту, обрабатывают графические изображения, переводят дорожки звукового компакт-диска в МРЗ-файлы, помогают пользователю настраивать операционную систему, генерируют итоговые финансовые отчеты. В общем, работают просто замечательно. Но...
Но как все это реализовано! Совершенно нелогичный интерфейс, основанный на диких цветах, ужасных шрифтах, криво сделанных элементах управления, в котором без документации (которая впрочем, все равно отсутствует), не разберешься; грубые и неинформативные сообщения об ошибках; инсталлятор, искореживший операционную систему; а в довершение всего этого — название, которое уже давно используется другими разработчиками. Представление программы — тоже никуда не годится: размещается она на бесплатном сервере, один мегабайт с которого модем 56 К выкачивает чуть ли не полчаса; кошмарная домашняя страничка программы предоставляет очень мало информации, зато вызывает стойкое желание сбежать отсюда и больше никогда не возвращаться. А эти грубейшие орфографические и грамматические ошибки дают повод для серьезных сомнений доверить автору логин и пароль для самостоятельного обновления информации о его программе в каталоге.
Да, качественный программный продукт, которым легко и приятно пользоваться, — это не только эффективный код. Более того, код стоит на последнем месте. Те программы, которые сегодня являются признанными лидерами в своей области, никогда не стали бы такими, какие они есть, если бы их авторы не уделяли повышенное внимание проектированию пользовательского интерфейса, написанию документации, технической поддержке, маркетинговым исследованиям, продвижению продукта на рынке и т. д. А программный код... Открою вам страшную тайну: большинство гениальных программ написано вовсе не гениальными программистами.
Итак, вы держите в руках книгу "Shareware: профессиональная разработка и продвижение программ". Эта книга — не о программировании. В ней рассказывается обо всех аспектах создания и продвижения собственной программы: планировании продукта, авторских правах программистов, проектировании пользовательского интерфейса, защите программ, написании документации, подготовке дистрибутива, размещении программы в Интернете и т. д. — но только не об алгоритмах, операторах, процедурах и функциях. О них и так написано уже предостаточно.
Читатели, наверное, спросят меня о том, что же все-таки я понимаю под словом "профессиональный", когда я говорю о разработке и продвижении программ. Видите ли, пользователь при знакомстве с программой рано или поздно (зависит от его опыта и квалификации) может сделать вывод о том, на каком уровне находится автор этой программы по сравнению с лидерами в области разработки программного обеспечения. Лично мне для этого не нужно даже смотреть, устанавливать и запускать программу — достаточно взглянуть внутрь дистрибутива, чтобы определить, что программа написана и представлена- мастером своего дела, а не человеком, который на рынке программ пока еще новичок. В первом случае как раз и можно сказать, что программа выполнена профессионально.
Но качественная разработка серьезного программного продукта требует больших затрат времени и сил. Поэтому неплохо было бы эти затраты компенсировать. Как это сделать? Решение подсказывает первое слово в названии книги: "Shareware".
Shareware — это не просто способ распространения программ, при котором пользователь платит за нее не сразу, а по истечении некоторого срока, во время которого он имеет возможность тестировать продукт. Это еще и уникальная возможность для каждого программиста полностью изменить свою жизнь, сделать себе имя, начать работать на самого себя. И при этом -продолжать заниматься своим любимым делом, т. е. программированием.
Shareware — это не последний этап в развитии продукта, когда созданная программа начинает продаваться на мировом рынке программного обеспечения. На любой стадии работы над программой — проектирование, разработка пользовательского интерфейса, написание документации, размещение в Интернете — ориентация на рынок shareware оказывает очень большое влияние. При осуществлении проекта нельзя не учитывать законы и тенденции, наблюдающиеся в shareware-индустрии. И если при взгляде на оглавление книги можно сделать вывод о том, что shareware посвящена только последняя, десятая глава, то при чтении других глав вы заметите, что все вопросы в них рассматриваются именно с точки зрения применения на shareware-рынке.
Для кого предназначена эта книга? Каждый, кто считает себя имеющим отношение к разработке программ, найдет в ней что-то полезное для себя.' Начинающие программисты, желающие создавать качественные программные продукты, смогут получить ответы на многие вопросы, связанные с разработкой программ, которые лежат вне рамок традиционной литературы для программистов. Опытные разработчики смогут расширить аудиторию пользователей своих продуктов и не только компенсировать свои затраты, но и получить хороший доход. А те из читателей, кто непосредственно не занимается разработкой программ, но работают в области информационных технологий, смогут получить комплексное представление об одной из самых значимых и перспективных областей индустрии программного обеспечения.
Говорят, что в нашей стране — самые лучшие программисты в мире. С этим трудно не согласиться. Я, по крайней мере, вижу подтверждение этому каждый день.
Ежедневно, отбирая новые программы для интернет-каталога, я просматриваю десятки программных продуктов, созданных российскими программистами. Каких только программ среди них нет! Почтовые клиенты, графические редакторы, мультимедиа-декодеры, системные утилиты, бизнес-пакеты и многое, многое другое. Иногда, читая описание той или иной программы, даже начинаешь сомневаться: а правда ли все это? Неужели может один-единственный никому не известный человек написать программу, не уступающую по своим возможностям мировым лидерам?
Загружая эти программы и устанавливая их, я убеждаюсь: действительно, это возможно. Программы, как и заявляют их авторы, принимают почту, обрабатывают графические изображения, переводят дорожки звукового компакт-диска в МРЗ-файлы, помогают пользователю настраивать операционную систему, генерируют итоговые финансовые отчеты. В общем, работают просто замечательно. Но...
Но как все это реализовано! Совершенно нелогичный интерфейс, основанный на диких цветах, ужасных шрифтах, криво сделанных элементах управления, в котором без документации (которая впрочем, все равно отсутствует), не разберешься; грубые и неинформативные сообщения об ошибках; инсталлятор, искореживший операционную систему; а в довершение всего этого — название, которое уже давно используется другими разработчиками. Представление программы — тоже никуда не годится: размещается она на бесплатном сервере, один мегабайт с которого модем 56 К выкачивает чуть ли не полчаса; кошмарная домашняя страничка программы предоставляет очень мало информации, зато вызывает стойкое желание сбежать отсюда и больше никогда не возвращаться. А эти грубейшие орфографические и грамматические ошибки дают повод для серьезных сомнений доверить автору логин и пароль для самостоятельного обновления информации о его программе в каталоге.
Да, качественный программный продукт, которым легко и приятно пользоваться, — это не только эффективный код. Более того, код стоит на последнем месте. Те программы, которые сегодня являются признанными лидерами в своей области, никогда не стали бы такими, какие они есть, если бы их авторы не уделяли повышенное внимание проектированию пользовательского интерфейса, написанию документации, технической поддержке, маркетинговым исследованиям, продвижению продукта на рынке и т. д. А программный код... Открою вам страшную тайну: большинство гениальных программ написано вовсе не гениальными программистами.
Итак, вы держите в руках книгу "Shareware: профессиональная разработка и продвижение программ". Эта книга — не о программировании. В ней рассказывается обо всех аспектах создания и продвижения собственной программы: планировании продукта, авторских правах программистов, проектировании пользовательского интерфейса, защите программ, написании документации, подготовке дистрибутива, размещении программы в Интернете и т. д. — но только не об алгоритмах, операторах, процедурах и функциях. О них и так написано уже предостаточно.
Читатели, наверное, спросят меня о том, что же все-таки я понимаю под словом "профессиональный", когда я говорю о разработке и продвижении программ. Видите ли, пользователь при знакомстве с программой рано или поздно (зависит от его опыта и квалификации) может сделать вывод о том, на каком уровне находится автор этой программы по сравнению с лидерами в области разработки программного обеспечения. Лично мне для этого не нужно даже смотреть, устанавливать и запускать программу — достаточно взглянуть внутрь дистрибутива, чтобы определить, что программа написана и представлена- мастером своего дела, а не человеком, который на рынке программ пока еще новичок. В первом случае как раз и можно сказать, что программа выполнена профессионально.
Но качественная разработка серьезного программного продукта требует больших затрат времени и сил. Поэтому неплохо было бы эти затраты компенсировать. Как это сделать? Решение подсказывает первое слово в названии книги: "Shareware".
Shareware — это не просто способ распространения программ, при котором пользователь платит за нее не сразу, а по истечении некоторого срока, во время которого он имеет возможность тестировать продукт. Это еще и уникальная возможность для каждого программиста полностью изменить свою жизнь, сделать себе имя, начать работать на самого себя. И при этом -продолжать заниматься своим любимым делом, т. е. программированием.
Shareware — это не последний этап в развитии продукта, когда созданная программа начинает продаваться на мировом рынке программного обеспечения. На любой стадии работы над программой — проектирование, разработка пользовательского интерфейса, написание документации, размещение в Интернете — ориентация на рынок shareware оказывает очень большое влияние. При осуществлении проекта нельзя не учитывать законы и тенденции, наблюдающиеся в shareware-индустрии. И если при взгляде на оглавление книги можно сделать вывод о том, что shareware посвящена только последняя, десятая глава, то при чтении других глав вы заметите, что все вопросы в них рассматриваются именно с точки зрения применения на shareware-рынке.
Для кого предназначена эта книга? Каждый, кто считает себя имеющим отношение к разработке программ, найдет в ней что-то полезное для себя.' Начинающие программисты, желающие создавать качественные программные продукты, смогут получить ответы на многие вопросы, связанные с разработкой программ, которые лежат вне рамок традиционной литературы для программистов. Опытные разработчики смогут расширить аудиторию пользователей своих продуктов и не только компенсировать свои затраты, но и получить хороший доход. А те из читателей, кто непосредственно не занимается разработкой программ, но работают в области информационных технологий, смогут получить комплексное представление об одной из самых значимых и перспективных областей индустрии программного обеспечения.
Администратор
Сообщений: 484
Нет на сайте
Глава 1. Что такое shareware?
Что такое shareware?
Shareware — это тип программного обеспечения, обусловленный особенностями распространения таких программ. В русском языке этот термин интерпретируется как "условно-бесплатное программное обеспечение". Такая длинная формулировка, естественно, не совсем удобна для частого применения, поэтому термин "shareware" используется и в русскоязычной литературе. Употребляется еще одно наименование этого типа программного обеспечения -"пробное" (trial).
Основной принцип shareware — "попробуй, прежде чем купить" (try before you buy). Программа, распространяемая как shareware, предоставляется потребителям бесплатно — пользователь платит только за время загрузки файлов по Интернету или за носитель (дискету или CD-ROM). В течение определенного срока, составляющего обычно тридцать дней, он может пользоваться программой, тестировать ее, осваивать ее возможности. Если по истечении этого срока пользователь решит продолжить использование программы, он должен зарегистрироваться, заплатив автору определенную сумму. В противном же случае пользователь обязан прекратить использование программы и удалить ее со своего компьютера.
Такой способ распространения программ очень удобен для" пользователя, особенно в сравнении с остальными методами дистрибуции программного обеспечения. Ведь если вы приобретаете в компьютерном магазине коробку с нужной программой или заказываете ее у компании-дистрибьютора, у вас практически всегда нет возможности тщательно протестировать работу программы. Максимум, на что вы можете надеяться — на то, что продавец продемонстрирует вам программу, установленную на его собственном компьютере. Естественно, о том, чтобы в течение месяца пользоваться программой, убедиться в ее нормальной работе на имеющейся конфигурации оборудования или, например, на всех компьютерах в вашей организации, и лишь потом оплатить ее, не может быть и речи.
Для программ, распространяемых по принципу "попробуй, прежде чем купить", все совсем иначе. Убедившись в том, что программа надежно работает в установленной на компьютере пользователя версии операционной системы, не конфликтует с "железом", например, традиционно "капризными" драйверами видеокарты и звуковой платы, удостоверившись, что заявленные разработчиком функции действительно присутствуют и работают без ошибок, пользователь оплачивает программу.
Эта особенность распространения программ никак не сказывается на уровне предоставляемого сервиса и технической поддержки. Пользователь по своему желанию может заказать экземпляр программы на нужном носителе (дискете или компакт-диске), получить консультацию относительно работы с программой по телефону или электронной почте. Регистрация программы может быть сделана по телефону, факсу, обычной почте, e-mail, со страниц Web-сайта. Оплата производится любым известным способом — банковским или почтовым переводом, кредитной картой, чеком и т. п. При наличии уважительной причины оплативший программу пользователь может без проблем получить свои деньги обратно.
Для разработчиков программного обеспечения индустрия shareware также очень привлекательна. В результате стремительного развития сети Интернет программы, предлагаемые их авторами для распространения, почти мгновенно становятся доступны миллионам пользователей по всему миру. Для того чтобы начать реализацию своих программ по принципу shareware, требуются минимальные затраты, не сравнимые с начальными вложениями ни в один бизнес. Всю сложную работу, требующую больших технических мощностей и специальных лицензий, например прием заказов и платежей, создание и отправка копий программы на дискетах и компакт-дисках, возьмут на себя сторонние компании — всего лишь за относительно небольшие комиссионные. Также для shareware не имеет значение место проживания или социальное положение человека. Житель европейской столицы и провинциального российского городка, студент и уже сформировавшийся профессионал — все они имеют примерно одинаковые шансы добиться успеха. Собственно, программа, которая будет продаваться, и доступ в Интернет -вот две главные составляющие, требующиеся для shareware.
Помимо принципа "попробуй, прежде чем купить", shareware включает в себя принцип свободного, т. е. бесплатного, распространения незарегистрированной версии программы — например, через Web-сайты, РТР-архивы, BBS и т. п. Однако авторы shareware-программ обычно разрешают включать свои продукты в сборники программного обеспечения на CD-ROM, распространяемые за плату, т. к. выпуск программы на CD-ROM увеличивает аудиторию пользователей программы.
Конечно, многие пользователи, заполучив экземпляр работающей программы, не спешат оплачивать регистрацию. Чтобы стимулировать пользователя зарегистрировать программу, разработчики встраивают в свои программы сообщения с напоминанием о необходимости регистрации или, например, включают счетчик времени использования программы. По истечении срока, отпущенного на тестирование, некоторые функции программы отключаются, а иногда программа перестает работать вообще. Эти меры позволяют значительно увеличить количество регистрации и повысить отдачу от разработки программы.
Высокую эффективность shareware подтверждает факт безбедного существования множества компаний и индивидуальных программистов, занимающихся исключительно созданием и поддержкой shareware-программ. Некоторые из них имеют годовые обороты в сотни тысяч и даже миллионы долларов -например, ACD Systems, производитель известной программы просмотра изображений ACDSee, или WinZip Inc., продающая одноименный и очень популярный, особенно в нашей стране, архиватор.
Не случайно в последнее время все больше крупных компаний (среди них -корпорации Microsoft, Symantec, Adobe), ранее распространявших свои программные продукты только в "коробочных" вариантах, которые можно было приобрести в компьютерных магазинах, выпускают shareware-версии с ограничением по времени работы. Например, Microsoft бесплатно распространяет 120-дневные версии операционной системы Windows 2000 и пакета Microsoft SQL Server 2000.
Несмотря на большую популярность shareware-программ и огромное количество участников shareware-индустрии, объем рынка shareware составляет не самую значительную часть общемирового рынка программного обеспечения. Объясняется это в основном тем, что shareware-программы в большинстве своем имеют относительно невысокую цену — в десятки, а иногда и сотни раз меньше цены многих необходимых пользователям программ, таких как операционные системы, офисные пакеты, базы данных, системы для профессиональной графики или издательского дела. Есть, конечно, shareware-программы ценой пятьсот, восемьсот, тысячу долларов, но подавляющее большинство продается по цене от пятнадцати до пятидесяти долларов.
Кроме того, многие пользователи (особенно представляющие интересы крупных компаний) больше доверяют программам, продающимся в "коробочных вариантах". Они привыкли, что за такими программами стоит крупный и надежный поставщик и квалифицированная служба технической поддержки. Невысокая цена shareware-программы в данном случае является скорее отрицательным фактором: по мнению такого пользователя, качественный продукт не может стоить дешево.
Тем не менее, блестящие перспективы shareware мало у кого вызывают сомнение: загрузка программ из Интернета и последующая их оплата в режиме online идеально вписываются в системы электронной коммерции, за которыми, как известно, будущее мировой торговли. Механизмы shareware
обладают поразительной гибкостью, позволяющей участникам быстро подстраиваться под частые изменения в такой динамично развивающейся отрасли, как индустрия программного обеспечения.
Итак, отличительные признаки shareware-программы состоят в следующем:
оплата только после определенного периода ее бесплатного использования в ознакомительных целях;
распространение незарегистрированной версии программного продукта без каких-либо ограничений;
относительно невысокая цена.
Freeware и другие
Говоря об индустрии программного обеспечения, помимо shareware, упоминают и другие типы программ. Вкратце расскажу о них.
Freeware
Это свободно распространяемые программы, за использование которых не нужно платить, благодаря чему "freeware" стало синонимом слова "бесплатно". Как это ни странно, сегодня, когда продажа программ является прибыльным бизнесом, число сторонников freeware даже среди серьезных компаний не уменьшается: бесплатная программа — прекрасный инструмент для продвижения новых технологий и продуктов. Например, успех формата документов PDF фирмы Adobe во многом обусловлен бесплатным распространением программы просмотра Acrobat Reader. Браузер Microsoft Internet Explorer, программа общения ICQ — все это примеры популярных бесплатных продуктов, имеющих очень сильные позиции по отношению к своим конкурентам.
Более того, некоторые shareware-продукты становятся бесплатными. Яркий пример -- знаменитый мультимедиа-проигрыватель WinAmp (http:// www.winamp.com). Первоначально он был shareware-программой стоимостью в десять долларов, а после того, как сайт winamp.com стал привлекать миллионы посетителей, разработчики, получая солидные доходы от рекламы, решили сделать свой продукт бесплатным, еще больше увеличив его популярность.
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.
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.
Commercialcc
Это коммерческое программное обеспечение, т. е. распространяемое за плату. При этом оплата программы должна быть сделана в момент заказа или получения копии ПО: использование такой программы до оплаты не допускается. Это, конечно же, отталкивает потребителей, не желающих покупать "кота в мешке", поэтому многие компании-разработчики коммерческого ПО распространяют демонстрационные версии своих программ, имеющие ограниченный набор функций и предназначенные для ознакомления потенциальных покупателей с продуктом.
Коммерческие программы в основном распространяются на физических носителях — дисках CD-ROM или дискетах, в "фирменной" упаковке (поэтому такие программы часто называют "коробочными"), снабжаются печатным руководством пользователя и гарантированной технической поддержкой. Коммерческие программы — наиболее массовый тип программного обеспечения, к которому принадлежат такие "монстры", как Microsoft Windows, Microsoft Office, Microsoft Visual Studio, Adobe Photoshop, CorelDRAW, Borland Delphi и многие другие. Именно коммерческим программам пока принадлежит наибольшая часть рынка программного обеспечения.
Как уже упоминалось, многие коммерческие программы распространяются и как shareware. В этом случае программа может стоить несколько дешевле, ведь производитель избавлен от расходов на упаковку, печать руководства пользователя, складских расходов, комиссионных отчислений дистрибьюторам и т. п.
Demo
Демонстрационные программы представляют собой ограниченные по функциональным возможностям версии коммерческих и shareware-программ, а иногда — просто видеоролики, своеобразные презентации программ. Предназначены они для ознакомительных целей: если пользователю программа понравилась, он может произвести оплату и получить полную версию продукта. Наиболее широко распространена практика применения demo-версий в игровой индустрии: почти каждая новая игра выходит одновременно в виде полной "коробочной" версии и в виде варианта, включающего несколько начальных уровней, который можно бесплатно скачать через Интернет.
[b]Adware[/b]
К этой категории относятся программы, которые во время своей работы демонстрируют пользователю рекламу -- чаще всего графические баннеры размером 468x60 точек (рис. 1.1). Adware сочетает в себе черты freeware и shareware: с одной стороны, пользователь может использовать программу бесплатно и не обязан регистрировать ее, платя деньги разработчику (последний получает денежные отчисления от рекламодателей); с другой стороны, у пользователя имеется стимул зарегистрировать программу, т. к. после регистрации показ рекламы отключается.
Так как загрузка новых рекламных баннеров осуществляется по Интернету с серверов соответствующих рекламных служб, то adware — это в основном такие программы, для работы которых требуется соединение с Интернетом — например, браузеры (Opera), download-менеджеры (ReGet, FlashGet), программы дозвона или ускорители соединения с Интернетом.
Перечисленные выше типы программ сегодня являются наиболее популярными среди разработчиков программного обеспечения. Однако существуют и другие, менее популярные категории программ, о которых, тем не менее, нельзя не упомянуть.
Shareware — это тип программного обеспечения, обусловленный особенностями распространения таких программ. В русском языке этот термин интерпретируется как "условно-бесплатное программное обеспечение". Такая длинная формулировка, естественно, не совсем удобна для частого применения, поэтому термин "shareware" используется и в русскоязычной литературе. Употребляется еще одно наименование этого типа программного обеспечения -"пробное" (trial).
Основной принцип shareware — "попробуй, прежде чем купить" (try before you buy). Программа, распространяемая как shareware, предоставляется потребителям бесплатно — пользователь платит только за время загрузки файлов по Интернету или за носитель (дискету или CD-ROM). В течение определенного срока, составляющего обычно тридцать дней, он может пользоваться программой, тестировать ее, осваивать ее возможности. Если по истечении этого срока пользователь решит продолжить использование программы, он должен зарегистрироваться, заплатив автору определенную сумму. В противном же случае пользователь обязан прекратить использование программы и удалить ее со своего компьютера.
Такой способ распространения программ очень удобен для" пользователя, особенно в сравнении с остальными методами дистрибуции программного обеспечения. Ведь если вы приобретаете в компьютерном магазине коробку с нужной программой или заказываете ее у компании-дистрибьютора, у вас практически всегда нет возможности тщательно протестировать работу программы. Максимум, на что вы можете надеяться — на то, что продавец продемонстрирует вам программу, установленную на его собственном компьютере. Естественно, о том, чтобы в течение месяца пользоваться программой, убедиться в ее нормальной работе на имеющейся конфигурации оборудования или, например, на всех компьютерах в вашей организации, и лишь потом оплатить ее, не может быть и речи.
Для программ, распространяемых по принципу "попробуй, прежде чем купить", все совсем иначе. Убедившись в том, что программа надежно работает в установленной на компьютере пользователя версии операционной системы, не конфликтует с "железом", например, традиционно "капризными" драйверами видеокарты и звуковой платы, удостоверившись, что заявленные разработчиком функции действительно присутствуют и работают без ошибок, пользователь оплачивает программу.
Эта особенность распространения программ никак не сказывается на уровне предоставляемого сервиса и технической поддержки. Пользователь по своему желанию может заказать экземпляр программы на нужном носителе (дискете или компакт-диске), получить консультацию относительно работы с программой по телефону или электронной почте. Регистрация программы может быть сделана по телефону, факсу, обычной почте, e-mail, со страниц Web-сайта. Оплата производится любым известным способом — банковским или почтовым переводом, кредитной картой, чеком и т. п. При наличии уважительной причины оплативший программу пользователь может без проблем получить свои деньги обратно.
Для разработчиков программного обеспечения индустрия shareware также очень привлекательна. В результате стремительного развития сети Интернет программы, предлагаемые их авторами для распространения, почти мгновенно становятся доступны миллионам пользователей по всему миру. Для того чтобы начать реализацию своих программ по принципу shareware, требуются минимальные затраты, не сравнимые с начальными вложениями ни в один бизнес. Всю сложную работу, требующую больших технических мощностей и специальных лицензий, например прием заказов и платежей, создание и отправка копий программы на дискетах и компакт-дисках, возьмут на себя сторонние компании — всего лишь за относительно небольшие комиссионные. Также для shareware не имеет значение место проживания или социальное положение человека. Житель европейской столицы и провинциального российского городка, студент и уже сформировавшийся профессионал — все они имеют примерно одинаковые шансы добиться успеха. Собственно, программа, которая будет продаваться, и доступ в Интернет -вот две главные составляющие, требующиеся для shareware.
Помимо принципа "попробуй, прежде чем купить", shareware включает в себя принцип свободного, т. е. бесплатного, распространения незарегистрированной версии программы — например, через Web-сайты, РТР-архивы, BBS и т. п. Однако авторы shareware-программ обычно разрешают включать свои продукты в сборники программного обеспечения на CD-ROM, распространяемые за плату, т. к. выпуск программы на CD-ROM увеличивает аудиторию пользователей программы.
Конечно, многие пользователи, заполучив экземпляр работающей программы, не спешат оплачивать регистрацию. Чтобы стимулировать пользователя зарегистрировать программу, разработчики встраивают в свои программы сообщения с напоминанием о необходимости регистрации или, например, включают счетчик времени использования программы. По истечении срока, отпущенного на тестирование, некоторые функции программы отключаются, а иногда программа перестает работать вообще. Эти меры позволяют значительно увеличить количество регистрации и повысить отдачу от разработки программы.
Высокую эффективность shareware подтверждает факт безбедного существования множества компаний и индивидуальных программистов, занимающихся исключительно созданием и поддержкой shareware-программ. Некоторые из них имеют годовые обороты в сотни тысяч и даже миллионы долларов -например, ACD Systems, производитель известной программы просмотра изображений ACDSee, или WinZip Inc., продающая одноименный и очень популярный, особенно в нашей стране, архиватор.
Не случайно в последнее время все больше крупных компаний (среди них -корпорации Microsoft, Symantec, Adobe), ранее распространявших свои программные продукты только в "коробочных" вариантах, которые можно было приобрести в компьютерных магазинах, выпускают shareware-версии с ограничением по времени работы. Например, Microsoft бесплатно распространяет 120-дневные версии операционной системы Windows 2000 и пакета Microsoft SQL Server 2000.
Несмотря на большую популярность shareware-программ и огромное количество участников shareware-индустрии, объем рынка shareware составляет не самую значительную часть общемирового рынка программного обеспечения. Объясняется это в основном тем, что shareware-программы в большинстве своем имеют относительно невысокую цену — в десятки, а иногда и сотни раз меньше цены многих необходимых пользователям программ, таких как операционные системы, офисные пакеты, базы данных, системы для профессиональной графики или издательского дела. Есть, конечно, shareware-программы ценой пятьсот, восемьсот, тысячу долларов, но подавляющее большинство продается по цене от пятнадцати до пятидесяти долларов.
Кроме того, многие пользователи (особенно представляющие интересы крупных компаний) больше доверяют программам, продающимся в "коробочных вариантах". Они привыкли, что за такими программами стоит крупный и надежный поставщик и квалифицированная служба технической поддержки. Невысокая цена shareware-программы в данном случае является скорее отрицательным фактором: по мнению такого пользователя, качественный продукт не может стоить дешево.
Тем не менее, блестящие перспективы shareware мало у кого вызывают сомнение: загрузка программ из Интернета и последующая их оплата в режиме online идеально вписываются в системы электронной коммерции, за которыми, как известно, будущее мировой торговли. Механизмы shareware
обладают поразительной гибкостью, позволяющей участникам быстро подстраиваться под частые изменения в такой динамично развивающейся отрасли, как индустрия программного обеспечения.
Итак, отличительные признаки shareware-программы состоят в следующем:
оплата только после определенного периода ее бесплатного использования в ознакомительных целях;
распространение незарегистрированной версии программного продукта без каких-либо ограничений;
относительно невысокая цена.
Freeware и другие
Говоря об индустрии программного обеспечения, помимо shareware, упоминают и другие типы программ. Вкратце расскажу о них.
Freeware
Это свободно распространяемые программы, за использование которых не нужно платить, благодаря чему "freeware" стало синонимом слова "бесплатно". Как это ни странно, сегодня, когда продажа программ является прибыльным бизнесом, число сторонников freeware даже среди серьезных компаний не уменьшается: бесплатная программа — прекрасный инструмент для продвижения новых технологий и продуктов. Например, успех формата документов PDF фирмы Adobe во многом обусловлен бесплатным распространением программы просмотра Acrobat Reader. Браузер Microsoft Internet Explorer, программа общения ICQ — все это примеры популярных бесплатных продуктов, имеющих очень сильные позиции по отношению к своим конкурентам.
Более того, некоторые shareware-продукты становятся бесплатными. Яркий пример -- знаменитый мультимедиа-проигрыватель WinAmp (http:// www.winamp.com). Первоначально он был shareware-программой стоимостью в десять долларов, а после того, как сайт winamp.com стал привлекать миллионы посетителей, разработчики, получая солидные доходы от рекламы, решили сделать свой продукт бесплатным, еще больше увеличив его популярность.
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.
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.
Commercialcc
Это коммерческое программное обеспечение, т. е. распространяемое за плату. При этом оплата программы должна быть сделана в момент заказа или получения копии ПО: использование такой программы до оплаты не допускается. Это, конечно же, отталкивает потребителей, не желающих покупать "кота в мешке", поэтому многие компании-разработчики коммерческого ПО распространяют демонстрационные версии своих программ, имеющие ограниченный набор функций и предназначенные для ознакомления потенциальных покупателей с продуктом.
Коммерческие программы в основном распространяются на физических носителях — дисках CD-ROM или дискетах, в "фирменной" упаковке (поэтому такие программы часто называют "коробочными"), снабжаются печатным руководством пользователя и гарантированной технической поддержкой. Коммерческие программы — наиболее массовый тип программного обеспечения, к которому принадлежат такие "монстры", как Microsoft Windows, Microsoft Office, Microsoft Visual Studio, Adobe Photoshop, CorelDRAW, Borland Delphi и многие другие. Именно коммерческим программам пока принадлежит наибольшая часть рынка программного обеспечения.
Как уже упоминалось, многие коммерческие программы распространяются и как shareware. В этом случае программа может стоить несколько дешевле, ведь производитель избавлен от расходов на упаковку, печать руководства пользователя, складских расходов, комиссионных отчислений дистрибьюторам и т. п.
Demo
Демонстрационные программы представляют собой ограниченные по функциональным возможностям версии коммерческих и shareware-программ, а иногда — просто видеоролики, своеобразные презентации программ. Предназначены они для ознакомительных целей: если пользователю программа понравилась, он может произвести оплату и получить полную версию продукта. Наиболее широко распространена практика применения demo-версий в игровой индустрии: почти каждая новая игра выходит одновременно в виде полной "коробочной" версии и в виде варианта, включающего несколько начальных уровней, который можно бесплатно скачать через Интернет.
[b]Adware[/b]
К этой категории относятся программы, которые во время своей работы демонстрируют пользователю рекламу -- чаще всего графические баннеры размером 468x60 точек (рис. 1.1). Adware сочетает в себе черты freeware и shareware: с одной стороны, пользователь может использовать программу бесплатно и не обязан регистрировать ее, платя деньги разработчику (последний получает денежные отчисления от рекламодателей); с другой стороны, у пользователя имеется стимул зарегистрировать программу, т. к. после регистрации показ рекламы отключается.
Так как загрузка новых рекламных баннеров осуществляется по Интернету с серверов соответствующих рекламных служб, то adware — это в основном такие программы, для работы которых требуется соединение с Интернетом — например, браузеры (Opera), download-менеджеры (ReGet, FlashGet), программы дозвона или ускорители соединения с Интернетом.
Перечисленные выше типы программ сегодня являются наиболее популярными среди разработчиков программного обеспечения. Однако существуют и другие, менее популярные категории программ, о которых, тем не менее, нельзя не упомянуть.
Администратор
Сообщений: 484
Нет на сайте
Donationware
Такие программы распространяются бесплатно и их регистрация не требуется, однако разработчик программы в лицензионном соглашении или документации указывает, что если пользователю программа нравится, то он может (именно может, а не обязан) выслать автору небольшое вознаграждение. Размер вознаграждения либо определен четко, либо оставлен на усмотрение пользователя - "кто сколько может". Иногда размер вознаграждения указывается даже так: "Пришлите мне столько денег, чтобы их хватило на ящик пива!". Для таких случаев придумали даже отдельный термин: "beerware" (от англ, beer - "пиво").
К сожалению, как показывает практика, пользователи очень вяло реагируют на такие просьбы и очень редко высылают деньги разработчикам программ. Некоторые авторы, чтобы хоть как-то стимулировать пользователей зарегистрировать программу, пытаются разжалобить их, указывая такие, например, подробности: "Мне нужно кормить шестерых детей, пожалуйста, не дайте им умереть от голода!"
Donationware привлекало авторов программ в то время, когда программистам-одиночкам было крайне затруднительно самостоятельно принимать платежи от пользователей. Сегодня, с распространением Интернета и появлением десятков компаний-регистраторов, берущих на себя все хлопоты по обслуживанию платежей любых видов, способом donationware свои программы распространяют в основном те авторы, для которых разработка программ — это хобби или развлечение.
Из наиболее известных donationware-программ можно назвать замечательный просмотрщик и редактор графических файлов Irfan View (http:// www.irfanview.com) Ирфана Скилжана (Irfan Skiljan) из Австрии. В лицензионном соглашении Ирфан пишет: "Irfan View распространяется как freeware, но только для частного, некоммерческого использования (это означает -для использования дома). [...] Если вам нравится эта программа, пожалуйста, зарегистрируйтесь, послав 10$ или 15DM (пожалуйста, только наличными) по адресу [...]". Как видите, регистрация программы на таких условиях маловероятна, т. к. почтовые службы многих стран, в том числе и России, запрещают пересылку наличной валюты в почтовых отправлениях. Кроме того, для юридических лиц существуют дополнительные трудности, связанные с ограничениями на операции с наличной валютой.
Postcardware, или Cardware
Экзотический способ распространения программ, при котором автор просит пользователей зарегистрироваться, прислав ему почтовую открытку. Этот способ вообще не может принести какие-либо деньги — только коллекцию открыток с видами различных уголков земного шара.
Homepageware
Эти программы напоминают adware. Пользователь не обязан оплачивать регистрацию, но незарегистрированная копия программы при каждом своем запуске автоматически; меняет начальную страницу установленного в системе браузера на домашнюю страницу программы. Homepageware не очень распространено, видимо, потому, что такое варварское обращение с пользовательскими настройками очень раздражает. Кроме того, такая программа сегодня, во времена скандалов, связанных с нарушением приватности и распространением "троянских коней", вызывает подозрения — не производит ли она какие-либо еще более вредоносные действия?
Careware
Совсем уж экзотический способ, которым распространяется, например, широко известный HTML-редактор Arachnophilia (http://www.arachnoid.com /arachnophilia). В лицензионном соглашении к программе сказано, что пользователь должен на час, день или неделю перестать жаловаться на жизнь и сказать кому-нибудь слова ободрения.
Отцы-основатели
Более двадцати лет назад, еще до появления первого 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 около пятисот долларов.
Замечание
Сегодня такие "партнерские программы" (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" данной главы).
Распространение 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.
Такие программы распространяются бесплатно и их регистрация не требуется, однако разработчик программы в лицензионном соглашении или документации указывает, что если пользователю программа нравится, то он может (именно может, а не обязан) выслать автору небольшое вознаграждение. Размер вознаграждения либо определен четко, либо оставлен на усмотрение пользователя - "кто сколько может". Иногда размер вознаграждения указывается даже так: "Пришлите мне столько денег, чтобы их хватило на ящик пива!". Для таких случаев придумали даже отдельный термин: "beerware" (от англ, beer - "пиво").
К сожалению, как показывает практика, пользователи очень вяло реагируют на такие просьбы и очень редко высылают деньги разработчикам программ. Некоторые авторы, чтобы хоть как-то стимулировать пользователей зарегистрировать программу, пытаются разжалобить их, указывая такие, например, подробности: "Мне нужно кормить шестерых детей, пожалуйста, не дайте им умереть от голода!"
Donationware привлекало авторов программ в то время, когда программистам-одиночкам было крайне затруднительно самостоятельно принимать платежи от пользователей. Сегодня, с распространением Интернета и появлением десятков компаний-регистраторов, берущих на себя все хлопоты по обслуживанию платежей любых видов, способом donationware свои программы распространяют в основном те авторы, для которых разработка программ — это хобби или развлечение.
Из наиболее известных donationware-программ можно назвать замечательный просмотрщик и редактор графических файлов Irfan View (http:// www.irfanview.com) Ирфана Скилжана (Irfan Skiljan) из Австрии. В лицензионном соглашении Ирфан пишет: "Irfan View распространяется как freeware, но только для частного, некоммерческого использования (это означает -для использования дома). [...] Если вам нравится эта программа, пожалуйста, зарегистрируйтесь, послав 10$ или 15DM (пожалуйста, только наличными) по адресу [...]". Как видите, регистрация программы на таких условиях маловероятна, т. к. почтовые службы многих стран, в том числе и России, запрещают пересылку наличной валюты в почтовых отправлениях. Кроме того, для юридических лиц существуют дополнительные трудности, связанные с ограничениями на операции с наличной валютой.
Postcardware, или Cardware
Экзотический способ распространения программ, при котором автор просит пользователей зарегистрироваться, прислав ему почтовую открытку. Этот способ вообще не может принести какие-либо деньги — только коллекцию открыток с видами различных уголков земного шара.
Homepageware
Эти программы напоминают adware. Пользователь не обязан оплачивать регистрацию, но незарегистрированная копия программы при каждом своем запуске автоматически; меняет начальную страницу установленного в системе браузера на домашнюю страницу программы. Homepageware не очень распространено, видимо, потому, что такое варварское обращение с пользовательскими настройками очень раздражает. Кроме того, такая программа сегодня, во времена скандалов, связанных с нарушением приватности и распространением "троянских коней", вызывает подозрения — не производит ли она какие-либо еще более вредоносные действия?
Careware
Совсем уж экзотический способ, которым распространяется, например, широко известный HTML-редактор Arachnophilia (http://www.arachnoid.com /arachnophilia). В лицензионном соглашении к программе сказано, что пользователь должен на час, день или неделю перестать жаловаться на жизнь и сказать кому-нибудь слова ободрения.
Отцы-основатели
Более двадцати лет назад, еще до появления первого 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 около пятисот долларов.
Замечание
Сегодня такие "партнерские программы" (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" данной главы).
Распространение 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.
Администратор
Сообщений: 484
Нет на сайте
Профессионалы 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.
Развитие индустрии 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-программ.
Shareware в России
По сравнению с мировой индустрией shareware, история которой насчитывает уже около двадцати лет, в России shareware еще очень молодо. Иначе, пожалуй, и быть не могло. В восьмидесятые годы прошлого века, во время зарождения и расцвета shareware, на пространствах существовавшего тогда СССР об этом мало кто слышал. Изоляция от остального мира, относительно небольшой парк персональных компьютеров, отсутствие системы кредитных карт, слабое развитие телекоммуникаций, высокий уровень компьютерного пиратства — в таких условиях, конечно же, ни о каком shareware не могло быть и речи. В начале девяностых, со всеми политическими и экономическими потрясениями, постигшими население России, тоже было как-то не до shareware.
Свою историю shareware в нашей стране ведет только с начала 1998 года. К этому времени в стране установилось относительное экономическое и политическое спокойствие (кризис 17 августа 1998 года был еще далеко) и, самое главное, Интернет — главная движущая сила shareware — для россиян уже перестал быть диковинкой.
Замечание
Конечно, в нашей стране 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-программ и наличие множества коммерческих дистрибьюторов), авторы стремились стимулировать пользователей оплачивать регистрации программ. Но сложными схемами, наподобие той, которую применял Боб Уоллес при распространении 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.
Развитие индустрии 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-программ.
Shareware в России
По сравнению с мировой индустрией shareware, история которой насчитывает уже около двадцати лет, в России shareware еще очень молодо. Иначе, пожалуй, и быть не могло. В восьмидесятые годы прошлого века, во время зарождения и расцвета shareware, на пространствах существовавшего тогда СССР об этом мало кто слышал. Изоляция от остального мира, относительно небольшой парк персональных компьютеров, отсутствие системы кредитных карт, слабое развитие телекоммуникаций, высокий уровень компьютерного пиратства — в таких условиях, конечно же, ни о каком shareware не могло быть и речи. В начале девяностых, со всеми политическими и экономическими потрясениями, постигшими население России, тоже было как-то не до shareware.
Свою историю shareware в нашей стране ведет только с начала 1998 года. К этому времени в стране установилось относительное экономическое и политическое спокойствие (кризис 17 августа 1998 года был еще далеко) и, самое главное, Интернет — главная движущая сила shareware — для россиян уже перестал быть диковинкой.
Замечание
Конечно, в нашей стране 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, общаются между собой, обмениваются опытом, знакомятся с теми, кого они до сих пор знали только по электронным сообщениям.
Администратор
Сообщений: 484
Нет на сайте
Зачем вам нужно 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-проекты
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 Александр Каталов рассказывает об опыте работы его компании 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-проекты
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, поэтому в ближайшем будущем я намерен значительно больше времени и средств уделять маркетинговым усилиям".
Администратор
Сообщений: 484
Нет на сайте
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 к моменту выхода этой книги, скорее всего, уже появится.
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 на западном рынке.
В марте 1999 года было принято решение расширить штат компании. На работу приняли еще одного программиста, затем появился человек, ответственный за поддержку пользователей, потом новые программисты.
В том же году принято еще одно очень важное решение: выпустить ReGet со встроенным рекламным модулем. Начиная с версии 1.5, ReGet распространяется в двух вариантах: ReGet Pro, который требует регистрации с первого запуска, и ReGet Free, который не требовал регистрации, но показывал рекламные баннеры, т. е. эта версия была adware (см. разд. "Freeware и другие" данной главы). После этого продажи, как и ожидалось, резко упали, но за счет обширной пользовательской аудитории это с лихвой компенсировалось выручкой от показов рекламы.
В январе 2000 года ReGet стал продаваться и на российском рынке. Цена для российских пользователей была установлена в 210 рублей, что является относительно небольшой суммой для такой сложной программы.
В настоящее время, по оценкам компании ReGet Software, аудитория ReGet исчисляется сотнями тысяч человек.
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 более десяти тысяч пользователей, не считая нескольких корпоративных клиентов, купивших сразу десятки и даже сотни лицензий.
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 рублей.
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 к моменту выхода этой книги, скорее всего, уже появится.
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 на западном рынке.
В марте 1999 года было принято решение расширить штат компании. На работу приняли еще одного программиста, затем появился человек, ответственный за поддержку пользователей, потом новые программисты.
В том же году принято еще одно очень важное решение: выпустить ReGet со встроенным рекламным модулем. Начиная с версии 1.5, ReGet распространяется в двух вариантах: ReGet Pro, который требует регистрации с первого запуска, и ReGet Free, который не требовал регистрации, но показывал рекламные баннеры, т. е. эта версия была adware (см. разд. "Freeware и другие" данной главы). После этого продажи, как и ожидалось, резко упали, но за счет обширной пользовательской аудитории это с лихвой компенсировалось выручкой от показов рекламы.
В январе 2000 года ReGet стал продаваться и на российском рынке. Цена для российских пользователей была установлена в 210 рублей, что является относительно небольшой суммой для такой сложной программы.
В настоящее время, по оценкам компании ReGet Software, аудитория ReGet исчисляется сотнями тысяч человек.
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 более десяти тысяч пользователей, не считая нескольких корпоративных клиентов, купивших сразу десятки и даже сотни лицензий.
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 рублей.
Администратор
Сообщений: 484
Нет на сайте
ГЛАВА 2.
С чего начинать
Какую программу писать
Прежде чем начинать собственную 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 и прочие платформы для карманных компьютеров-"наладонников". Писать для них можно на обычном персональном компьютере. Сейчас в связи с бурным развитием данной отрасли компьютерной индустрии, эта платформа имеет шанс "приобрести такое же значение, как и ее "старший брат". Пользователи карманных компьютеров неплохо покупают игры, записные книжки, компактные почтовые клиенты и другие подобные программы. Если у вас есть возможность отлаживать такие программы, то стоит попробовать...
Выбор названия программы
После того как вы определились с тематикой программы, нужно решить, как вы ее назовете. К этому делу следует подходить также ответственно, как, например, к выбору имени для ребенка — ведь от этого будет зависеть, будет ли "жизнь" вашей программы успешной и яркой или ваше детище будет прозябать в безвестности.
Первое, что приходит на ум начинающему шароварщику, — это назвать программу как-нибудь кричаще и вызывающе — с использованием слов "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".
Как вы видите, при выборе названия нужно обязательно проконсультироваться с зарубежными пользователями и при этом проверять, не используется ли выбранное вами название уже кем-то другим.
Обратите внимание на то, что относительно будущего названия для вашего продукта нужно обязательно консультироваться не просто с англоговорящими пользователями, а с теми, для которых английский язык является родным. Только они могут указать вам на различные лингвистические тонкости, из-за которых вашу программу просто никто не захочет купить, или, наоборот, подскажут вам лучший вариант.
Замечание
При этом из-за разницы в культурных традициях вариант, который российский программист вряд ли выберет в качестве названия для своего продукта, окажется вполне благозвучным для зарубежного пользователя. Например, американцы очень уважают змей, которые считаются символом мудрости, и название, включающее английское "snake", может быть неплохим вариантом, однако мало у кого из россиян змеи вызывают положительные эмоции. А слово "maniac" в США в первую очередь обозначает увлекающегося человека, фаната, а не извращенца, как в России.
В крайнем случае, спросите совета у профессионального и квалифицированного переводчика, работавшего за рубежом, или посмотрите в библиотеке самый обширный англо-русский словарь, напечатанный в течение нескольких последних лет. Такие словари учитывают особенности современного английского языка и обычно содержат и сленговые словоформы.
Что касается проверок, не используется ли выбранное вами название уже кем-то другим: если вы не сделаете этого, может оказаться, что выбранное вами название не только занято, но и официально зарегистрировано в качестве торговой марки. А это через некоторое время обязательно приведет к конфликту с владельцем прав на нее, и вам придется в лучшем случае спешно переименовывать свою программу или сайт, а в худшем — сильно страдать материально. Кроме того, многие пользователи, занимаясь поиском вашей программы в Интернете, будут натыкаться на сайт "тезки". Скорее всего, вашу программу также не возьмут и серьезные каталоги программного обеспечения, чтобы избежать путаницы из-за множества программ с одинаковыми именами.
Проверку уникальности выбранного вами названия можно проводить в три этапа.
Проверка, не является ли выбранное название чьей-то зарегистрированной торговой маркой. Сделать это можно по адресу http:// www.nameprotect.com.
Проверка, не используется ли название кем-то другим. Для этого можно воспользоваться одной из крупнейших поисковых систем AltaVista (http://www.altavista.com). Введите в поле образца для поиска интересующее вас слово (если вы проверяете сочетание слов, то обязательно в кавычках и только строчными буквами) и нажмите кнопку Search (Поиск). Если в результате запроса ничего не было найдено или было найдено несколько ссылок, к предмету поиска не относящихся, то этот этап можно считать пройденным.
Проверка, не зарегистрирован ли соответствующий домен в зоне .com (это можно сделать, например, по адресу http://www.domainsearch.ru ) (О доменах и их регистрации см. гл. 9).
Если все три этапа были пройдены успешно — выбранное вами название можно считать пригодным для использования.
Delphi, Basic или С
В этом разделе книги я не собираюсь проводить сравнительный анализ различных сред разработки приложений, пытаясь помочь определиться с выбором. Думаю, это было бы бесполезно: большинство из читателей, наверное, и так уже решили, какую именно из сред разработки приложений они будут использовать для написания своих программ. Кроме того, пользователям все равно, на каком языке программирования написан тот или иной продукт: главное, чтобы он был удобен в использовании и выполнял те функции, которые от него требуются. Вместо этого я расскажу, какие плюсы и минусы имеют наиболее популярные из современных систем программирования с точки зрения разработки продуктов для рынка shareware, иными словами, что вам нужно ожидать от своей любимой среды разработки.
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-автора. Возможно, вам хватит и обширной документации и множества примеров исходных текстов, размещенных в Интернете, а также информации из тематических конференций.
Borland Delphi
Как и Microsoft Visual C++, Borland Delphi позволяет компилировать свои проекты в исполняемые файлы, не требующие каких-либо внешних runtime-библиотек. Их размер, хотя и превышает размер файлов, созданных при помощи Visual C++", все-таки остается довольно компактным, что выгодно отличает Delphi от своего основного конкурента — Visual Basic. Единственное, где нужно быть осторожным, - - эт
Прежде чем начинать собственную 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 и прочие платформы для карманных компьютеров-"наладонников". Писать для них можно на обычном персональном компьютере. Сейчас в связи с бурным развитием данной отрасли компьютерной индустрии, эта платформа имеет шанс "приобрести такое же значение, как и ее "старший брат". Пользователи карманных компьютеров неплохо покупают игры, записные книжки, компактные почтовые клиенты и другие подобные программы. Если у вас есть возможность отлаживать такие программы, то стоит попробовать...
Выбор названия программы
После того как вы определились с тематикой программы, нужно решить, как вы ее назовете. К этому делу следует подходить также ответственно, как, например, к выбору имени для ребенка — ведь от этого будет зависеть, будет ли "жизнь" вашей программы успешной и яркой или ваше детище будет прозябать в безвестности.
Первое, что приходит на ум начинающему шароварщику, — это назвать программу как-нибудь кричаще и вызывающе — с использованием слов "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".
Как вы видите, при выборе названия нужно обязательно проконсультироваться с зарубежными пользователями и при этом проверять, не используется ли выбранное вами название уже кем-то другим.
Обратите внимание на то, что относительно будущего названия для вашего продукта нужно обязательно консультироваться не просто с англоговорящими пользователями, а с теми, для которых английский язык является родным. Только они могут указать вам на различные лингвистические тонкости, из-за которых вашу программу просто никто не захочет купить, или, наоборот, подскажут вам лучший вариант.
Замечание
При этом из-за разницы в культурных традициях вариант, который российский программист вряд ли выберет в качестве названия для своего продукта, окажется вполне благозвучным для зарубежного пользователя. Например, американцы очень уважают змей, которые считаются символом мудрости, и название, включающее английское "snake", может быть неплохим вариантом, однако мало у кого из россиян змеи вызывают положительные эмоции. А слово "maniac" в США в первую очередь обозначает увлекающегося человека, фаната, а не извращенца, как в России.
В крайнем случае, спросите совета у профессионального и квалифицированного переводчика, работавшего за рубежом, или посмотрите в библиотеке самый обширный англо-русский словарь, напечатанный в течение нескольких последних лет. Такие словари учитывают особенности современного английского языка и обычно содержат и сленговые словоформы.
Что касается проверок, не используется ли выбранное вами название уже кем-то другим: если вы не сделаете этого, может оказаться, что выбранное вами название не только занято, но и официально зарегистрировано в качестве торговой марки. А это через некоторое время обязательно приведет к конфликту с владельцем прав на нее, и вам придется в лучшем случае спешно переименовывать свою программу или сайт, а в худшем — сильно страдать материально. Кроме того, многие пользователи, занимаясь поиском вашей программы в Интернете, будут натыкаться на сайт "тезки". Скорее всего, вашу программу также не возьмут и серьезные каталоги программного обеспечения, чтобы избежать путаницы из-за множества программ с одинаковыми именами.
Проверку уникальности выбранного вами названия можно проводить в три этапа.
Проверка, не является ли выбранное название чьей-то зарегистрированной торговой маркой. Сделать это можно по адресу http:// www.nameprotect.com.
Проверка, не используется ли название кем-то другим. Для этого можно воспользоваться одной из крупнейших поисковых систем AltaVista (http://www.altavista.com). Введите в поле образца для поиска интересующее вас слово (если вы проверяете сочетание слов, то обязательно в кавычках и только строчными буквами) и нажмите кнопку Search (Поиск). Если в результате запроса ничего не было найдено или было найдено несколько ссылок, к предмету поиска не относящихся, то этот этап можно считать пройденным.
Проверка, не зарегистрирован ли соответствующий домен в зоне .com (это можно сделать, например, по адресу http://www.domainsearch.ru ) (О доменах и их регистрации см. гл. 9).
Если все три этапа были пройдены успешно — выбранное вами название можно считать пригодным для использования.
Delphi, Basic или С
В этом разделе книги я не собираюсь проводить сравнительный анализ различных сред разработки приложений, пытаясь помочь определиться с выбором. Думаю, это было бы бесполезно: большинство из читателей, наверное, и так уже решили, какую именно из сред разработки приложений они будут использовать для написания своих программ. Кроме того, пользователям все равно, на каком языке программирования написан тот или иной продукт: главное, чтобы он был удобен в использовании и выполнял те функции, которые от него требуются. Вместо этого я расскажу, какие плюсы и минусы имеют наиболее популярные из современных систем программирования с точки зрения разработки продуктов для рынка shareware, иными словами, что вам нужно ожидать от своей любимой среды разработки.
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-автора. Возможно, вам хватит и обширной документации и множества примеров исходных текстов, размещенных в Интернете, а также информации из тематических конференций.
Borland Delphi
Как и Microsoft Visual C++, Borland Delphi позволяет компилировать свои проекты в исполняемые файлы, не требующие каких-либо внешних runtime-библиотек. Их размер, хотя и превышает размер файлов, созданных при помощи Visual C++", все-таки остается довольно компактным, что выгодно отличает Delphi от своего основного конкурента — 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.
Что еще нужно помнить
Главное правило начинающего шароварщика — писать свою программу нужно очень быстро. Современный ранок программного обеспечения очень динамичен: на нем постоянно появляются новые продукты, а существующие расширяют свои возможности. Если вы протянете с выпуском своей программы несколько месяцев, то, когда, наконец, решитесь представить ее публике, вполне может оказаться, что она уже мало кому нужна.
Особенно следует поторопиться, если вы хотите попасть "в струю", т. е. направление, которому посвящена ваша программа, стало популярным совсем недавно (например, как в свое время — утилиты для работы с МРЗ). Вероятно, довольно большое число разработчиков уже пишут программы, аналогичные вашим, и тот, кто первый появится на рынке, "снимет" все "сливки".
Как следствие, от написания первой строки кода до появления первой рабочей версии программы должно пройти 1—2 месяца. Многие разработчики почему-то боятся объявить свою программу финальной версией и бесконечно оттягивают начало продаж своего продукта, выпуская все новые бета- и предварительные версии и предоставляя их ограниченному числу пользователей. Делать этого, по указанным выше причинам, не стоит: ваша программа должна появиться на массовом рынке как можно быстрее.
Помимо этого, на работу нужно настроиться очень серьезно. После прочтения истории shareware и рассказов об успешных российских shareware-проектах (см. гл. 1), у кого-то из читателей, возможно, сложилось впечатление, что стоит выпустить на рынок хоть какую-нибудь программу — и регистрации благодарных пользователей посыпятся, как из рога изобилия. Увы, сегодня все обстоит несколько иначе. Вам придется конкурировать как минимум с несколькими, а может быть, и с десятками соперников, многие из которых находятся на рынке уже не один год и знают, как именно нужно продвигать конкретный продукт. Да и большинство пользователей не платят деньги за первую встреченную программу, а обязательно посмотрят несколько продуктов и выберут самый лучший.
Поэтому если вы действительно хотите добиться серьезного успеха, то установка на результат должна быть бескомпромиссной. Мало просто написать продукт — ваш продукт в своей категории должен быть самым лучшим в мире. Если пишете HTML-редактор — стремитесь сделать его лучше, чем HomeSite. Разрабатываете менеджер файлов — пусть он видится вам лучшим, чем FAR и Windows Commander, вместе взятые. Закладываться нужно на 200%, перепрыгивать через голову, тогда что-то получится. Этот принцип действительно помог многим российским шароварщикам стать лидерами на рынке shareware.
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.
Что еще нужно помнить
Главное правило начинающего шароварщика — писать свою программу нужно очень быстро. Современный ранок программного обеспечения очень динамичен: на нем постоянно появляются новые продукты, а существующие расширяют свои возможности. Если вы протянете с выпуском своей программы несколько месяцев, то, когда, наконец, решитесь представить ее публике, вполне может оказаться, что она уже мало кому нужна.
Особенно следует поторопиться, если вы хотите попасть "в струю", т. е. направление, которому посвящена ваша программа, стало популярным совсем недавно (например, как в свое время — утилиты для работы с МРЗ). Вероятно, довольно большое число разработчиков уже пишут программы, аналогичные вашим, и тот, кто первый появится на рынке, "снимет" все "сливки".
Как следствие, от написания первой строки кода до появления первой рабочей версии программы должно пройти 1—2 месяца. Многие разработчики почему-то боятся объявить свою программу финальной версией и бесконечно оттягивают начало продаж своего продукта, выпуская все новые бета- и предварительные версии и предоставляя их ограниченному числу пользователей. Делать этого, по указанным выше причинам, не стоит: ваша программа должна появиться на массовом рынке как можно быстрее.
Помимо этого, на работу нужно настроиться очень серьезно. После прочтения истории shareware и рассказов об успешных российских shareware-проектах (см. гл. 1), у кого-то из читателей, возможно, сложилось впечатление, что стоит выпустить на рынок хоть какую-нибудь программу — и регистрации благодарных пользователей посыпятся, как из рога изобилия. Увы, сегодня все обстоит несколько иначе. Вам придется конкурировать как минимум с несколькими, а может быть, и с десятками соперников, многие из которых находятся на рынке уже не один год и знают, как именно нужно продвигать конкретный продукт. Да и большинство пользователей не платят деньги за первую встреченную программу, а обязательно посмотрят несколько продуктов и выберут самый лучший.
Поэтому если вы действительно хотите добиться серьезного успеха, то установка на результат должна быть бескомпромиссной. Мало просто написать продукт — ваш продукт в своей категории должен быть самым лучшим в мире. Если пишете HTML-редактор — стремитесь сделать его лучше, чем HomeSite. Разрабатываете менеджер файлов — пусть он видится вам лучшим, чем FAR и Windows Commander, вместе взятые. Закладываться нужно на 200%, перепрыгивать через голову, тогда что-то получится. Этот принцип действительно помог многим российским шароварщикам стать лидерами на рынке shareware.
Администратор
Сообщений: 484
Нет на сайте
ГЛАВА 3.
Немного об авторском праве
Авторское право на компьютерные программы — это такая обширная тема, что ей можно было бы посвятить всю эту книгу целиком. Но, учитывая специфику тематики книги, в этой главе я вкратце расскажу о наиболее актуальных для shareware-разработчика вопросах авторского права.
Нужно ли регистрировать или патентовать свою программу
Согласно российскому законодательству о правовой защите программ для ЭВМ, а это в первую очередь Закон Российской Федерации о правовой охране программ для электронных вычислительных машин и баз данных №3523-1 от 23 сентября 1992 года, авторское право на компьютерные программы возникает в силу их создания. Для признания и осуществления авторского права на программу не требуется депонирования, т. е. сдачи экземпляра программы на хранение, регистрации, патентования или соблюдения иных формальностей. Такой упрощенный порядок признания прав автора программы применяется для более надежной их защиты, т. к. в случае необходимости регистрации программы авторские права оставались бы без охраны, если автор по каким-либо причинам не мог зарегистрировать свою программу.
Автором программы признается физическое лицо (т. е. конкретный человек, а не организация), в результате творческой деятельности которого эта программа создана.
Замечание
Исключительные права на программу (см. разд. "Какие права есть у программиста" этой главы) могут передаваться авторами другим лицам — как физическим, так и юридическим, т. е. организациям. Поэтому, говоря о правах на соответствующую программу, да и вообще на любое произведение, охраняемое авторским правом, употребляют термин "правообладатель", а не "автор", т. к. владелец прав на программу не обязательно является ее автором.
Для оповещения о своих правах на соответствующую программу правообладатель может поместить в ней (обычно в диалоговом окне О программе (About), справочной системы и файле readme.txt) знак охраны авторского права (рис. 3.1), состоящий из следующих элементов:
Буквы С в окружности или в круглых скобках.
Наименования (имени) правообладателя.
Года первого выпуска программы в свет.
Так как shareware-программы в основном предназначаются для иностранного рынка, то знак охраны авторского права в них обычно пишется на западный манер:
Слово "Copyright" (что означает "авторское право").
Буква С в окружности или в круглых скобках.
Год первого выпуска программы в свет и через средний дефис — год выпуска последней версии программы (естественно, если они не совпадают).
Наименование (имя) правообладателя.
Фраза "All rights reserved".
Несмотря на то, что регистрация программ не требуется, обладатель прав на программу может по своему желанию зарегистрировать ее в Российском агентстве по правовой защите программ для ЭВМ и баз данных.
Для этого грамотно должна быть оформлена заявка (см. "Правила составления, подачи и рассмотрения заявок на официальную регистрацию программ для электронных вычислительных машин и баз данных", утвержденные Приказом РосАПО от 5 марта 1993 г. № 7п). В заявку, помимо информации о программе и ее авторе, включаются материалы, идентифицирующие программу, в том числе реферат. После одобрения заявки программа включается в Реестр программ ЭВМ, сведения о ней публикуются в официальном бюллетене Роспатента, а автору выдается свидетельство об официальной регистрации.
Государственная регистрация, несмотря на свой официальный статус и внешнее сходство с процедурой патентования, не имеет и сотой доли значения последней и не предоставляет никаких дополнительных прав. Например, тех материалов, которые предоставляются на депозитное хранение в Российском агентстве по правовой защите программ для ЭВМ и баз данных, недостаточно для проведения технической экспертизы при разрешении возможного спора об авторстве той или иной программы. Регистрация в основном нужна только тогда, когда планируется передача авторских прав на программу, и лицу, передающему права, требуется официальное подтверждение своих полномочий, чтобы предъявить его своему партнеру. Поэтому регистрация программ на практике — не очень частое явление.
А можно ли запатентовать свою программу, чтобы она была так же надежно защищена, как, например, и изобретения? Согласно п. 3 ст. 4 Патентного закона компьютерные программы и алгоритмы не относятся к числу патентоспособных изобретений, т. е. патентование программ не допускается.
Вопрос о том, нужно ли ввести в Российской Федерации патентование программ - очень дискуссионный. Большинство из российских ученых считают, что патентование компьютерных программ является нецелесообразным по многим причинам. Например, программы и так уже охраняются авторским правом, и эта охрана возникает в момент создания программы. А вот для того, чтобы защитить программу патентом (при этом о.бъем прав, представленных правообладателю, будет такой же, как и в случае защиты авторским правом), нужно заполнить заявку, соблюсти определенные формальности, заплатить относительно крупные пошлины. Если по какой-то причине срок уплаты пошлины будет пропущен, то патентная охрана прекращается. Авторское же право на программу действует в течение всей жизни автора и еще пятьдесят лет после его смерти, что является, учитывая скорость морального старения компьютерных программ, практически вечностью. Кроме того, возможны коллизии и злоупотребления, вызванные наличием дублирующих друг друга способов охраны программ для компьютеров.
Противоположная точка зрения тоже имеет сторонников, т. к. патентование программного обеспечения допускается в иностранных государствах. Однако, изучая практику по этому вопросу, существующую за рубежом, можно предположить, что патентование в обозримом будущем вряд ли коснется shareware-программ. Например, в США, Великобритании и Европе, в Европейском патентном ведомстве, участниками которого являются 19 стран Европы: Германия, Австрия, Франция, Бельгия, Испания, Италия и др., патентуются такие программы, при использовании которых уже известное аппаратное обеспечение приобретает новые свойства. Естественно, такого рода программы имеют слишком высокую стоимость разработки и достаточно специфическую область применения, чтобы быть распространяемыми на shareware-рынке.
Какие права есть у программиста
Авторские права делятся на две группы: личные неимущественные и имущественные авторские права. Личные неимущественные права, как следует из их названия, связаны с личностью автора, не могут отчуждаться или передаваться по договору. Они могут принадлежать только автору. Личные неимущественные авторские права охраняются бессрочно.
Автором программы, как уже упоминалось в предыдущем разделе, признается физическое лицо, в результате творческой деятельности которого эта программа создана. Если программа создана совместной творческой деятельностью двух и более физических лиц, то независимо от того, состоит ли программа из частей, каждая из которых имеет самостоятельное значение, или является неделимой, каждое из этих лиц признается автором такой программы. В случае если части программы имеют самостоятельное значение, каждый из авторов имеет право авторства на созданную им часть.
Автору программы принадлежат следующие личные неимущественные права:
право авторства — т. е. право считаться автором программы. Какими бы резкими не были повороты в судьбе автора, кто бы ни владел программой — но автором программы всегда будет считаться тот, чьим трудом она создана — и это право у автора никто не отнимет;
право на имя — т. е. право определять форму указания имени автора в программе: под своим именем, под условным именем (псевдонимом) или анонимно;
право на неприкосновенность (целостность) — т. е. право на защиту как самой программы, так и ее названия от всякого рода искажений или иных посягательств, способных нанести ущерб чести и достоинству автора. Это право, в отличие от прав на авторство и на имя, после смерти автора может передаваться по наследству, чтобы наследники могли защищать честь и достоинство автора.
Замечание
Неотчуждаемость и непередаваемость личных неимущественных прав дает основание такому распространенному заблуждению, что лишь эти права и являются "авторскими", т. к. они могут принадлежать только автору. На самом деле объем правомочий, охватываемых понятием "авторское право", гораздо шире — в него входят и имущественные права.
Вторая группа авторских прав — имущественные. Такие права, после создания программы принадлежащие ее автору, могут передаваться по договору, и в результате этого обладателями таких прав могут становиться как частные лица, так и организации.
Общий смысл имущественных прав — это право использовать программу или разрешать ее использование в любой форме и любым способом. В частности, автор (или обладатель исключительных прав на программу) имеет право осуществлять или разрешать:
выпуск программы в свет;
воспроизведение программы (полное или частичное) в любой форме, любыми способами;
распространение программы. Это право в индустрии shareware нарушается чаще всего, когда кто-то начинает распространять чужие программы без разрешения правообладателя;
модификацию программы для ЭВМ или базы данных, в том числе перевод программы с одного языка на другой. Это право также нарушается достаточно часто — например, когда пользователи из неанглоговорящих стран переводят интерфейс программы на свой родной язык, изменив DLL- или ЕХЕ-файлы программы. Впрочем, авторы относятся к таким самодельным модификациям своих программ лояльно (если, конечно, других изменений, например взлома защиты, нет) — ведь это только повышает популярность программы.
Допускаются и другие способы использования компьютерных программ, Закон не устанавливает их точный перечень, завершая список словами "иное использование программы". Важно то, что все права на любое использование программы принадлежат автору (или тому, кому эти права автором переданы).
Замечание
Среди пользователей распространено мнение, что программу в некоммерческих целях можно использовать бесплатно — это якобы разрешают статьи Закона об авторском праве и смежных правах. Это — всего лишь неудачная попытка оправдать использование пиратских копий программ "домашними" пользователями. Разрешения бесплатного использования программ в некоммерческих целях в законодательстве нет, только автор вправе решать, на каких условиях можно пользоваться его программой.
Имущественные права на программу, как уже упоминалось выше, могут быть переданы полностью или частично другим физическим или юридическим лицам. Передача прав осуществляется по договору, который заключается в письменной форме. Этот договор обязательно должен определять объем и способы использования программы, порядок выплаты и размер вознаграждения, срок действия договора. Кроме того, имущественные права на программу переходят и по наследству.
Использование программы осуществляется также по письменному договору с правообладателем. Естественно, при массовом распространении программ физически невозможно с каждым пользователем отдельно заключать договор. В этом случае допускается применение особого порядка заключения договоров, например путем изложения типовых условий договора на передаваемых экземплярах программ.
Таким особым порядком заключения договора на использование программы является лицензионное соглашение.
Лицензионное соглашение
Лицензионное соглашение (License Agreement, также End-User License Agreement (EULA) — лицензионное соглашение для конечного пользователя), прикладываемое к копии программы, является юридическим документом, определяющим, условия, на которых владелец прав на программу разрешает ее использование. По сути дела, это двусторонний письменный договор между правообладателем и пользователем, договор, имеющий упрощенный порядок заключения: под ним не ставятся подписи его участников. Такое лицензионное соглашение считается заключенным, если пользователь устанавливает, копирует или осуществляет доступ или иным образом использует программу. Если пользователь не согласен с условиями лицензионного соглашения, то он обязан прекратить использование программы и удалить ее файлы со своего компьютера. Объем прав, предоставляемых лицензионным соглашением, называется лицензией.
Для shareware-программ, которые распространяются в виде файла инсталлятора, лицензионное соглашение обычно выполняется в виде текстового файла license.txt и/или раздела в справочной системе. Для того чтобы пользователь мог сразу ознакомиться с его условиями, и в дальнейшем лицензионное соглашение было всегда под рукой, рекомендуется:
включить показ текста лицензионного соглашения в инсталлятор программы, чтобы пользователь не смог продолжить установку, не нажимая кнопку Согласен. Большинство современных пакетов для создания инсталляционных программ позволяют организовать эту функцию;
при инсталляции программы создавать папке соответствующей программы в меню Пуск не только ярлык к файлу программы, но и к файлу license.txt. Можно также включить кнопку Лицензия для просмотра лицензионного соглашения в окне О программе (About).
Замечание
Кто-то из читателей, возможно, с иронией отнесется к тому, сколько внимания уделяется мной лицензионному соглашению. Тем не менее, лицензионное соглашение является действительно значимым юридическим документом, уважаемым не только официальными лицами, но и обыкновенными пользователями, особенно в странах Западной Европы и Северной Америки, которые являются основными легальными потребителями 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 и буду продавать! Ведь автор-то — я!"
Поступать так не стоит даже и пытаться. Скорее всего, вам будет предъявлен серьезный иск в нарушении авторских прав, и выйти из судебного разбирательства победителем нет шансов. И вот почему.
Имущественные права на программу (как и другое произведение), созданную в порядке выполнения служебных обязанностей или по заданию работодателя (так называемая служебная программа), принадлежат работодателю, если в договоре между ним и автором не предусмотрено иное. Естественно, работодатель, который и так выплачивает автору "зарплату и несет другие расходы, связанные с содержанием персонала, заинтересован в полной передаче имущественных прав на программу.
У автора остаются личные неимущественные права — например, право на авторство, на имя и т. п. Но обладание этими правами не позволяет автору заниматься распространением программы — это относится к сфере имущественных прав, которые, как уже говорилось выше, по умолчанию принадлежат работодателю.
Чтобы программа считалась служебной, работодатель должен четко зафиксировать конкретные служебные обязанности сотрудника (например, в должностной инструкции) или выдать ему служебное (например, техническое) задание, причем обязательно в письменной форме.
Для того чтобы закрепить взаимоотношения работодателя и автора при работе по какому-либо определенному проекту, работодатель может заключить с автором договор, в котором будут подробно расписаны условия работы. Чтобы увеличить заинтересованность своего сотрудника в результатах работы по созданию программного обеспечения, работодатель может определить размер выплаты автору в качестве вознаграждения, дополнительно к заработной плате, определенного процента с дохода или прибыли, полученной работодателем от реализации данной программной разработки.
А вот если программист пишет на рабочем месте программу без ведома работодателя, в свободное от выполнения основной работы время — например, какие-то утилиты "для себя", то все авторские права, в том числе и имущественные, в данном случае сохраняются за автором. Конечно, работодатели не одобряют такую деятельность, и лучше стараться не предавать ее огласке.
Авторское право на компьютерные программы — это такая обширная тема, что ей можно было бы посвятить всю эту книгу целиком. Но, учитывая специфику тематики книги, в этой главе я вкратце расскажу о наиболее актуальных для shareware-разработчика вопросах авторского права.
Нужно ли регистрировать или патентовать свою программу
Согласно российскому законодательству о правовой защите программ для ЭВМ, а это в первую очередь Закон Российской Федерации о правовой охране программ для электронных вычислительных машин и баз данных №3523-1 от 23 сентября 1992 года, авторское право на компьютерные программы возникает в силу их создания. Для признания и осуществления авторского права на программу не требуется депонирования, т. е. сдачи экземпляра программы на хранение, регистрации, патентования или соблюдения иных формальностей. Такой упрощенный порядок признания прав автора программы применяется для более надежной их защиты, т. к. в случае необходимости регистрации программы авторские права оставались бы без охраны, если автор по каким-либо причинам не мог зарегистрировать свою программу.
Автором программы признается физическое лицо (т. е. конкретный человек, а не организация), в результате творческой деятельности которого эта программа создана.
Замечание
Исключительные права на программу (см. разд. "Какие права есть у программиста" этой главы) могут передаваться авторами другим лицам — как физическим, так и юридическим, т. е. организациям. Поэтому, говоря о правах на соответствующую программу, да и вообще на любое произведение, охраняемое авторским правом, употребляют термин "правообладатель", а не "автор", т. к. владелец прав на программу не обязательно является ее автором.
Для оповещения о своих правах на соответствующую программу правообладатель может поместить в ней (обычно в диалоговом окне О программе (About), справочной системы и файле readme.txt) знак охраны авторского права (рис. 3.1), состоящий из следующих элементов:
Буквы С в окружности или в круглых скобках.
Наименования (имени) правообладателя.
Года первого выпуска программы в свет.
Так как shareware-программы в основном предназначаются для иностранного рынка, то знак охраны авторского права в них обычно пишется на западный манер:
Слово "Copyright" (что означает "авторское право").
Буква С в окружности или в круглых скобках.
Год первого выпуска программы в свет и через средний дефис — год выпуска последней версии программы (естественно, если они не совпадают).
Наименование (имя) правообладателя.
Фраза "All rights reserved".
Несмотря на то, что регистрация программ не требуется, обладатель прав на программу может по своему желанию зарегистрировать ее в Российском агентстве по правовой защите программ для ЭВМ и баз данных.
Для этого грамотно должна быть оформлена заявка (см. "Правила составления, подачи и рассмотрения заявок на официальную регистрацию программ для электронных вычислительных машин и баз данных", утвержденные Приказом РосАПО от 5 марта 1993 г. № 7п). В заявку, помимо информации о программе и ее авторе, включаются материалы, идентифицирующие программу, в том числе реферат. После одобрения заявки программа включается в Реестр программ ЭВМ, сведения о ней публикуются в официальном бюллетене Роспатента, а автору выдается свидетельство об официальной регистрации.
Государственная регистрация, несмотря на свой официальный статус и внешнее сходство с процедурой патентования, не имеет и сотой доли значения последней и не предоставляет никаких дополнительных прав. Например, тех материалов, которые предоставляются на депозитное хранение в Российском агентстве по правовой защите программ для ЭВМ и баз данных, недостаточно для проведения технической экспертизы при разрешении возможного спора об авторстве той или иной программы. Регистрация в основном нужна только тогда, когда планируется передача авторских прав на программу, и лицу, передающему права, требуется официальное подтверждение своих полномочий, чтобы предъявить его своему партнеру. Поэтому регистрация программ на практике — не очень частое явление.
А можно ли запатентовать свою программу, чтобы она была так же надежно защищена, как, например, и изобретения? Согласно п. 3 ст. 4 Патентного закона компьютерные программы и алгоритмы не относятся к числу патентоспособных изобретений, т. е. патентование программ не допускается.
Вопрос о том, нужно ли ввести в Российской Федерации патентование программ - очень дискуссионный. Большинство из российских ученых считают, что патентование компьютерных программ является нецелесообразным по многим причинам. Например, программы и так уже охраняются авторским правом, и эта охрана возникает в момент создания программы. А вот для того, чтобы защитить программу патентом (при этом о.бъем прав, представленных правообладателю, будет такой же, как и в случае защиты авторским правом), нужно заполнить заявку, соблюсти определенные формальности, заплатить относительно крупные пошлины. Если по какой-то причине срок уплаты пошлины будет пропущен, то патентная охрана прекращается. Авторское же право на программу действует в течение всей жизни автора и еще пятьдесят лет после его смерти, что является, учитывая скорость морального старения компьютерных программ, практически вечностью. Кроме того, возможны коллизии и злоупотребления, вызванные наличием дублирующих друг друга способов охраны программ для компьютеров.
Противоположная точка зрения тоже имеет сторонников, т. к. патентование программного обеспечения допускается в иностранных государствах. Однако, изучая практику по этому вопросу, существующую за рубежом, можно предположить, что патентование в обозримом будущем вряд ли коснется shareware-программ. Например, в США, Великобритании и Европе, в Европейском патентном ведомстве, участниками которого являются 19 стран Европы: Германия, Австрия, Франция, Бельгия, Испания, Италия и др., патентуются такие программы, при использовании которых уже известное аппаратное обеспечение приобретает новые свойства. Естественно, такого рода программы имеют слишком высокую стоимость разработки и достаточно специфическую область применения, чтобы быть распространяемыми на shareware-рынке.
Какие права есть у программиста
Авторские права делятся на две группы: личные неимущественные и имущественные авторские права. Личные неимущественные права, как следует из их названия, связаны с личностью автора, не могут отчуждаться или передаваться по договору. Они могут принадлежать только автору. Личные неимущественные авторские права охраняются бессрочно.
Автором программы, как уже упоминалось в предыдущем разделе, признается физическое лицо, в результате творческой деятельности которого эта программа создана. Если программа создана совместной творческой деятельностью двух и более физических лиц, то независимо от того, состоит ли программа из частей, каждая из которых имеет самостоятельное значение, или является неделимой, каждое из этих лиц признается автором такой программы. В случае если части программы имеют самостоятельное значение, каждый из авторов имеет право авторства на созданную им часть.
Автору программы принадлежат следующие личные неимущественные права:
право авторства — т. е. право считаться автором программы. Какими бы резкими не были повороты в судьбе автора, кто бы ни владел программой — но автором программы всегда будет считаться тот, чьим трудом она создана — и это право у автора никто не отнимет;
право на имя — т. е. право определять форму указания имени автора в программе: под своим именем, под условным именем (псевдонимом) или анонимно;
право на неприкосновенность (целостность) — т. е. право на защиту как самой программы, так и ее названия от всякого рода искажений или иных посягательств, способных нанести ущерб чести и достоинству автора. Это право, в отличие от прав на авторство и на имя, после смерти автора может передаваться по наследству, чтобы наследники могли защищать честь и достоинство автора.
Замечание
Неотчуждаемость и непередаваемость личных неимущественных прав дает основание такому распространенному заблуждению, что лишь эти права и являются "авторскими", т. к. они могут принадлежать только автору. На самом деле объем правомочий, охватываемых понятием "авторское право", гораздо шире — в него входят и имущественные права.
Вторая группа авторских прав — имущественные. Такие права, после создания программы принадлежащие ее автору, могут передаваться по договору, и в результате этого обладателями таких прав могут становиться как частные лица, так и организации.
Общий смысл имущественных прав — это право использовать программу или разрешать ее использование в любой форме и любым способом. В частности, автор (или обладатель исключительных прав на программу) имеет право осуществлять или разрешать:
выпуск программы в свет;
воспроизведение программы (полное или частичное) в любой форме, любыми способами;
распространение программы. Это право в индустрии shareware нарушается чаще всего, когда кто-то начинает распространять чужие программы без разрешения правообладателя;
модификацию программы для ЭВМ или базы данных, в том числе перевод программы с одного языка на другой. Это право также нарушается достаточно часто — например, когда пользователи из неанглоговорящих стран переводят интерфейс программы на свой родной язык, изменив DLL- или ЕХЕ-файлы программы. Впрочем, авторы относятся к таким самодельным модификациям своих программ лояльно (если, конечно, других изменений, например взлома защиты, нет) — ведь это только повышает популярность программы.
Допускаются и другие способы использования компьютерных программ, Закон не устанавливает их точный перечень, завершая список словами "иное использование программы". Важно то, что все права на любое использование программы принадлежат автору (или тому, кому эти права автором переданы).
Замечание
Среди пользователей распространено мнение, что программу в некоммерческих целях можно использовать бесплатно — это якобы разрешают статьи Закона об авторском праве и смежных правах. Это — всего лишь неудачная попытка оправдать использование пиратских копий программ "домашними" пользователями. Разрешения бесплатного использования программ в некоммерческих целях в законодательстве нет, только автор вправе решать, на каких условиях можно пользоваться его программой.
Имущественные права на программу, как уже упоминалось выше, могут быть переданы полностью или частично другим физическим или юридическим лицам. Передача прав осуществляется по договору, который заключается в письменной форме. Этот договор обязательно должен определять объем и способы использования программы, порядок выплаты и размер вознаграждения, срок действия договора. Кроме того, имущественные права на программу переходят и по наследству.
Использование программы осуществляется также по письменному договору с правообладателем. Естественно, при массовом распространении программ физически невозможно с каждым пользователем отдельно заключать договор. В этом случае допускается применение особого порядка заключения договоров, например путем изложения типовых условий договора на передаваемых экземплярах программ.
Таким особым порядком заключения договора на использование программы является лицензионное соглашение.
Лицензионное соглашение
Лицензионное соглашение (License Agreement, также End-User License Agreement (EULA) — лицензионное соглашение для конечного пользователя), прикладываемое к копии программы, является юридическим документом, определяющим, условия, на которых владелец прав на программу разрешает ее использование. По сути дела, это двусторонний письменный договор между правообладателем и пользователем, договор, имеющий упрощенный порядок заключения: под ним не ставятся подписи его участников. Такое лицензионное соглашение считается заключенным, если пользователь устанавливает, копирует или осуществляет доступ или иным образом использует программу. Если пользователь не согласен с условиями лицензионного соглашения, то он обязан прекратить использование программы и удалить ее файлы со своего компьютера. Объем прав, предоставляемых лицензионным соглашением, называется лицензией.
Для shareware-программ, которые распространяются в виде файла инсталлятора, лицензионное соглашение обычно выполняется в виде текстового файла license.txt и/или раздела в справочной системе. Для того чтобы пользователь мог сразу ознакомиться с его условиями, и в дальнейшем лицензионное соглашение было всегда под рукой, рекомендуется:
включить показ текста лицензионного соглашения в инсталлятор программы, чтобы пользователь не смог продолжить установку, не нажимая кнопку Согласен. Большинство современных пакетов для создания инсталляционных программ позволяют организовать эту функцию;
при инсталляции программы создавать папке соответствующей программы в меню Пуск не только ярлык к файлу программы, но и к файлу license.txt. Можно также включить кнопку Лицензия для просмотра лицензионного соглашения в окне О программе (About).
Замечание
Кто-то из читателей, возможно, с иронией отнесется к тому, сколько внимания уделяется мной лицензионному соглашению. Тем не менее, лицензионное соглашение является действительно значимым юридическим документом, уважаемым не только официальными лицами, но и обыкновенными пользователями, особенно в странах Западной Европы и Северной Америки, которые являются основными легальными потребителями 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 и буду продавать! Ведь автор-то — я!"
Поступать так не стоит даже и пытаться. Скорее всего, вам будет предъявлен серьезный иск в нарушении авторских прав, и выйти из судебного разбирательства победителем нет шансов. И вот почему.
Имущественные права на программу (как и другое произведение), созданную в порядке выполнения служебных обязанностей или по заданию работодателя (так называемая служебная программа), принадлежат работодателю, если в договоре между ним и автором не предусмотрено иное. Естественно, работодатель, который и так выплачивает автору "зарплату и несет другие расходы, связанные с содержанием персонала, заинтересован в полной передаче имущественных прав на программу.
У автора остаются личные неимущественные права — например, право на авторство, на имя и т. п. Но обладание этими правами не позволяет автору заниматься распространением программы — это относится к сфере имущественных прав, которые, как уже говорилось выше, по умолчанию принадлежат работодателю.
Чтобы программа считалась служебной, работодатель должен четко зафиксировать конкретные служебные обязанности сотрудника (например, в должностной инструкции) или выдать ему служебное (например, техническое) задание, причем обязательно в письменной форме.
Для того чтобы закрепить взаимоотношения работодателя и автора при работе по какому-либо определенному проекту, работодатель может заключить с автором договор, в котором будут подробно расписаны условия работы. Чтобы увеличить заинтересованность своего сотрудника в результатах работы по созданию программного обеспечения, работодатель может определить размер выплаты автору в качестве вознаграждения, дополнительно к заработной плате, определенного процента с дохода или прибыли, полученной работодателем от реализации данной программной разработки.
А вот если программист пишет на рабочем месте программу без ведома работодателя, в свободное от выполнения основной работы время — например, какие-то утилиты "для себя", то все авторские права, в том числе и имущественные, в данном случае сохраняются за автором. Конечно, работодатели не одобряют такую деятельность, и лучше стараться не предавать ее огласке.
Администратор
Сообщений: 484
Нет на сайте
ГЛАВА 4.
Как работает правильная программа
Размер имеет значение
После прочтения разд. "Delphi, Basic или С" гл. 2, где я уделил повышенное внимание размеру исполняемых файлов, генерируемых компиляторами современных систем программирования, некоторые из читателей, возможно, решили, что я являюсь сторонником тотального минимализма и рекомендую оптимизировать каждый байт кода. Нет, это не так — затраты времени и сил на такую кропотливую работу могли окупиться разве что лет десять назад, когда ни один серьезный программист не мог обойтись без знания ассемблера, а 64 Кбайт (да, вы прочитали правильно, килобайтов, а не мегабайтов) оперативной памяти казались огромным пространством. Я считаю, что размер файла программы должен быть не минимальным, а адекватным ее возможностям, т. е. соответствовать набору функций, предоставляемых пользователю.
"Стоп!" - скажут опытные программисты. — Не имеет значения, каков размер файла программы, важно, каков размер данных, используемых программой!" Абсолютно верно. Программа, ЕХЕ-файл которой имеет объем, например, всего 300 Кбайт, будучи запущенной, займет в оперативной памяти в несколько раз больше места. Дополнительное пространство в памяти "отъедают" переменные и их массивы, используемые программой, но больше всего занятых ресурсов приходится на всевозможные DLL-библиотеки, ведь для реализации почти любой функциональной возможности у Windows заготовлена специальная DLL (табл. 4.1).
Все эти DLL совместно используются разными Windows-приложениями, и когда ваша программа запускается, чаще всего большинство нужных библиотек уже "сидят" в памяти. Именно поэтому стандартный Диспетчер задач в Windows NT и Windows 2000 показывает какие-то дикие цифры — по несколько мегабайтов занимаемой оперативной памяти на каждый запущенный процесс, в том числе и на крошечные вспомогательные утилиты.
Однако для shareware размер именно файла программы, а особенно ее дистрибутива, имеет очень большое значение.
В первую очередь это обусловлено, конечно же, тем, что основной средой для распространения программ является Интернет. Несмотря на то, что пропускная способность каналов связи постоянно растет, около половины пользователей испытывают трудности с загрузкой файлов объемом более чем 1 Мбайт. Да-да, примерно 50% пользователей прекращают процесс закачки больших файлов, не дождавшись его завершения (по мере того, как увеличивается размер файла, который требуется загрузить, процент неудачных закачек, естественно, растет). Виной тому, конечно, не зловредность пользователей, а то, что многие из них не применяют специальные программы для загрузки файлов типа ReGet, GetRight, GolZilla и пр., а предпочитают скачивать даже многомегабайтовые файлы, просто щелкая мышью по ссылкам в браузере. Вследствие этого имеет смысл поместить на странице загрузки файла программы рекомендацию все-таки использовать down-load-менеджеры для закачки
Кроме того, значительная часть серверов, хранящих файлы программ, подключена к Интернету по медленным каналам (загрузка больших файлов предъявляет достаточно жесткие требования к пропускной ширине канала), что тоже вносит свою лепту в статистику неудачных загрузок.
Очень важно и то, что большой размер файла программы может сильно ударить по карману... самого автора программы. Видите ли, для того чтобы выйти на более-менее приличный уровень продаж, нужно добиться, чтобы вашу программу скачивало как можно больше людей — ведь, по статистике, регистрацию программного продукта оплачивают не более 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-программы напоминают мне некоторых моих преподавателей из университета, считавших, что их предмет — самый главный из всех дисциплин учебной программы и именно он станет ни много ни мало делом всей жизни каждого из их студентов. Подобно им, страдающие эгоизмом программы всем своим видом и поведением демонстрируют, что компьютер, операционная система, да и сам пользователь созданы только для того, чтобы удовлетворять их малейшие прихоти.
Естественно, пользовательская аудитория таких эгоистичных программ не отличается многочисленностью. Ведь на рынке существует большое количество программных продуктов, авторы которых руководствуются принципом "Пользователь всегда прав". Итак, какие правила нужно соблюдать для того, чтобы у пользователей остались наилучшие впечатления от работы с вашей программой?
Не трогайте системные файлы и настройки
В первую очередь нужно обратить внимание на недопустимость изменения системных файлов и пользовательских настроек без разрешения пользователя. Вам наверняка встречались программы, уже во время установки которых становится ясно: их авторы не допускают и мысли о том, что на компьютере пользователя будут работать какие-либо иные приложения. Поведение программ, считающих себя "пупом всей системы", очень разнообразно. Они изменяют файлы autoexec.bat и config.sys, заменяют системные DLL, позволяют устанавливать себя только в одну папку, причем часто — исключительно в корневой каталог диска С:, добавляют ярлыки в верхний уровень меню Пуск (а не в подменю Программы) и на Рабочий стол. Изменяют ассоциации файлов, делают стартовой страницей установленного в системе браузера домашнюю страницу разработчика программы, при каждом запуске добавляют себя в секцию автозагрузки и многое другое (рис. 4.2). При всем разнообразии поведения их объединяет одно: все это они проделывают, даже не спросив разрешения пользователя.
Обычно о том, что программа занимается самоуправством относительно системных ресурсов, в лучшем случае упоминается в readme-файле или одном из разделов справочной системы. Но такого упоминания, смахивающего на обычную "постановку перед фактом" недостаточно! Программа обязательно должна предупредить пользователя о том, что сейчас последует изменение ресурсов и настроек системы, и предоставить ему возможность запрета этих действий.
После того, как инсталлятор такой программы завершит свою работу и пользователь увидит, во что теперь превратилась его рабочая среда, недовольство этим автоматически перенесется и на саму программу. Возможно, пользователь запустит ее, чтобы мельком посмотреть на то, что же так исковеркало его систему, но долго такая программа на его компьютере не задержится.
Некоторые разработчики полагают, что иногда спрашивать разрешение пользователя на модификацию каких-либо системных настроек не требуется. Например, если программа хранит свои данные в файлах не с каким-либо распространенным расширением вроде txt или html, а с экзотическим, предположим, fgh или hjk, то можно безбоязненно зарегистрировать их в системе на собственную программу, не запрашивая разрешение пользователя. Однако программных продуктов на рынке очень много, и вполне может оказаться, что избранные разработчиком расширения fgh или hjk уже используются другой программой. Более того, пользователь предпочитает открывать эти файлы именно с ее помощью. Это один из примеров того, что программа и ее инсталлятор должны обязательно запрашивать разрешение пользователя на замену системных файлов, модификацию настроек операционной системы и рабочего окружения пользователя
Относитесь к пользователю с уважением
При работе с некоторыми программами никак не удается отделаться от ощущения, что их авторы делают тебе одолжение — слишком уж лаконичны и порой даже грубы сообщения, выдаваемые их программами. Характерный пример — сообщение, с которым у многих пользователей ассоциируется операционная система Microsoft Windows и которое стало объектом большого количества шуток и анекдотов: "Программа выполнила недопустимую операцию и будет закрыта. Если ошибка будет повторяться, обратитесь к разработчику".
У вашей программы гораздо больше шансов понравиться потенциальным покупателям и обойти своих конкурентов, если вы будете относиться к своим пользователям с уважением и элементарной вежливостью. Для этого нужно не так уж много:
делайте сообщения, выдаваемые вашей программой, более-менее информативными;
сопровождайте сообщения об ошибках словом "извините", показывая, что вам жаль, что ваша программа, даже если в данном случае и не по своей вине, вынуждена расстроить пользователя;
если от пользователя требуется совершить какие-то действия, то не забудьте о слове "пожалуйста", чтобы ваше требование выглядело просьбой, а не приказом. А если можно предположить, что выполнение вашей просьбы для пользователя будет сопряжено с ощутимыми затратами времени или денежных средств (например, в случае необходимости скачать из Интернета какой-либо дополнительный компонент), также скажите "извините", чтобы выразить свое сожаление по этому поводу.
Многие российские разработчики shareware следуют этому -правилу буквально во всем. Например, даже если пользователь в окне регистрации программы вводит код, приобретенный ранее по украденному номеру кредитной карточки, то в ответ выводится вежливое сообщение о причинах того, почему программа не может быть зарегистрирована, и рассказывается о том, как приобрести программу легальным путем. Поддаться порыву обозвать пользователя вором и процитировать ему Уголовный кодекс было бы неразумно, т. к. пользователь, возможно, просто не знает, как нужно регистрировать программы и думает, что случайно попавшийся ему в Интернете ключ является вполне законным средством. Если вежливо объяснить ему, в чем дело — не исключено, что он оплатит регистрацию (в практике такие случаи не редкость), а в дальнейшем будет рекомендовать программу всем своим друзьям и знакомым. А вот если он будет оскорблен — еще одного пользователя можно будет считать потерянным.
Да, вежливость shareware-авторов чаще всего обусловлена не альтруизмом, а желанием заработать больше денег. Однако пользователей это не особенно волнует, и они охотно оплачивают регистрации программ, работа с которыми приносит удовольствие.
Не делайте из программы культа
Некоторые авторы превращают работу со своими программами в подобие торжественного ритуала. Они никак не могут допустить, чтобы пользователь забыл о существовании их программ хотя бы на минуту и полностью сосредоточился на своей работе. Такие программы назойливо лезут в глаза, стараясь подчеркнуть свое, по мнению их авторов, особое значение для пользователя.
Я имею в виду в первую очередь такую, казалось бы, мелочь, как так называемый splash screen ("всплывающий экран"), т. е. заставку, появляющуюся при старте программы. Конечно, разговор об оформлении продукта больше подходит для гл. 5 "Пользовательский интерфейс", однако сплэш-скрин — характерный пример не только неправильного подхода к проектированию интерфейса программы, но и неправильного подхода к созданию всей программы в целом.
В больших продуктах вроде Microsoft Windows 2000 или Adobe Photoshop, запуск которых даже на мощных компьютерах длится заметное время, стартовая заставка имеет вполне практическую цель: развлекать пользователя во время запуска и показывать ход процесса загрузки приложения. Вместе с тем в больших программах сплэш-скрин не держится на экране ни на мгновение больше необходимого. Например, Microsoft Word 2000 грузится на моем новом компьютере за полторы секунды, и я даже не могу толком рассмотреть промелькнувшую на экране заставку. Однако многих авторов небольших по сравнению с "монстрами" shareware-программ такая ситуация, когда пользователь не успевает рассмотреть на заставке название программы, ее версию, имя автора и адрес сайта, не устраивает. И они специально замедляют загрузку программы, вставляя паузу в несколько секунд, и при этом не предоставляют никакой возможности отключить показ заставки!
Однако нужно обратить внимание на то, что заставка, висящая несколько секунд при старте программы, является мощнейшим источником раздражения пользователей. Не случайно одним из стандартных способов стимуляции пользователей регистрировать shareware-программы является показ при старте приложения экрана с напоминанием о необходимости регистрации, которое нельзя закрыть в течение нескольких секунд (так называемый nag screen). (См. гл. 6.)
Совершенно недопустимым, на мой взгляд, является принудительный показ стартовых заставок в программах, которые предназначены для их ежедневного запуска в начале работы компьютера — антивирусов, часов, утилит управления устройствами компьютера и т. п. Ежедневное созерцание появляющихся один за другим экранов с логотипами программ может вывести из себя кого угодно. Например, я отказался от использования прилагавшейся к моей новой материнской плате утилиты мониторинга ASUS Probe именно из-за надоедливого сплэш-скрина. То же я мог бы сказать и об антивирусе Antiviral Toolkit Pro, чью заставку с раскрытым зонтом я уже терпеть не могу, если бы без эффективной антивирусной защиты можно было обойтись. И зачем только разработчики обрекают легальных пользователей, купивших их программу, на такие страдания?
Вред сплэш-скринов, замедляющих запуск приложений, как глобального дефекта программы, а не просто неудачного элемента интерфейса, подчеркивает, например, Лу Гринзоу, авторитетный специалист в области разработки приложений. Он также обращает внимание на то, что каждая программа, показывающая пользователю стартовую заставку, обязательно должна иметь возможность ее отключения.
Мудрое хранение настроек
То, каким именно образом приложение управляется со своими настройками и параметрами, обычно очень мало беспокоит пользователей. Однако продуманный подход к организации хранения параметров работы программы может принести вам благодарность ваших пользователей, сэкономившим благодаря этому много времени.
В 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-файле, объем которого обычно составляет несколько килобайтов, осуществляется гораздо быстрее. А т. к. чтение и запись настроек во время сеанса работы программы происходит довольно часто, разница в скорости может сэкономить немало времени.
Замечание
Некоторые программы сохраняют свои настройки только в момент завершения работы — например, когда пользователь выбирает из меню 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 — опытные пользователи наверняка это оценят и будут уважать вашу программу еще больше
Продуманная локализация
Рано или поздно любой 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-файлов. Такие файлы пользователи легко могут редактировать сами. Достаточно приложить к программе образец языкового файла с английскими строками — и любой, кто имеет навыки работы с текстовым редактором, может сделать на основе этого образца такой же файл для своего родного языка.
Замечание
Учтите, что отдельный файл с переводом интерфейса на английский язык — это не более чем образец для новых переводов, непосредственно программа не должна этот файл использовать. Английский вариант интерфейса должен быть жестко "прошит" в программу — это обеспечит ее корректную работу в том случае, если какие-то строки в языковом файле (или даже сам этот файл) отсутствуют.
Существуют даже специальные ActiveX- и VCL-компоненты, предназначенные для реализации многоязычного интерфейса программы. Но, я думаю, что пользоваться ими особого смысла нет. Включение таких компонентов в проект лишь неоправданно увеличит его размер, ведь с технической точки зрения реализация интерфейса на разных языках — достаточно тривиальная задача. Стандартные функции, имеющиеся в современных системах программирования, а также их "основа" -- функции API Windows замечательно справляются с чтением секций и ключей INI-файлов, не доставляя разработчику никаких хлопот.
Для того чтобы сделать код, отвечающий за чтение строк с описанием интерфейса, более компактным и универсальным, строки для каждой формы хранятся в секции файла, название которой совпадает с именем формы.
Подписи к элементам управления, находящимся на этой форме, соответствует ключ, который называется так же, как и элемент управления (рис. 4.4). В результате при открытии формы запускается цикл, в котором опрашиваются все элементы управления, расположенные на форме, и соответствующие им текстовые строки считываются из языкового файла.
В заключение я хотел бы обратить ваше внимание на излишнюю торжественность, которая сопровождает процедуру смены языка интерфейса в некоторых программах. После того, как пользователь выберет новый язык интерфейса, программа сообщает ему, что для того, чтобы сделанное изменение вступило в силу, нужно перезапустить программу. Их авторам так и хочется сказать: "Не делайте из своей программы культа!" (см. разд. "Поменьше эгоизма" данной главы). Ведь существует достаточно большое количество shareware-продуктов, язык интерфейса которых меняется прямо "на лету", без перезапуска самой программы. Все, что нужно для этого — немного времени программиста, потраченного на реализацию соответствующих функций.
После прочтения разд. "Delphi, Basic или С" гл. 2, где я уделил повышенное внимание размеру исполняемых файлов, генерируемых компиляторами современных систем программирования, некоторые из читателей, возможно, решили, что я являюсь сторонником тотального минимализма и рекомендую оптимизировать каждый байт кода. Нет, это не так — затраты времени и сил на такую кропотливую работу могли окупиться разве что лет десять назад, когда ни один серьезный программист не мог обойтись без знания ассемблера, а 64 Кбайт (да, вы прочитали правильно, килобайтов, а не мегабайтов) оперативной памяти казались огромным пространством. Я считаю, что размер файла программы должен быть не минимальным, а адекватным ее возможностям, т. е. соответствовать набору функций, предоставляемых пользователю.
"Стоп!" - скажут опытные программисты. — Не имеет значения, каков размер файла программы, важно, каков размер данных, используемых программой!" Абсолютно верно. Программа, ЕХЕ-файл которой имеет объем, например, всего 300 Кбайт, будучи запущенной, займет в оперативной памяти в несколько раз больше места. Дополнительное пространство в памяти "отъедают" переменные и их массивы, используемые программой, но больше всего занятых ресурсов приходится на всевозможные DLL-библиотеки, ведь для реализации почти любой функциональной возможности у Windows заготовлена специальная DLL (табл. 4.1).
Все эти DLL совместно используются разными Windows-приложениями, и когда ваша программа запускается, чаще всего большинство нужных библиотек уже "сидят" в памяти. Именно поэтому стандартный Диспетчер задач в Windows NT и Windows 2000 показывает какие-то дикие цифры — по несколько мегабайтов занимаемой оперативной памяти на каждый запущенный процесс, в том числе и на крошечные вспомогательные утилиты.
Однако для shareware размер именно файла программы, а особенно ее дистрибутива, имеет очень большое значение.
В первую очередь это обусловлено, конечно же, тем, что основной средой для распространения программ является Интернет. Несмотря на то, что пропускная способность каналов связи постоянно растет, около половины пользователей испытывают трудности с загрузкой файлов объемом более чем 1 Мбайт. Да-да, примерно 50% пользователей прекращают процесс закачки больших файлов, не дождавшись его завершения (по мере того, как увеличивается размер файла, который требуется загрузить, процент неудачных закачек, естественно, растет). Виной тому, конечно, не зловредность пользователей, а то, что многие из них не применяют специальные программы для загрузки файлов типа ReGet, GetRight, GolZilla и пр., а предпочитают скачивать даже многомегабайтовые файлы, просто щелкая мышью по ссылкам в браузере. Вследствие этого имеет смысл поместить на странице загрузки файла программы рекомендацию все-таки использовать down-load-менеджеры для закачки
Кроме того, значительная часть серверов, хранящих файлы программ, подключена к Интернету по медленным каналам (загрузка больших файлов предъявляет достаточно жесткие требования к пропускной ширине канала), что тоже вносит свою лепту в статистику неудачных загрузок.
Очень важно и то, что большой размер файла программы может сильно ударить по карману... самого автора программы. Видите ли, для того чтобы выйти на более-менее приличный уровень продаж, нужно добиться, чтобы вашу программу скачивало как можно больше людей — ведь, по статистике, регистрацию программного продукта оплачивают не более 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-программы напоминают мне некоторых моих преподавателей из университета, считавших, что их предмет — самый главный из всех дисциплин учебной программы и именно он станет ни много ни мало делом всей жизни каждого из их студентов. Подобно им, страдающие эгоизмом программы всем своим видом и поведением демонстрируют, что компьютер, операционная система, да и сам пользователь созданы только для того, чтобы удовлетворять их малейшие прихоти.
Естественно, пользовательская аудитория таких эгоистичных программ не отличается многочисленностью. Ведь на рынке существует большое количество программных продуктов, авторы которых руководствуются принципом "Пользователь всегда прав". Итак, какие правила нужно соблюдать для того, чтобы у пользователей остались наилучшие впечатления от работы с вашей программой?
Не трогайте системные файлы и настройки
В первую очередь нужно обратить внимание на недопустимость изменения системных файлов и пользовательских настроек без разрешения пользователя. Вам наверняка встречались программы, уже во время установки которых становится ясно: их авторы не допускают и мысли о том, что на компьютере пользователя будут работать какие-либо иные приложения. Поведение программ, считающих себя "пупом всей системы", очень разнообразно. Они изменяют файлы autoexec.bat и config.sys, заменяют системные DLL, позволяют устанавливать себя только в одну папку, причем часто — исключительно в корневой каталог диска С:, добавляют ярлыки в верхний уровень меню Пуск (а не в подменю Программы) и на Рабочий стол. Изменяют ассоциации файлов, делают стартовой страницей установленного в системе браузера домашнюю страницу разработчика программы, при каждом запуске добавляют себя в секцию автозагрузки и многое другое (рис. 4.2). При всем разнообразии поведения их объединяет одно: все это они проделывают, даже не спросив разрешения пользователя.
Обычно о том, что программа занимается самоуправством относительно системных ресурсов, в лучшем случае упоминается в readme-файле или одном из разделов справочной системы. Но такого упоминания, смахивающего на обычную "постановку перед фактом" недостаточно! Программа обязательно должна предупредить пользователя о том, что сейчас последует изменение ресурсов и настроек системы, и предоставить ему возможность запрета этих действий.
После того, как инсталлятор такой программы завершит свою работу и пользователь увидит, во что теперь превратилась его рабочая среда, недовольство этим автоматически перенесется и на саму программу. Возможно, пользователь запустит ее, чтобы мельком посмотреть на то, что же так исковеркало его систему, но долго такая программа на его компьютере не задержится.
Некоторые разработчики полагают, что иногда спрашивать разрешение пользователя на модификацию каких-либо системных настроек не требуется. Например, если программа хранит свои данные в файлах не с каким-либо распространенным расширением вроде txt или html, а с экзотическим, предположим, fgh или hjk, то можно безбоязненно зарегистрировать их в системе на собственную программу, не запрашивая разрешение пользователя. Однако программных продуктов на рынке очень много, и вполне может оказаться, что избранные разработчиком расширения fgh или hjk уже используются другой программой. Более того, пользователь предпочитает открывать эти файлы именно с ее помощью. Это один из примеров того, что программа и ее инсталлятор должны обязательно запрашивать разрешение пользователя на замену системных файлов, модификацию настроек операционной системы и рабочего окружения пользователя
Относитесь к пользователю с уважением
При работе с некоторыми программами никак не удается отделаться от ощущения, что их авторы делают тебе одолжение — слишком уж лаконичны и порой даже грубы сообщения, выдаваемые их программами. Характерный пример — сообщение, с которым у многих пользователей ассоциируется операционная система Microsoft Windows и которое стало объектом большого количества шуток и анекдотов: "Программа выполнила недопустимую операцию и будет закрыта. Если ошибка будет повторяться, обратитесь к разработчику".
У вашей программы гораздо больше шансов понравиться потенциальным покупателям и обойти своих конкурентов, если вы будете относиться к своим пользователям с уважением и элементарной вежливостью. Для этого нужно не так уж много:
делайте сообщения, выдаваемые вашей программой, более-менее информативными;
сопровождайте сообщения об ошибках словом "извините", показывая, что вам жаль, что ваша программа, даже если в данном случае и не по своей вине, вынуждена расстроить пользователя;
если от пользователя требуется совершить какие-то действия, то не забудьте о слове "пожалуйста", чтобы ваше требование выглядело просьбой, а не приказом. А если можно предположить, что выполнение вашей просьбы для пользователя будет сопряжено с ощутимыми затратами времени или денежных средств (например, в случае необходимости скачать из Интернета какой-либо дополнительный компонент), также скажите "извините", чтобы выразить свое сожаление по этому поводу.
Многие российские разработчики shareware следуют этому -правилу буквально во всем. Например, даже если пользователь в окне регистрации программы вводит код, приобретенный ранее по украденному номеру кредитной карточки, то в ответ выводится вежливое сообщение о причинах того, почему программа не может быть зарегистрирована, и рассказывается о том, как приобрести программу легальным путем. Поддаться порыву обозвать пользователя вором и процитировать ему Уголовный кодекс было бы неразумно, т. к. пользователь, возможно, просто не знает, как нужно регистрировать программы и думает, что случайно попавшийся ему в Интернете ключ является вполне законным средством. Если вежливо объяснить ему, в чем дело — не исключено, что он оплатит регистрацию (в практике такие случаи не редкость), а в дальнейшем будет рекомендовать программу всем своим друзьям и знакомым. А вот если он будет оскорблен — еще одного пользователя можно будет считать потерянным.
Да, вежливость shareware-авторов чаще всего обусловлена не альтруизмом, а желанием заработать больше денег. Однако пользователей это не особенно волнует, и они охотно оплачивают регистрации программ, работа с которыми приносит удовольствие.
Не делайте из программы культа
Некоторые авторы превращают работу со своими программами в подобие торжественного ритуала. Они никак не могут допустить, чтобы пользователь забыл о существовании их программ хотя бы на минуту и полностью сосредоточился на своей работе. Такие программы назойливо лезут в глаза, стараясь подчеркнуть свое, по мнению их авторов, особое значение для пользователя.
Я имею в виду в первую очередь такую, казалось бы, мелочь, как так называемый splash screen ("всплывающий экран"), т. е. заставку, появляющуюся при старте программы. Конечно, разговор об оформлении продукта больше подходит для гл. 5 "Пользовательский интерфейс", однако сплэш-скрин — характерный пример не только неправильного подхода к проектированию интерфейса программы, но и неправильного подхода к созданию всей программы в целом.
В больших продуктах вроде Microsoft Windows 2000 или Adobe Photoshop, запуск которых даже на мощных компьютерах длится заметное время, стартовая заставка имеет вполне практическую цель: развлекать пользователя во время запуска и показывать ход процесса загрузки приложения. Вместе с тем в больших программах сплэш-скрин не держится на экране ни на мгновение больше необходимого. Например, Microsoft Word 2000 грузится на моем новом компьютере за полторы секунды, и я даже не могу толком рассмотреть промелькнувшую на экране заставку. Однако многих авторов небольших по сравнению с "монстрами" shareware-программ такая ситуация, когда пользователь не успевает рассмотреть на заставке название программы, ее версию, имя автора и адрес сайта, не устраивает. И они специально замедляют загрузку программы, вставляя паузу в несколько секунд, и при этом не предоставляют никакой возможности отключить показ заставки!
Однако нужно обратить внимание на то, что заставка, висящая несколько секунд при старте программы, является мощнейшим источником раздражения пользователей. Не случайно одним из стандартных способов стимуляции пользователей регистрировать shareware-программы является показ при старте приложения экрана с напоминанием о необходимости регистрации, которое нельзя закрыть в течение нескольких секунд (так называемый nag screen). (См. гл. 6.)
Совершенно недопустимым, на мой взгляд, является принудительный показ стартовых заставок в программах, которые предназначены для их ежедневного запуска в начале работы компьютера — антивирусов, часов, утилит управления устройствами компьютера и т. п. Ежедневное созерцание появляющихся один за другим экранов с логотипами программ может вывести из себя кого угодно. Например, я отказался от использования прилагавшейся к моей новой материнской плате утилиты мониторинга ASUS Probe именно из-за надоедливого сплэш-скрина. То же я мог бы сказать и об антивирусе Antiviral Toolkit Pro, чью заставку с раскрытым зонтом я уже терпеть не могу, если бы без эффективной антивирусной защиты можно было обойтись. И зачем только разработчики обрекают легальных пользователей, купивших их программу, на такие страдания?
Вред сплэш-скринов, замедляющих запуск приложений, как глобального дефекта программы, а не просто неудачного элемента интерфейса, подчеркивает, например, Лу Гринзоу, авторитетный специалист в области разработки приложений. Он также обращает внимание на то, что каждая программа, показывающая пользователю стартовую заставку, обязательно должна иметь возможность ее отключения.
Мудрое хранение настроек
То, каким именно образом приложение управляется со своими настройками и параметрами, обычно очень мало беспокоит пользователей. Однако продуманный подход к организации хранения параметров работы программы может принести вам благодарность ваших пользователей, сэкономившим благодаря этому много времени.
В 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-файле, объем которого обычно составляет несколько килобайтов, осуществляется гораздо быстрее. А т. к. чтение и запись настроек во время сеанса работы программы происходит довольно часто, разница в скорости может сэкономить немало времени.
Замечание
Некоторые программы сохраняют свои настройки только в момент завершения работы — например, когда пользователь выбирает из меню 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 — опытные пользователи наверняка это оценят и будут уважать вашу программу еще больше
Продуманная локализация
Рано или поздно любой 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-файлов. Такие файлы пользователи легко могут редактировать сами. Достаточно приложить к программе образец языкового файла с английскими строками — и любой, кто имеет навыки работы с текстовым редактором, может сделать на основе этого образца такой же файл для своего родного языка.
Замечание
Учтите, что отдельный файл с переводом интерфейса на английский язык — это не более чем образец для новых переводов, непосредственно программа не должна этот файл использовать. Английский вариант интерфейса должен быть жестко "прошит" в программу — это обеспечит ее корректную работу в том случае, если какие-то строки в языковом файле (или даже сам этот файл) отсутствуют.
Существуют даже специальные ActiveX- и VCL-компоненты, предназначенные для реализации многоязычного интерфейса программы. Но, я думаю, что пользоваться ими особого смысла нет. Включение таких компонентов в проект лишь неоправданно увеличит его размер, ведь с технической точки зрения реализация интерфейса на разных языках — достаточно тривиальная задача. Стандартные функции, имеющиеся в современных системах программирования, а также их "основа" -- функции API Windows замечательно справляются с чтением секций и ключей INI-файлов, не доставляя разработчику никаких хлопот.
Для того чтобы сделать код, отвечающий за чтение строк с описанием интерфейса, более компактным и универсальным, строки для каждой формы хранятся в секции файла, название которой совпадает с именем формы.
Подписи к элементам управления, находящимся на этой форме, соответствует ключ, который называется так же, как и элемент управления (рис. 4.4). В результате при открытии формы запускается цикл, в котором опрашиваются все элементы управления, расположенные на форме, и соответствующие им текстовые строки считываются из языкового файла.
В заключение я хотел бы обратить ваше внимание на излишнюю торжественность, которая сопровождает процедуру смены языка интерфейса в некоторых программах. После того, как пользователь выберет новый язык интерфейса, программа сообщает ему, что для того, чтобы сделанное изменение вступило в силу, нужно перезапустить программу. Их авторам так и хочется сказать: "Не делайте из своей программы культа!" (см. разд. "Поменьше эгоизма" данной главы). Ведь существует достаточно большое количество shareware-продуктов, язык интерфейса которых меняется прямо "на лету", без перезапуска самой программы. Все, что нужно для этого — немного времени программиста, потраченного на реализацию соответствующих функций.
Администратор
Сообщений: 484
Нет на сайте
Глава 5. Пользовательский интерфейс
Значение пользовательского интерфейса
Один из самых частых вопросов, которые задают в конференциях начинающие 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" (простой обучающей программы) до дизайна форм.
Основы построения интерфейсов
Когда говорят о научных основах проектирования пользовательских интерфейсов, в первую очередь упоминают термин 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 "Блокнот" стал более дружественен к пользователю.
Другой пример недооценки возможностей пользователя — вывод информационных сообщений в ситуациях, когда этого не требуется. Многие авторы наделяют свои программы излишней "болтливостью" из благих намерений — например, для того, чтобы облегчить освоение продукта или информировать пользователей о полезных функциях программы. Однако вполне может оказаться так, что пользователь уже достаточно уверенно чувствует себя при работе с программой и не нуждается в подсказках, выскакивающих каждую минуту, а некоторые полезные, с точки зрения автора программного продукта, функции для конкретного пользователя таковыми не являются. Поэтому среди разработчиков программного обеспечения хорошим тоном считается предоставление пользователю возможности отключить вывод информационных сообщений. Это позволяет сохранить легкость освоения продукта для начинающих пользователей и одновременно с этим добиться, чтобы информационные сообщения не вызывали у опытных пользователей раздражения.
И, наконец, третий принцип - "Программа должна работать так, чтобы пользователь не считал компьютер дураком".
Несмотря на стремительное развитие информационных технологий, многие компьютерные программы все еще имеют примитивный искусственный интеллект. Они прерывают работу пользователя глупыми вопросами и выводят на экран бессмысленные сообщения, повергая его в недоумение в самых простых ситуациях. В результате многие люди, работающие с компьютерами, раздраженно восклицают: "Как мне надоела эта тупая машина!"
Примечание
Конечно, искусственный интеллект компьютерных программ в основном зависит от усилий их авторов, а не характеристик аппаратного обеспечения. Однако у большинства пользователей компьютер ассоциируется именно с программами, которые на нем работают, и плохое впечатление от использования программного обеспечения автоматически переносится на сам компьютер.
Примеров таких неудачных решений в области интерфейсов существует очень много — как среди продуктов известных компаний, так и среди программ мелких разработчиков. Вот один из них: система управления базами данных Microsoft Access запрашивает у пользователя подтверждение обновления информации в таблице. Все бы хорошо, если бы не бессмысленность этого сообщения: обновления данных все равно не будет в любом случае, т. к. количество строк, в которых были изменены данные, равно нулю.
А этот пример особенно часто приводится в качестве иллюстрации к рассказу о "тупых" интерфейсах. Утилита преобразования текстовых файлов, включенная в Microsoft Word, способна распознать формат открываемого файла. Но, тем не менее, она просит пользователя подтвердить, что структура файла была определена правильно. Во многих случаях (например, когда человек открывает файл, созданный не им, или просто при недостатке знаний) он не может указать, каков формат файла на самом деле. Но, т. к. его все-таки просят сделать выбор, он начинает колебаться, выбирать из списка другие форматы, что приводит к некорректным результатам.
Еще один известный пример интерфейса, который дает повод поразиться "глупости" компьютера. Если в текстовом редакторе WordPad открыть обыкновенный текстовый файл и, даже ничего в нем не меняя, попробовать сохранить его, то программа сообщит, что такая операция "приведет к потере форматирования". Особую пикантность этой ситуации придает тот факт, что в текстовом (ASCII) файле какое-либо форматирование отсутствует изначально.
Есть и откровенно дурацкие сообщения, которые заставляют задуматься, почему современный мощный компьютер стоимостью несколько сотен долларов обладает интеллектом простого калькулятора. Впрочем, очень часто такие сообщения вызваны ошибками в самой программе.
Нужно заметить, что, как и в любой другой науке, принципы построения интерфейсов компьютерных программ тесно взаимосвязаны. Нарушение одного правила почти наверняка повлечет нарушение и другого. Например, если при работе пользователя с программой на экране появилось сообщение заставляющее усомниться в том, что компьютер может справиться со своими функциями (третий принцип), то о соблюдении первого принципа (прозрачность интерфейса) говорить тоже не приходится, т. к. вместо того, чтобы продолжить работу, человек вынужден теряться в догадках: "Что бы это значило?"
Эвристические правила Якоба Нильсена
Три основных принципа проектирования интерфейсов компьютерных программ, о которых я рассказал в предыдущем разделе, являются, безусловно, чрезвычайно полезными и эффективными, все же они представляют собой довольно общие правила. Далеко не каждый, а уж тем более начинающий разработчик интерфейсов, сможет качественно выполнить свою задачу, руководствуясь только ими. Требуются более конкретизированные правила, которые давали бы развернутую картину стратегии построения интерфейсов.
Одними из самых цитируемых в книгах по HCI являются десять так называемых эвристических правил известнейшего американского специалиста в области проектирования интерфейсов Якоба Нильсена (Jakob Nielsen), разработанных им совместно с другим исследователем, Рольфом Моличем (Rolf Molich). Формулировку этих принципов в оригинале можно прочитать по адресу http://www.useit.com/papers/heuristic/heuristic_list.html. Это десять главных заповедей любого разработчика компьютерных интерфейсов, т. е. минимальные критерии, которым должен отвечать интерфейс любой программы.
Видимость состояния системы (правило обратной связи)
Система (в данном случае — компьютерная программа) должна всегда информировать пользователя о состоянии своей работы с помощью соответствующих средств, в разумное время. При рассмотрении этого правила нужно учитывать несколько аспектов.
Информированность пользователя
Пользователь всегда должен иметь информацию о текущем статусе работы программы — например, сколько времени прошло от начала процесса копирования файлов, когда будет завершено кодирование звуковой дорожки CD-диска в МРЗ-файл и т. п. Кроме этого, пользователь обязательно должен видеть, к чему привело любое его действие: ввод данных, нажатие кнопки и т. п.
Средства обеспечения обратной связи
Выбор конкретного средства обратной связи зависит от типа информации, которую нужно донести до пользователя, а также типа действия, которое вызывает потребность в обратной связи.
Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках — в статусной строке окна приложения без остановки его работы. Характерен пример браузера Microsoft Explorer: если открыть запрашиваемую Web-страницу в данный момент невозможно (например, отсутствует соединение с Интернетом), то на экране появляется модальное окно с сообщением о критической ошибке. Если же страница была успешно загружена, но при этом возникли незначительные ошибки, то соответствующее сообщение отображается в строке состояния программы.
Что касается зависимости выбора средства обратной связи от типа действия, вызывающего ее, то традиционно считается, что если пользователь сделал какое-то действие -- например, запустил процесс кодирования большого файла или дал команду подсчитать количество знаков в тексте, — и ожидает какого-то результата, то этот результат (или сообщение об ошибке) должен быть выведен в отдельном окне. Если же результат, о котором требуется сообщить пользователю, просто текущая информация о процессе, и не является прямым следствием действий пользователя, то в данном случае можно ограничиться отображением соответствующего сообщения в строке состояния.
Часто реакция на одно и то же действие различается именно в зависимости от того, кем это действие произведено. Пример — функция автоматической загрузки своих новых версий по Интернету, имеющаяся во многих программах. Если пользователь самостоятельно отдает команду проверить наличие обновлений, то обычно после этого пользователю демонстрируется диалоговое окно, где отображаются результаты проверки — вне зависимости от того, были результаты проверки отрицательными или положительными. Если же такая проверка выполняется автоматически (например, при каждом запуске программы), то обычно пользователю сообщается информация, что обнаружена новая версия продукта. Сообщения о том, что новая версия программы не найдена, или сообщения об ошибках обычно не выводятся, чтобы не отвлекать пользователя от работы и не раздражать его.
Помимо текстовых сообщений, выводящихся в окне программы, для организации обратной связи могут быть использованы и другие средства. Самое популярное из них — звук. Звуковое оповещение может быть полезным в самых различных ситуациях. Наиболее часто звук помогает тогда, когда появление на экране модальных окон нежелательно, а сообщения в статусной строке могут быть не замечены (например, если главное окно программы, как таковое, отсутствует). Это является типичным, например, для утилит, периодически проверяющих e-mail-ящики на наличие свежей почты. Другое полезное применение звука — оповещение пользователя, находящегося не за компьютером, а где-то поблизости. Также звуковое сопровождение окажет помощь пользователям с ограниченными возможностями (например, с плохим зрением).
Важно помнить, что звуковое оповещение не должно быть основным средством организации обратной связи. Звук должен лишь дополнять текстовые сообщения. Иначе пользователь может пропустить сообщение -- ведь на компьютере может отсутствовать звуковая карта или звук может быть отключен. Таким образом, исчезнет единственное средство организации обратной связи, и работа с программой станет очень неудобной или вообще невозможной. Интересно, что эта особенность интерфейса специально используется некоторыми shareware-авторами для стимуляции пользователей оплачивать регистрации. Например, в незарегистрированной версии программы получения сообщений по сети Vypress Auvis (http://www.vypress.cora) оповещение о приходящих сообщениях с помощью всплывающих окон отключено — до регистрации можно пользоваться только звуковым оповещением. Как следствие, работа с программой становится очень некомфортной, т. к. основная область ее применения — локальные офисные сети, где количество компьютеров, не оснащенных звуковыми картами, довольно велико.
Среди других средств организации обратной связи можно упомянуть запись сообщений в log-файл, отправку сообщений по e-mail. Естественно, они применяются в качестве дополнительных способов оповещения — например, для сбора статистики или доступа удаленных пользователей, подключающихся к системе по каналам связи.
Время оповещения
Промежуток времени, в который пользователь получает информацию о реакции на его действие или о событии, должен быть минимальным. Это особенно важно, т. к. от наличия или отсутствия у пользователя информации о текущем состоянии системы определяет его дальнейшие действия. Если он не будет знать, что последняя операция была завершена неудачно, то последующие действия могут вызвать новые ошибки.
При разработке большинства приложений обеспечение мгновенной реакции на события и действия пользователя не представляет никакой сложности. Однако в некоторых случаях это может быть затруднительным. Например, один программист, специализирующийся на разработке сложных приложений для Web-серверов, рассказывал, что многие пользователи просят дополнить существующий Web-интерфейс (формы с элементами управления на Web-странице) e-mail-интерфейсом — т. е. возможностью управлять системой с помощью сообщений электронной почты. Техническая реализация этого не представляет никакой сложности, однако это ставит под угрозу стабильность работы системы. Дело в том, что при управлении серверным программным обеспечением посредством e-mail, проходит немало времени между моментом отправки письма и моментом его обработки на сервере. При обнаружении ошибки (например, запрос пользователя был сформулирован неправильно) сервер высылает пользователю письмо, которое будет получено пользователем еще через некоторое время. Таким образом, время оповещения становится слишком большим, чтобы можно было уверенно работать со сложным серверным приложением, где любая операция должна осуществляться только с учетом того, что все предыдущие завершены успешно.
Равенство между системой и реальным миром
Система должна разговаривать с пользователем на его языке. Имеется в виду не язык его страны, хотя это тоже имеет значение. В данном случае подразумевается использование понятий, образов и целых концепций, которые уже знакомы пользователю по реальному миру, к которым он привык. Представление информации и объектов в программе должно быть организовано в естественном и логичном порядке.
Ни в коем случае нельзя использовать специализированные термины. Многие авторы даже при разработке приложений, ориентированных на широкую аудиторию, применяют понятия, которые годятся только для профессиональных справочников по программированию.
Самый распространенный пример реализации этого принципа — построение интерфейсов, имитирующих объекты реального мира. Часы, калькуляторы, проигрыватели компакт-дисков, записные книжки — большинство из программ, осуществляющих эти функции, выглядят почти точно так же, как их материальные аналоги. А знаменитая Мусорная корзина на Рабочем столе Windows или Macintosh, в которую можно "бросить" ненужный файл или папку — почти хрестоматийный пример построения интерфейса на основе объектов реального мира. Да и сам способ "перетащи и брось" (Drag-and-Drop) — прекрасная иллюстрация этого принципа, абсолютно естественная операция даже для тех пользователей, кто впервые сел за компьютер.
Однако такое заимствование идей из окружающего мира нужно производить очень осторожно. Дело в том, что программы, которые уже знакомы пользователю — тоже часть его мира, часть его знаний, навыков и привычек. Поэтому некоторые детали компьютерных интерфейсов являются для пользователей более привычными, чем объекты реального мира — это особенно касается элементов интерфейса, реализующих функции, не имеющих прямых аналогов в реальном мире. В качестве примера можно привести известный мультимедийный проигрыватель WinAmp. Для управления воспроизведением музыкальных композиций программа использует кнопки Play, Stop, Pause и др., очень напоминающие аналогичные по назначению кнопки на проигрывателях, стоящих в наших квартирах. Но вот кнопка, расположенная справа от них, которая на "настоящем" аппарате открывает лоток CD-плейера, в WinAmp, вопреки ожиданиям, не открывает лоток CD-ROM-дисковода, а вызывает окно Открыть файл. Это несколько сбивает с толку, т. к. в очень многих аналогичных компьютерных программах такая кнопка как раз служит для открытия/закрытия лотка дисковода CD-ROM.
Поэтому интерфейсы, которые полностью, т. е. без всяких исключений, копируют объекты реального мира, почти всегда в результате получаются не очень удобными, т. к. пользователь тратит довольно много времени, пытаясь освоить абсолютно новый интерфейс. Например, эксперимент компании IBM в области интерфейсов, использующих в качестве своей основы модели реальных материальных объектов — программа Real Phone, считается полным провалом: число проблем, возникающих при освоении "реального телефона", очень велико.
А вот дизайн популярной программы Lotus Organizer, наоборот, считается классическим примером удачного заимствования объектов реального мира. Главное окно программы выполнено в виде ежедневника с закладками — объекта, к которому пользователи уже давно привыкли. Но, тем не менее, в окне Lotus Organizer присутствуют традиционные, чисто "компьютерные" элементы — кнопочная панель инструментов и меню. Дело как раз в слове "традиционный" - - к панели кнопок и меню пользователи давно уже привыкли, и это помогает им быстро освоить программу. А если бы дизайнеры Lotus в своих экспериментах пошли дальше и заменили бы меню и панель кнопок на, скажем, изображение офисного шкафа с парой десятков ящиков и полочек, то интерфейс программы стал бы громоздким и запутанным.
Свобода действий пользователя
Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Очень часто пользователь дает различные команды по ошибке (например, случайно нажав не ту кнопку или "промахнувшись" мышью мимо нужного пункта меню), и у него должен быть "аварийный выход" из этой ситуации, четко обозначенный в программе. Чаще всего такой "выход" реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Кроме этого, нажатие на клавиатуре клавиши <Escape> является традиционным и поэтому привычным для большинства пользователей средством "аварийного выхода". Характерно, что "escape" в переводе с английского означает "побег, уход". Оно также незаменимо тогда, когда кнопка Cancel (Отмена) недоступна — чаще всего в Главном окне приложения, ведь размещение кнопок OK, Cancel, Help и других здесь, в отличие от диалоговых окон, не допускается. В частности, Microsoft Word при выполнении трудоемких и продолжительных по времени операций, например чтения очень больших файлов, выводит в строку состойния индикатор, отображающий ход процесса и сообщение: "Для отмены нажмите <Escape>. Клавиша <Escape> аналогично работает и в Adobe Photoshop, позволяя прервать загрузку большого файла или выполнение сложного фильтра, и во многих других приложениях.
Хорошим тоном считается, если позволяет текущая ситуация, сочетать оба эти способа — кнопку Cancel (Отмена) и клавишу <Escape>: современные системы разработки приложений для Windows при проектировании форм диалоговых окон позволяют назначить кнопке свойство срабатывания по нажатию клавиши <Escape>. Как следствие, для пользователя привычным действием при попадании в ситуацию, из которой ему поскорее хочется выбраться, является именно нажатие клавиши <Escape>. Что может быть проще: не нужно искать глазами какую-то там кнопку Cancel (Отмена), достаточно ударить по клавише в верхнем левом углу клавиатуры — и готово!
Еще одно, причем немаловажное, средство выхода из ошибочной ситуации — функции Undo (Отменить) и Redo (Повторить). Они являются настолько удобными и поддерживаются таким большим количеством программ, что пользователи уже привыкли к ним и подсознательно ожидают, что любое произведенное действие можно отменить, вернувшись к предыдущему состоянию. Функция Undo (Повторить) даже стала предметом многих шуток и историй о том, как привыкший к компьютеру человек, в реальном мире разбив далеко не виртуальную вазу, или сделав ошибку в простом, "бумажном", письме, непроизвольно ищет кнопку Undo (Отменить).
Все это просто обязывает разработчика качественного интерфейса компьютерной программы поддерживать функции Undo и Redo. Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно будет выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.
Последовательность и стандарты
Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Принцип последовательности при разработке интерфейсов должен соблюдаться буквально во всем.
Во-первых, последовательность при выборе средств оповещения о событиях и действиях. Например, информация о текущем статусе программы, как уже говорилось при рассмотрении принципа "Видимость состояния системы", обычно выводится в статусную строку в нижней части экрана, а сообщения с результатами запросов пользователя — в отдельном диалоговом окне. Сообщения о критических ошибках при этом должны сильно отличаться от обычных информационных сообщений: например, они могут сопровождаться резким звуком.
Во-вторых, последовательность при оформлении элементов интерфейса. Если дизайн форм вашей программы основан на классическом интерфейсе 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" (простой обучающей программы) до дизайна форм.
Основы построения интерфейсов
Когда говорят о научных основах проектирования пользовательских интерфейсов, в первую очередь упоминают термин 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 "Блокнот" стал более дружественен к пользователю.
Другой пример недооценки возможностей пользователя — вывод информационных сообщений в ситуациях, когда этого не требуется. Многие авторы наделяют свои программы излишней "болтливостью" из благих намерений — например, для того, чтобы облегчить освоение продукта или информировать пользователей о полезных функциях программы. Однако вполне может оказаться так, что пользователь уже достаточно уверенно чувствует себя при работе с программой и не нуждается в подсказках, выскакивающих каждую минуту, а некоторые полезные, с точки зрения автора программного продукта, функции для конкретного пользователя таковыми не являются. Поэтому среди разработчиков программного обеспечения хорошим тоном считается предоставление пользователю возможности отключить вывод информационных сообщений. Это позволяет сохранить легкость освоения продукта для начинающих пользователей и одновременно с этим добиться, чтобы информационные сообщения не вызывали у опытных пользователей раздражения.
И, наконец, третий принцип - "Программа должна работать так, чтобы пользователь не считал компьютер дураком".
Несмотря на стремительное развитие информационных технологий, многие компьютерные программы все еще имеют примитивный искусственный интеллект. Они прерывают работу пользователя глупыми вопросами и выводят на экран бессмысленные сообщения, повергая его в недоумение в самых простых ситуациях. В результате многие люди, работающие с компьютерами, раздраженно восклицают: "Как мне надоела эта тупая машина!"
Примечание
Конечно, искусственный интеллект компьютерных программ в основном зависит от усилий их авторов, а не характеристик аппаратного обеспечения. Однако у большинства пользователей компьютер ассоциируется именно с программами, которые на нем работают, и плохое впечатление от использования программного обеспечения автоматически переносится на сам компьютер.
Примеров таких неудачных решений в области интерфейсов существует очень много — как среди продуктов известных компаний, так и среди программ мелких разработчиков. Вот один из них: система управления базами данных Microsoft Access запрашивает у пользователя подтверждение обновления информации в таблице. Все бы хорошо, если бы не бессмысленность этого сообщения: обновления данных все равно не будет в любом случае, т. к. количество строк, в которых были изменены данные, равно нулю.
А этот пример особенно часто приводится в качестве иллюстрации к рассказу о "тупых" интерфейсах. Утилита преобразования текстовых файлов, включенная в Microsoft Word, способна распознать формат открываемого файла. Но, тем не менее, она просит пользователя подтвердить, что структура файла была определена правильно. Во многих случаях (например, когда человек открывает файл, созданный не им, или просто при недостатке знаний) он не может указать, каков формат файла на самом деле. Но, т. к. его все-таки просят сделать выбор, он начинает колебаться, выбирать из списка другие форматы, что приводит к некорректным результатам.
Еще один известный пример интерфейса, который дает повод поразиться "глупости" компьютера. Если в текстовом редакторе WordPad открыть обыкновенный текстовый файл и, даже ничего в нем не меняя, попробовать сохранить его, то программа сообщит, что такая операция "приведет к потере форматирования". Особую пикантность этой ситуации придает тот факт, что в текстовом (ASCII) файле какое-либо форматирование отсутствует изначально.
Есть и откровенно дурацкие сообщения, которые заставляют задуматься, почему современный мощный компьютер стоимостью несколько сотен долларов обладает интеллектом простого калькулятора. Впрочем, очень часто такие сообщения вызваны ошибками в самой программе.
Нужно заметить, что, как и в любой другой науке, принципы построения интерфейсов компьютерных программ тесно взаимосвязаны. Нарушение одного правила почти наверняка повлечет нарушение и другого. Например, если при работе пользователя с программой на экране появилось сообщение заставляющее усомниться в том, что компьютер может справиться со своими функциями (третий принцип), то о соблюдении первого принципа (прозрачность интерфейса) говорить тоже не приходится, т. к. вместо того, чтобы продолжить работу, человек вынужден теряться в догадках: "Что бы это значило?"
Эвристические правила Якоба Нильсена
Три основных принципа проектирования интерфейсов компьютерных программ, о которых я рассказал в предыдущем разделе, являются, безусловно, чрезвычайно полезными и эффективными, все же они представляют собой довольно общие правила. Далеко не каждый, а уж тем более начинающий разработчик интерфейсов, сможет качественно выполнить свою задачу, руководствуясь только ими. Требуются более конкретизированные правила, которые давали бы развернутую картину стратегии построения интерфейсов.
Одними из самых цитируемых в книгах по HCI являются десять так называемых эвристических правил известнейшего американского специалиста в области проектирования интерфейсов Якоба Нильсена (Jakob Nielsen), разработанных им совместно с другим исследователем, Рольфом Моличем (Rolf Molich). Формулировку этих принципов в оригинале можно прочитать по адресу http://www.useit.com/papers/heuristic/heuristic_list.html. Это десять главных заповедей любого разработчика компьютерных интерфейсов, т. е. минимальные критерии, которым должен отвечать интерфейс любой программы.
Видимость состояния системы (правило обратной связи)
Система (в данном случае — компьютерная программа) должна всегда информировать пользователя о состоянии своей работы с помощью соответствующих средств, в разумное время. При рассмотрении этого правила нужно учитывать несколько аспектов.
Информированность пользователя
Пользователь всегда должен иметь информацию о текущем статусе работы программы — например, сколько времени прошло от начала процесса копирования файлов, когда будет завершено кодирование звуковой дорожки CD-диска в МРЗ-файл и т. п. Кроме этого, пользователь обязательно должен видеть, к чему привело любое его действие: ввод данных, нажатие кнопки и т. п.
Средства обеспечения обратной связи
Выбор конкретного средства обратной связи зависит от типа информации, которую нужно донести до пользователя, а также типа действия, которое вызывает потребность в обратной связи.
Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках — в статусной строке окна приложения без остановки его работы. Характерен пример браузера Microsoft Explorer: если открыть запрашиваемую Web-страницу в данный момент невозможно (например, отсутствует соединение с Интернетом), то на экране появляется модальное окно с сообщением о критической ошибке. Если же страница была успешно загружена, но при этом возникли незначительные ошибки, то соответствующее сообщение отображается в строке состояния программы.
Что касается зависимости выбора средства обратной связи от типа действия, вызывающего ее, то традиционно считается, что если пользователь сделал какое-то действие -- например, запустил процесс кодирования большого файла или дал команду подсчитать количество знаков в тексте, — и ожидает какого-то результата, то этот результат (или сообщение об ошибке) должен быть выведен в отдельном окне. Если же результат, о котором требуется сообщить пользователю, просто текущая информация о процессе, и не является прямым следствием действий пользователя, то в данном случае можно ограничиться отображением соответствующего сообщения в строке состояния.
Часто реакция на одно и то же действие различается именно в зависимости от того, кем это действие произведено. Пример — функция автоматической загрузки своих новых версий по Интернету, имеющаяся во многих программах. Если пользователь самостоятельно отдает команду проверить наличие обновлений, то обычно после этого пользователю демонстрируется диалоговое окно, где отображаются результаты проверки — вне зависимости от того, были результаты проверки отрицательными или положительными. Если же такая проверка выполняется автоматически (например, при каждом запуске программы), то обычно пользователю сообщается информация, что обнаружена новая версия продукта. Сообщения о том, что новая версия программы не найдена, или сообщения об ошибках обычно не выводятся, чтобы не отвлекать пользователя от работы и не раздражать его.
Помимо текстовых сообщений, выводящихся в окне программы, для организации обратной связи могут быть использованы и другие средства. Самое популярное из них — звук. Звуковое оповещение может быть полезным в самых различных ситуациях. Наиболее часто звук помогает тогда, когда появление на экране модальных окон нежелательно, а сообщения в статусной строке могут быть не замечены (например, если главное окно программы, как таковое, отсутствует). Это является типичным, например, для утилит, периодически проверяющих e-mail-ящики на наличие свежей почты. Другое полезное применение звука — оповещение пользователя, находящегося не за компьютером, а где-то поблизости. Также звуковое сопровождение окажет помощь пользователям с ограниченными возможностями (например, с плохим зрением).
Важно помнить, что звуковое оповещение не должно быть основным средством организации обратной связи. Звук должен лишь дополнять текстовые сообщения. Иначе пользователь может пропустить сообщение -- ведь на компьютере может отсутствовать звуковая карта или звук может быть отключен. Таким образом, исчезнет единственное средство организации обратной связи, и работа с программой станет очень неудобной или вообще невозможной. Интересно, что эта особенность интерфейса специально используется некоторыми shareware-авторами для стимуляции пользователей оплачивать регистрации. Например, в незарегистрированной версии программы получения сообщений по сети Vypress Auvis (http://www.vypress.cora) оповещение о приходящих сообщениях с помощью всплывающих окон отключено — до регистрации можно пользоваться только звуковым оповещением. Как следствие, работа с программой становится очень некомфортной, т. к. основная область ее применения — локальные офисные сети, где количество компьютеров, не оснащенных звуковыми картами, довольно велико.
Среди других средств организации обратной связи можно упомянуть запись сообщений в log-файл, отправку сообщений по e-mail. Естественно, они применяются в качестве дополнительных способов оповещения — например, для сбора статистики или доступа удаленных пользователей, подключающихся к системе по каналам связи.
Время оповещения
Промежуток времени, в который пользователь получает информацию о реакции на его действие или о событии, должен быть минимальным. Это особенно важно, т. к. от наличия или отсутствия у пользователя информации о текущем состоянии системы определяет его дальнейшие действия. Если он не будет знать, что последняя операция была завершена неудачно, то последующие действия могут вызвать новые ошибки.
При разработке большинства приложений обеспечение мгновенной реакции на события и действия пользователя не представляет никакой сложности. Однако в некоторых случаях это может быть затруднительным. Например, один программист, специализирующийся на разработке сложных приложений для Web-серверов, рассказывал, что многие пользователи просят дополнить существующий Web-интерфейс (формы с элементами управления на Web-странице) e-mail-интерфейсом — т. е. возможностью управлять системой с помощью сообщений электронной почты. Техническая реализация этого не представляет никакой сложности, однако это ставит под угрозу стабильность работы системы. Дело в том, что при управлении серверным программным обеспечением посредством e-mail, проходит немало времени между моментом отправки письма и моментом его обработки на сервере. При обнаружении ошибки (например, запрос пользователя был сформулирован неправильно) сервер высылает пользователю письмо, которое будет получено пользователем еще через некоторое время. Таким образом, время оповещения становится слишком большим, чтобы можно было уверенно работать со сложным серверным приложением, где любая операция должна осуществляться только с учетом того, что все предыдущие завершены успешно.
Равенство между системой и реальным миром
Система должна разговаривать с пользователем на его языке. Имеется в виду не язык его страны, хотя это тоже имеет значение. В данном случае подразумевается использование понятий, образов и целых концепций, которые уже знакомы пользователю по реальному миру, к которым он привык. Представление информации и объектов в программе должно быть организовано в естественном и логичном порядке.
Ни в коем случае нельзя использовать специализированные термины. Многие авторы даже при разработке приложений, ориентированных на широкую аудиторию, применяют понятия, которые годятся только для профессиональных справочников по программированию.
Самый распространенный пример реализации этого принципа — построение интерфейсов, имитирующих объекты реального мира. Часы, калькуляторы, проигрыватели компакт-дисков, записные книжки — большинство из программ, осуществляющих эти функции, выглядят почти точно так же, как их материальные аналоги. А знаменитая Мусорная корзина на Рабочем столе Windows или Macintosh, в которую можно "бросить" ненужный файл или папку — почти хрестоматийный пример построения интерфейса на основе объектов реального мира. Да и сам способ "перетащи и брось" (Drag-and-Drop) — прекрасная иллюстрация этого принципа, абсолютно естественная операция даже для тех пользователей, кто впервые сел за компьютер.
Однако такое заимствование идей из окружающего мира нужно производить очень осторожно. Дело в том, что программы, которые уже знакомы пользователю — тоже часть его мира, часть его знаний, навыков и привычек. Поэтому некоторые детали компьютерных интерфейсов являются для пользователей более привычными, чем объекты реального мира — это особенно касается элементов интерфейса, реализующих функции, не имеющих прямых аналогов в реальном мире. В качестве примера можно привести известный мультимедийный проигрыватель WinAmp. Для управления воспроизведением музыкальных композиций программа использует кнопки Play, Stop, Pause и др., очень напоминающие аналогичные по назначению кнопки на проигрывателях, стоящих в наших квартирах. Но вот кнопка, расположенная справа от них, которая на "настоящем" аппарате открывает лоток CD-плейера, в WinAmp, вопреки ожиданиям, не открывает лоток CD-ROM-дисковода, а вызывает окно Открыть файл. Это несколько сбивает с толку, т. к. в очень многих аналогичных компьютерных программах такая кнопка как раз служит для открытия/закрытия лотка дисковода CD-ROM.
Поэтому интерфейсы, которые полностью, т. е. без всяких исключений, копируют объекты реального мира, почти всегда в результате получаются не очень удобными, т. к. пользователь тратит довольно много времени, пытаясь освоить абсолютно новый интерфейс. Например, эксперимент компании IBM в области интерфейсов, использующих в качестве своей основы модели реальных материальных объектов — программа Real Phone, считается полным провалом: число проблем, возникающих при освоении "реального телефона", очень велико.
А вот дизайн популярной программы Lotus Organizer, наоборот, считается классическим примером удачного заимствования объектов реального мира. Главное окно программы выполнено в виде ежедневника с закладками — объекта, к которому пользователи уже давно привыкли. Но, тем не менее, в окне Lotus Organizer присутствуют традиционные, чисто "компьютерные" элементы — кнопочная панель инструментов и меню. Дело как раз в слове "традиционный" - - к панели кнопок и меню пользователи давно уже привыкли, и это помогает им быстро освоить программу. А если бы дизайнеры Lotus в своих экспериментах пошли дальше и заменили бы меню и панель кнопок на, скажем, изображение офисного шкафа с парой десятков ящиков и полочек, то интерфейс программы стал бы громоздким и запутанным.
Свобода действий пользователя
Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Очень часто пользователь дает различные команды по ошибке (например, случайно нажав не ту кнопку или "промахнувшись" мышью мимо нужного пункта меню), и у него должен быть "аварийный выход" из этой ситуации, четко обозначенный в программе. Чаще всего такой "выход" реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Кроме этого, нажатие на клавиатуре клавиши <Escape> является традиционным и поэтому привычным для большинства пользователей средством "аварийного выхода". Характерно, что "escape" в переводе с английского означает "побег, уход". Оно также незаменимо тогда, когда кнопка Cancel (Отмена) недоступна — чаще всего в Главном окне приложения, ведь размещение кнопок OK, Cancel, Help и других здесь, в отличие от диалоговых окон, не допускается. В частности, Microsoft Word при выполнении трудоемких и продолжительных по времени операций, например чтения очень больших файлов, выводит в строку состойния индикатор, отображающий ход процесса и сообщение: "Для отмены нажмите <Escape>. Клавиша <Escape> аналогично работает и в Adobe Photoshop, позволяя прервать загрузку большого файла или выполнение сложного фильтра, и во многих других приложениях.
Хорошим тоном считается, если позволяет текущая ситуация, сочетать оба эти способа — кнопку Cancel (Отмена) и клавишу <Escape>: современные системы разработки приложений для Windows при проектировании форм диалоговых окон позволяют назначить кнопке свойство срабатывания по нажатию клавиши <Escape>. Как следствие, для пользователя привычным действием при попадании в ситуацию, из которой ему поскорее хочется выбраться, является именно нажатие клавиши <Escape>. Что может быть проще: не нужно искать глазами какую-то там кнопку Cancel (Отмена), достаточно ударить по клавише в верхнем левом углу клавиатуры — и готово!
Еще одно, причем немаловажное, средство выхода из ошибочной ситуации — функции Undo (Отменить) и Redo (Повторить). Они являются настолько удобными и поддерживаются таким большим количеством программ, что пользователи уже привыкли к ним и подсознательно ожидают, что любое произведенное действие можно отменить, вернувшись к предыдущему состоянию. Функция Undo (Повторить) даже стала предметом многих шуток и историй о том, как привыкший к компьютеру человек, в реальном мире разбив далеко не виртуальную вазу, или сделав ошибку в простом, "бумажном", письме, непроизвольно ищет кнопку Undo (Отменить).
Все это просто обязывает разработчика качественного интерфейса компьютерной программы поддерживать функции Undo и Redo. Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно будет выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.
Последовательность и стандарты
Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Принцип последовательности при разработке интерфейсов должен соблюдаться буквально во всем.
Во-первых, последовательность при выборе средств оповещения о событиях и действиях. Например, информация о текущем статусе программы, как уже говорилось при рассмотрении принципа "Видимость состояния системы", обычно выводится в статусную строку в нижней части экрана, а сообщения с результатами запросов пользователя — в отдельном диалоговом окне. Сообщения о критических ошибках при этом должны сильно отличаться от обычных информационных сообщений: например, они могут сопровождаться резким звуком.
Во-вторых, последовательность при оформлении элементов интерфейса. Если дизайн форм вашей программы основан на классическом интерфейсе Windows-приложений, характеризующемся строгой цветовой гаммой, прямыми линиями и углами, то очень странным выглядело бы решение придать одному из окон программы овальную форму и раскрасить его яркими цветами. Увы, но такие случаи не редкость.
В-третьих, последовательность при выборе терминов. Пользователей не должно сбивать с толку то, что три разных понятия, используемых в вашей программе, на самом деле означают одно и то же. И дело даже не в том, чтобы подобрать наиболее точное определение какому-либо термину. Главное — решить для себя, что для обозначения какого-то конкретного действия или события вы будете применять один конкретный термин, при этом будете использовать его четко определенным способом (например, слово "Интернет" вы будете писать с прописной буквы и склоняя), и в ходе работы над программой от этого правила не отступать. Это можно назвать своеобразной разработкой собственного стандарта
Принцип последовательности — одно из важнейших правил проектирования пользовательских интерфейсов. Последовательный интерфейс интуитивно понятен и очень легок для освоения, т. к. при его изучении пользователь не сталкивается с сюрпризами, и даже те части интерфейса, которые он видит впервые, кажутся ему давно знакомыми. Если же в одних и тех же ситуациях программа реагирует по-разному, элементы управления в формах имеют различную компоновку, а текстовые сообщения удивляют все новыми и новыми терминами, то вся программа станет для пользователя одним сплошным сюрпризом.
Администратор
Сообщений: 484
Нет на сайте
Предупреждение ошибок
Этот принцип широко распространен и в обычной жизни, вне сферы компьютеров и интерфейсов для них. "Пожар легче предупредить, чем потушить" - гласил один из плакатов, изданных в конце девяностых годов Министерством внутренних дел для обучения людей технике пожарной безопасности. "Преступление легче предупредить, чем раскрыть" -- гласит одно из правил науки криминологии.
Применительно к теме проектирования интерфейсов компьютерных программ, принцип предупреждения ошибок означает следующее: "Дизайн, который предупреждает возникновение проблем, лучше, чем самое хорошее сообщение об ошибке".
Интерфейс, предупреждающий возникновение ошибок и связанных с ними проблем, образно называют "услужливым". Программа как бы заботится о пользователе, будучи всегда готовой предложить пользователю помощь, дать подсказку.
Кроме того, уменьшение вероятности возникновения ошибок пользователя при работе с программой достигается тщательной проработкой всех элементов интерфейса и его концепции в целом в соответствии с правилами проектирования интерфейсов. Интуитивно понятный, легкий для освоения интерфейс у большинства пользователей не вызывает никаких затруднений.
Принцип предупреждения ошибок, хотя и упоминается Якобом Нильсеном в списке его эвристических правил пятым по счету, по моему мнению, должен быть указан в нем последним, т. к. он имеет значение принципа, обобщающего все остальные правила. Ведь интерфейс, предупреждающий возникновение ошибок и проблем, должен информировать пользователя о статусе программы, давать ему контроль над работой приложения, общаться с пользователем на понятном ему языке, соответствовать принципу последовательности и т. д.
Понимание лучше, чем запоминание
При разработке интерфейса нужно делать все объекты, функции, действия видимыми и легко доступными пользователю. Минимизируйте запоминание — пользователь не должен постоянно стараться удержать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент пользователю должно быть ясно, что нужно делать в данный момент. В хорошем интерфейсе инструкции по использованию системы всегда видимы или легко доступны для вызова в любое время, когда это требуется. Это может быть реализовано как в виде продуманной организации элементов интерфейса, так и непосредственно в виде подсказок пользователю. Хороший и очень известный пример — анимированная надпись, которая появляется на панели задач Windows и "подъезжает" к кнопке Пуск: "Начните работу с нажатия этой кнопки".
Это правило отражает принцип прозрачного интерфейса — интерфейса, который понятен и не заставляет пользователя вспоминать, какую же кнопку нужно нажать или какой пункт меню выбрать в данный момент.
Гибкость и эффективность использования
Правило вполне закономерное, ведь программа в первую очередь должна решать задачу (см. разд. "Основы построения интерфейсов" данной главы), над которой работает пользователь. Однако при проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Но нужно учитывать, это во многом разные потребители, с разными требованиями к программе и разным стилем работы. Если сделать простой интерфейс с минимумом опций, который будет легок для освоения новичками, то более опытные пользователи не смогут работать с программой достаточно эффективно, чтобы удовлетворять свои потребности.
Для решения этой проблемы прибегают к простому приему: функции, которые ускоряют работу, оформлены так, что они не видны начинающим, но легко доступны продвинутым пользователям. Самый простой пример — это "горячие клавиши", с помощью которых можно быстро вызвать часто выполняющиеся функции программы, в частности открытие и сохранение файлов. Обозначения "горячих клавиш" пишутся рядом с соответствующими пунктами меню, поэтому они, с одной стороны, не мешают новичкам (они могут воспользоваться мышью для выбора пункта меню или щелчка по кнопке на панели инструментов), а, с другой стороны, легко доступны опытным пользователям.
Разработчики системы программирования Microsoft Quick Basic, которая была очень популярна еще в восьмидесятых и начале девяностых годов, пошли еще дальше: они предусмотрели два варианта главного меню приложения: полный и сокращенный, между которыми можно переключаться одним щелчком.
Другой пример реализации универсального "интерфейса для каждого" — возможность выполнить сложные функции программы как с помощью Мастера, который, словно за руку, проведет начинающего пользователя по всем этапам процесса, так и вручную, посредством настройки опций в соответствующем диалоговом окне.
Еще одна составляющая часть правила "Гибкость и эффективность использования" — необходимость предоставлять пользователю возможность быстрого выполнения частых действий. Варианты реализации этого очень разнообразны: это и уже упоминавшиеся "горячие клавиши", и команды для вызова последних открывавшихся файлов, и меню, в которых сначала показываются наиболее часто выполняющиеся команды, и макросы, и даже целые языки программирования, встраиваемые в приложения, наподобие Visual Basic for Applications в продуктах семейства Microsoft Office.
Эстетичный и минималистический дизайн
Если выразиться проще, то это правило означает: "Ничего лишнего". Не нужно загромождать интерфейс программы элементами, которые в данном случае являются неуместными и малополезными. Дело в том, что каждый элемент, будь то кнопка или текстовая подпись, обязательно отвлекает часть внимания пользователя. Это может привести к тому, что видимость и, соответственно, легкость восприятия пользователем действительно нужных и полезных частей интерфейса будет сильно уменьшена за счет элементов, без которых в данном случае можно было бы вполне обойтись.
Распознавание и исправление ошибок
"Помогайте пользователю, распознавать и исправлять ошибки" - говорит Якоб Нильсен. Это правило определяет проектирование сообщений об ошибках. Хорошие сообщения об ошибках — это сообщения, которые объясняют, в чем состоит проблема и, самое главное, как ее исправить. Таким образом, хорошее сообщение об ошибке должно состоять из двух частей.
Описание ошибки
Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки. Многие разработчики программ опасаются делать сообщения об ошибках очень информативными, чтобы не "пугать" начинающих пользователей техническими подробностями. Однако в этом случае нарушается описанный выше принцип гибкости и эффективности использования: опытные пользователи, получив слишком краткое сообщение об ошибке, не могут выяснить ее причину. А программа, в которой появляются какие-то непонятные ошибки, в конце концов начинает производить впечатление некачественной поделки.
Самое простое решение — создать в справочной системе программы соответствующий раздел, разъясняющий содержание проблемы и причины ее возникновения. В самом же диалоговом окне с сообщением об ошибке может присутствовать кнопка Справка для вызова этого раздела. Чисто технически реализовать это очень просто: в современных системах программирования для ее создания таких дружественных сообщений об ошибках достаточно при вызове функции MessageBox указать флаг наличия кнопки Справка и идентификатор соответствующего раздела справки. А вот составление подробных описаний ошибок, которых, к тому же, может быть очень много, для shareware-программистов гораздо более нудное и неприятное занятие.
Еще один пример решения, причем более изящного, данной проблемы является кнопка Подробнее, при нажатии на которую диалоговое окно с сообщением об ошибке "распахивается", отображая более подробную информацию о причине возникновения сбоя. Так, например, организованы многие сообщения об ошибках в 32-разрядных версиях Windows, самое известное из которых - "Программа выполнила недопустимую операцию и будет закрыта". За кнопкой Подробнее в этом сообщении скрывается имя программы-виновника, а также адрес места возникновения ошибки.
Замечание
Обратите внимание, что даже в "распахивающихся" сообщениях об ошибках, несмотря на то, что в них присутствует подробная информация, все равно должна присутствовать кнопка Справка для вызова раздела справочной системы с описанием соответствующей ошибки. Это необходимо потому, что обращение к справочной системе программы является более привычным для пользователя, чем менее распространенные "распахивающиеся" диалоговые окна.
К сожалению, такие изящные сообщения об ошибках в прикладных программах для Windows встречаются не очень часто, т. к. их включение требует хотя и несложной, но кропотливой работы.
Очень важно помнить то, что сообщение об ошибке должно содержать ее описание нормальным человеческим языком. Некоторые программисты совершенно серьезно считают, что такие лаконичные сообщения, в стиле известного в Интернете "Error 216", производят на пользователя неизгладимое впечатление: чем "загадочнее" программа, тем она сложнее и, в конечном итоге, "круче". Но, на самом деле, эффект сродни тому, что был уже описан выше: непонятные ошибки возникают только в некачественных поделках.
При составлении описаний ошибок нужно не забывать проверять правильность сообщений, генерируемых программой. На первый взгляд, это правило относится к разряду само собой разумеющихся вещей, однако многие авторы этим пренебрегают. В результате существует много программ, в которых сообщения об ошибках "врут" пользователю, рапортуя совсем не о тех проблемах, которые возникли на самом деле. Промашки в этом деле допускают даже программисты крупных компаний. Например, рекомендуется с осторожностью относиться к сообщениям об ошибках Windows, т. к. система не всегда правильно идентифицирует возникшие проблемы и вводит пользователей в заблуждение.
Описание решения проблемы
Как уже упоминалось выше, информация о том, как исправить ошибку или решить проблему имеет даже большее значение, чем собственно описание ошибки или проблемы. Ведь подсказка, помогающая решить проблему, способствует реализации одного из принципов построения пользовательского интерфейса — программа должна помогать выполнить задачу, а не становиться этой задачей.
Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. Дело в том, что не все пользователи догадываются нажать спасительную кнопку Справка, хотя это было бы вполне естественным ходом (как известно, в английских версиях Windows в этих случаях используется слово "Help" - "Помощь").
При описании пути решения проблемы, как и при написании любой документации, нужно избегать составления слишком объемных текстов, т. к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Лучше всего составить что-то наподобие пошаговой инструкции, каждый шаг из которой составляет 1—2 предложения.
Справка и документация
Принцип о необходимости предоставления справочной системы и документации к программе, идущий в списке Якоба Нильсена последним, не становится от этого менее важным. Составлению справочных систем для shreware-программ в этой книге посвящена отдельная, седьмая, глава.
Другие принципы построения интерфейсов
Конечно, помимо эвристических правил Якоба Нильсена, тех минимальных требований, которым должен удовлетворять интерфейс любой программы, существует довольно большое число принципов создания интерфейсов, о которых в своих трудах говорят специалисты, причем специалисты не только в области дизайна интерфейса. Ведь при проектировании интерфейсов применяются данные психологии, геометрии и других наук. Эти принципы, хотя и не обязательны при проектировании интерфейсов, но при их реализации программа будет выглядеть гораздо более выигрышно.
Золотое сечение
Золотое сечение — это самая комфортная для глаза пропорция. Форма, в основе построения которой лежит сочетание симметрии и золотого сечения, способствует наилучшему зрительному восприятию и появлению ощущения красоты и гармонии.
В математике пропорцией называют равенство двух отношений: а : 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) вызывает такая, казалось бы, обыденная вещь, как вид диалогового окна Свойства. А все потому, что при его проектировании использовался именно принцип золотого сечения.
Кошелек Миллера
Этот принцип назван так в честь ученого-психолога Г. А. Миллера, который исследовал кратковременную память, проверяя выводы, сделанные ранее его коллегой, Г. Эббингаузом. Эббингауз пытался выяснить, сколько информации может запомнить человек без каких-либо специальных мнемонических приемов. Оказалось, что емкость памяти ограничена семью цифрами, семью буквами или названиями семи предметов. Это "магическое число" семь, служащее своего рода меркой памяти, и было проверено Миллером, который показал, что память действительно в среднем не может хранить более семи элементов; в зависимости от сложности элементов это число может колебаться в пределах от пяти до девяти.
Если необходимо в течение короткого времени сохранить информацию, включающую больше семи элементов, мозг почти бессознательно группирует эту информацию таким образом, чтобы число запоминаемых элементов не превышало предельно допустимого. Например, номер банковского счета 30 637 402 710, состоящий из одиннадцати элементов, будет, скорее всего, запоминаться как 30 63 740 27 10, т. е. как пять числовых элементов, или восемь слов (тридцать, шестьдесят, три, семьсот, сорок, двадцать, семь, десять).
Применяя принцип кошелька Миллера в дизайне интерфейсов, следует группировать элементы в программе (кнопки на панелях инструментов, пункты меню, закладки, опции на этих закладках и т. п.) с учетом этого правила— т. е. не более семи в группе, в крайнем случае — девяти. Взгляните, например, на главное окно программы-словаря ABBYY Lingvo 6.0: четырнадцать кнопок на верхней панели, между которыми нет ни одного разделителя, воспринимаются гораздо хуже, чем кнопки на панели внизу, которые разделены на группы.
Итак, принцип кошелька Миллера говорит о семи плюс-минус двух элементах. Но если взглянуть на программы, интерфейс которых совершенствовался годами (тот же Microsoft Word), то можно заметить, что число объектов (пунктов меню, кнопок на панелях инструментов) в группах доходит до шести-семи довольно редко, а в основном элементы сгруппированы по три-четыре объекта. Такие небольшие группы объектов наиболее хорошо воспринимаются взглядом пользователя, уже слегка утомленного сложными интерфейсами современных программ. Я думаю, при проектировании интерфейсов программ верхнюю границу кошелька Миллера — семь-девять элементов — нужно применять очень осторожно, стараясь обходиться группами, содержащими максимум пять объектов.
Принцип группировки
Согласно этому правилу, экран программы должен быть разбит на ясно очерченные блоки элементов, может быть, даже с заголовком для каждого блока. При этом группировка, естественно, должна быть осмысленной: как расположение элементов в группах, так и расположение самих групп друг от друга должны быть продуманы.
Примеров реализации этого принципа очень много: это уже упоминавшиеся при разговоре о кошельке Миллера пункты меню, кнопочные панели инструментов, а также сгруппированные по назначению флажки и переключатели, с помощью которых настраиваются параметры работы программы в диалоговых окнах Свойства, Настройка и т. п.
Бритва Оккама или KISS
Философский принцип, носящий название "Бритва Оккама", гласит: "Не множить сущности без надобности". Или, как говорят американцы, KISS ("Keep It Simple, Stupid" •- "He усложняй, болван").
На языке интерфейсов это означает, что:
любая задача должна решаться минимальным числом действий;
логика этих действий должна быть очевидной для пользователя;
движения курсора и даже глаз пользователя должны быть оптимизированы.
Простым на первый взгляд требованиям из этого списка на самом деле не так уж легко следовать. Для проектирования сложного по своим функциям и простого для понимания интерфейса требуется немалые опыт, знания и особое чутье. Как пишет Лу Гринзоу: "Если и есть в мире что-то такое, что почти все программисты постоянно повторяют наизусть, как мантры, но при этом откровенно игнорируют, так это — принцип KISS".
Принцип KISS перекликается с несколькими из эвристических правил Якоба Нильсена - ''Эстетичный и минималистический дизайн", "Равенство между системой и реальным миром", "Понимание лучше, чем запоминание". KISS более универсален и применяется практически во всех сферах человеческой деятельности, в том числе и в области, очень близкой к теме книги—в программировании.
Видимость отражает полезность
Смысл этого принципа состоит в том, чтобы вынести самую важную информацию и элементы управления на первый план и сделать их легкодоступными пользователю, а менее важную — переместить, например, в меню.
Этот вопрос уже немного затрагивался при разговоре о принципе Якоба Нильсена "Эстетичный и минималистический дизайн", правда, в привязке к отражению полезности.
Отличие принципа "Видимость отражает полезность" как раз и состоит в том, что интерфейс программы должен быть построен вокруг объектов, с которыми манипулирует пользователь, и отражать состояние текущего объекта. Реализацию этого принципа вы видите каждый раз, когда пользуетесь компьютером: контекстные панели инструментов в программах пакета Microsoft Office, которые меняются в зависимости от того, с какой частью программы (редактором, предварительным просмотром, рисованием и т. п.) в данный момент работает пользователь. Еще один пример — уже упоминавшееся меню Пуск в Windows ME и Windows 2000: по умолчанию в них видимы наиболее часто используемые, т. е. полезные для пользователя, пункты.
Умное заимствование
Заимствование широко распространенных приемов дизайна интерфейсов и удачных находок авторов конкурирующих программ позволяет резко сократить время обучения и повысить комфорт пользователя. При работе он будет использовать уже приобретенные навыки -- этот вопрос затрагивает и принцип равенства между системой и реальным миром.
Заимствование чужих интерфейсных находок не является чем-то зазорным. Программы, лидирующие на рынке, являются неистощимым источником вдохновения для разработчиков более мелких программ, поразительно напоминающих легендарный Norton Commander: FAR, Volcov Commander, DOS Navigator, DISCo Commander
Этот принцип широко распространен и в обычной жизни, вне сферы компьютеров и интерфейсов для них. "Пожар легче предупредить, чем потушить" - гласил один из плакатов, изданных в конце девяностых годов Министерством внутренних дел для обучения людей технике пожарной безопасности. "Преступление легче предупредить, чем раскрыть" -- гласит одно из правил науки криминологии.
Применительно к теме проектирования интерфейсов компьютерных программ, принцип предупреждения ошибок означает следующее: "Дизайн, который предупреждает возникновение проблем, лучше, чем самое хорошее сообщение об ошибке".
Интерфейс, предупреждающий возникновение ошибок и связанных с ними проблем, образно называют "услужливым". Программа как бы заботится о пользователе, будучи всегда готовой предложить пользователю помощь, дать подсказку.
Кроме того, уменьшение вероятности возникновения ошибок пользователя при работе с программой достигается тщательной проработкой всех элементов интерфейса и его концепции в целом в соответствии с правилами проектирования интерфейсов. Интуитивно понятный, легкий для освоения интерфейс у большинства пользователей не вызывает никаких затруднений.
Принцип предупреждения ошибок, хотя и упоминается Якобом Нильсеном в списке его эвристических правил пятым по счету, по моему мнению, должен быть указан в нем последним, т. к. он имеет значение принципа, обобщающего все остальные правила. Ведь интерфейс, предупреждающий возникновение ошибок и проблем, должен информировать пользователя о статусе программы, давать ему контроль над работой приложения, общаться с пользователем на понятном ему языке, соответствовать принципу последовательности и т. д.
Понимание лучше, чем запоминание
При разработке интерфейса нужно делать все объекты, функции, действия видимыми и легко доступными пользователю. Минимизируйте запоминание — пользователь не должен постоянно стараться удержать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент пользователю должно быть ясно, что нужно делать в данный момент. В хорошем интерфейсе инструкции по использованию системы всегда видимы или легко доступны для вызова в любое время, когда это требуется. Это может быть реализовано как в виде продуманной организации элементов интерфейса, так и непосредственно в виде подсказок пользователю. Хороший и очень известный пример — анимированная надпись, которая появляется на панели задач Windows и "подъезжает" к кнопке Пуск: "Начните работу с нажатия этой кнопки".
Это правило отражает принцип прозрачного интерфейса — интерфейса, который понятен и не заставляет пользователя вспоминать, какую же кнопку нужно нажать или какой пункт меню выбрать в данный момент.
Гибкость и эффективность использования
Правило вполне закономерное, ведь программа в первую очередь должна решать задачу (см. разд. "Основы построения интерфейсов" данной главы), над которой работает пользователь. Однако при проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Но нужно учитывать, это во многом разные потребители, с разными требованиями к программе и разным стилем работы. Если сделать простой интерфейс с минимумом опций, который будет легок для освоения новичками, то более опытные пользователи не смогут работать с программой достаточно эффективно, чтобы удовлетворять свои потребности.
Для решения этой проблемы прибегают к простому приему: функции, которые ускоряют работу, оформлены так, что они не видны начинающим, но легко доступны продвинутым пользователям. Самый простой пример — это "горячие клавиши", с помощью которых можно быстро вызвать часто выполняющиеся функции программы, в частности открытие и сохранение файлов. Обозначения "горячих клавиш" пишутся рядом с соответствующими пунктами меню, поэтому они, с одной стороны, не мешают новичкам (они могут воспользоваться мышью для выбора пункта меню или щелчка по кнопке на панели инструментов), а, с другой стороны, легко доступны опытным пользователям.
Разработчики системы программирования Microsoft Quick Basic, которая была очень популярна еще в восьмидесятых и начале девяностых годов, пошли еще дальше: они предусмотрели два варианта главного меню приложения: полный и сокращенный, между которыми можно переключаться одним щелчком.
Другой пример реализации универсального "интерфейса для каждого" — возможность выполнить сложные функции программы как с помощью Мастера, который, словно за руку, проведет начинающего пользователя по всем этапам процесса, так и вручную, посредством настройки опций в соответствующем диалоговом окне.
Еще одна составляющая часть правила "Гибкость и эффективность использования" — необходимость предоставлять пользователю возможность быстрого выполнения частых действий. Варианты реализации этого очень разнообразны: это и уже упоминавшиеся "горячие клавиши", и команды для вызова последних открывавшихся файлов, и меню, в которых сначала показываются наиболее часто выполняющиеся команды, и макросы, и даже целые языки программирования, встраиваемые в приложения, наподобие Visual Basic for Applications в продуктах семейства Microsoft Office.
Эстетичный и минималистический дизайн
Если выразиться проще, то это правило означает: "Ничего лишнего". Не нужно загромождать интерфейс программы элементами, которые в данном случае являются неуместными и малополезными. Дело в том, что каждый элемент, будь то кнопка или текстовая подпись, обязательно отвлекает часть внимания пользователя. Это может привести к тому, что видимость и, соответственно, легкость восприятия пользователем действительно нужных и полезных частей интерфейса будет сильно уменьшена за счет элементов, без которых в данном случае можно было бы вполне обойтись.
Распознавание и исправление ошибок
"Помогайте пользователю, распознавать и исправлять ошибки" - говорит Якоб Нильсен. Это правило определяет проектирование сообщений об ошибках. Хорошие сообщения об ошибках — это сообщения, которые объясняют, в чем состоит проблема и, самое главное, как ее исправить. Таким образом, хорошее сообщение об ошибке должно состоять из двух частей.
Описание ошибки
Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки. Многие разработчики программ опасаются делать сообщения об ошибках очень информативными, чтобы не "пугать" начинающих пользователей техническими подробностями. Однако в этом случае нарушается описанный выше принцип гибкости и эффективности использования: опытные пользователи, получив слишком краткое сообщение об ошибке, не могут выяснить ее причину. А программа, в которой появляются какие-то непонятные ошибки, в конце концов начинает производить впечатление некачественной поделки.
Самое простое решение — создать в справочной системе программы соответствующий раздел, разъясняющий содержание проблемы и причины ее возникновения. В самом же диалоговом окне с сообщением об ошибке может присутствовать кнопка Справка для вызова этого раздела. Чисто технически реализовать это очень просто: в современных системах программирования для ее создания таких дружественных сообщений об ошибках достаточно при вызове функции MessageBox указать флаг наличия кнопки Справка и идентификатор соответствующего раздела справки. А вот составление подробных описаний ошибок, которых, к тому же, может быть очень много, для shareware-программистов гораздо более нудное и неприятное занятие.
Еще один пример решения, причем более изящного, данной проблемы является кнопка Подробнее, при нажатии на которую диалоговое окно с сообщением об ошибке "распахивается", отображая более подробную информацию о причине возникновения сбоя. Так, например, организованы многие сообщения об ошибках в 32-разрядных версиях Windows, самое известное из которых - "Программа выполнила недопустимую операцию и будет закрыта". За кнопкой Подробнее в этом сообщении скрывается имя программы-виновника, а также адрес места возникновения ошибки.
Замечание
Обратите внимание, что даже в "распахивающихся" сообщениях об ошибках, несмотря на то, что в них присутствует подробная информация, все равно должна присутствовать кнопка Справка для вызова раздела справочной системы с описанием соответствующей ошибки. Это необходимо потому, что обращение к справочной системе программы является более привычным для пользователя, чем менее распространенные "распахивающиеся" диалоговые окна.
К сожалению, такие изящные сообщения об ошибках в прикладных программах для Windows встречаются не очень часто, т. к. их включение требует хотя и несложной, но кропотливой работы.
Очень важно помнить то, что сообщение об ошибке должно содержать ее описание нормальным человеческим языком. Некоторые программисты совершенно серьезно считают, что такие лаконичные сообщения, в стиле известного в Интернете "Error 216", производят на пользователя неизгладимое впечатление: чем "загадочнее" программа, тем она сложнее и, в конечном итоге, "круче". Но, на самом деле, эффект сродни тому, что был уже описан выше: непонятные ошибки возникают только в некачественных поделках.
При составлении описаний ошибок нужно не забывать проверять правильность сообщений, генерируемых программой. На первый взгляд, это правило относится к разряду само собой разумеющихся вещей, однако многие авторы этим пренебрегают. В результате существует много программ, в которых сообщения об ошибках "врут" пользователю, рапортуя совсем не о тех проблемах, которые возникли на самом деле. Промашки в этом деле допускают даже программисты крупных компаний. Например, рекомендуется с осторожностью относиться к сообщениям об ошибках Windows, т. к. система не всегда правильно идентифицирует возникшие проблемы и вводит пользователей в заблуждение.
Описание решения проблемы
Как уже упоминалось выше, информация о том, как исправить ошибку или решить проблему имеет даже большее значение, чем собственно описание ошибки или проблемы. Ведь подсказка, помогающая решить проблему, способствует реализации одного из принципов построения пользовательского интерфейса — программа должна помогать выполнить задачу, а не становиться этой задачей.
Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. Дело в том, что не все пользователи догадываются нажать спасительную кнопку Справка, хотя это было бы вполне естественным ходом (как известно, в английских версиях Windows в этих случаях используется слово "Help" - "Помощь").
При описании пути решения проблемы, как и при написании любой документации, нужно избегать составления слишком объемных текстов, т. к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Лучше всего составить что-то наподобие пошаговой инструкции, каждый шаг из которой составляет 1—2 предложения.
Справка и документация
Принцип о необходимости предоставления справочной системы и документации к программе, идущий в списке Якоба Нильсена последним, не становится от этого менее важным. Составлению справочных систем для shreware-программ в этой книге посвящена отдельная, седьмая, глава.
Другие принципы построения интерфейсов
Конечно, помимо эвристических правил Якоба Нильсена, тех минимальных требований, которым должен удовлетворять интерфейс любой программы, существует довольно большое число принципов создания интерфейсов, о которых в своих трудах говорят специалисты, причем специалисты не только в области дизайна интерфейса. Ведь при проектировании интерфейсов применяются данные психологии, геометрии и других наук. Эти принципы, хотя и не обязательны при проектировании интерфейсов, но при их реализации программа будет выглядеть гораздо более выигрышно.
Золотое сечение
Золотое сечение — это самая комфортная для глаза пропорция. Форма, в основе построения которой лежит сочетание симметрии и золотого сечения, способствует наилучшему зрительному восприятию и появлению ощущения красоты и гармонии.
В математике пропорцией называют равенство двух отношений: а : 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) вызывает такая, казалось бы, обыденная вещь, как вид диалогового окна Свойства. А все потому, что при его проектировании использовался именно принцип золотого сечения.
Кошелек Миллера
Этот принцип назван так в честь ученого-психолога Г. А. Миллера, который исследовал кратковременную память, проверяя выводы, сделанные ранее его коллегой, Г. Эббингаузом. Эббингауз пытался выяснить, сколько информации может запомнить человек без каких-либо специальных мнемонических приемов. Оказалось, что емкость памяти ограничена семью цифрами, семью буквами или названиями семи предметов. Это "магическое число" семь, служащее своего рода меркой памяти, и было проверено Миллером, который показал, что память действительно в среднем не может хранить более семи элементов; в зависимости от сложности элементов это число может колебаться в пределах от пяти до девяти.
Если необходимо в течение короткого времени сохранить информацию, включающую больше семи элементов, мозг почти бессознательно группирует эту информацию таким образом, чтобы число запоминаемых элементов не превышало предельно допустимого. Например, номер банковского счета 30 637 402 710, состоящий из одиннадцати элементов, будет, скорее всего, запоминаться как 30 63 740 27 10, т. е. как пять числовых элементов, или восемь слов (тридцать, шестьдесят, три, семьсот, сорок, двадцать, семь, десять).
Применяя принцип кошелька Миллера в дизайне интерфейсов, следует группировать элементы в программе (кнопки на панелях инструментов, пункты меню, закладки, опции на этих закладках и т. п.) с учетом этого правила— т. е. не более семи в группе, в крайнем случае — девяти. Взгляните, например, на главное окно программы-словаря ABBYY Lingvo 6.0: четырнадцать кнопок на верхней панели, между которыми нет ни одного разделителя, воспринимаются гораздо хуже, чем кнопки на панели внизу, которые разделены на группы.
Итак, принцип кошелька Миллера говорит о семи плюс-минус двух элементах. Но если взглянуть на программы, интерфейс которых совершенствовался годами (тот же Microsoft Word), то можно заметить, что число объектов (пунктов меню, кнопок на панелях инструментов) в группах доходит до шести-семи довольно редко, а в основном элементы сгруппированы по три-четыре объекта. Такие небольшие группы объектов наиболее хорошо воспринимаются взглядом пользователя, уже слегка утомленного сложными интерфейсами современных программ. Я думаю, при проектировании интерфейсов программ верхнюю границу кошелька Миллера — семь-девять элементов — нужно применять очень осторожно, стараясь обходиться группами, содержащими максимум пять объектов.
Принцип группировки
Согласно этому правилу, экран программы должен быть разбит на ясно очерченные блоки элементов, может быть, даже с заголовком для каждого блока. При этом группировка, естественно, должна быть осмысленной: как расположение элементов в группах, так и расположение самих групп друг от друга должны быть продуманы.
Примеров реализации этого принципа очень много: это уже упоминавшиеся при разговоре о кошельке Миллера пункты меню, кнопочные панели инструментов, а также сгруппированные по назначению флажки и переключатели, с помощью которых настраиваются параметры работы программы в диалоговых окнах Свойства, Настройка и т. п.
Бритва Оккама или KISS
Философский принцип, носящий название "Бритва Оккама", гласит: "Не множить сущности без надобности". Или, как говорят американцы, KISS ("Keep It Simple, Stupid" •- "He усложняй, болван").
На языке интерфейсов это означает, что:
любая задача должна решаться минимальным числом действий;
логика этих действий должна быть очевидной для пользователя;
движения курсора и даже глаз пользователя должны быть оптимизированы.
Простым на первый взгляд требованиям из этого списка на самом деле не так уж легко следовать. Для проектирования сложного по своим функциям и простого для понимания интерфейса требуется немалые опыт, знания и особое чутье. Как пишет Лу Гринзоу: "Если и есть в мире что-то такое, что почти все программисты постоянно повторяют наизусть, как мантры, но при этом откровенно игнорируют, так это — принцип KISS".
Принцип KISS перекликается с несколькими из эвристических правил Якоба Нильсена - ''Эстетичный и минималистический дизайн", "Равенство между системой и реальным миром", "Понимание лучше, чем запоминание". KISS более универсален и применяется практически во всех сферах человеческой деятельности, в том числе и в области, очень близкой к теме книги—в программировании.
Видимость отражает полезность
Смысл этого принципа состоит в том, чтобы вынести самую важную информацию и элементы управления на первый план и сделать их легкодоступными пользователю, а менее важную — переместить, например, в меню.
Этот вопрос уже немного затрагивался при разговоре о принципе Якоба Нильсена "Эстетичный и минималистический дизайн", правда, в привязке к отражению полезности.
Отличие принципа "Видимость отражает полезность" как раз и состоит в том, что интерфейс программы должен быть построен вокруг объектов, с которыми манипулирует пользователь, и отражать состояние текущего объекта. Реализацию этого принципа вы видите каждый раз, когда пользуетесь компьютером: контекстные панели инструментов в программах пакета Microsoft Office, которые меняются в зависимости от того, с какой частью программы (редактором, предварительным просмотром, рисованием и т. п.) в данный момент работает пользователь. Еще один пример — уже упоминавшееся меню Пуск в Windows ME и Windows 2000: по умолчанию в них видимы наиболее часто используемые, т. е. полезные для пользователя, пункты.
Умное заимствование
Заимствование широко распространенных приемов дизайна интерфейсов и удачных находок авторов конкурирующих программ позволяет резко сократить время обучения и повысить комфорт пользователя. При работе он будет использовать уже приобретенные навыки -- этот вопрос затрагивает и принцип равенства между системой и реальным миром.
Заимствование чужих интерфейсных находок не является чем-то зазорным. Программы, лидирующие на рынке, являются неистощимым источником вдохновения для разработчиков более мелких программ, поразительно напоминающих легендарный Norton Commander: FAR, Volcov Commander, DOS Navigator, DISCo Commander
Администратор
Сообщений: 484
Нет на сайте
Типы интерфейса Windows-программ
В справочниках по созданию приложений для Windows интерфейсы программ традиционно делятся на два вида: однодокументный и многодокументный интерфейсы.
Однодокументный интерфейс (Single Document Interface, SDI) характеризуется тем, что главное окно программы, основанной на нем, не может содержать других окон, кроме диалоговых (окон настройки, информационных сообщений, сообщений об ошибках и т. п.). Как видно из его названия, такой интерфейс предназначен для работы с одним-единственным документом (под документом здесь понимается не только ассоциирующийся с этим словом у большинства пользователей текстовый файл, но и вообще любой объект — например, список папок на диске компьютера). За примерами использования SDI-интерфейса далеко ходить не надо: достаточно вспомнить входящие в Windows утилиты Блокнот, WordPad, Paint, Проводник и т. д.
Многодокументный, или мультидокументный, интерфейс (Multi-Document Interface, MDI) отличается от SDI тем, что главное окно программы может содержать другие, подчиненные окна, которые нельзя переместить за пределы основного окна. Такие подчиненные окна называют "child", т. е. "детскими", а окно, которое их содержит, соответственно, "parent" -"родительским". Как родительские, так и детские окна могут иметь свои меню, причем меню главного окна меняется на меню подчиненного окна, если последнее максимизируется, расширяясь до его, главного окна, границ.
Примеры реализации 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, многодокументный интерфейс более удобен и привычен.
Создание профессионального интерфейса
Иногда бывает достаточно одного взгляда, чтобы определить, что интерфейс программы делался новичком-любителем: настолько они отличаются от интерфейсов продуктов, которые разработаны крупными компаниями, которые, как правило, привлекают к работе над интерфейсом опытных специалистов.
Но беда в том, что при этой заметной разнице между интерфейсами, созданными профессионалами и новичками, не каждый начинающий разработчик может выяснить, что же конкретно в интерфейсе его программы сделано не так. Человек вроде бы всеми силами стремится к тому, чтобы создать качественный интерфейс, однако в результате получается совсем не то.
В этом разделе я расскажу о том, что чаще всего ускользает из поля зрения начинающего разработчика и что в конечном итоге приводит к появлению интерфейса, который никак нельзя назвать профессиональным.
Стандартные элементы интерфейса
Постарайтесь не использовать в своей программе нестандартные элементы интерфейса - например, командные кнопки не только с текстом, но и с рисунком, или комбинированные списки со сложной рамкой, которые в изобилии можно найти в online-коллекциях VCL и ActiveX-компонентов. Хотя бы потому, что именно так поступают профессиональные разработчики интерфейсов. "Чем стандартнее компоненты, тем лучше и профессиональнее вид" - не раз приходилось слышать от опытных авторов. Посудите сами: вы когда-нибудь видели в программе от Microsoft, Corel или Adobe элемент управления, сделанный начинающим программистом, выложенный в Интернете и сопровожденный припиской в файле readme.txt: "Это мой первый опыт в создании компонента, поэтому не пинайте слишком сильно!"
Замечание
Обратите внимание, что применение стандартных элементов настоятельно рекомендуется только для оформления стандартных функций. В программах, решающих какие-то специфические задачи, одними стандартными элементами обойтись очень нелегко. Самый простой пример — графический редактор: организовать выбор цвета или просмотр цветовых каналов при помощи традиционных списков или панелей довольно затруднительно.
У многих людей прилагательное "стандартный" прочно ассоциируется со словами "серый", "безыскусный", "неоригинальный" и им подобными, имеющими довольно негативное значение. Однако преимущества стандартного интерфейса отражены в принципах последовательности, равенства системы и реального мира, а также заимствования.
Небольшая палитра инструментов
Логическое развитие правила применения стандартных элементов: не используйте слишком большое их количество. Например, если где-то в одном из диалоговых окон программы вы поместили командную кнопку стандартного вида, то не нужно в другом месте программы использовать кнопку, отличающуюся от нее по оформлению. Да-да, это тоже наглядный
Одинаковое расстояние между элементами управления
Если элементы управления на форме приложения располагаются на разном расстоянии между ними, то это сразу придает интерфейсу непрофессиональный вид. Наоборот, аккуратно выстроенные на форме кнопки, переключатели, флажки и другие элементы -- признак качественной работы.
TabOrder. "Правильный" порядок
TabOrder — это порядок, в котором экранный курсор перемещается по элементам управления в форме при нажатии клавиши <Таb> на клавиатуре компьютера. На стадии разработки программы, при размещении элементов управления на форме, TabOrder эквивалентен тому порядку, в котором создаются эти элементы. Однако в процессе проектирования программы автор многократно меняет расположение элементов на форме, какие-то из них удаляет, добавляет новые компоненты. В результате почти всегда оказывается, что TabOrder не соответствует тому порядку, в котором визуально расположены элементы, и при нажатии клавиши <ТаЬ> курсор хаотично скачет по экрану вместо последовательного перемещения по компонентам.
Опытные разработчики по окончании проектирования формы обязательно проверяют TabOrder и, при необходимости, корректируют его. А вот начинающие авторы, увы, часто забывают об этом.
Выбор шрифтов
Здесь все просто — автор не должен выбирать никаких шрифтов. Оставьте их такими, какими они определены по умолчанию, а лучше — укажите в свойстве Шрифт (Font) соответствующие глобальные переменные Windows: WindowText, MenuText и т. д. В этом случае смена пользователем стандартных шрифтов Windows по своему вкусу с помощью Панели управления отразится и на внешнем виде вашей программы. Таким образом, пользователь, запустив ваш продукт, окажется в знакомом ему окружении.
Еще один вопрос — предпочтительное начертание шрифтов. Современные системы программирования допускают указание для свойства Шрифт, помимо обычного (normal) начертания еще и полужирное (bold), курсивное (italic) и подчеркнутое (underlined), а также их сочетания. Многие авторы, обрадовавшись предоставленным возможностям, охотно ими пользуются, применяя различные комбинации шрифтовых начертаний. На самом же деле в интерфейсах Windows-программ принято использовать всего два начертания: нормальное и полужирное (последнее — для выделения какой-либо важной информации, заголовков и т. п.). Применение курсива или подчеркивания, которое, к тому же, пользователь ошибочно может принять за гиперссылку — это дурной тон.
Масштабирование шрифтов
Нужно учитывать, что на разных компьютерах установлены различные по масштабу шрифты: одни пользователи предпочитают крупный шрифт, другие — более мелкий. Из-за этого текстовые подписи (на кнопках, панелях и т. п.), которые автор поместил в своей программе, при запуске продукта пользователями могут увеличиваться в размерах. Многие элементы управления автоматически подстраивают свои размеры согласно содержимому, но некоторые, например Строка состояния (StatusBar), таким свойством не обладают, и текст в этом случае может обрезаться.
Выбор цветов
Здесь ситуация в точности такая же, как и со шрифтами: никакого выбора. При проектировании интерфейса нужно вообще забыть о свойстве Цвет (Color) элементов управления. Оставьте цвета стандартными, и пусть ваша программа выглядит так, как этого хочет ее пользователь, а не автор (хорошая идея — предусмотреть в программе возможность изменения цветовой гаммы различных частей интерфейса: многие пользователи любят настраивать цвета "под себя", причем так, что другому человеку такое "сочетание" цветов может показаться совершенно неудобоваримым). И в этом, нужно сказать, авторам программ повезло: они лишены одной из самых главных забот дизайнеров и художников, какие же цвета выбрать для своего нового творения.
Многие программисты все-таки жестко прописывают в своей программе используемые цвета, и это может служить причиной возникновения одного неприятного эффекта. Дело в том, что, как вы знаете, с помощью Панели управления можно легко изменить цветовую гамму Windows. Жестко фиксируя в своей программе выбранные цвета, автор не учитывает, что его программа выглядит хорошо только до тех пор, пока она работает на компьютере с такой же цветовой гаммой, как и на компьютере разработчика. Если же ее запускают в системе с другим цветовым оформлением, то результат может выглядеть, мягко говоря, не очень хорошо. Для предотвращения таких досадных ошибок в процессе разработки программы нужно время от времени переключаться на другие цветовые "схемы" Windows, проверяя, как ваша программа будет выглядеть на компьютере с нестандартной цветовой гаммой.
Альтернативное управление
Ваша программа должна одинаково хорошо управляться как с помощью мыши, так и клавиатуры. Не должно быть функций, которые можно выполнить только мышью (за исключением традиционно "мышиных" операций -например, рисования в графических редакторах). Наиболее популярные функции следует снабдить "горячими клавишами" для их быстрого вызова. При выборе комбинаций клавиш не забывайте о привычках и навыках пользователей: остановитесь на тех комбинациях, которые обычно используются в программах такого рода. Например, если вы разрабатываете файловый менеджер в стиле Проводника Windows, то лучше создавать комбинации, традиционные для Windows-программ (табл. 5.1); если же вы ориентируетесь на Norton Commander, то, например, для функции обновления списка файлов присвойте "горячую клавишу" <Ctrl>+<R>, а не <F5> Windows. Но, наверное, в такой ситуации идеальный, но, естественно, не самый легкий вариант — предусмотреть для функций программы две "схемы" горячих клавиш, чтобы удовлетворить потребности приверженцев обоих стилей работы с файлами.
Кирпичики интерфейса
Итак, вы познакомились с теорией проектирования интерфейсов и практическими рекомендациями по выбору типа интерфейса и приданию ему профессионального вида. Настало время поговорить о самых мелких частицах интерфейса, из которых, как дом из кирпичей, строится внешний вид программного продукта, — элементах управления (компонентах).
В графическом пользовательском интерфейсе элемент управления -- это средство, при помощи которого пользователь взаимодействует с компьютерной программой. Качество этого взаимодействия зависит от двух аспектов:
соответствия элемента управления выполняемой им задаче;
от последовательности правил, по которым функционирует элемент управления.
Достаточно выбрать не тот инструмент для работы или изменить правила, по которым он действует, и вы создадите проблемы для пользователей своей программы. Далее я расскажу о некоторых элементах управления и о наиболее часто возникающих проблемах, связанных с интеграцией компонентов в интерфейс, а также о том, как можно решить эти проблемы.
Заголовок окна (формы)
Хотя в палитрах доступных программисту компонентов современных систем создания приложений отсутствует такой элемент управления, как заголовок окна, он определяется свойством Заголовок (Caption) объекта Форма (Form), ему нужно уделять не меньшее внимание, чем кнопкам, спискам и тому подобным элементам.
Заголовок главного окна программы традиционно используется для вывода информации о двух вещах: названии программы и названии документа, с которым в данный момент работает пользователь (если, конечно, в программе вообще предусмотрена обработка каких-либо документов). Так вот, вопрос в том, в каком порядке должна помещаться в окне программы такая информация?
Вопрос вовсе не праздный, как кажется на первый взгляд. Традиционно в программах с мультидокументным интерфейсом в заголовке окна сначала помещается название программы, а затем — название открытого документа. Однако для пользователя более удобным является другой порядок расположения информации в заголовке окна, когда первым идет название открытого документа, а после него — название программы. Такой подход к организации заголовка окна имеет следующие преимущества:
если название документа помещается в заголовке окна первым, то оно всегда видимо на кнопке, представляющей соответствующую программу на Панели задач Windows, и узнать, какой в данный момент открыт документ, не представляет никакого труда. А вот если в заголовке окна сначала идет название программы, то, следовательно, оно и видно на Панели задач, и для того, чтобы выяснить, с каким именно документом работает данное окно, нужно переключиться в него (или навести курсор на кнопку Панели задач и подождать секунду, пока не появится всплывающая подсказка);
т. к. при чтении взгляд человека скользит слева направо, то идущее в заголовке окна первым название документа (а именно для того, чтобы выяснить название текущего документа, и смотрит в заголовок окна пользователь чаще всего) читается наиболее легко. Если же применяется традиционная схема (Название программы -- название документа), то пользователю сначала нужно пробежать глазами название программы, т. е. восприятие важной информации затрудняется.
В новых версиях программных продуктов постепенно происходит отказ от традиционной схемы построения заголовков окон. Например, Microsoft уже перевела на новый формат заголовка окна свои продукты — от простого "Блокнота" из состава Windows до программ пакета Office 2000.
Командные кнопки
Наиболее частая ошибка начинающих разработчиков интерфейсов — использование в проекте нестандартных кнопок, включающих, помимо текста, также и графику. Во-первых, из-за обычно невысокого качества графики выглядят такие кнопки очень непрофессионально; во-вторых, почти всегда у автора программы не хватает рисунков на все кнопки, имеющиеся в программе, и часть кнопок приходится делать обычными, с текстовыми подписями и без рисунков. Нарушается принцип последовательности, что, сами понимаете, не добавляет интерфейсу привлекательности.
Пожалуй, единственная категория программ, в интерфейс которых можно включать кнопки с графикой, — это игры. Здесь такие кнопки могут оживить стандартный интерфейс Windows-программ, придать ему более праздничный и нарядный вид.
Командная кнопка — один из тех элементов управления, для которых наиболее часто применяется динамически изменяемое свойство disable, т. е. отключение кнопки, когда она перестает реагировать на нажатия, и ее включение, в зависимости от текущего состояния программы. Для индикации состояния отключения граница вокруг кнопки и буквы текста на ней становятся светло-серыми.
Динамическое отключение и включение кнопки выглядит очень эффектно и производит впечатление высокого искусственного интеллекта программы (в большинстве случаев так и есть). Например, в диалоговых окнах кнопка ОК остается недоступной до тех пор, пока пользователь не введет необходимые данные, т. е. при каждом изменении информации происходит ее проверка. И вот здесь нужно быть очень осторожным. Дело в том, что пользователь при вводе сложных данных может не иметь информации о том, что именно он делает неправильно. "Серая" отключенная кнопка только говорит ему о том, что он что-то сделал не так, как нужно — например, ввел неверные или неполные данные, но вот в чем конкретно состоит проблема... И никто не может подсказать пользователю, что необходимо сделать, чтобы заветная кнопка наконец стала реагировать на нажатия мышью. Было бы гораздо лучше, если бы кнопка ОК была доступной, а после ее нажатия выдавалось бы сообщение об ошибке.
Лично мне приходилось не раз сталкиваться с описанной выше проблемой. Однажды я даже не смог зарегистрировать законно приобретенную копию shareware-программы: кнопка Зарегистрировать все время оставалась отключенной, несмотря на ввод в текстовое окно регистрационного кода. И информацию о том, что именно я делаю неправильно, я смог получить, только написав письмо автору программы... Поэтому при проектировании интерфейса собственной программы, Actual Startup, я решил не поддаваться соблазну сделать диалоговые окна слишком "умными". Кнопка ОК в окне создания нового "сервиса" становится доступной даже при вводе неправильных данных, зато после ее нажатия появляется окно с сообщением об ошибке и информацией о том, как ее исправить.
В справочниках по созданию приложений для Windows интерфейсы программ традиционно делятся на два вида: однодокументный и многодокументный интерфейсы.
Однодокументный интерфейс (Single Document Interface, SDI) характеризуется тем, что главное окно программы, основанной на нем, не может содержать других окон, кроме диалоговых (окон настройки, информационных сообщений, сообщений об ошибках и т. п.). Как видно из его названия, такой интерфейс предназначен для работы с одним-единственным документом (под документом здесь понимается не только ассоциирующийся с этим словом у большинства пользователей текстовый файл, но и вообще любой объект — например, список папок на диске компьютера). За примерами использования SDI-интерфейса далеко ходить не надо: достаточно вспомнить входящие в Windows утилиты Блокнот, WordPad, Paint, Проводник и т. д.
Многодокументный, или мультидокументный, интерфейс (Multi-Document Interface, MDI) отличается от SDI тем, что главное окно программы может содержать другие, подчиненные окна, которые нельзя переместить за пределы основного окна. Такие подчиненные окна называют "child", т. е. "детскими", а окно, которое их содержит, соответственно, "parent" -"родительским". Как родительские, так и детские окна могут иметь свои меню, причем меню главного окна меняется на меню подчиненного окна, если последнее максимизируется, расширяясь до его, главного окна, границ.
Примеры реализации 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, многодокументный интерфейс более удобен и привычен.
Создание профессионального интерфейса
Иногда бывает достаточно одного взгляда, чтобы определить, что интерфейс программы делался новичком-любителем: настолько они отличаются от интерфейсов продуктов, которые разработаны крупными компаниями, которые, как правило, привлекают к работе над интерфейсом опытных специалистов.
Но беда в том, что при этой заметной разнице между интерфейсами, созданными профессионалами и новичками, не каждый начинающий разработчик может выяснить, что же конкретно в интерфейсе его программы сделано не так. Человек вроде бы всеми силами стремится к тому, чтобы создать качественный интерфейс, однако в результате получается совсем не то.
В этом разделе я расскажу о том, что чаще всего ускользает из поля зрения начинающего разработчика и что в конечном итоге приводит к появлению интерфейса, который никак нельзя назвать профессиональным.
Стандартные элементы интерфейса
Постарайтесь не использовать в своей программе нестандартные элементы интерфейса - например, командные кнопки не только с текстом, но и с рисунком, или комбинированные списки со сложной рамкой, которые в изобилии можно найти в online-коллекциях VCL и ActiveX-компонентов. Хотя бы потому, что именно так поступают профессиональные разработчики интерфейсов. "Чем стандартнее компоненты, тем лучше и профессиональнее вид" - не раз приходилось слышать от опытных авторов. Посудите сами: вы когда-нибудь видели в программе от Microsoft, Corel или Adobe элемент управления, сделанный начинающим программистом, выложенный в Интернете и сопровожденный припиской в файле readme.txt: "Это мой первый опыт в создании компонента, поэтому не пинайте слишком сильно!"
Замечание
Обратите внимание, что применение стандартных элементов настоятельно рекомендуется только для оформления стандартных функций. В программах, решающих какие-то специфические задачи, одними стандартными элементами обойтись очень нелегко. Самый простой пример — графический редактор: организовать выбор цвета или просмотр цветовых каналов при помощи традиционных списков или панелей довольно затруднительно.
У многих людей прилагательное "стандартный" прочно ассоциируется со словами "серый", "безыскусный", "неоригинальный" и им подобными, имеющими довольно негативное значение. Однако преимущества стандартного интерфейса отражены в принципах последовательности, равенства системы и реального мира, а также заимствования.
Небольшая палитра инструментов
Логическое развитие правила применения стандартных элементов: не используйте слишком большое их количество. Например, если где-то в одном из диалоговых окон программы вы поместили командную кнопку стандартного вида, то не нужно в другом месте программы использовать кнопку, отличающуюся от нее по оформлению. Да-да, это тоже наглядный
Одинаковое расстояние между элементами управления
Если элементы управления на форме приложения располагаются на разном расстоянии между ними, то это сразу придает интерфейсу непрофессиональный вид. Наоборот, аккуратно выстроенные на форме кнопки, переключатели, флажки и другие элементы -- признак качественной работы.
TabOrder. "Правильный" порядок
TabOrder — это порядок, в котором экранный курсор перемещается по элементам управления в форме при нажатии клавиши <Таb> на клавиатуре компьютера. На стадии разработки программы, при размещении элементов управления на форме, TabOrder эквивалентен тому порядку, в котором создаются эти элементы. Однако в процессе проектирования программы автор многократно меняет расположение элементов на форме, какие-то из них удаляет, добавляет новые компоненты. В результате почти всегда оказывается, что TabOrder не соответствует тому порядку, в котором визуально расположены элементы, и при нажатии клавиши <ТаЬ> курсор хаотично скачет по экрану вместо последовательного перемещения по компонентам.
Опытные разработчики по окончании проектирования формы обязательно проверяют TabOrder и, при необходимости, корректируют его. А вот начинающие авторы, увы, часто забывают об этом.
Выбор шрифтов
Здесь все просто — автор не должен выбирать никаких шрифтов. Оставьте их такими, какими они определены по умолчанию, а лучше — укажите в свойстве Шрифт (Font) соответствующие глобальные переменные Windows: WindowText, MenuText и т. д. В этом случае смена пользователем стандартных шрифтов Windows по своему вкусу с помощью Панели управления отразится и на внешнем виде вашей программы. Таким образом, пользователь, запустив ваш продукт, окажется в знакомом ему окружении.
Еще один вопрос — предпочтительное начертание шрифтов. Современные системы программирования допускают указание для свойства Шрифт, помимо обычного (normal) начертания еще и полужирное (bold), курсивное (italic) и подчеркнутое (underlined), а также их сочетания. Многие авторы, обрадовавшись предоставленным возможностям, охотно ими пользуются, применяя различные комбинации шрифтовых начертаний. На самом же деле в интерфейсах Windows-программ принято использовать всего два начертания: нормальное и полужирное (последнее — для выделения какой-либо важной информации, заголовков и т. п.). Применение курсива или подчеркивания, которое, к тому же, пользователь ошибочно может принять за гиперссылку — это дурной тон.
Масштабирование шрифтов
Нужно учитывать, что на разных компьютерах установлены различные по масштабу шрифты: одни пользователи предпочитают крупный шрифт, другие — более мелкий. Из-за этого текстовые подписи (на кнопках, панелях и т. п.), которые автор поместил в своей программе, при запуске продукта пользователями могут увеличиваться в размерах. Многие элементы управления автоматически подстраивают свои размеры согласно содержимому, но некоторые, например Строка состояния (StatusBar), таким свойством не обладают, и текст в этом случае может обрезаться.
Выбор цветов
Здесь ситуация в точности такая же, как и со шрифтами: никакого выбора. При проектировании интерфейса нужно вообще забыть о свойстве Цвет (Color) элементов управления. Оставьте цвета стандартными, и пусть ваша программа выглядит так, как этого хочет ее пользователь, а не автор (хорошая идея — предусмотреть в программе возможность изменения цветовой гаммы различных частей интерфейса: многие пользователи любят настраивать цвета "под себя", причем так, что другому человеку такое "сочетание" цветов может показаться совершенно неудобоваримым). И в этом, нужно сказать, авторам программ повезло: они лишены одной из самых главных забот дизайнеров и художников, какие же цвета выбрать для своего нового творения.
Многие программисты все-таки жестко прописывают в своей программе используемые цвета, и это может служить причиной возникновения одного неприятного эффекта. Дело в том, что, как вы знаете, с помощью Панели управления можно легко изменить цветовую гамму Windows. Жестко фиксируя в своей программе выбранные цвета, автор не учитывает, что его программа выглядит хорошо только до тех пор, пока она работает на компьютере с такой же цветовой гаммой, как и на компьютере разработчика. Если же ее запускают в системе с другим цветовым оформлением, то результат может выглядеть, мягко говоря, не очень хорошо. Для предотвращения таких досадных ошибок в процессе разработки программы нужно время от времени переключаться на другие цветовые "схемы" Windows, проверяя, как ваша программа будет выглядеть на компьютере с нестандартной цветовой гаммой.
Альтернативное управление
Ваша программа должна одинаково хорошо управляться как с помощью мыши, так и клавиатуры. Не должно быть функций, которые можно выполнить только мышью (за исключением традиционно "мышиных" операций -например, рисования в графических редакторах). Наиболее популярные функции следует снабдить "горячими клавишами" для их быстрого вызова. При выборе комбинаций клавиш не забывайте о привычках и навыках пользователей: остановитесь на тех комбинациях, которые обычно используются в программах такого рода. Например, если вы разрабатываете файловый менеджер в стиле Проводника Windows, то лучше создавать комбинации, традиционные для Windows-программ (табл. 5.1); если же вы ориентируетесь на Norton Commander, то, например, для функции обновления списка файлов присвойте "горячую клавишу" <Ctrl>+<R>, а не <F5> Windows. Но, наверное, в такой ситуации идеальный, но, естественно, не самый легкий вариант — предусмотреть для функций программы две "схемы" горячих клавиш, чтобы удовлетворить потребности приверженцев обоих стилей работы с файлами.
Кирпичики интерфейса
Итак, вы познакомились с теорией проектирования интерфейсов и практическими рекомендациями по выбору типа интерфейса и приданию ему профессионального вида. Настало время поговорить о самых мелких частицах интерфейса, из которых, как дом из кирпичей, строится внешний вид программного продукта, — элементах управления (компонентах).
В графическом пользовательском интерфейсе элемент управления -- это средство, при помощи которого пользователь взаимодействует с компьютерной программой. Качество этого взаимодействия зависит от двух аспектов:
соответствия элемента управления выполняемой им задаче;
от последовательности правил, по которым функционирует элемент управления.
Достаточно выбрать не тот инструмент для работы или изменить правила, по которым он действует, и вы создадите проблемы для пользователей своей программы. Далее я расскажу о некоторых элементах управления и о наиболее часто возникающих проблемах, связанных с интеграцией компонентов в интерфейс, а также о том, как можно решить эти проблемы.
Заголовок окна (формы)
Хотя в палитрах доступных программисту компонентов современных систем создания приложений отсутствует такой элемент управления, как заголовок окна, он определяется свойством Заголовок (Caption) объекта Форма (Form), ему нужно уделять не меньшее внимание, чем кнопкам, спискам и тому подобным элементам.
Заголовок главного окна программы традиционно используется для вывода информации о двух вещах: названии программы и названии документа, с которым в данный момент работает пользователь (если, конечно, в программе вообще предусмотрена обработка каких-либо документов). Так вот, вопрос в том, в каком порядке должна помещаться в окне программы такая информация?
Вопрос вовсе не праздный, как кажется на первый взгляд. Традиционно в программах с мультидокументным интерфейсом в заголовке окна сначала помещается название программы, а затем — название открытого документа. Однако для пользователя более удобным является другой порядок расположения информации в заголовке окна, когда первым идет название открытого документа, а после него — название программы. Такой подход к организации заголовка окна имеет следующие преимущества:
если название документа помещается в заголовке окна первым, то оно всегда видимо на кнопке, представляющей соответствующую программу на Панели задач Windows, и узнать, какой в данный момент открыт документ, не представляет никакого труда. А вот если в заголовке окна сначала идет название программы, то, следовательно, оно и видно на Панели задач, и для того, чтобы выяснить, с каким именно документом работает данное окно, нужно переключиться в него (или навести курсор на кнопку Панели задач и подождать секунду, пока не появится всплывающая подсказка);
т. к. при чтении взгляд человека скользит слева направо, то идущее в заголовке окна первым название документа (а именно для того, чтобы выяснить название текущего документа, и смотрит в заголовок окна пользователь чаще всего) читается наиболее легко. Если же применяется традиционная схема (Название программы -- название документа), то пользователю сначала нужно пробежать глазами название программы, т. е. восприятие важной информации затрудняется.
В новых версиях программных продуктов постепенно происходит отказ от традиционной схемы построения заголовков окон. Например, Microsoft уже перевела на новый формат заголовка окна свои продукты — от простого "Блокнота" из состава Windows до программ пакета Office 2000.
Командные кнопки
Наиболее частая ошибка начинающих разработчиков интерфейсов — использование в проекте нестандартных кнопок, включающих, помимо текста, также и графику. Во-первых, из-за обычно невысокого качества графики выглядят такие кнопки очень непрофессионально; во-вторых, почти всегда у автора программы не хватает рисунков на все кнопки, имеющиеся в программе, и часть кнопок приходится делать обычными, с текстовыми подписями и без рисунков. Нарушается принцип последовательности, что, сами понимаете, не добавляет интерфейсу привлекательности.
Пожалуй, единственная категория программ, в интерфейс которых можно включать кнопки с графикой, — это игры. Здесь такие кнопки могут оживить стандартный интерфейс Windows-программ, придать ему более праздничный и нарядный вид.
Командная кнопка — один из тех элементов управления, для которых наиболее часто применяется динамически изменяемое свойство disable, т. е. отключение кнопки, когда она перестает реагировать на нажатия, и ее включение, в зависимости от текущего состояния программы. Для индикации состояния отключения граница вокруг кнопки и буквы текста на ней становятся светло-серыми.
Динамическое отключение и включение кнопки выглядит очень эффектно и производит впечатление высокого искусственного интеллекта программы (в большинстве случаев так и есть). Например, в диалоговых окнах кнопка ОК остается недоступной до тех пор, пока пользователь не введет необходимые данные, т. е. при каждом изменении информации происходит ее проверка. И вот здесь нужно быть очень осторожным. Дело в том, что пользователь при вводе сложных данных может не иметь информации о том, что именно он делает неправильно. "Серая" отключенная кнопка только говорит ему о том, что он что-то сделал не так, как нужно — например, ввел неверные или неполные данные, но вот в чем конкретно состоит проблема... И никто не может подсказать пользователю, что необходимо сделать, чтобы заветная кнопка наконец стала реагировать на нажатия мышью. Было бы гораздо лучше, если бы кнопка ОК была доступной, а после ее нажатия выдавалось бы сообщение об ошибке.
Лично мне приходилось не раз сталкиваться с описанной выше проблемой. Однажды я даже не смог зарегистрировать законно приобретенную копию shareware-программы: кнопка Зарегистрировать все время оставалась отключенной, несмотря на ввод в текстовое окно регистрационного кода. И информацию о том, что именно я делаю неправильно, я смог получить, только написав письмо автору программы... Поэтому при проектировании интерфейса собственной программы, Actual Startup, я решил не поддаваться соблазну сделать диалоговые окна слишком "умными". Кнопка ОК в окне создания нового "сервиса" становится доступной даже при вводе неправильных данных, зато после ее нажатия появляется окно с сообщением об ошибке и информацией о том, как ее исправить.
Администратор
Сообщений: 484
Нет на сайте
Текстовые подписи
Казалось бы, какие "подводные камни" могут быть при использовании одного из самых простых элементов управления — Label? Во-первых, не забудьте о масштабировании шрифтов: чтобы текстовая подпись автоматически подстраивала свои размеры согласно содержащемуся в ней тексту, проверьте, что свойство AutoSize имеет значение True. Во-вторых, также присвойте значение True свойству Transparent (если ваша среда разработки поддерживает его) — это приведет к тому, что фон подписи станет прозрачным, и гарантированно убережет вас от возникновения проблемы.
Вот такой он непростой, элемент Label: "обрезанный" текст и фон, не соответствующий фону основной формы, могут сильно испортить отношение пользователя ко всей программе.
Меню
Список команд по работе с программой, предлагаемых на выбор пользователя — одно из самых старых и универсальных средств организации интерфейса компьютерных программ.
В самых первых программах, предназначенных для работы на персональных компьютерах, меню представляло собой список операций, и для выбора какой-либо из них требовалось нажать на клавиатуре клавишу с цифрой, обозначающей порядковый номер соответствующей команды в меню. В программных продуктах для IBM PC середины 80-х годов, большинство из которых работало в текстовом режиме экрана (тот же Norton Commander), меню уже имело сложную структуру: команды были разбиты на группы, названия которых выводились в строке вверху экрана; по ниспадающим спискам команд можно было перемещаться нажатием клавиш со стрелками, а выбор делать при помощи клавиши <Enter>. Во многих программах к управлению подключилась мышь.
С расцветом Windows и ростом популярности графического интерфейса меню заняло основное место среди средств управления компьютерными программами. Законодатель мод в области интерфейсов Windows-приложений — корпорация Microsoft — постоянно улучшала внешний вид и эргономику меню. В Windows 95 в меню были добавлены графические пиктограммы и возможность перемещения курсора мышью, а не только клавиатурой, как в Windows 3.1; в Windows 2000 появились "умные" меню, в которых первыми показывались наиболее часто вызываемые пользователем команды.
Но, тем не менее, всех этих заслуг меню в деле построения интерфейсов не производят на некоторых авторов программ никакого впечатления, и они -о ужас! — начинают считать, что без меню в программе вполне можно обойтись. Я как-то спросил одного из shareware-авторов, в главном окне программы которого присутствовала только кнопочная панель инструментов, а меню не было. "Да ну его... Я не знаю, чего туда помещать" - услышал я в ответ.
Вопрос "Что помещать в меню?" я рассмотрю чуть позже, а пока хотел бы обратить внимание на обязательность присутствия меню в главном окне программы. Это, если угодно, такое же правило хорошего тона, как и любое из эвристик Якоба Нильсена, о которых рассказывалось выше. Отказываясь от включения меню в проект своей программы, автор игнорирует опыт и навыки пользователей, заставляет их отказываться от стиля работы, к которому они привыкли. Особенно меня забавляет, когда авторы не делают в программе меню, но создают кнопочную панель инструментов: последняя появилась в интерфейсе программ для персональных компьютеров относительно недавно и, конечно, не может быть полноценной заменой меню. Хотя бы потому, что меню — это не просто список команд, это еще и многофункциональная "шпаргалка" по работе с программой, "шпаргалка", которая всегда под рукой (как известно, читать справочные файлы пользователи не очень любят). Достаточно провести мышью по строке меню вверху экрана, и можно выяснить набор функций программы, комбинации "горячих клавиш" и даже — объяснение назначения кнопок на панели инструментов.
Замечание
Если главное окно программы выполнено в виде диалога, т. е. окна, имеющего фиксированную границу, то в таком окне строка меню не обязательна. Однако некоторые авторы, высоко оценивая эргономику меню, включают его и в диалоговые окна.
Теперь — о том, что же можно помещать в меню. Некоторые авторы считают, что для простых программ меню вовсе не нужно, т. к. не стоит делать меню ради двух-трех пунктов. Но даже программа, которая ничего не делает, достойна меню как минимум из двух пунктов: Файл, где находится команда Выход и Справка, включающий подпункт О программе (ведь потенциальные пользователи должны знать, куда отправлять свои денежки, правда?).
Пункт Файл, даже если программа непосредственно с файлами не работает, очень желателен, я бы сказал — необходим. Просто Файл — настолько привычный элемент меню, что все основные команды (начать новую работу, сохранить результаты, выйти из программы) пользователи ищут прежде всего там. Пункт Справка я рекомендую включать в любое меню по двум причинам: во-первых, пользователь сразу видит, что в программе есть справочная система и есть куда обратиться в случае возникновения затруднений; во-вторых, если в строке меню содержится только один пункт -Файл, то это выглядит не очень красиво. Добавление еще одного пункта уравновешивает картину.
И, конечно же, не стоит забывать о контекстных меню — меню, появляющихся при щелчке правой кнопкой мыши на каком-либо объекте и содержащими команды для работы с этим объектом. Разработка таких меню -дело, хотя технически очень простое, но при этом довольно кропотливое. Тем не менее, затраты времени и сил обязательно окупятся. Операционная система Windows 95 и ее последующие версии приучили пользователей к мысли, что при щелчке правой кнопкой мыши появляется контекстное меню. Щелчок правой кнопкой мыши стал уже настолько естественным действием, что профамма, не "понимающая" его, напоминает человека, который не слышит, что ему говорят. Контекстное меню — одна из самых сильных привычек пользователей и навык, который имеют даже малоопытные новички. Нужно обязательно учитывать это при разработке интерфейсов собственных программ.
Некоторые авторы программ забывают о значении термина "контекстное меню". Такое меню должно содержать только те команды, которые относятся к объекту, которому принадлежит меню. Вызывать по щелчку правой кнопкой мыши, меню из пары десятков пунктов и уж тем более дубликат главного меню программы не имеет смысла: практическая ценность такого "контекстного" меню равна нулю.
Но и переоценивать значение контекстных меню не нужно. При всем их удобстве и эффективности это всего лишь дополнительный элемент интерфейса, а не его основа. При проектировании программы они должны создаваться в расчете на использование совместно с главным меню, но ни в коем случае не как его замена. Дело в том, что несмотря на большую популярность контекстных меню, есть люди, которые ими никогда не пользуются. Кроме того, в некоторых случаях контекстное меню не всегда удобно, по сравнению с главным меню, кнопочной панелью инструментов или клавиатурой. Таким образом, если контекстное меню — единственный способ управления программой, то это будет вызывать отрицательную реакцию пользователей: никому не нравится, когда его лишают привычных средств работы и навязывают что-то другое, не всегда удобное и полезное.
Списки
Элемент управления Список (ListBox) один из самых популярных во всей палитре компонентов для создания интерфейса. Он позволяет легко просматривать большие объемы информации и осуществлять выделение нужных строк. Однако у него есть неприятная особенность: отсутствие горизонтальной линейки прокрутки. Из-за этого слишком длинные строки обрезаются на границе элемента, что особенно неприятно, если таким образом становится недоступной какая-либо важная информация.
Во избежание возникновения подобных проблем нужно тщательно протестировать работу программы, чтобы выяснить, возможна ли ситуация, что в список будут выведены слишком длинные строки, чтобы уместиться в нем полностью. Если это не исключается, то можно предусмотреть средства, позволяющие все-таки полностью просмотреть "обрезанную" строку, например, при двойном щелчке мышью на интересующей пользователя строке выводить на экран небольшое окошко, где требуемый текст отображается полностью. Еще один хороший путь решения этой проблемы — заменить элемент Список (ListBox) более функциональным, скажем, ListView (в нем, например, Проводник Windows выводит список файлов). Задав определенным образом некоторые свойства ListView, можно добиться его полного внешнего сходства с традиционным списком, однако в отличие от последнего в окне ListView будет присутствовать горизонтальная линейка прокрутки.
Флажки и переключатели
Флажки (Checkboxes) и переключатели (Option Buttons) используются для одной цели: для выбора из группы предложенных вариантов. Разница между ними, как вам, наверное, известно, состоит в том, что флажки используются для выбора одновременно нескольких вариантов из группы, а переключатели позволяют сделать выбор в пользу только одного варианта.
К сожалению, даже некоторые довольно авторитетные специалисты не придают большого значения этому различию между флажками и переключателями. В очередном номере Visual Basic Programmer's Journal 101 Tech Tips for VB Developers, вышедшем в августе 1999 года, был опубликован небольшой кусок кода, который модифицировал функциональность группы флажков, позволяя им работать, как переключатели: с их помощью можно было выбрать только один вариант из предложенных. "Такое изменение может быть полезно, если вы хотите использовать флажки вместо переключателей", -говорилось в публикации. Редактор сайта iarchitect.com с иронией предложил заменить вторую часть этой фразы на следующее: "...если вы хотите запутать ваших пользователей". Ведь само появление на экране группы флажков сразу говорит пользователю о том, что сейчас ему можно будет сделать выбор нескольких вариантов, а не одного-единственного. Поэтому ни в коем случае не применяйте флажки для организации выбора одного варианта из группы.
Панели инструментов
Кнопочные панели инструментов (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 были более последовательны: в нижнем правом углу каждой "сложной" кнопки в качестве индикации помещено изображение стрелки
Тип границы кнопок на панелях инструментов — тоже не такой простой вопрос, как кажется. Традиционно кнопки на инструментальных панелях точно так же, как и обычные командные кнопки, имели объемную границу вокруг них. Сложившийся порядок нарушил выход версии 3.0 браузера Microsoft Internet Explorer. Кнопки на панели инструментов этой программы имели "плоский" вид: граница появлялась на них лишь после того, как пользователь наводил на кнопку курсор мыши. Оригинальную, хотя и не бесспорную идею охотно подхватили все разработчики, и сегодня практически все программы имеют "плоскую" панель инструментов. Лично я разделяю мнение, что "плоская" панель инструментов выглядит очень необычно и интересно, однако есть пользователи, которым больше по душе традиционное оформление панели инструментов, когда кнопки выглядят именно так, как должны выглядеть кнопки. И те разработчики программ, которые стараются не упускать из виду даже самые незначительные мелочи, предусматривают в своих продуктах возможность смены пользователем вида панели "обычный"/"плоский", тем более что технически реализовать такую функцию в программе очень просто — нужно менять значение всего одного
Вкладки
Вкладки (Tabs) широко используются при проектировании интерфейсов современных программ, с тех самых пор, как вышла Windows 95, в которой практически каждое диалоговое окно содержало вкладки. Нужно отдать должное этому элементу управления: он не только выглядит не менее эффектно, чем кнопочная панель инструментов, но и очень эффективен, позволяя логически группировать большое количество информации, позволяя пользователю комфортно воспринимать ее.
Да, вкладки позволяют упорядочить большие объемы данных, однако это полезное свойство вкладок сходит на нет, если число самих вкладок становится слишком большим. Здесь явно наблюдается противоречие с правилом кошелька Миллера (см. разд. "Другие принципы построения интерфейсов" данной главы), определяющим, что человек может удерживать в своей кратковременной памяти семь плюс-минус две сущности. Поэтому в нескольких рядах вкладок, которые уже перестают умещаться в рамках диалогового окна, очень легко запутаться. Даже тот десяток вкладок, которые находятся в окне Параметры Microsoft Word, вызывает многочисленные нарекания со стороны пользователей. Действительно, мало кому не приходилось беспорядочно щелкать по вкладкам окна настроек Microsoft Word, чтобы отыскать нужную опцию.
Но что же тогда делать авторам функционально очень сложных программ, где диалоговые окна заполнены самой разной информацией? Без вкладок все окажется словно сваленным в одну большую кучу, в которой разобраться будет гораздо труднее, чем в десятке вкладок.
Если посмотреть, как эта проблема решается в известных shareware-программах, то можно заметить, что их авторы стремятся уменьшить число вкладок в диалоговых окнах за счет разделения всех вкладок в новые группы, где число вкладок относительно невелико. Например, в главном меню популярного почтового клиента The Bat! (http://www.ritlabs.com) есть отдельный пункт — Свойства, а в нем — несколько подпунктов, вызывающих соответствующие диалоговые окна: Редактор писем, Быстрые шаблоны, Подключение и администрирование и т. п. В некоторых из них вообще отсутствуют вкладки, а некоторые обошлись всего лишь двумя-тремя вкладками. В не менее популярном текстовом редакторе UltraEdit аналогичным образом разнесены окна настройки самого редактора и вспомогательных утилит. В уже много раз упоминавшейся программе Chameleon Clock, в окне Свойства создано три группы опций: Настройки, Действия и Виды (переключение между ними происходит при помоши панели в стиле Microsoft Outlook), в которых находятся по четыре-пять вкладок (а в опции Виды их вообще нет)
Всплывающие подсказки
Всплывающие подсказки (ToolTips) — это, конечно, не самостоятельные элементы управления, хотя в коллекциях компонентов и можно найти модули для создания сложных (многострочных, с разными типами шрифтов, с графикой и т. п.) подсказок. На практике они применяются как дополнение к другим элементам управления, выдавая пояснение относительно назначения соответствующего элемента. Стоит пользователю на секунду задержать курсор мыши над интересующим его элементом, как появляется небольшой желтый прямоугольник с поясняющим текстом.
Нужно помнить, что всплывающие подсказки — спутник далеко не любого компонента на форме приложения. Традиционно они используются для "озвучивания" назначения только кнопок на панелях инструментов, секций на строке состояния и..., пожалуй, все. Есть некоторые случаи использования всплывающих подсказок для других компонентов (например, вертикальная линейка прокрутки в Microsoft Word или меню Пуск в Windows 2000), но это скорее исключение, чем правило
Тем не менее, иногда встречаются программы, интерфейс которых словно шевелится: такой эффект создают всплывающие подсказки, выскакивающие буквально из каждого элемента управления, будь то командная кнопка, список, текстовое поле ввода, флажок или переключатель. Такой энтузиазм разработчиков относительно всплывающих подсказок иногда обусловлен излишней заботой о пользователях, а иногда, наоборот, нежеланием автора писать отдельный справочный файл программы. Но в любом случае снабжать все элементы управления в программе всплывающими подсказками крайне не рекомендуется.
Осторожно: скины
Скин (англ, skin — кожа, шкура) — это набор графических изображений, с помощью которых можно менять внешний вид программы. Естественно, сама эта программа должна поддерживать работу со скинами.
Человек всегда стремится как-то выделиться, придать себе и своим вещам индивидуальность. Многие люди стараются так украсить собственный дом, автомобиль, рабочее место, чтобы они отличались от других. То же самое наблюдается с компьютерами: пользователи устанавливают в качестве "обоев" Рабочего стола Windows понравившиеся картинки, перенастраивают цветовую и звуковую схемы. Введение возможности изменить вид программы по своему вкусу - закономерное развитие компьютерных интерфейсов, еще один шаг к удовлетворению желания пользователей настраивать все "под себя" и индивидуализировать себя и свое окружение.
Хрестоматийный пример программы, использующей скины, — это мультимедийный плейер WinAmp (http://www.winamp.com). Именно после ее выхода слово "скины" стало очень модным. Огромной популярностью стали пользоваться программы, как и WinAmp, позволявшие менять "кожу", online-коллекции скинов (например, сайт http://www.skinz.org ). Слово "скины" буквально завораживало пользователей, и они торопились скачать и опробовать любой программный продукт, в описании которого оно встречалось. Естественно, сам WinAmp тоже не остался без внимания, заполучив огромную аудиторию пользователей со всего мира, и его часто приводят как пример удачного маркетингового хода.
На стремительный рост популярности скинов тут же отреагировали авторы инструментов для разработки программного обеспечения: на рынке быстро появилось множество VCL- и ActiveX-компонентов, позволявших программистам легко встроить в собственные продукты поддержку скинов, и таким образом, снабдить свою программу одной из самых модных функций.
Однако у этих компонентов есть на первый взгляд не заметный, но, тем не менее, очень значительный недостаток. Каждый из этих компонентов, как правило, работает только с собственным форматом скинов. Вследствие этого, в программах, в которых поддержка скинов организована при помощи таких компонентов, не могут быть скины из других программ, например из того же WinAmp. Кроме того, количество "шкур", которые есть в распоряжении программиста, использующего один из таких компонентов, обычно очень невелико, не более 10—20.
Некоторые программисты не обращают на эти доводы никакого внимания: "Подумаешь, несовместимость форматов, ну и пусть, что скинов мало -главное, они, скины, ЕСТЬ!" Но давайте-ка немного порассуждаем. Если каждая программа использует собственный формат скинов, значит, существует вероятность, что в разных программах скины будут также разные (на самом деле именно так и есть). Кроме того, раз для каждой программы существует всего лишь по паре десятков "шкур", то пользователь точно не сможет выбрать из них ту, которая устраивает его на сто процентов. И теперь представьте картину: каждая программа на компьютере пользователя имеет разный вид, да к тому же и не полностью устраивающий хозяина системы. Кстати, вряд ли пользователи будут самостоятельно рисовать скины к вашей программе: это не такое уж простое занятие, а в ситуации, когда
скины требуются сразу для нескольких программ на компьютере, это дело становится и вовсе бесперспективным.
Гораздо более выигрышный вариант — пойти в фарватере лидера (прием, который действенен не только в области программирования вообще и скинов в частности). Кандидатура на эту роль только одна: WinAmp. Посудите сами:
WinAmp — самая популярная программа, которая поддерживает скины. Благодаря действительно хорошим функциональным возможностям и бесплатности, она чаще всего используется как плейер звуковых файлов;
к WinAmp уже нарисовано огромное количество скинов — более сорока трех тысяч (!) на август 2001 года;
некоторые программы независимых разработчиков уже поддерживают скины WinAmp.
Таким образом, сделав свой продукт совместимым со "шкурам" WinAmp, вы одним выстрелом убиваете не двух, а трех зайцев, получая:
десятки тысяч готовых скинов, доступных пользователям;
огромную потенциальную аудиторию, значительная часть которой вполне может из потенциальной стать реальной: многие пользователи захотят заполучить, например, калькулятор или записную книжку, которые выглядят так же, как и их любимый WinAmp;
возможность эффективно рекламировать свою программу: наличие в описании программы слов "поддержка скинов WinAmp" дает неплохой отклик со стороны пользователей на поисковых системах и в online-архивах программного обеспечения.
Если вы захотите встроить в свою программу поддержку скинов, то сначала хорошенько подумайте: а действительно ли "шкуры" так необходимы вашему продукту?
Традиционно поддержка скинов встраивалась в программы, которые либо имитируют предмет, который существует в реальном мире (плейер, калькулятор, часы и т. п.), либо ориентируются на сферу развлечений, либо оба варианта сразу. Поэтому способность менять свой вид при помощи "шкур" для таких программ стала уже привычной и почти обязательной функцией. Однако авторы, разрабатывающие программы, которые не попадают в указанные тематические группы (например, системные утилиты), впечатлив-шись успехом скинов, также встраивают в свои продукты их поддержку, ожидая, что это благоприятно скажется на популярности программы.
Шаг, на мой взгляд, спорный. Пользователей системных утилит или, скажем, бизнес-программ не очень-то привлекают всякие украшательства, скорее, наоборот. Ведь скины, как уже говорилось в предыдущем абзаце, ассоциируются с развлекательными программами, и упоминание "шкур" может серьезно повредить имиджу программы. Кроме того, поддержка скинов часто реализуется программистами с помощью громоздких ActiveX-компонентов, что неоправданно увеличивает размер программы. Для некоторых программ, например системных утилит, главное требование к которым — компактность, это может оказаться слишком большой жертвой, принесенной ради красоты.
Но, уж если вы все-таки встроили в свою программу поддержку скинов, позаботьтесь о том, чтобы пользователь мог ее отключить, вернувшись к традиционному виду. Стандартное оформление Windows-приложений - это тоже своеобразный скин, и у него есть немало приверженцев.
Казалось бы, какие "подводные камни" могут быть при использовании одного из самых простых элементов управления — Label? Во-первых, не забудьте о масштабировании шрифтов: чтобы текстовая подпись автоматически подстраивала свои размеры согласно содержащемуся в ней тексту, проверьте, что свойство AutoSize имеет значение True. Во-вторых, также присвойте значение True свойству Transparent (если ваша среда разработки поддерживает его) — это приведет к тому, что фон подписи станет прозрачным, и гарантированно убережет вас от возникновения проблемы.
Вот такой он непростой, элемент Label: "обрезанный" текст и фон, не соответствующий фону основной формы, могут сильно испортить отношение пользователя ко всей программе.
Меню
Список команд по работе с программой, предлагаемых на выбор пользователя — одно из самых старых и универсальных средств организации интерфейса компьютерных программ.
В самых первых программах, предназначенных для работы на персональных компьютерах, меню представляло собой список операций, и для выбора какой-либо из них требовалось нажать на клавиатуре клавишу с цифрой, обозначающей порядковый номер соответствующей команды в меню. В программных продуктах для IBM PC середины 80-х годов, большинство из которых работало в текстовом режиме экрана (тот же Norton Commander), меню уже имело сложную структуру: команды были разбиты на группы, названия которых выводились в строке вверху экрана; по ниспадающим спискам команд можно было перемещаться нажатием клавиш со стрелками, а выбор делать при помощи клавиши <Enter>. Во многих программах к управлению подключилась мышь.
С расцветом Windows и ростом популярности графического интерфейса меню заняло основное место среди средств управления компьютерными программами. Законодатель мод в области интерфейсов Windows-приложений — корпорация Microsoft — постоянно улучшала внешний вид и эргономику меню. В Windows 95 в меню были добавлены графические пиктограммы и возможность перемещения курсора мышью, а не только клавиатурой, как в Windows 3.1; в Windows 2000 появились "умные" меню, в которых первыми показывались наиболее часто вызываемые пользователем команды.
Но, тем не менее, всех этих заслуг меню в деле построения интерфейсов не производят на некоторых авторов программ никакого впечатления, и они -о ужас! — начинают считать, что без меню в программе вполне можно обойтись. Я как-то спросил одного из shareware-авторов, в главном окне программы которого присутствовала только кнопочная панель инструментов, а меню не было. "Да ну его... Я не знаю, чего туда помещать" - услышал я в ответ.
Вопрос "Что помещать в меню?" я рассмотрю чуть позже, а пока хотел бы обратить внимание на обязательность присутствия меню в главном окне программы. Это, если угодно, такое же правило хорошего тона, как и любое из эвристик Якоба Нильсена, о которых рассказывалось выше. Отказываясь от включения меню в проект своей программы, автор игнорирует опыт и навыки пользователей, заставляет их отказываться от стиля работы, к которому они привыкли. Особенно меня забавляет, когда авторы не делают в программе меню, но создают кнопочную панель инструментов: последняя появилась в интерфейсе программ для персональных компьютеров относительно недавно и, конечно, не может быть полноценной заменой меню. Хотя бы потому, что меню — это не просто список команд, это еще и многофункциональная "шпаргалка" по работе с программой, "шпаргалка", которая всегда под рукой (как известно, читать справочные файлы пользователи не очень любят). Достаточно провести мышью по строке меню вверху экрана, и можно выяснить набор функций программы, комбинации "горячих клавиш" и даже — объяснение назначения кнопок на панели инструментов.
Замечание
Если главное окно программы выполнено в виде диалога, т. е. окна, имеющего фиксированную границу, то в таком окне строка меню не обязательна. Однако некоторые авторы, высоко оценивая эргономику меню, включают его и в диалоговые окна.
Теперь — о том, что же можно помещать в меню. Некоторые авторы считают, что для простых программ меню вовсе не нужно, т. к. не стоит делать меню ради двух-трех пунктов. Но даже программа, которая ничего не делает, достойна меню как минимум из двух пунктов: Файл, где находится команда Выход и Справка, включающий подпункт О программе (ведь потенциальные пользователи должны знать, куда отправлять свои денежки, правда?).
Пункт Файл, даже если программа непосредственно с файлами не работает, очень желателен, я бы сказал — необходим. Просто Файл — настолько привычный элемент меню, что все основные команды (начать новую работу, сохранить результаты, выйти из программы) пользователи ищут прежде всего там. Пункт Справка я рекомендую включать в любое меню по двум причинам: во-первых, пользователь сразу видит, что в программе есть справочная система и есть куда обратиться в случае возникновения затруднений; во-вторых, если в строке меню содержится только один пункт -Файл, то это выглядит не очень красиво. Добавление еще одного пункта уравновешивает картину.
И, конечно же, не стоит забывать о контекстных меню — меню, появляющихся при щелчке правой кнопкой мыши на каком-либо объекте и содержащими команды для работы с этим объектом. Разработка таких меню -дело, хотя технически очень простое, но при этом довольно кропотливое. Тем не менее, затраты времени и сил обязательно окупятся. Операционная система Windows 95 и ее последующие версии приучили пользователей к мысли, что при щелчке правой кнопкой мыши появляется контекстное меню. Щелчок правой кнопкой мыши стал уже настолько естественным действием, что профамма, не "понимающая" его, напоминает человека, который не слышит, что ему говорят. Контекстное меню — одна из самых сильных привычек пользователей и навык, который имеют даже малоопытные новички. Нужно обязательно учитывать это при разработке интерфейсов собственных программ.
Некоторые авторы программ забывают о значении термина "контекстное меню". Такое меню должно содержать только те команды, которые относятся к объекту, которому принадлежит меню. Вызывать по щелчку правой кнопкой мыши, меню из пары десятков пунктов и уж тем более дубликат главного меню программы не имеет смысла: практическая ценность такого "контекстного" меню равна нулю.
Но и переоценивать значение контекстных меню не нужно. При всем их удобстве и эффективности это всего лишь дополнительный элемент интерфейса, а не его основа. При проектировании программы они должны создаваться в расчете на использование совместно с главным меню, но ни в коем случае не как его замена. Дело в том, что несмотря на большую популярность контекстных меню, есть люди, которые ими никогда не пользуются. Кроме того, в некоторых случаях контекстное меню не всегда удобно, по сравнению с главным меню, кнопочной панелью инструментов или клавиатурой. Таким образом, если контекстное меню — единственный способ управления программой, то это будет вызывать отрицательную реакцию пользователей: никому не нравится, когда его лишают привычных средств работы и навязывают что-то другое, не всегда удобное и полезное.
Списки
Элемент управления Список (ListBox) один из самых популярных во всей палитре компонентов для создания интерфейса. Он позволяет легко просматривать большие объемы информации и осуществлять выделение нужных строк. Однако у него есть неприятная особенность: отсутствие горизонтальной линейки прокрутки. Из-за этого слишком длинные строки обрезаются на границе элемента, что особенно неприятно, если таким образом становится недоступной какая-либо важная информация.
Во избежание возникновения подобных проблем нужно тщательно протестировать работу программы, чтобы выяснить, возможна ли ситуация, что в список будут выведены слишком длинные строки, чтобы уместиться в нем полностью. Если это не исключается, то можно предусмотреть средства, позволяющие все-таки полностью просмотреть "обрезанную" строку, например, при двойном щелчке мышью на интересующей пользователя строке выводить на экран небольшое окошко, где требуемый текст отображается полностью. Еще один хороший путь решения этой проблемы — заменить элемент Список (ListBox) более функциональным, скажем, ListView (в нем, например, Проводник Windows выводит список файлов). Задав определенным образом некоторые свойства ListView, можно добиться его полного внешнего сходства с традиционным списком, однако в отличие от последнего в окне ListView будет присутствовать горизонтальная линейка прокрутки.
Флажки и переключатели
Флажки (Checkboxes) и переключатели (Option Buttons) используются для одной цели: для выбора из группы предложенных вариантов. Разница между ними, как вам, наверное, известно, состоит в том, что флажки используются для выбора одновременно нескольких вариантов из группы, а переключатели позволяют сделать выбор в пользу только одного варианта.
К сожалению, даже некоторые довольно авторитетные специалисты не придают большого значения этому различию между флажками и переключателями. В очередном номере Visual Basic Programmer's Journal 101 Tech Tips for VB Developers, вышедшем в августе 1999 года, был опубликован небольшой кусок кода, который модифицировал функциональность группы флажков, позволяя им работать, как переключатели: с их помощью можно было выбрать только один вариант из предложенных. "Такое изменение может быть полезно, если вы хотите использовать флажки вместо переключателей", -говорилось в публикации. Редактор сайта iarchitect.com с иронией предложил заменить вторую часть этой фразы на следующее: "...если вы хотите запутать ваших пользователей". Ведь само появление на экране группы флажков сразу говорит пользователю о том, что сейчас ему можно будет сделать выбор нескольких вариантов, а не одного-единственного. Поэтому ни в коем случае не применяйте флажки для организации выбора одного варианта из группы.
Панели инструментов
Кнопочные панели инструментов (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 были более последовательны: в нижнем правом углу каждой "сложной" кнопки в качестве индикации помещено изображение стрелки
Тип границы кнопок на панелях инструментов — тоже не такой простой вопрос, как кажется. Традиционно кнопки на инструментальных панелях точно так же, как и обычные командные кнопки, имели объемную границу вокруг них. Сложившийся порядок нарушил выход версии 3.0 браузера Microsoft Internet Explorer. Кнопки на панели инструментов этой программы имели "плоский" вид: граница появлялась на них лишь после того, как пользователь наводил на кнопку курсор мыши. Оригинальную, хотя и не бесспорную идею охотно подхватили все разработчики, и сегодня практически все программы имеют "плоскую" панель инструментов. Лично я разделяю мнение, что "плоская" панель инструментов выглядит очень необычно и интересно, однако есть пользователи, которым больше по душе традиционное оформление панели инструментов, когда кнопки выглядят именно так, как должны выглядеть кнопки. И те разработчики программ, которые стараются не упускать из виду даже самые незначительные мелочи, предусматривают в своих продуктах возможность смены пользователем вида панели "обычный"/"плоский", тем более что технически реализовать такую функцию в программе очень просто — нужно менять значение всего одного
Вкладки
Вкладки (Tabs) широко используются при проектировании интерфейсов современных программ, с тех самых пор, как вышла Windows 95, в которой практически каждое диалоговое окно содержало вкладки. Нужно отдать должное этому элементу управления: он не только выглядит не менее эффектно, чем кнопочная панель инструментов, но и очень эффективен, позволяя логически группировать большое количество информации, позволяя пользователю комфортно воспринимать ее.
Да, вкладки позволяют упорядочить большие объемы данных, однако это полезное свойство вкладок сходит на нет, если число самих вкладок становится слишком большим. Здесь явно наблюдается противоречие с правилом кошелька Миллера (см. разд. "Другие принципы построения интерфейсов" данной главы), определяющим, что человек может удерживать в своей кратковременной памяти семь плюс-минус две сущности. Поэтому в нескольких рядах вкладок, которые уже перестают умещаться в рамках диалогового окна, очень легко запутаться. Даже тот десяток вкладок, которые находятся в окне Параметры Microsoft Word, вызывает многочисленные нарекания со стороны пользователей. Действительно, мало кому не приходилось беспорядочно щелкать по вкладкам окна настроек Microsoft Word, чтобы отыскать нужную опцию.
Но что же тогда делать авторам функционально очень сложных программ, где диалоговые окна заполнены самой разной информацией? Без вкладок все окажется словно сваленным в одну большую кучу, в которой разобраться будет гораздо труднее, чем в десятке вкладок.
Если посмотреть, как эта проблема решается в известных shareware-программах, то можно заметить, что их авторы стремятся уменьшить число вкладок в диалоговых окнах за счет разделения всех вкладок в новые группы, где число вкладок относительно невелико. Например, в главном меню популярного почтового клиента The Bat! (http://www.ritlabs.com) есть отдельный пункт — Свойства, а в нем — несколько подпунктов, вызывающих соответствующие диалоговые окна: Редактор писем, Быстрые шаблоны, Подключение и администрирование и т. п. В некоторых из них вообще отсутствуют вкладки, а некоторые обошлись всего лишь двумя-тремя вкладками. В не менее популярном текстовом редакторе UltraEdit аналогичным образом разнесены окна настройки самого редактора и вспомогательных утилит. В уже много раз упоминавшейся программе Chameleon Clock, в окне Свойства создано три группы опций: Настройки, Действия и Виды (переключение между ними происходит при помоши панели в стиле Microsoft Outlook), в которых находятся по четыре-пять вкладок (а в опции Виды их вообще нет)
Всплывающие подсказки
Всплывающие подсказки (ToolTips) — это, конечно, не самостоятельные элементы управления, хотя в коллекциях компонентов и можно найти модули для создания сложных (многострочных, с разными типами шрифтов, с графикой и т. п.) подсказок. На практике они применяются как дополнение к другим элементам управления, выдавая пояснение относительно назначения соответствующего элемента. Стоит пользователю на секунду задержать курсор мыши над интересующим его элементом, как появляется небольшой желтый прямоугольник с поясняющим текстом.
Нужно помнить, что всплывающие подсказки — спутник далеко не любого компонента на форме приложения. Традиционно они используются для "озвучивания" назначения только кнопок на панелях инструментов, секций на строке состояния и..., пожалуй, все. Есть некоторые случаи использования всплывающих подсказок для других компонентов (например, вертикальная линейка прокрутки в Microsoft Word или меню Пуск в Windows 2000), но это скорее исключение, чем правило
Тем не менее, иногда встречаются программы, интерфейс которых словно шевелится: такой эффект создают всплывающие подсказки, выскакивающие буквально из каждого элемента управления, будь то командная кнопка, список, текстовое поле ввода, флажок или переключатель. Такой энтузиазм разработчиков относительно всплывающих подсказок иногда обусловлен излишней заботой о пользователях, а иногда, наоборот, нежеланием автора писать отдельный справочный файл программы. Но в любом случае снабжать все элементы управления в программе всплывающими подсказками крайне не рекомендуется.
Осторожно: скины
Скин (англ, skin — кожа, шкура) — это набор графических изображений, с помощью которых можно менять внешний вид программы. Естественно, сама эта программа должна поддерживать работу со скинами.
Человек всегда стремится как-то выделиться, придать себе и своим вещам индивидуальность. Многие люди стараются так украсить собственный дом, автомобиль, рабочее место, чтобы они отличались от других. То же самое наблюдается с компьютерами: пользователи устанавливают в качестве "обоев" Рабочего стола Windows понравившиеся картинки, перенастраивают цветовую и звуковую схемы. Введение возможности изменить вид программы по своему вкусу - закономерное развитие компьютерных интерфейсов, еще один шаг к удовлетворению желания пользователей настраивать все "под себя" и индивидуализировать себя и свое окружение.
Хрестоматийный пример программы, использующей скины, — это мультимедийный плейер WinAmp (http://www.winamp.com). Именно после ее выхода слово "скины" стало очень модным. Огромной популярностью стали пользоваться программы, как и WinAmp, позволявшие менять "кожу", online-коллекции скинов (например, сайт http://www.skinz.org ). Слово "скины" буквально завораживало пользователей, и они торопились скачать и опробовать любой программный продукт, в описании которого оно встречалось. Естественно, сам WinAmp тоже не остался без внимания, заполучив огромную аудиторию пользователей со всего мира, и его часто приводят как пример удачного маркетингового хода.
На стремительный рост популярности скинов тут же отреагировали авторы инструментов для разработки программного обеспечения: на рынке быстро появилось множество VCL- и ActiveX-компонентов, позволявших программистам легко встроить в собственные продукты поддержку скинов, и таким образом, снабдить свою программу одной из самых модных функций.
Однако у этих компонентов есть на первый взгляд не заметный, но, тем не менее, очень значительный недостаток. Каждый из этих компонентов, как правило, работает только с собственным форматом скинов. Вследствие этого, в программах, в которых поддержка скинов организована при помощи таких компонентов, не могут быть скины из других программ, например из того же WinAmp. Кроме того, количество "шкур", которые есть в распоряжении программиста, использующего один из таких компонентов, обычно очень невелико, не более 10—20.
Некоторые программисты не обращают на эти доводы никакого внимания: "Подумаешь, несовместимость форматов, ну и пусть, что скинов мало -главное, они, скины, ЕСТЬ!" Но давайте-ка немного порассуждаем. Если каждая программа использует собственный формат скинов, значит, существует вероятность, что в разных программах скины будут также разные (на самом деле именно так и есть). Кроме того, раз для каждой программы существует всего лишь по паре десятков "шкур", то пользователь точно не сможет выбрать из них ту, которая устраивает его на сто процентов. И теперь представьте картину: каждая программа на компьютере пользователя имеет разный вид, да к тому же и не полностью устраивающий хозяина системы. Кстати, вряд ли пользователи будут самостоятельно рисовать скины к вашей программе: это не такое уж простое занятие, а в ситуации, когда
скины требуются сразу для нескольких программ на компьютере, это дело становится и вовсе бесперспективным.
Гораздо более выигрышный вариант — пойти в фарватере лидера (прием, который действенен не только в области программирования вообще и скинов в частности). Кандидатура на эту роль только одна: WinAmp. Посудите сами:
WinAmp — самая популярная программа, которая поддерживает скины. Благодаря действительно хорошим функциональным возможностям и бесплатности, она чаще всего используется как плейер звуковых файлов;
к WinAmp уже нарисовано огромное количество скинов — более сорока трех тысяч (!) на август 2001 года;
некоторые программы независимых разработчиков уже поддерживают скины WinAmp.
Таким образом, сделав свой продукт совместимым со "шкурам" WinAmp, вы одним выстрелом убиваете не двух, а трех зайцев, получая:
десятки тысяч готовых скинов, доступных пользователям;
огромную потенциальную аудиторию, значительная часть которой вполне может из потенциальной стать реальной: многие пользователи захотят заполучить, например, калькулятор или записную книжку, которые выглядят так же, как и их любимый WinAmp;
возможность эффективно рекламировать свою программу: наличие в описании программы слов "поддержка скинов WinAmp" дает неплохой отклик со стороны пользователей на поисковых системах и в online-архивах программного обеспечения.
Если вы захотите встроить в свою программу поддержку скинов, то сначала хорошенько подумайте: а действительно ли "шкуры" так необходимы вашему продукту?
Традиционно поддержка скинов встраивалась в программы, которые либо имитируют предмет, который существует в реальном мире (плейер, калькулятор, часы и т. п.), либо ориентируются на сферу развлечений, либо оба варианта сразу. Поэтому способность менять свой вид при помощи "шкур" для таких программ стала уже привычной и почти обязательной функцией. Однако авторы, разрабатывающие программы, которые не попадают в указанные тематические группы (например, системные утилиты), впечатлив-шись успехом скинов, также встраивают в свои продукты их поддержку, ожидая, что это благоприятно скажется на популярности программы.
Шаг, на мой взгляд, спорный. Пользователей системных утилит или, скажем, бизнес-программ не очень-то привлекают всякие украшательства, скорее, наоборот. Ведь скины, как уже говорилось в предыдущем абзаце, ассоциируются с развлекательными программами, и упоминание "шкур" может серьезно повредить имиджу программы. Кроме того, поддержка скинов часто реализуется программистами с помощью громоздких ActiveX-компонентов, что неоправданно увеличивает размер программы. Для некоторых программ, например системных утилит, главное требование к которым — компактность, это может оказаться слишком большой жертвой, принесенной ради красоты.
Но, уж если вы все-таки встроили в свою программу поддержку скинов, позаботьтесь о том, чтобы пользователь мог ее отключить, вернувшись к традиционному виду. Стандартное оформление Windows-приложений - это тоже своеобразный скин, и у него есть немало приверженцев.
Администратор
Сообщений: 484
Нет на сайте
ГЛАВА 6.
Защита программ
Зачем нужна защита
Наличие защиты в shareware-программах обусловлено самим принципом shareware: "Попробуй, прежде чем купить". Разработчик предоставляет свою программу для тестирования, а если программа понравится, то пользователь может оплатить регистрацию. Если бы распространение копий программы строго контролировалось, а все пользователи были известны, что называется, "в лицо", с получением денег за программу не было бы почти никаких проблем. Но shareware-программы скачиваются по Интернету огромным числом людей, находящихся от автора на большом расстоянии. Для того чтобы стимулировать пользователей оплачивать регистрацию, программисты включают в программу всевозможные ограничения, отличающие незарегистрированную версию от зарегистрированной.
В самом начале развития shareware-индустрии, во времена расцвета PC-Talk и PC-File (см. разд. "История shareware" гл. 1), условно-бесплатные программы не имели никаких ограничений. В документации автор просто указывал, что пользователи, если программа им понравится, могут прислать ему определенную сумму денег.
С появлением множества других shareware программ эта схема быстро потеряла свою эффективность. Многие разработчики на своем опыте убедились, что при отсутствии защиты программу покупают очень мало, зато при вставке в программу хотя бы экрана, напоминающего о необходимости регистрации продукта, число зарегистрированных пользователей резко увеличивается. Защиту не заменит даже то, что вместо денег за регистрацию требуется прислать всего лишь заполненную анкету: пользователей, действительно сделавших это, будут единицы. У пользователя должен быть реальный стимул зарегистрировать программу, одного лишь сообщения о ее статусе shareware в лицензионном соглашении недостаточно.
Несмотря на это, начинающие шароварщики до сих пор пытаются начать продавать свою программу без защиты, лишь с напоминанием о необходимости зарегистрироваться, указанным не в самом заметном месте — в справочной системе, файле readme.txt или диалоговом окне О программе. Многих вдохновляет пример 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-архиваторами и мультимедиа-плейерами — вряд ли они стали бы такими же популярными и прибыльными, как тогда. Поэтому не нужно полагаться на такую схему. Дайте пользователю почувствовать, что взамен своих денег он получил что-то вполне определенное.
Виды защиты
Существует три основных типа защиты shareware-программ: демо-версия, ограниченная по времени версия и функционально ограниченная версия.
Демо-версия
Демо-версия — самый простой для реализации, но одновременно самый неудобный вид защиты. Из программы просто удаляются некоторые фрагменты кода, в результате чего функциональные возможности программы сильно ограничиваются. Такая "урезанная" версия затем выкладывается на Web-сайт, а оплатившим регистрацию пользователям высылается "полная" версия по электронной или обычной почте либо сообщается "скрытый" от посторонних адрес, по которому ее можно скачать.
Достоинство этого варианта в том, что "взломать" саму программу невозможно — ведь программная защита как таковая в ЕХЕ-файле отсутствует. С другой стороны, зарегистрированная версия программы может легко стать доступной всем, а не только тем, кто ее оплатил. Например, кто-нибудь из купивших программу может выложить ее где-нибудь в Интернете или, если зарегистрированная версия не высылается по почте, а скачивается с Web-сервера — опубликовать "секретный" адрес для всеобщего пользования. Самое обидное, что у автора нет никаких шансов узнать, кто именно из пользователей сделал ему такую гадость (если только виновник сам не укажет себя).
Разработчику же распространение программы в виде демо-версии доставляет много хлопот. Например, рассылка зарегистрированных версий по электронной, не говоря уже об обычной, почте сопряжена с большими накладными расходами. Если же пользователи должны загружать "полную" версию с Web-сервера, то автор программы должен постоянно быть готовым к тому, что экземпляр полнофункциональной версии появится в свободном доступе где-нибудь в Сети, а убрать ее оттуда окажется очень непросто. Если разработчик захочет защититься от скачивания "полной" версии незарегистрированными пользователями с помощью опубликованного кем-то "секретного" адреса, ему следует поместить файл с дистрибутивом программы в специальный защищенный паролем каталог на своем сервере. Далее необходимо постоянно добавлять в настройки имена новых пользователей, имеющих право доступа к этому каталогу, а также удалять имена пользователей, опубликовавших свои логины и пароли в Интернете.
Демо-версии не так удобны и для пользователей. Например, для получения полной версии нужно обязательно иметь доступ в сеть Интернет (рассылка "полных" версий обычной почтой встречается очень редко), а это не всегда возможно, ведь дистрибутив программы может быть переписан у знакомых или куплен на CD-ROM со сборником shareware-программ. Кроме того, доступ этот должен быть довольно быстрым, чтобы перекачать из почтового ящика большой файл (кстати, многие почтовые серверы настроены таким образом, что не принимают большие файлы).
Как видите, недостатки этого вида защиты более весомы, чем достоинства, поэтому в shareware демо-версии используются очень мало. Их можно распространять разве что дополнительно к ограниченным по времени или функционально версиям -- включать на CD-ROM, раздавать на выставках — т. е. применять исключительно в рекламных целях.
Ограниченная по времени версия
Ограниченная по времени (time-limited) версия — более распространенный вариант, хотя и более сложный для реализации. Незарегистрированная версия после установки на компьютере пользователя работает какой-то период времени, исчисляемый либо в днях (обычно 30 дней), либо в запусках (рис. 6.2). По истечении этого срока программа прекращает работать, выводя после запуска сообщение об окончании "trial period" и необходимости зарегистрироваться.
В чем же считать "испытательный срок" - в днях или запусках? Чаще всего отсчет ведется в днях. Тридцать дней — стандартная продолжительность этого срока, указанная в Уставе Ассоциации профессионалов shareware. Если же выбрать для отсчета запуски, то может получиться ситуация, когда пользователь еще не успел изучить работу с программой, а количество запусков уже превысило лимит незарегистрированной версии и программа отказывается работать — ведь невозможно предугадать, с какой интенсивностью программа будет использоваться. Мне как-то попалась "звонилка" (утилита для дозвона к интернет-провайдеру), "испытательный срок" которой исчислялся всего пятнадцатью запусками. Программа работала не очень корректно, из-за чего приходилось ее постоянно перезапускать, и когда милосердно отпущенные мне 15 запусков прошли, я так и не успел с ней разобраться. Естественно, о регистрации, которую настойчиво стала требовать программа, не могло быть и речи.
Сложность реализации этого вида защиты состоит в том, что ограничение работы по времени может быть снято и, таким образом, в руках пользователя, не заплатившего за программу ни копейки, окажется полнофункциональная версия.
Функционально ограниченная версия
В отличие от демо-версии, в функционально ограниченной версии возможности "урезаны" не окончательно, а только до регистрации программы. Код, с помощью которого реализуются эти функции, из файлов программы не удален, однако при запуске программа определяет, что она не зарегистрирована, и переходит в "ограниченный" режим работы.
Какие именно функции закрыть — решает, конечно, сам автор программы. Можно, например, запретить сохранение настроек. Графические редакторы обычно при сохранении изображения добавляют в него штамп "Сделано в зарегистрированной версии"; системы управления базами данных работают с ограниченным числом записей или таблиц программы поиска в Интернете, опрашивают только одну-две поисковых системы вместо "полного комплекта" и т. д. Главное — не перестараться с ограничением функций и не превратить свою программу в маломощную поделку, иначе пользователь может просто не оценить полезные свойства программы и решить, что регистрация ему не требуется. Нужно стараться не выкидывать какие-то функции, а ограничивать их мощь, чтобы пользователь попробовал их и хотел бы использовать в полную силу. Это своеобразная "приманка" в охоте за регистрация-ми пользователя. А вот если какие-то функции программы в незарегистрированной версии не доступны полностью и о них только рассказывается в справочной системе, то это является не таким сильным стимулом для пользователей.
Как и в случае с "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
Хакеры и крякеры
О них наслышан, наверное, каждый, кто хоть немного интересуется информационными технологиями, а уж компьютерными программами — особенно. Ведь, как известно, именно хакеры и крякеры занимаются взломом защит 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-программ.
Реализация защиты и ее взлом
Как видно из разд. "Виды защиты" этой главы, сегодня для shareware-рынка актуальны два типа защиты программ: ограничение по времени работы и ограничение по функциям. О демо-версиях говорить особенно не нужно, т. к. это очень простой и одновременно очень непопулярный вариант реализации защиты shareware-программ.
При ограничении по времени программа хранит в каком-нибудь файле дату первого запуска и при очередном запуске проверяет, сколько дней осталось до окончания ознакомительного срока. Если ограничение по времени исчисляется в количестве запусков, то программа при первом запуске записывает в файл начальное значение счетчика и при каждом последующем запуске это значение увеличивается па единицу и проверяется, не превышен ли лимит на число запусков, установленный автором. В случае положительного результата (ознакомительный срок закончен) программа перестает работать.
Что касается ограничения по функциям, то здесь тоже не нужно много объяснять. При старте программа проверяет, зарегистрирована ли она, и в зависимости от этого решает, разблокировать ли недоступные для незарегистрированных пользователей функции или нет.
В обоих случаях — при временном и функциональном ограничении — программа разблокируется посредством ввода регистрационного ключа. Эти ключи бывают двух видов: статические, которые заранее определены автором программы, и динамические, т. е. генерируемые в зависимости от каких-то исходных данных — чаще всего имени пользователя.
Как только программа появляется на shareware-рынке, она почти сразу привлекает внимание взломщиков, которые, немного потрудясь, выпускают к программе кряки.
Кряки делятся на две основные группы: патчи и кодогенераторы. Патч (patch) — это небольшая программка, которая модифицирует один или несколько файлов исходной программы таким образом, чтобы отключить защиту. Кодогенератор (keygen) — также небольшая программа, которая генерирует регистрационные ключи, введя которые можно разблокировать ту или иную shareware-программу (рис. 6.3). Иногда крякеры публикуют в Интернете не кодогенератор, а просто подобранный регистрационный номер (serial number, reg. code или просто serial code).
Нужно сказать, что защита большинства программ взламывается всего за 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 ), и воспользоваться ими — все равно, что приложить к программе подробную инструкцию по ее взлому.
Усиление защиты
А теперь — несколько рекомендаций и советов, которые могут помочь повысить стойкость защиты 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-файлов.
И, наконец, никогда и никому не рассказывайте, как устроена ваша защита.
Замечание
Любая защита, которую даже теоретически нельзя сломать, все-таки ломается, если к злоумышленнику попадает правильный регистрационный ключ (например, в результате покупки по украденному номеру кредитной карточки). Здесь — полная аналогия с бытом: любой самый совершенный замок откроется, если иметь ключ. Поэтому нужно не терять бдительности и помнить, что самая нерушимая защита — еще не решение проблемы кряков.
Надеюсь, эти советы помогут вам построить очень сложную и даже невозможную для взлома защиту. А если вы все-таки не уверены в своих силах -читайте следующий раздел.
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-проекта.
Наличие защиты в shareware-программах обусловлено самим принципом shareware: "Попробуй, прежде чем купить". Разработчик предоставляет свою программу для тестирования, а если программа понравится, то пользователь может оплатить регистрацию. Если бы распространение копий программы строго контролировалось, а все пользователи были известны, что называется, "в лицо", с получением денег за программу не было бы почти никаких проблем. Но shareware-программы скачиваются по Интернету огромным числом людей, находящихся от автора на большом расстоянии. Для того чтобы стимулировать пользователей оплачивать регистрацию, программисты включают в программу всевозможные ограничения, отличающие незарегистрированную версию от зарегистрированной.
В самом начале развития shareware-индустрии, во времена расцвета PC-Talk и PC-File (см. разд. "История shareware" гл. 1), условно-бесплатные программы не имели никаких ограничений. В документации автор просто указывал, что пользователи, если программа им понравится, могут прислать ему определенную сумму денег.
С появлением множества других shareware программ эта схема быстро потеряла свою эффективность. Многие разработчики на своем опыте убедились, что при отсутствии защиты программу покупают очень мало, зато при вставке в программу хотя бы экрана, напоминающего о необходимости регистрации продукта, число зарегистрированных пользователей резко увеличивается. Защиту не заменит даже то, что вместо денег за регистрацию требуется прислать всего лишь заполненную анкету: пользователей, действительно сделавших это, будут единицы. У пользователя должен быть реальный стимул зарегистрировать программу, одного лишь сообщения о ее статусе shareware в лицензионном соглашении недостаточно.
Несмотря на это, начинающие шароварщики до сих пор пытаются начать продавать свою программу без защиты, лишь с напоминанием о необходимости зарегистрироваться, указанным не в самом заметном месте — в справочной системе, файле readme.txt или диалоговом окне О программе. Многих вдохновляет пример 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-архиваторами и мультимедиа-плейерами — вряд ли они стали бы такими же популярными и прибыльными, как тогда. Поэтому не нужно полагаться на такую схему. Дайте пользователю почувствовать, что взамен своих денег он получил что-то вполне определенное.
Виды защиты
Существует три основных типа защиты shareware-программ: демо-версия, ограниченная по времени версия и функционально ограниченная версия.
Демо-версия
Демо-версия — самый простой для реализации, но одновременно самый неудобный вид защиты. Из программы просто удаляются некоторые фрагменты кода, в результате чего функциональные возможности программы сильно ограничиваются. Такая "урезанная" версия затем выкладывается на Web-сайт, а оплатившим регистрацию пользователям высылается "полная" версия по электронной или обычной почте либо сообщается "скрытый" от посторонних адрес, по которому ее можно скачать.
Достоинство этого варианта в том, что "взломать" саму программу невозможно — ведь программная защита как таковая в ЕХЕ-файле отсутствует. С другой стороны, зарегистрированная версия программы может легко стать доступной всем, а не только тем, кто ее оплатил. Например, кто-нибудь из купивших программу может выложить ее где-нибудь в Интернете или, если зарегистрированная версия не высылается по почте, а скачивается с Web-сервера — опубликовать "секретный" адрес для всеобщего пользования. Самое обидное, что у автора нет никаких шансов узнать, кто именно из пользователей сделал ему такую гадость (если только виновник сам не укажет себя).
Разработчику же распространение программы в виде демо-версии доставляет много хлопот. Например, рассылка зарегистрированных версий по электронной, не говоря уже об обычной, почте сопряжена с большими накладными расходами. Если же пользователи должны загружать "полную" версию с Web-сервера, то автор программы должен постоянно быть готовым к тому, что экземпляр полнофункциональной версии появится в свободном доступе где-нибудь в Сети, а убрать ее оттуда окажется очень непросто. Если разработчик захочет защититься от скачивания "полной" версии незарегистрированными пользователями с помощью опубликованного кем-то "секретного" адреса, ему следует поместить файл с дистрибутивом программы в специальный защищенный паролем каталог на своем сервере. Далее необходимо постоянно добавлять в настройки имена новых пользователей, имеющих право доступа к этому каталогу, а также удалять имена пользователей, опубликовавших свои логины и пароли в Интернете.
Демо-версии не так удобны и для пользователей. Например, для получения полной версии нужно обязательно иметь доступ в сеть Интернет (рассылка "полных" версий обычной почтой встречается очень редко), а это не всегда возможно, ведь дистрибутив программы может быть переписан у знакомых или куплен на CD-ROM со сборником shareware-программ. Кроме того, доступ этот должен быть довольно быстрым, чтобы перекачать из почтового ящика большой файл (кстати, многие почтовые серверы настроены таким образом, что не принимают большие файлы).
Как видите, недостатки этого вида защиты более весомы, чем достоинства, поэтому в shareware демо-версии используются очень мало. Их можно распространять разве что дополнительно к ограниченным по времени или функционально версиям -- включать на CD-ROM, раздавать на выставках — т. е. применять исключительно в рекламных целях.
Ограниченная по времени версия
Ограниченная по времени (time-limited) версия — более распространенный вариант, хотя и более сложный для реализации. Незарегистрированная версия после установки на компьютере пользователя работает какой-то период времени, исчисляемый либо в днях (обычно 30 дней), либо в запусках (рис. 6.2). По истечении этого срока программа прекращает работать, выводя после запуска сообщение об окончании "trial period" и необходимости зарегистрироваться.
В чем же считать "испытательный срок" - в днях или запусках? Чаще всего отсчет ведется в днях. Тридцать дней — стандартная продолжительность этого срока, указанная в Уставе Ассоциации профессионалов shareware. Если же выбрать для отсчета запуски, то может получиться ситуация, когда пользователь еще не успел изучить работу с программой, а количество запусков уже превысило лимит незарегистрированной версии и программа отказывается работать — ведь невозможно предугадать, с какой интенсивностью программа будет использоваться. Мне как-то попалась "звонилка" (утилита для дозвона к интернет-провайдеру), "испытательный срок" которой исчислялся всего пятнадцатью запусками. Программа работала не очень корректно, из-за чего приходилось ее постоянно перезапускать, и когда милосердно отпущенные мне 15 запусков прошли, я так и не успел с ней разобраться. Естественно, о регистрации, которую настойчиво стала требовать программа, не могло быть и речи.
Сложность реализации этого вида защиты состоит в том, что ограничение работы по времени может быть снято и, таким образом, в руках пользователя, не заплатившего за программу ни копейки, окажется полнофункциональная версия.
Функционально ограниченная версия
В отличие от демо-версии, в функционально ограниченной версии возможности "урезаны" не окончательно, а только до регистрации программы. Код, с помощью которого реализуются эти функции, из файлов программы не удален, однако при запуске программа определяет, что она не зарегистрирована, и переходит в "ограниченный" режим работы.
Какие именно функции закрыть — решает, конечно, сам автор программы. Можно, например, запретить сохранение настроек. Графические редакторы обычно при сохранении изображения добавляют в него штамп "Сделано в зарегистрированной версии"; системы управления базами данных работают с ограниченным числом записей или таблиц программы поиска в Интернете, опрашивают только одну-две поисковых системы вместо "полного комплекта" и т. д. Главное — не перестараться с ограничением функций и не превратить свою программу в маломощную поделку, иначе пользователь может просто не оценить полезные свойства программы и решить, что регистрация ему не требуется. Нужно стараться не выкидывать какие-то функции, а ограничивать их мощь, чтобы пользователь попробовал их и хотел бы использовать в полную силу. Это своеобразная "приманка" в охоте за регистрация-ми пользователя. А вот если какие-то функции программы в незарегистрированной версии не доступны полностью и о них только рассказывается в справочной системе, то это является не таким сильным стимулом для пользователей.
Как и в случае с "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
Хакеры и крякеры
О них наслышан, наверное, каждый, кто хоть немного интересуется информационными технологиями, а уж компьютерными программами — особенно. Ведь, как известно, именно хакеры и крякеры занимаются взломом защит 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-программ.
Реализация защиты и ее взлом
Как видно из разд. "Виды защиты" этой главы, сегодня для shareware-рынка актуальны два типа защиты программ: ограничение по времени работы и ограничение по функциям. О демо-версиях говорить особенно не нужно, т. к. это очень простой и одновременно очень непопулярный вариант реализации защиты shareware-программ.
При ограничении по времени программа хранит в каком-нибудь файле дату первого запуска и при очередном запуске проверяет, сколько дней осталось до окончания ознакомительного срока. Если ограничение по времени исчисляется в количестве запусков, то программа при первом запуске записывает в файл начальное значение счетчика и при каждом последующем запуске это значение увеличивается па единицу и проверяется, не превышен ли лимит на число запусков, установленный автором. В случае положительного результата (ознакомительный срок закончен) программа перестает работать.
Что касается ограничения по функциям, то здесь тоже не нужно много объяснять. При старте программа проверяет, зарегистрирована ли она, и в зависимости от этого решает, разблокировать ли недоступные для незарегистрированных пользователей функции или нет.
В обоих случаях — при временном и функциональном ограничении — программа разблокируется посредством ввода регистрационного ключа. Эти ключи бывают двух видов: статические, которые заранее определены автором программы, и динамические, т. е. генерируемые в зависимости от каких-то исходных данных — чаще всего имени пользователя.
Как только программа появляется на shareware-рынке, она почти сразу привлекает внимание взломщиков, которые, немного потрудясь, выпускают к программе кряки.
Кряки делятся на две основные группы: патчи и кодогенераторы. Патч (patch) — это небольшая программка, которая модифицирует один или несколько файлов исходной программы таким образом, чтобы отключить защиту. Кодогенератор (keygen) — также небольшая программа, которая генерирует регистрационные ключи, введя которые можно разблокировать ту или иную shareware-программу (рис. 6.3). Иногда крякеры публикуют в Интернете не кодогенератор, а просто подобранный регистрационный номер (serial number, reg. code или просто serial code).
Нужно сказать, что защита большинства программ взламывается всего за 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 ), и воспользоваться ими — все равно, что приложить к программе подробную инструкцию по ее взлому.
Усиление защиты
А теперь — несколько рекомендаций и советов, которые могут помочь повысить стойкость защиты 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-файлов.
И, наконец, никогда и никому не рассказывайте, как устроена ваша защита.
Замечание
Любая защита, которую даже теоретически нельзя сломать, все-таки ломается, если к злоумышленнику попадает правильный регистрационный ключ (например, в результате покупки по украденному номеру кредитной карточки). Здесь — полная аналогия с бытом: любой самый совершенный замок откроется, если иметь ключ. Поэтому нужно не терять бдительности и помнить, что самая нерушимая защита — еще не решение проблемы кряков.
Надеюсь, эти советы помогут вам построить очень сложную и даже невозможную для взлома защиту. А если вы все-таки не уверены в своих силах -читайте следующий раздел.
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-проекта.
Сообщений:
ГЛАВА 7.
Документация
Зачем нужна документация
Многие разработчики считают, что справочная система для их продуктов совершенно не нужна. Это и не удивительно: автор досконально знает свое творение, и оно кажется ему абсолютно простым для понимания и освоения. Если быть откровенным, то у программистов существует прямо-таки природное отвращение к написанию документации: это занятие представляется им на редкость нудным и скучным. Многие из них согласны проводить целые дни и ночи напролет, как говорится, "в глубокой отладке", но ни в коем случае не описывать все эти меню, диалоговые окна и т: п.
Между тем документация — это одно из основных отличий программы "для себя" от серьезного продукта, который можно успешно продавать на shareware-рынке, С помощью Справки пользователи могут быстро найти ответы на возникающие у них вопросы по работе с программой, что произведет на них благоприятное впечатление и поможет сделать выбор в пользу оплаты регистрации продукта. А многие компьютерные журналы и online-архивы программного обеспечения даже не рассматривают программы, не имеющие справочной системы (рис. 7.1), не говоря уже о получении положительных отзывов и наград ("звезд", "коров" и т. п.) от обозревателей. И наконец, хорошо составленная справочная система избавляет разработчика от необходимости отвечать на одни и те же вопросы пользователей.
Что касается того, что "моей программе Справка не нужна — там и так все понятно"... Практика показывает, что у большинства пользователей рано или поздно возникают затруднения при освоении программ. К тому же уровень квалификации у всех разный: не каждый может разобраться, например, в специфическом формате файлов или механизме записи макросов
Виды документации
Текстовый файл
Чисто теоретически, документация может быть выполнена в виде обычного текстового файла — например, readme.txt. Однако для серьезной shareware-программы один текстовый файл — явно недостаточно. В крайнем случае, readme.txt может быть временной заменой справочной системы на этапе, когда программа существует в виде бета-версии. У готового же к продажам продукта документация должна быть оформлена в одном из форматов, специально предназначенных для справочной системы.
В то же время файл readme.txt тоже должен входить в дистрибутив программы, служа важным дополнением "основной" документации. Readme.txt обычно содержит краткую информацию о продукте: номер версии, дата выпуска, имя разработчика, адрес домашней страницы, важные заметки о текущем выпуске (новые возможности, необходимость установки каких-либо компонентов и т. п.). Особенности, из-за которых формат ASCII не подходит для создания полноценных справочных систем — отсутствие возможностей для удобной навигации по страницам и поиска,. — здесь являются достоинством. Благодаря им, пользователь может быстро получить доступ к важной информации, не путаясь в многочисленных страницах традиционной справочной системы.
WinHelp
WinHelp (рис. 7.2) — настоящий долгожитель среди форматов справочных систем. Программа winhelp.exe, обеспечивавшая работу HLP-файлов, входила в состав еще шестнадцатиразрядных версий Windows. Несмотря на свой почтенный возраст, WinHelp — довольно эффективный формат для организации документации: он позволяет хранить в HLP-файлах форматированный текст (включая таблицы, списки и тому подобные элементы), графику, видео, анимацию, звук, проводить поиск, индексировать справочный файл для более эффективного поиска.
У WinHelp очень мало недостатков. Один из самых серьезных — невозможность печати всего справочного файла целиком, в результате чего приходится посылать на принтер каждый раздел отдельно. Другой минус — то, что каждый экземпляр справочной системы может состоять из пяти файлов (табл. 7.1): не слишком изящный способ организации документации.
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 и "настоящей" Справкой.
Существует также несколько аналогичных форматов HTML Help, также использующих язык HTML для описания структуры справочной системы: NetHelp от компании Netscape (рис. 7.4), WebHelp от Oracle и, наконец, JavaHelp от Sun. Однако эти форматы не получили сколько-нибудь широкого распространения и используются в основном в продуктах соответствующих фирм-разработчиков.
Adobe Acrobat
Adobe Acrobat был разработан компанией Adobe как более эффективная альтернатива HTML. Как известно, основное достоинство HTML -независимость платформы: HTML-документ можно прочитать на компьютере с любой операционной системой, главное, чтобы было установлено средство просмотра HTML-файлов. Однако при этом документ выглядит на разных компьютерах по-разному: это зависит от установленных на компьютере пользователя шрифтов и других системных настроек, а также названия и версии средства просмотра HTML. Как известно, страница, отлично отображаемая в Internet Explorer, может вообще не показываться в Netscape Navigator, и наоборот. А уж многочисленные мелкие, но раздражающие искажения, которые возникают при просмотре страниц в разных браузерах, давно стали предметом горячих споров в интернет-конференциях.
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 можно обойтись бесплатными продуктами.
Печатная документация
Документация, отпечатанная типографским способом, столь привычная для коммерческих программных продуктов, для shareware — явление очень редкое. Если она все-таки имеется, то обычно продается отдельно и за довольно большие деньги, порой превышающие стоимость самой программы.
Документация на Web-сайте
Некоторые разработчики слишком буквально понимают термин "online help", который на самом деле обозначает справочную систему в электронном, а не печатном, виде. Поэтому при нажатии клавиши <F1> или вызова меню Help в их программе, запускается установленный в системе интернет-браузер и загружает... раздел "Справка" с Web-сайта разработчика программы!
Это пример того, как не следует делать документацию. Ведь у пользователя она всегда должна быть под рукой, а размещение справочной системы в
Интернете часто приводит к тому, что пользователь не может получить к ней доступ тогда, когда ему требуется помощь. Например, пользователь может скачать программу дома, а использовать ее на работе, где по каким-либо причинам выход в Интернет может отсутствовать, и наоборот. И даже если доступ в Интернет на компьютере имеется, то домашнему пользователю для выяснения каких-то деталей относительно работы с программой нужно дозваниваться до интернет-провайдера, что при частых обращениях к справочной системе очень раздражает. Кроме того, скорость доступа к справочной системе, размещенной в Сети, не сравнима со скоростью чтения файла Справки с жесткого диска компьютера. И наконец, не нужно забывать, что за пользование Интернетом провайдеры берут деньги, а значит, доступ к справочной системе программы тоже будет платным!
WinHelp или HTML Help?
Как видно из предыдущего раздела, сегодня существует два реальных варианта для реализации справочной системы: WinHelp и HTML Help. Какой же из них предпочесть?
Возможности
Конечно, по функциональности справочной системы 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.
Скорость работы
Как уже упоминалось, для чтения СНМ-файлов формата HTML Help используется браузер Internet Explorer, который вызывает много нареканий за высокие требования к системным ресурсам и относительно медленную работу. Действительно, при вызове Справки в формате HTML Help, особенно имеющей довольно большой объем, задержки в работе по сравнению с WinHelp хорошо заметны.
Перспектива
Здесь, конечно же, все козыри у 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, позволяя пользователю самому выбрать предпочтительный формат. Программ с таким оригинальным решением проблемы выбора формата документации я пока не встречал, но, если бы это случилось, то лично на меня, в том числе и как на пользователя, это произвело бы большое впечатление.
Как писать документацию
Прежде чем писать документацию, нужно определить ее будущую структуру, т. е. из каких разделов она будет состоять.
На выбор структуры справочной системы 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 (Справка), т. к. в этом случае приходится самостоятельно искать нужный раздел Справки. Зато они вполне готовы нажать клавишу <F1> в каком-либо диалоговом окне или воспользоваться кнопкой с вопросом ("What's This?" "Что это такое?"), чтобы получить пояснение именно по текущей ситуации.
Разработка контекстной системы помощи — это вопрос, затрагивающий и тему построения интерфейсов. Есть, например, даже такой принцип: "Предлагайте помощь". Для того чтобы пользователь программы при работе с ней чувствовал себя человеком и видел, что автор хочет сделать его работу наиболее простой и понятной, нужно позаботиться о том, чтобы программа всегда могла бы пояснить пользователю порядок действий в текущий момент.
Конечно, не нужно предлагать помощь также навязчиво, как известная скрепка-помощник из Microsoft Office (рис. 7.6). Созданный для придания "ящику" большей интеллектуальности и, так сказать, человечности, Помощник заслужил неоднозначные отзывы. У некоторых пользователей, которые не смогли понять, как отключить Помощника, скачущая по экрану скрепка даже вызывала истерику
Лучше сосредоточить свои усилия в другом направлении. Например, все диалоговые окна программы должны содержать кнопку Help (Справка). Это касается не только диалогов, в которых непосредственно осуществляется и ввод данных (например, окон Настройка), но и информационных диалогов, например, диагностических или сообщений об ошибках.
Так как при появлении на экране диалога у пользователя чаще всего появляется вопрос "Почему?", то вполне стандартным приемом является дополнение текста диалога подсказкой: "For help, press F1" (Для справки, нажмите F1). Использование такого предложения помощи полезно не только в диалогах, но и в обычных окнах, где оно выводится в строку состояния сразу после старта программы. И даже если пользователю в настоящий момент справка не нужна, такое ненавязчивое предложение помощи как бы сигнализирует, что программа, в случае необходимости, может дать пояснения.
Нужно помнить, что контекстная помощь — это не только разделы в файле Справки, которые вызываются из соответствующих частей программы. К контекстной помощи также относятся подсказки, появляющиеся в строке состояния, когда пользователь ведет мышью по пунктам меню. Не нужно забывать и про всплывающие подсказки к кнопкам на панелях инструментов и секциям строки состояния.
С контекстной справкой связан интересный случай, который еще раз напомнил не только составителям документации, но и проектировщикам интерфейсов о том, что с пользователями нужно обращаться максимально вежливо и учтиво. Как рассказал один из посетителей Web-сайта iarchitect.com, однажды справочная система инженерного пакета AutoCAD Mechanical от фирмы Autodesk показала вот такое сообщение.
Кому-то это сообщение - "Нажми здесь, идиот" -- может показаться смешным, но на самом деле оно выражает скорее пренебрежительное отношение к пользователю. Как оказалось, человек, ответственный за этот участок программы, пошутил, полагая, что это сообщение не увидит ни один пользователь. Но его работодатель, компания Autodesk, не оценила его чувство юмора: служащий был уволен, а тысячам заказчиков компании были разосланы письма с извинениями.
Средства создания документации
Сделать справочную систему не так уж сложно. Для создания справочных файлов в формате 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 не поддерживается) распознает все содержащиеся в программе диалоги и позволяет указать для них подсказки. После этого текст подсказок записывается обратно в ЕХЕ-файл (!) — вот такое простое до гениальности решение.
Как видите, у разработчика существует большой выбор средств для создания справочных систем. Остается посмотреть их и выбрать, то, которое придется по душе.
Многие разработчики считают, что справочная система для их продуктов совершенно не нужна. Это и не удивительно: автор досконально знает свое творение, и оно кажется ему абсолютно простым для понимания и освоения. Если быть откровенным, то у программистов существует прямо-таки природное отвращение к написанию документации: это занятие представляется им на редкость нудным и скучным. Многие из них согласны проводить целые дни и ночи напролет, как говорится, "в глубокой отладке", но ни в коем случае не описывать все эти меню, диалоговые окна и т: п.
Между тем документация — это одно из основных отличий программы "для себя" от серьезного продукта, который можно успешно продавать на shareware-рынке, С помощью Справки пользователи могут быстро найти ответы на возникающие у них вопросы по работе с программой, что произведет на них благоприятное впечатление и поможет сделать выбор в пользу оплаты регистрации продукта. А многие компьютерные журналы и online-архивы программного обеспечения даже не рассматривают программы, не имеющие справочной системы (рис. 7.1), не говоря уже о получении положительных отзывов и наград ("звезд", "коров" и т. п.) от обозревателей. И наконец, хорошо составленная справочная система избавляет разработчика от необходимости отвечать на одни и те же вопросы пользователей.
Что касается того, что "моей программе Справка не нужна — там и так все понятно"... Практика показывает, что у большинства пользователей рано или поздно возникают затруднения при освоении программ. К тому же уровень квалификации у всех разный: не каждый может разобраться, например, в специфическом формате файлов или механизме записи макросов
Виды документации
Текстовый файл
Чисто теоретически, документация может быть выполнена в виде обычного текстового файла — например, readme.txt. Однако для серьезной shareware-программы один текстовый файл — явно недостаточно. В крайнем случае, readme.txt может быть временной заменой справочной системы на этапе, когда программа существует в виде бета-версии. У готового же к продажам продукта документация должна быть оформлена в одном из форматов, специально предназначенных для справочной системы.
В то же время файл readme.txt тоже должен входить в дистрибутив программы, служа важным дополнением "основной" документации. Readme.txt обычно содержит краткую информацию о продукте: номер версии, дата выпуска, имя разработчика, адрес домашней страницы, важные заметки о текущем выпуске (новые возможности, необходимость установки каких-либо компонентов и т. п.). Особенности, из-за которых формат ASCII не подходит для создания полноценных справочных систем — отсутствие возможностей для удобной навигации по страницам и поиска,. — здесь являются достоинством. Благодаря им, пользователь может быстро получить доступ к важной информации, не путаясь в многочисленных страницах традиционной справочной системы.
WinHelp
WinHelp (рис. 7.2) — настоящий долгожитель среди форматов справочных систем. Программа winhelp.exe, обеспечивавшая работу HLP-файлов, входила в состав еще шестнадцатиразрядных версий Windows. Несмотря на свой почтенный возраст, WinHelp — довольно эффективный формат для организации документации: он позволяет хранить в HLP-файлах форматированный текст (включая таблицы, списки и тому подобные элементы), графику, видео, анимацию, звук, проводить поиск, индексировать справочный файл для более эффективного поиска.
У WinHelp очень мало недостатков. Один из самых серьезных — невозможность печати всего справочного файла целиком, в результате чего приходится посылать на принтер каждый раздел отдельно. Другой минус — то, что каждый экземпляр справочной системы может состоять из пяти файлов (табл. 7.1): не слишком изящный способ организации документации.
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 и "настоящей" Справкой.
Существует также несколько аналогичных форматов HTML Help, также использующих язык HTML для описания структуры справочной системы: NetHelp от компании Netscape (рис. 7.4), WebHelp от Oracle и, наконец, JavaHelp от Sun. Однако эти форматы не получили сколько-нибудь широкого распространения и используются в основном в продуктах соответствующих фирм-разработчиков.
Adobe Acrobat
Adobe Acrobat был разработан компанией Adobe как более эффективная альтернатива HTML. Как известно, основное достоинство HTML -независимость платформы: HTML-документ можно прочитать на компьютере с любой операционной системой, главное, чтобы было установлено средство просмотра HTML-файлов. Однако при этом документ выглядит на разных компьютерах по-разному: это зависит от установленных на компьютере пользователя шрифтов и других системных настроек, а также названия и версии средства просмотра HTML. Как известно, страница, отлично отображаемая в Internet Explorer, может вообще не показываться в Netscape Navigator, и наоборот. А уж многочисленные мелкие, но раздражающие искажения, которые возникают при просмотре страниц в разных браузерах, давно стали предметом горячих споров в интернет-конференциях.
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 можно обойтись бесплатными продуктами.
Печатная документация
Документация, отпечатанная типографским способом, столь привычная для коммерческих программных продуктов, для shareware — явление очень редкое. Если она все-таки имеется, то обычно продается отдельно и за довольно большие деньги, порой превышающие стоимость самой программы.
Документация на Web-сайте
Некоторые разработчики слишком буквально понимают термин "online help", который на самом деле обозначает справочную систему в электронном, а не печатном, виде. Поэтому при нажатии клавиши <F1> или вызова меню Help в их программе, запускается установленный в системе интернет-браузер и загружает... раздел "Справка" с Web-сайта разработчика программы!
Это пример того, как не следует делать документацию. Ведь у пользователя она всегда должна быть под рукой, а размещение справочной системы в
Интернете часто приводит к тому, что пользователь не может получить к ней доступ тогда, когда ему требуется помощь. Например, пользователь может скачать программу дома, а использовать ее на работе, где по каким-либо причинам выход в Интернет может отсутствовать, и наоборот. И даже если доступ в Интернет на компьютере имеется, то домашнему пользователю для выяснения каких-то деталей относительно работы с программой нужно дозваниваться до интернет-провайдера, что при частых обращениях к справочной системе очень раздражает. Кроме того, скорость доступа к справочной системе, размещенной в Сети, не сравнима со скоростью чтения файла Справки с жесткого диска компьютера. И наконец, не нужно забывать, что за пользование Интернетом провайдеры берут деньги, а значит, доступ к справочной системе программы тоже будет платным!
WinHelp или HTML Help?
Как видно из предыдущего раздела, сегодня существует два реальных варианта для реализации справочной системы: WinHelp и HTML Help. Какой же из них предпочесть?
Возможности
Конечно, по функциональности справочной системы 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.
Скорость работы
Как уже упоминалось, для чтения СНМ-файлов формата HTML Help используется браузер Internet Explorer, который вызывает много нареканий за высокие требования к системным ресурсам и относительно медленную работу. Действительно, при вызове Справки в формате HTML Help, особенно имеющей довольно большой объем, задержки в работе по сравнению с WinHelp хорошо заметны.
Перспектива
Здесь, конечно же, все козыри у 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, позволяя пользователю самому выбрать предпочтительный формат. Программ с таким оригинальным решением проблемы выбора формата документации я пока не встречал, но, если бы это случилось, то лично на меня, в том числе и как на пользователя, это произвело бы большое впечатление.
Как писать документацию
Прежде чем писать документацию, нужно определить ее будущую структуру, т. е. из каких разделов она будет состоять.
На выбор структуры справочной системы 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 (Справка), т. к. в этом случае приходится самостоятельно искать нужный раздел Справки. Зато они вполне готовы нажать клавишу <F1> в каком-либо диалоговом окне или воспользоваться кнопкой с вопросом ("What's This?" "Что это такое?"), чтобы получить пояснение именно по текущей ситуации.
Разработка контекстной системы помощи — это вопрос, затрагивающий и тему построения интерфейсов. Есть, например, даже такой принцип: "Предлагайте помощь". Для того чтобы пользователь программы при работе с ней чувствовал себя человеком и видел, что автор хочет сделать его работу наиболее простой и понятной, нужно позаботиться о том, чтобы программа всегда могла бы пояснить пользователю порядок действий в текущий момент.
Конечно, не нужно предлагать помощь также навязчиво, как известная скрепка-помощник из Microsoft Office (рис. 7.6). Созданный для придания "ящику" большей интеллектуальности и, так сказать, человечности, Помощник заслужил неоднозначные отзывы. У некоторых пользователей, которые не смогли понять, как отключить Помощника, скачущая по экрану скрепка даже вызывала истерику
Лучше сосредоточить свои усилия в другом направлении. Например, все диалоговые окна программы должны содержать кнопку Help (Справка). Это касается не только диалогов, в которых непосредственно осуществляется и ввод данных (например, окон Настройка), но и информационных диалогов, например, диагностических или сообщений об ошибках.
Так как при появлении на экране диалога у пользователя чаще всего появляется вопрос "Почему?", то вполне стандартным приемом является дополнение текста диалога подсказкой: "For help, press F1" (Для справки, нажмите F1). Использование такого предложения помощи полезно не только в диалогах, но и в обычных окнах, где оно выводится в строку состояния сразу после старта программы. И даже если пользователю в настоящий момент справка не нужна, такое ненавязчивое предложение помощи как бы сигнализирует, что программа, в случае необходимости, может дать пояснения.
Нужно помнить, что контекстная помощь — это не только разделы в файле Справки, которые вызываются из соответствующих частей программы. К контекстной помощи также относятся подсказки, появляющиеся в строке состояния, когда пользователь ведет мышью по пунктам меню. Не нужно забывать и про всплывающие подсказки к кнопкам на панелях инструментов и секциям строки состояния.
С контекстной справкой связан интересный случай, который еще раз напомнил не только составителям документации, но и проектировщикам интерфейсов о том, что с пользователями нужно обращаться максимально вежливо и учтиво. Как рассказал один из посетителей Web-сайта iarchitect.com, однажды справочная система инженерного пакета AutoCAD Mechanical от фирмы Autodesk показала вот такое сообщение.
Кому-то это сообщение - "Нажми здесь, идиот" -- может показаться смешным, но на самом деле оно выражает скорее пренебрежительное отношение к пользователю. Как оказалось, человек, ответственный за этот участок программы, пошутил, полагая, что это сообщение не увидит ни один пользователь. Но его работодатель, компания Autodesk, не оценила его чувство юмора: служащий был уволен, а тысячам заказчиков компании были разосланы письма с извинениями.
Средства создания документации
Сделать справочную систему не так уж сложно. Для создания справочных файлов в формате 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 не поддерживается) распознает все содержащиеся в программе диалоги и позволяет указать для них подсказки. После этого текст подсказок записывается обратно в ЕХЕ-файл (!) — вот такое простое до гениальности решение.
Как видите, у разработчика существует большой выбор средств для создания справочных систем. Остается посмотреть их и выбрать, то, которое придется по душе.
Администратор
Сообщений: 484
Нет на сайте
Маг Илья Герман, по благодарным отзывам, признан самым сильным магом России в 2009 году. По поводу его деятельности существует масса положительных отзывов. Маг Илья Н Герман – специалист в области белой и черной магии, любовной магии, любовных приворотов и отворотов, магических воздействий, любовных заговоров, обрядов, ясновидения и экстрасенсорики. Обладая врожденными экстрасенсорными способностями, имеет возможность управлять поведением человека на расстоянии и влиять на различного рода ситуации. В 2001 году Словацкой Академией Высшей Магии ему присвоена степень академика Высшей магии. В процессе своей работы разработал несколько уникальных методов, позволяющих корректировать энергетический потенциал человека и получать моментальный результат в моделировании поведения человека на расстоянии.
Данные методы является эксклюзивными, так как, в отличии от повсеместно применяемых «бабушкиных способов», позволяют получать моментальный результат, контролировать ход
воздействия и являются абсолютно безвредными. Помимо этого, И.Н.Герман работает методами, позволяющими избавить человека от негативных зависимостей, таких как алкоголизм, наркомания, игромания и др. При этом не страдает психика пациента, что часто происходит при обычных методах медицинского кодирования.
C 2007 года Илья Николаевич Герман успешно применяет уникальный авторский метод коррекции биопотенциала организма, что позволяет быстро избавиться от тяжелых хронических болезней, ранее не поддававшихся обычному медицинскому лечению. Многие
Вся проводимая деятельность узаконена. На все виды услуг предоставляется гарантия. Имеется лицензия на право деятельности и разрешение Комитета по контролю за деятельностью
магов и целителей на территории РФ.
Маг Илья Герман запатентовал и успешно практикует следующие авторские методы воздействий:
* Трансфермальный приворот (любовный приворот, самый сильный авторский приворот в сфере любовный магии).По отзывам благодарных клиентов можно сделать вывод, что этот приворот является реально действующим.
* Код на удачу в деньгах и личной жизни (открытие скрытого потенциала человека, установка персональной информационной программы, что позволяет резко поднять бизнес,
карьеру, привлечь финансовое благополучие даже в самых запущенных случаях, а также изменить личную жизнь. Данный метод, судя по отзывам о работе
Ильи Германа, известен многим постоянным пациентам И.Н.Германа, а ныне преуспевающим людям, как "таблетка от безденежья").
* Зеркальная защита (установка данного вида защиты авторским методом И.Н.Германа позволяет полностью избавиться от любых негативных влияний, восстановить психику и вернуть
состояние человека в прежний гармоничный вид. После установки зеркальной защиты никто не сможет оказать никакого негативного воздействия на человека. При этом происходит снятие сглаза или порчи навсегда.
* Коррекция биопотенциала (позволяет навсегда избавиться от тяжелых хронических заболеваний различной этиологии, в т.ч. бесплодия, психических расстройств и мн.др.).
Судя по отзывам о работе Ильи Германа, он является наиболее сильным магом и действительно оказывает реальную помощь людям. Именно поэтому многие клиенты благодарят его и
оставляют положительные отзывы о работе Ильи Германа.
Более подробную информацию и отзывы о работе Ильи Германа можно найти на сайте
http://www.mukhamadzokir1c.nm.ru/OVGssgElxu.htm Отзыв о маге Германе
снять черную магию
как снять порчу на здоровье
отворот
от сглаза латынь
сонник развод с мужем
приворот мужа
скачать бесплатно любовный приворот
порча сглаз наговор
порча на работу
приворот пермь
удачный приворот
приворот на здоровье
хочу научиться привороту
приворот на месячные
любовный приворот по фото
привороты заговоры на любовь
как приворожить парня
что помогает от сглаза
остуда рассорка
как вернуть любовь любимого
как помириться с любимым человеком
любовный приворот
форма акта порчи имущества
снять порчу в омске
чёрная и белая магия заговоры
птицефабрика порча земель
отношения с мужем после развода
Маг Илья Герман, по благодарным отзывам, признан самым сильным магом России в 2009 году. По поводу его деятельности существует масса положительных отзывов. Маг Илья Н Герман – специалист в области белой и черной магии, любовной магии, любовных приворотов и отворотов, магических воздействий, любовных заговоров, обрядов, ясновидения и экстрасенсорики. Обладая врожденными экстрасенсорными способностями, имеет возможность управлять поведением человека на расстоянии и влиять на различного рода ситуации. В 2001 году Словацкой Академией Высшей Магии ему присвоена степень академика Высшей магии. В процессе своей работы разработал несколько уникальных методов, позволяющих корректировать энергетический потенциал человека и получать моментальный результат в моделировании поведения человека на расстоянии.
Данные методы является эксклюзивными, так как, в отличии от повсеместно применяемых «бабушкиных способов», позволяют получать моментальный результат, контролировать ход
воздействия и являются абсолютно безвредными. Помимо этого, И.Н.Герман работает методами, позволяющими избавить человека от негативных зависимостей, таких как алкоголизм, наркомания, игромания и др. При этом не страдает психика пациента, что часто происходит при обычных методах медицинского кодирования.
C 2007 года Илья Николаевич Герман успешно применяет уникальный авторский метод коррекции биопотенциала организма, что позволяет быстро избавиться от тяжелых хронических болезней, ранее не поддававшихся обычному медицинскому лечению. Многие
Вся проводимая деятельность узаконена. На все виды услуг предоставляется гарантия. Имеется лицензия на право деятельности и разрешение Комитета по контролю за деятельностью
магов и целителей на территории РФ.
Маг Илья Герман запатентовал и успешно практикует следующие авторские методы воздействий:
* Трансфермальный приворот (любовный приворот, самый сильный авторский приворот в сфере любовный магии).По отзывам благодарных клиентов можно сделать вывод, что этот приворот является реально действующим.
* Код на удачу в деньгах и личной жизни (открытие скрытого потенциала человека, установка персональной информационной программы, что позволяет резко поднять бизнес,
карьеру, привлечь финансовое благополучие даже в самых запущенных случаях, а также изменить личную жизнь. Данный метод, судя по отзывам о работе
Ильи Германа, известен многим постоянным пациентам И.Н.Германа, а ныне преуспевающим людям, как "таблетка от безденежья").
* Зеркальная защита (установка данного вида защиты авторским методом И.Н.Германа позволяет полностью избавиться от любых негативных влияний, восстановить психику и вернуть
состояние человека в прежний гармоничный вид. После установки зеркальной защиты никто не сможет оказать никакого негативного воздействия на человека. При этом происходит снятие сглаза или порчи навсегда.
* Коррекция биопотенциала (позволяет навсегда избавиться от тяжелых хронических заболеваний различной этиологии, в т.ч. бесплодия, психических расстройств и мн.др.).
Судя по отзывам о работе Ильи Германа, он является наиболее сильным магом и действительно оказывает реальную помощь людям. Именно поэтому многие клиенты благодарят его и
оставляют положительные отзывы о работе Ильи Германа.
Более подробную информацию и отзывы о работе Ильи Германа можно найти на сайте
http://www.mukhamadzokir1c.nm.ru/OVGssgElxu.htm Отзыв о маге Германе
снять черную магию
как снять порчу на здоровье
отворот
от сглаза латынь
сонник развод с мужем
приворот мужа
скачать бесплатно любовный приворот
порча сглаз наговор
порча на работу
приворот пермь
удачный приворот
приворот на здоровье
хочу научиться привороту
приворот на месячные
любовный приворот по фото
привороты заговоры на любовь
как приворожить парня
что помогает от сглаза
остуда рассорка
как вернуть любовь любимого
как помириться с любимым человеком
любовный приворот
форма акта порчи имущества
снять порчу в омске
чёрная и белая магия заговоры
птицефабрика порча земель
отношения с мужем после развода
Гость
Quote (Boictiohomb)
Маг Илья Герман, по благодарным отзывам, признан самым сильным магом России в 2009 году. По поводу его деятельности существует масса положительных отзывов.
Простите, если вдруг мешаю, но чтото я совсем не выжу ничего общего между Вашим германом и программированием.
Вам не кажется, что раздел можно было подобрать, более схожий с тематикой Вашего поста.
Маг Илья Герман, по благодарным отзывам, признан самым сильным магом России в 2009 году. По поводу его деятельности существует масса положительных отзывов.
Простите, если вдруг мешаю, но чтото я совсем не выжу ничего общего между Вашим германом и программированием.
Вам не кажется, что раздел можно было подобрать, более схожий с тематикой Вашего поста.
Заблокированный
Сообщений: 571
Нет на сайте
Всем привет начал собирать прогу наебка для лохов мне надо как то сделать что бы при нажатии на кнопку вход логин и парол которые ввели в поля отпровлялось на мое мыло подскожите плизззз.
Делаю через PHP Devel Studio 2.0
Всем привет начал собирать прогу наебка для лохов мне надо как то сделать что бы при нажатии на кнопку вход логин и парол которые ввели в поля отпровлялось на мое мыло подскожите плизззз.
Делаю через PHP Devel Studio 2.0
Гость
Quote (Гость)
Всем привет начал собирать прогу наебка для лохов мне надо как то сделать что бы при нажатии на кнопку вход логин и парол которые ввели в поля отпровлялось на мое мыло подскожите плизззз.
Делаю через PHP Devel Studio 2.0
хм, а с чего вы взяли что у вас чтото получиться?
А вообще это уголовно наказуемо, поэтому наврядли Вам здесь ктото поможет...
Всем привет начал собирать прогу наебка для лохов мне надо как то сделать что бы при нажатии на кнопку вход логин и парол которые ввели в поля отпровлялось на мое мыло подскожите плизззз.
Делаю через PHP Devel Studio 2.0
хм, а с чего вы взяли что у вас чтото получиться?
А вообще это уголовно наказуемо, поэтому наврядли Вам здесь ктото поможет...
Гость
Как можно монетизировать программу, не делая её платной? У меня есть программа, есть ли какие-нибудь партнерские программы для приложений чтоли?
Вы любите играть, играть много и часто, находите в этом громадное удовольствие и радость, отдыхаете во время игры душой после рабочего дня? Тогда вы найдете интересным наш сайт с игровой тематикой flashplayer.ru. Вам не надо ничего загружать или осуществлять ещё какие-либо действия, чтобы начать играть. Быстрая простая регистрация, и вы сразу сможете начать игру и наслаждаться процессом столько, сколько пожелаете.
Наш ресурс предлагает игры на самые разные тематики, тем самым радуя всех любителей флеш-игр. Логические, стратегии, стрелялки и бродилки, спортивные, драки и гонки. И все это абсолютно бесплатно!
Вы найдете здесь и старые игры, которые уже стали любимыми, стали классическими, поэтому они остаются популярны, и продолжают радовать и восхищать геймеров. Однако много и новых предложений, которые, несомненно, покажутся вам увлекательными, ведь создание новых игрушек не стоит на месте. Работают целые команды, чтобы сделать игру зрелищной и интересной. Потому, мы не сомневаемся, что и новые игровые варианты вам понравятся, скрасят досуг, уберут усталость.
Вы любите играть, играть много и часто, находите в этом громадное удовольствие и радость, отдыхаете во время игры душой после рабочего дня? Тогда вы найдете интересным наш сайт с игровой тематикой flashplayer.ru. Вам не надо ничего загружать или осуществлять ещё какие-либо действия, чтобы начать играть. Быстрая простая регистрация, и вы сразу сможете начать игру и наслаждаться процессом столько, сколько пожелаете.
Наш ресурс предлагает игры на самые разные тематики, тем самым радуя всех любителей флеш-игр. Логические, стратегии, стрелялки и бродилки, спортивные, драки и гонки. И все это абсолютно бесплатно!
Вы найдете здесь и старые игры, которые уже стали любимыми, стали классическими, поэтому они остаются популярны, и продолжают радовать и восхищать геймеров. Однако много и новых предложений, которые, несомненно, покажутся вам увлекательными, ведь создание новых игрушек не стоит на месте. Работают целые команды, чтобы сделать игру зрелищной и интересной. Потому, мы не сомневаемся, что и новые игровые варианты вам понравятся, скрасят досуг, уберут усталость.
Гость
