Геннадий Тышов писал(а):
Мне тоже
Здесь я отвечу на вопросы 4 и 5, остальное будет в личном сообщении.
Цитата:
К вам есть вопросы:
...4. Есть ли у вас опыт по созданию и реализации программных продуктов?, насколько он успешный?
1. У меня есть система управления бизнесом, текущую версию которой я, практически написал сам. К сожалению, я могу предоставить информацию только в виде релиза для потенциальных партнёров:
http://www.educationservice.ru/cooperation.php2. Несколько лет назад я в сотрудничестве с одним своим коллегой разработал и реализовал идею коммерческой программы проверки обратных ссылок BackLinksChecker (был написан на Delphi). Проект был заморожен после того, как поисковые системы закрыли доступ к своей информации о наличии внешних ссылок на сайты.
Я сам не могу назвать себя профессиональным программистом, и набор моих навыков (PHP/DHTML-JavaScript) находится примерно в рамках задач, решаемых при реализации системы, указанной в п.1. Но некоторым опыт сотрудничества в коммерческой (и, в частности, ИТ) области у меня имеется.
Цитата:
5. Какие вы, видите возможные отличия от ИС Дракон?, что не устраивает в ИС Дракон?
Не устраивает отсутствие некоторых ключевых (на мой взгляд) опций, несоответствие интерфейса и некоторых опций существующим стандартам и имеющиеся ошибки. На последнем моменте я останавливаться не буду, поскольку наверняка вам и так о них сообщают, упомяну только об одной, главным образом, чтобы выяснить - считаете ли вы это сами ошибкой или концептуальной недоработкой?
Итак, насколько я знаю, в соответствии с концепцией языка Дракон, пересечения линий запрещены. Однако это часто происходит после того, как добавляется новая ветка и чтобы устранить это, приходится прибегать к трюкам, что, конечно, вряд ли нравится кому-либо из пользователей.
Остальное я постараюсь изложить в виде категорий:
1. Отклонения от общепринятых стандартов.
2. Опции, наличие которых необходимо добавить для обеспечения минимальной привлекательности программы, как коммерческого продукта.
Кат. 1.
*Отсутствие стандартно выполняемой опции UnDo/ReDo.
Мне потребовалось некоторое время, чтобы сообразить, где она. Решение реализовать её в текущем виде представляется мне очень неудачным. Я допускаю, что, может быть, у программ подобного класса принято нечто подобное, но у подавляющего большинства пользователей данный подход может вызвать большие затруднения.
Я позволю здесь себе небольшое отступление. Если говорить о профессионально выполненной (потенциально коммерческой) версии (здесь и далее я буду в первую очередь иметь в виду web-сервис), то критически важно помнить о поведении потребителей в интернет. На этот счёт существует масса исследований, но основная мысль сводится к тому, что если посетитель сайта что-то не может понять в течение нескольких секунд, то он попросту уйдёт оттуда и выкинет его из головы. Навсегда. Соответственно, когда он автоматически нажимает Ctrl+Z и ничего не происходит, или ищет стрелочку "Назад" (UnDo) и не находит, то ничего кроме раздражения, у него это не вызывает.
*Отсутствие дружественного мануала для текущей версии.
*Неудачно реализованная опция перехода по листам. Крайне неинформативно и неудобно.
*Отсутствие возможности вырезать-вставлять целые блоки. Например, я не могу вырезать блок "Развилка" вместе с его дочерними объектами, пока не удалю их.
*В некоторых случаях программа отказывается пересадить лиану прямо, но намекает, что может это сделать, если на неё добавить комментарий. Здесь она не обманывает - действительно, если комментарий добавить, она разрывает лиану и пересаживает её конец, куда надо. Потом можно и комментарий удалить. Так как, вообще-то, цель была пересадить лиану, а не вставлять комментарий.
Т.е., снова приходится прибегать к трюкам, что для профессиональной версии абсолютно неприемлемо.
*Неудачные определения для некоторых блоков в контекстном меню. В частности - для циклов. Абсолютно непонятно, для чего употреблять термин "цикл ДЛЯ", когда любой человек, хоть мало-мальски знакомый с программированием, знает цикл FOR? А если это цикл Do, While, Do while, Foreach? Мне кажется, подобный подход только затрудняет работу с программой
Это основные моменты. Остальное не так критично, может быть, является вопросом вкуса и т.п.
Кат. 2.
*КРИТИЧЕСКИ ВАЖНО!!!-
Опция конвертации уже существующего кода в Дракон-схему. Маловероятно, что кто-то долго протянет, делая это вручную - очень утомительный и нудный процесс. При этом возможность преобразовать хаос программного кода в алгоритмическую карту исключительно привлекательна и может стать тем самым drive, который привлечёт массу клиентов. Более того, я считаю, что акцент стОит делать именно на этом.
Потому что:
1. У разработчиков масса УЖЕ НАПИСАННОГО кода, требующего документирования.
2. Выполнить автоматическую конвертацию кода гораздо проще, чем изучать то, как работает программа создания схем.
3. Успешная конвертация код->алгоритмическая карта может стать дополнительным стимулом для того, чтобы в будущем разработчик начинал сразу же с работы в Дракон-редакторе, т.о., фактически переходя на новые стандарты разработки, предлагаемые сервисом.
*ПОЧТИ также важно, как и предыдущий пункт -
Возможность перемещать объекты мышью. Без этого программа не получит той привлекательности, которую обеспечивает любой современный профессионально выполненный софт.
*ПОЧТИ также важно, как и оба предыдущих пункта -
Возможность сворачивания блоков (один из участников форума уже высказывал идею "макроблоков", однако я не полностью уверен, что он имел в виду точно то же самое). Мы же не можем охватить одним взглядом сразу всю большую схему? Конечно нет. Мы мысленно разбиваем её на блоки, с таким расчётом, чтобы мы могли держать в уме любой из них. Но только 1. Или тот, или другой. То же самое происходит, когда мы смотрим на Дракон-схему. Если вы часто работаете в MS Word, вы наверняка активно используете опцию структурирования больших документов. Также эта опция поддерживается в PDF.
В Дракон-редакторе это могут быть блоки условий, циклов и всего, что помещается между {...} Вплоть до сворачивания каждой ветки в один исходный блок. Внедрение этой опции СУЩЕСТВЕННО повысит привлекательность работы с программой.
*Изменение масштаба изображения. Его отсутствие очень расстраивает. Особенно после того, как привыкаешь к хорошему в OpenOffice.Draw, PhotoShop, FireWorks, DreamWeaver, Word, Excel... продолжать можно до бесконечности. Т.е., это уже фактически - стандарт.
Таковы основные моменты по п.2.
Конечно, можно было бы много ещё чего добавить, но это уже потом.
Потенциал программы представляется мне огромным, а решение, лежащее в основе, сама концепция языка Дракон - очень удачной, логичной, рациональной и, я бы сказал, элегантной.
Я убеждён, что полноценный программный продукт, позволяющий полностью использовать эту концепцию будет очень востребован огромным числом потребителей. Разумеется, при разумном маркетинговом подходе и подобающей организации всего процесса, ключевым фактором которого я считаю эффективное взаимодействие его участников.