jite
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Поправка.
Еще раз перечитав тему, нашел на 4-й странице про технологию APP и столкновение на этой почве Inquiry с Ad-охотником. На основании этого делаю вывод, что кроме невозможности показа сохраненных страниц больше ничего негативного не происходит...
---- позже----
А вот и нет, прочитал ответ. Значит есть последствия... Поэксперементирую тогда с блокировщиком вкл/выкл. Кстати, чтобы охотик не мешал сабжу, достаточно все галочки поубирать, или браузер перезапустить, или перезагрузиться?
Если так, то первая (узкая) часть вопроса снимается.
Хотелось бы спросить не только авторов сабжа, но и других участников о случаях столкновения Inquiry с другими плагинами.
<<<
Поясню, почему так интересуюсь статистикой глюков: важно узнать, с чего начать в первую очередь при отлавливании своих. Экспортированное из сабжа в .mht/.html/.chm на одной машине может не читаться на другой. Т. к. версии и конфигурации (ОС, браузеров, сабжа) варьируются в широком диапазоне, не хотелось бы сразу предъявлять что-то именно на счет сабжа. Но глюки место имеют, а так как в результате запросто может потеряться многое из "нажитого непосильным трудом". Скажем, перевёл архив в базу, а потом выяснилось, что часть не перевелась корректно, или экспортировать не получается, или... (подставьте свой вариант).
Предваряя рассуждения про пиратские версии, сразу сообщаю, что лицензии на продукт не имею. Готов потратиться, если будет работать надежно, ибо тогда оно того стоит. А вот выложить сразу 800 р. на нечто неизвестное и неопробованное не считаю целесообразным. Прежде надо внимательно ознакомиться - ощутить потребности и возможности. Ну а возиться приходилось с теми версиями/программами какие уж попадались. Пробовал не только сабж. Так что вполне может быть глюки и из-за этого.
>>>
Но независимо от того, что там у меня случилось (со своими-то глюками сам разберусь), думаю, поставленный вопрос будет интересен всем участникам темы.
Кстати, по теме пожеланий к версии 2.0, надежность (хранения-импорта-экспорта) считаю одним из самых важных требований к продукту. Если красиво и удобно но сбоит, то прр с ними с кнопочками... Так что недавнее сообщение в этой теме о "выпадении" в архиве данных "по октябрь" меня настораживает... Предлагаю предусмотреть в сабже процедуру проверки целостности и восстановления данных: автоматически, или лучше отдельной кнопочкой, еще лучше с возможностью указать пределы проверяемого/восстанавливаемого, например, в контекстном меню на папке в Inquiry сделать пункт "Проверить целостность/восстановить", кнопку на панель сделать, но не выводить по умолчанию - чтобы не испугать "обычного полдьзователя",  или как там у вас в политике определено?
И еще мелкая неприятность с боковой панелью Inquiry в Maxthon: в отличие от работы в отдельном приложении со встроенным браузером, редактирование в боковой панели названий сохраненных страниц без участия мыши затруднительно - после каждого нажатия Enter теряется фокус. Как его возвращать с клавиатуры? Наверное, это Maxthon перехватывает, но может есть возможность сабжу [Inquiry] ему [Макстону] его [фокус] не отдавать?
Добавлено:
Рассуждения о «задумчивом импорте» и «всех других браузерах»
Прежде всего, конечно, авторам, но и в немалой степени участникам. Каково ваше мнение на счет такой поддержки браузеров (2-я часть, синим)?
Начинал пост фразой «Ах да! Вот еще что…» Через часа два, перечитав начало, усмехнулся проследив эволюцию дописки в статью. Добавил заголовок и вновь углубился в рассуждения. Закончив, перечитал и решил оставить все почти как было, а то, боюсь, убью еще столько же времени на правку, а ведь это всего лишь пост. Не стоит его превращать в рассказ.
Страницы, сохраненные на диск, часто импортируются в базу с "задумчивостью", для предотвращения которой предусмотрен движок таймаута.
Поправьте, если это не так, но для импорта с жесткого диска в Inquiry одной страницы объемом до 1 Mb с учетом картинок (подавляющее большинство страниц не превышает этого размера) на компьютере с конфигурацией даже 3-годичной давности требуется времени не более 2-3 секунд. Конечно, если система/процессор/диск не загружены чем-нибудь под завязку.
Но почему-то минимальное значение таймаута – 15 сек. Полагаю, что для эффективной реализации упомянутого режима импорта следует расширить диапазон таймаута, установив его минимальное значение хотя бы в 3 сек.
Насколько я понял, у вашего продукта есть некоторые приоритеты по соответствию вкусам и требованиям т. н. «среднего пользователя», который, увидев движок, вероятней всего единожды и навсегда переведет его в крайнее левое положение и забудет, а потом будет ругать продукт за страницы, недогруженные с оптических/флоппи/флэш-накопителей или через сеть. Так что, думаю, эти 15 сек. – защита от дурака или коэффициент запаса.
Но такой запас играет злую шутку с пользователем, решившим импортировать с сотню-другую страниц, а те, как на грех, ну все однотипные "задумчивые" (например, странички форума ). Для импорта 100 страниц с учетом ожидания 15 сек. на каждую потребуется 25 минут!!! Не много ли?
Можно щелкать вручную «Пропустить» на каждой. Выход сомнительный. Пощелкал как-то таким образом всего на несколько десятков страниц и желание щелкать исчезло напрочь – пусть само как-нибудь в бэкграунде доползает…
Ну а хоть и поползет в бэкграунде, я вряд ли буду в это время активно работать (ну если только читать какую-нибудь страницу) с основным окном Inquiry, т. к. это просто психологически некомфортно – работать с объектами, количество которых увеличивается. А работать вероятней всего мне захочется именно в той папке, в которую импортируется, ведь что делают после импорта? Рассовывают, сортируют или по крайней мере смотрят, как получилось… Словом пока идет импорт «средний пользователь» вероятно либо будет ждать, либо уйдет в другое приложение. В любом случае операция такого импорта оставит негативные впечатления.
Короче, вот мои...
Предложения:
1. Минимальный таймаут в 2-3 сек.
2. Для защиты от дурака:
а, метод так себе) сбрасывать после каждой операции импорта или при каждом новом запуске Inquiry таймаут на те самые 15 сек., если его значение меньше;
б, метод получше) запоминать любое значение таймаута, но при значении меньше рекомендованного выводить циферку таймаута, скажем красным цветом и выводить, если сочтете это необходимым, предупреждение (всплывающее или так) о возможности недогрузки страниц (вот только не popup’ом с вечным «ОК»!)
3) Обеспечить механизм определения скорости импорта страниц из источника (можно просто сделать проверку, локальный ли это диск) и использования соответствующего алгоритма импорта по возможности вообще безо всяких движков и задержек – просто пусть качает все что найдет, а ненайденное отрубать на первых же миллисекундах.
(Возможно, в последнем пункте нагородил не в тему, будучи не в курсе, что управлять загрузкой страниц это дело не Inquiry, а движка IE. Но я точно не знаю, можете ли вы вмешиваться, поэтому пусть будет.)
Вопросы:
1) каков на настоящий момент алгоритм импорта страниц и стоит ли ждать 15 секунд, чтобы с диска гарантированно импортировалось все что есть в папке files соответствующей страницы?
3) в чем причина «задумчивости» при импорте?
Смотрите, сколько рассуждений я накатал про такую казалось бы незначительную и «разовую» операцию. Этому есть одна веская причина.
Подумайте, какая аудитория пользователей испытывает в наибольшей степени неудобства от задумчивого импорта? Это – пользователи «все остальных браузеров».
Говорите, альтернативными браузерами пользуется меньшинство? Соглашусь. Но также рискну предположить, что у этого «меньшинства» процент потенциальных потребителей утилит сбора информации (в том числе и вашей Inquiry) значительно выше, чем у IE-большинства. Не пытаюсь сказать, кого больше, но говорю – не пренебрегайте меньшей частью, взяв бОльшую.
Для пользователей IE и Maxthon импорт – операция незначительная, а остальных – основной канал загрузки контента. А тут ограничитель «100 стр. за 25 мин.» Вот такая вот поддержка остальных браузеров…
На мой взгляд, для сносной поддержки всех остальных не требуется городить массу плагинов под экзотические и не очень браузеры. Достаточно сделать один нормальный порт на всех – быстрый и удобный импорт. Я даже схему простую и сердитую могу подсказать. Ну – проще некуда, потому должна работать железно.
Схема универсальной поддержки «всех остальных браузеров» (простая и сердитая)
Славный серфер Василий Пупкин за сеанс исходив инет вдоль и поперек сваливает все результаты (от 3 до 333 страниц) в какой-нибудь одной папке (все в кучу или по подпапкам, не важно). Назову эту папку условно «спецкэш» Быстро сохранять – это его заботы. Справится вполне, ведь он уже имеет «особый» браузер и ему понадобилась Inquiry – значит страниц уже насохранял немало.
После чего он идет в Inquiry и жмет всего 1 раз, всего 1 кнопку. И вот весь контент собранного – у него в базе, в папке подобной Автосохранению (а может даже и в ней же – как решите). И на все это десяток секунд, если, конечно, импорт шустрый.
Теперь о том, что за 1 кнопка – это конечно же импорт, только специальный. Зачем, ведь у нас уже есть импорт? А за тем, что обыденные операции должны исполняться без раздумий – автоматом.
Что мы сейчас имеем с импортом? 1. Выбираем папку в которую сложить (ее все-таки надо найти и кликнуть, уже работа) 2. Кнопка импорт (2 клика) или пункт меню (3 клика + хождение по подменю) 3. наконец, выбор папки, откуда импортировать (в лучшем случае 1 клик, если папка та-самая, а если не та, то черт-те-знает сколько еще кликов, потому что ползем мышкой по дереву папок без всякой возможности использовать закладки (нету), модифицировать старый путь или вставлять новый из буфера обмена (некуда)) 4. собственно импорт с известным ограничителем (и если хотите, покликайте еще для ускорения задумчивых страничек).
Предлагаю и заменить все это безобразие на 1 клик по значку. И в опциях добавить выбор папки спецкэша для Автоимпорта (вот вам и название операции).
Плюс, для минимального менеджмента (читай, очистки) содержимого спецкэша, добавить в контекстное меню (только для этой папки) «Очистить файлы на диске». Т. к. со спокойной совестью удалить импортированные страницы пользователь решится лишь после проверки их состояния в базе, а значит автоудаление страниц с диска сразу после импорта противопоказано, а с другой стороны отдельно лезть в эту папку с целью почистить – можно просто забыть, да и неудобно.
Ну а накрутить еще некоторые фишки для удобства автоимпорта – это дело желания пользователей и времени разработчиков.
Например, несложно реализовать неудаляемость подпапок в спецкэше.: В сабже на папку ставим из контекстного некую галочку, а физически в папку добавляется файл descript.ion с записью и она пропускается алгоритмом удаления при чистке спецкэша. Тот же механизм – для пропуска папок при автоимпорте.
Можно организовать даже более тонкое управление файлами и подпапками спецкэша средствами проводника. Кстати, чем не тема для плагина в самой Inquiry. В этом случае даже приходит в голову просто отображать папку спецкэша в Inquiry как есть, а автоимпорт осуществлять именно в папку Автосохранение – так мы разделяем файлы на диске и страницы в базе. В пользу последнего способа реализации говорит еще и то, что часто папка со страницами это еще и download папка для браузера. Нам не простят, если удалят по недоразумению только что скачанный альбом mp3-шек. А чтобы этого не происходило, надо видеть что удаляешь – выход отображение всего содержимого спецкэша и пусть пользователь сам чистит что хочет и когда хочет.
|
... 
Эх, если бы еще для Offline Explorer'а такую акцию устроили? 
) сделать возможность выбора между анси и юникодом?