parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

nmakarov 12.04.2004 13:59

Я себе не противоречу.

>> предлагаете к 160страничному документу что-то добавить.
Не бейте меня тапком, потому как я ща скажу кощунство.
Документацию надо _переработать_. Есть такое слово - юзабилити. Проблема в том, что это не есть абсолютная истина. Каждый расценивает _нечто_ как юзабельное с точки зрения его _конкретных_ задач.
Теперь будет перевод на общедоступный язык применительно к Парсеру и его документации. Юзеры бывают всякие. Кому-то надо забацать домашнюю страничку, чтоб было круто, типа, background меняется чрез каждые две секунды, шрифты сами по себе пляшут и все такое. Кому-то (мне, например), надо сделать фишку. Бывает еще категория населения, которым надо просто прикрутить новую приблуду к существующей технологической связке "Апач + ПХП + Перл + МайСиквел + ...", чтоб потенциальный юзер сервиса понял, что тут все круто, такой провайдер услуг достоин, чтобы принести ему денег. Напрашивается классификация - чайник полный, чайник деятельный, чайник корпоративный.
А теперь вопрос - кто из них полностью прочтет документацию?
А теперь _главный_ вопрос - что именно хотят такие товарищи читать?
Ответ на 1й вопрос - я. Привык, потому что. Больше никто.
Ответ на 2й вопрос - библиотека _готовых_ решений. Простых, тупых, прямолинейных. Документированных. Большая такая библиотека. Даже очень большая.
Фишка в том, что, начиная изучать новое нечто, очень сложно сформулировать вопрос. Результат - посты типа "Помогите!!!!!!!!!!!!!!!!". Это жизненный процесс. Не у всех хватает усидчивости, чтобы читать документацию от корки и до того места, где станет понятно.
Все равно непонятно пишу. Если проще, то FAQ должен обновляться после каждого глупого вопроса юзера. Если юзер упорно задает вопрос, описанный в FAQе, то следует ответить на него так, чтобы он понял, и обновить запись в FAQ.
Народ читает FAQ и документацию. По крайней мере, старается читать. Бросает же, когда объем информации превышает критический лимит для данного индивидуума (в среднем, нескольких страниц оказывается достаточно.
Я, например, очень люблю эстетствовать. Однако, User Manual, вышедший из под моей редакии, никогда не содержит ничего заумного (если, конечно, вообще выходит в свет).
Конкретный пример. Моя последняя работа в России была связана с крупным министерством. Так вот, начало эксплуатации показало, что процент звонков и писем в службу поддержки был менее одного процента от общего количества задействованных работников (которых было несколько тысяч). Потому что временные затраты на написание руководства превысили общее время кодирования раза эдак в два.

Резюме. Проще, нагляднее и чтоб много примеров.

Sorry, guys. May be it will hurt you a bit. But that's truth.