Xpoint
   [напомнить пароль]

О пользе применения клиентских сценариев

Метки: usability, клиентский сценарий
2001-09-19 10:36:02 [обр] Ilya Muzukin(0/39)[досье]

Не вдаваясь в глубокую философию, смею заметить, что в некоторых случаях клиентские программы могут заметно облегчить жизнь пользователям.
1.Публикация прайс-листов: Если сравнить размер страницы с прайсом в байтах с количеством полезной информации (тоже в байтах) для большинства инет магазинов и каталогов то получается КПД примерно 10%. Это происходит изза наличия большого количества повторяющихся html тегов. И чем больше наворотов на позицию тем хуже КПД. Если прайс формировать скриптом, где все теги будут записаны один раз, то по моему опыту КПД увеличивается до 50%.

  1. Иерархические меню. Не рассматривая простые сайты, можно заметить , что в каталогах типа torg.ru где глубина вложенности подразделов существенна очень тяжело добраться до конечного пункта назначения. Приходится перезагружать страницу до 6 раз не получая при этом никакой полезной информации. Решение - иерархическое созданное с помощью Java JavaScript . Эти несложные программки могут не превышать 10кб, существенно экономя время и нервы пользователей.

3.Нестандартная работа с информацией. Например попытаться примерить платье в интернет магазине можно только в клиентском Java апплете.

спустя 3 часа 16 минут [обр] peter eropkin(0/3)[досье]

Разумность в таком подходе есть, но есть и другая крайность, когда выполнения достаточно количества js кода на клиенте ощутимо тормозит машину. С точки зрения юзабилити, мне кажется, что как раз послденее хуже, потому как мы все привыкли ждать пока загрузится (привычное действие), но не привыкли, что при загрузке чего-то в броузер все остальные задачи начинают тормозить... Интуитивно хочется закрыть броузер..
Есть опыт когда на клиенте делали сротировку. Так вот, сортировка массива из 100 стрингов на клиенте имхо уже не допустима.

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

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

  1. Не забывайте, что в сеть ходят с разных машин, и с не очень быстрых тоже..
спустя 1 час 31 минуту [обр] Артём Сапронов aka Capricorn(0/569)[досье]
  1. Не забывайте, что ходят и с отключенными скриптами...
спустя 11 минут [обр] Сергей Круглов(10/2057)[досье]
"Не пишите игрушек под 3д-ускорители, они не у всех есть"
Но ведь пишут...
И владельцы гефорсов на них за это не в обиде... :)
спустя 5 минут [обр] Ilya Muzukin(0/39)[досье]
Я предлагаю вообще забыть о глупых наворотах, когда на странице все летает и переливается непонятно для чего.Скрипт должен быть компактным и простым без сложной математики и логики.
  1. Обычно все иерархические навигаторы работают быстро. в www.webreference.com www.brainjar.com... тут больше проблем с поддержкой разных броузеров - хотя и они решаются
  2. все мои апплетики,даже самые сложные прилично работали даже на 486х. А некоторые умудряются всунуть в апплет трехмерную графику - и тоже работает. Тормозить начинает изза утечки ресурсов- тут уж вина программиста а не концепции
спустя 1 час 3 минуты [обр] [DF](0/18)[досье]
  А про Flash уже забыли ? :)
  
А технологию сервер-клиент нужно использовать поровну.
  Если JS/JAVA отключен, данные обработает сервер.
спустя 1 час 16 минут [обр] Сергей Сирик(0/737)[досье]
А если поставить mod_gzip, то оно все сожмется со страшной силой (из-за этих самых одинаковых тегов) и с тем же успехом передастся с высокой скоростью ... и нормально отработается в большинстве браузеров. Если чистый хтмл в большинстве своем отражается нормально, то с ЖС могут быть непредвиденные траблы ... да и управлять такой страничкой сложнее. Про "делать" молчу :)) Из личного опыта - клиент захотел три странички с небольшими объемами информации вместо одной большой ...
спустя 48 минут [обр] Владислав Пустынский(17/852)[досье]
Программировать тоже можно эффективно (как ни странно). Сначала культурно проверить, есть ли у клиента JS. Если есть, загрузить скриптовый файл, если нет - передать ему бесскриптовый вариант, который тоже должен быть "навигабельным". Скрипты можно писать аккуратно, оптимизировать. Забыть про привычку писать кучу избыточного кода и снабжать его комментариями - для JS это не катит. Давать переменным короткие имена. Не бояться превращать код в спагетти, если это ухудшит читаемость, но улучшит производительность и уменьшит объём: клиенту не нужно читать ваш код, а часто вы, наоборот, хотите это предотвратить. Не забывайте предлагать клиенту варианты - навороченный с кучей объектов для "крутых" и упрощённый для тех, кто "всмятку". Думайте о людях, и они к вам потянутся. Конечно, не забывайте и о своих накладных расходах :-)
спустя 16 часов [обр] [DF](0/18)[досье]

Владислав Пустынский:
  Не согласен, короткие имена, отсутствие комментариев - признак
  плохого программирования (если не нужно скрывать код).
  Приводит к вечной отладке.

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

  Из вариантов expert или novice, как правило выбирают первый

спустя 16 минут [обр] Сергей Круглов(10/2057)[досье]

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

Тем более, что выбирать будут не пользователи, а ихние браузеры :)

спустя 15 минут [обр] Владислав Пустынский(17/852)[досье]

[DF]: Вы правы в том, что "короткие имена, отсутствие комментариев - признак плохого программирования. <...> Приводит к вечной отладке". Но это относится исключительно к коду, подлежащему отладке. Код скрипта, который Вы посылаете клиенту, отладке не подлежит, он сравним с двоичным продуктом компиляции, который никто комментариями не снабжает :-) Очевидно, Вы можете писать JS-скрипты с соблюдением всех правил программирования, снабжать их обильными комментариями и проч. Когда скрипт готов, положите себе этот рабочий вариант в архив и в случае необходимости редактируйте его. Но перед помещением на страницу будьте добры, оптимизируйте скрипт. Выкиньте все комментарии, лишние пробелы, избыточные определения, сократите имена, не бойтесь использовать переменные повторно. Это отнимет силы, время, превратит код в спагетти. Но в результате объём кода сократится в 1,5-3 раза. Проверено. Значит, если у Вас много скриптов, скажем, 15 килобайт, Вы выиграете 7 килобайт, т. е. больше 10% рекомендуемого максимального объёма страницы. Умножте на количество просматриваемых в среднем страниц, на количество посетителей... Клиенты оценят Ваш труд!

Пример оптимизированного кода:

pN=Array();aN=Array();aI=Array();onload=function(VVP){var i,d=document,c=comLine.split("%"),t=Function("j","return'return '+j+(/i/.exec(j)?'':'[i]')");iN=Function("i",t(c[0]));for(i=0;i<(/\[/.exec(comLine)?eval(/\[.[^(\[)]+\]/.exec(comLine)[0]).length:c[2]);i++){aI[i]=new Image();aI[i].src=aN[i]=(pN[i]=d.images[iN(i)].src).replace(/\.gif/,"_a.gif");var e=Function("e","p","d.links[Function('i','"+t(c[1])+"')("+i+")][e]=Function('d.images[iN("+i+")].src=\"'+p+'\"')");e("onmouseover",aN[i]);e("onmouseout",pN[i])}}

516 байт. Рабочая копия в архиве занимает, с комментариями, в 2,5 раза больше.

> Из вариантов expert или novice, как правило выбирают первый

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

спустя 1 час 40 минут [обр] [DF](0/18)[досье]

 Скорость загрузки не всегда зависит от скорости соединения.
  Можно представить следующую ситуацию.
  Я сижу на выделенке в64к, у меня крутой комп, и начинаю грузить сайт
  "быстрая связь/компьютер", но кроме данного сайта у меня грузятся
  еще и другие, FlashGet качает музыку, а друг Вася шлет по Асе
  классную картинку.
  Тоже самое в офисах, менеджер думает что связь 1мб, также думают и
  остальные 200 менеджеров.
  Все это не учитывая проблемы в самой сети.
  И так скорее поступят 80% посетителей.

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

  Согласен с Сергей Кругловом, про браузеры.

  ИХМО: Не нужно предлагать посетителю выбор "расширенный" или
  "стандартный", а понять за чем он пришел, если за прайсом,
  организовать с помощью JS, выбор для серверного скрипта
  определенных позиций из прайса, если нужен весь, предложить скачать
  zip.
  Вот к примеру данный форум, если ответов перевалит за 100, мне
  придется их все качать, а нужны лишь первые 2 и последние 10 :)

ЗЫ: ух .. скока написал.. :)

спустя 3 часа 53 минуты [обр] Владислав Пустынский(17/852)[досье]

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

Насчёт лапши - ещё раз возражу: у тех разработчиков, которые будут поддерживать сайт после Вас, останется Ваш архив, и они будут пользоваться рабочими вариантами. Если у них будет возможность и потребность - они, после доработки скриптов, смогут их заново сжать. Это как оптимизация графики: в архиве Вы ведь храните высококачественный TIFF, но в Сеть выкладываете оптимизированный JPG. Понадобиться - будете корректировать оригинал, а не сжатую копию. Не стоит упускать возможности уменьшить размер страницы - это один из важных компонентов usability. Конечно, всегда следует учитывать и соотношение "объём затрат/результат".

спустя 57 минут [обр] Алексей Рюмин aka Dwarf(0/864)[досье]
Владислав Пустынский: Про лапшу - совершенно справедливое замечание. Тем более, что есть такая штука, как MS Script Encoder. И тем более, что это справедливо не только по отношению к JS, но и к апплетам и flash-роликам, например (зачем в готовом ролике Trace или в апплете System.out.println?), а также по отношению и к серверной части, что бы там не использовалось - ASP, JSP, Perl, etc.
спустя 56 минут [обр] Yuri Pavlov(2/13)[досье]
Проходит время, появляется новый броузер, у которого DOM несколько отличается (см. Netscape 6 или IE 6), и возникают новые проблемы.
Слои рассыпаются, ошибки сыпятся... Можно ли это учесть?
Наверное, можно.
А реально кто-нибудь учитывает?
Нет.
Учитывают только существующие версии в надежде, что в следующих все будет ну никак не хуже.
Flash.
Выходит 6 версия, и у всех возникает одна и та же проблема - какие-то сайты сделаны на ней, и надо грузить плагин.
Если честно, тема по-моему абсурдна. Скрипты нужны, но без глюков не обойдешься.
(приведите пример сайта, где все скрипты работают на всех платформах и броузерах).
спустя 22 минуты [обр] Владислав Пустынский(17/852)[досье]

Алексей: MS Script Encoder в общем случае есть бяка, т. к. браузерно-специфична. Помнится, это ужо обсуждалось... :-) Но в Интранете или в (редких) частных случаях сайтов под только ИЕ - допустимо.

Yuri: вообще-то всё так. Но нельзя доходить до крайности, всё зависит от соотношений размера текущей аудитории, доли отсеиваемых пользователей, усилий на возможную переработку в будущем, связанного с "наворотами" эффекта привлекательности и проч. А то ведь можно прийти к абсурду: можно ли использовать HTML, ведь его стандарт через N лет изменится до неузнаваемости? а можно ли вообще печатать в кириллице, ведь может быть, через N лет нынешние кодировки изчезнут? :-)))

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

спустя 14 часов [обр] Ilya Muzukin(0/39)[досье]
Вопрос по моему нужно ставить в практической области. Если коммерческий сервер сможет в скриптовом варианте сэкономить 50% траффика то выбор очевиден. А на всех платформах ,во всехбраузерах -это глубокая теория. Если уж на то пошло то все дело опять в качестве программирования. Веб разработки, как и другие разработки дело сугубо профессионалов и только профессионалов. Наплыв недоучек, стряпающих и передирающих друг у друга скрипты -дело временное. Давайте обсудим саму концепцию клиентских скриптов. Если клиент хочет удобства и быстроты- он должен все это получить. Не надо ссылаться на все остальные браузеры и платформы. Если скрипт помогает сделать страницу быстрой и удобной - пиши скрипт. Другое дело действительно ли помогает, и в каких случаях.
Теперь по поводу gzip- все правильно, но сжатие сильно кушает серверное время, так что если не использовать распределенные вычисления боюсь чтосдесь тупик. Кроме того это не отменяет эффективность скрипта.
Пару слов о best viewed in any browser. Както написали мне, что мой апплет не работает в опере. Я ночей не спал и наконец вылизал его, что тот работал не токмо в опере но и в нс3 и ие3- и что же?. Из тысяч посетителей с оперы заходило всего 20-30 и это был Я!!!Может быть лучше было полнее использовать возможности более популярных браузеров?
спустя 54 минуты [обр] Алексей Рюмин aka Dwarf(0/864)[досье]
Владислав Пустынский: MS Script Encoder можно применять и для серверных скриптов :)
спустя 1 час 21 минуту [обр] peter eropkin(0/3)[досье]
простите за глупы вопрос, но что такое MS Script Encoder
спустя 2 часа 14 минут [обр] Владислав Пустынский(17/852)[досье]
Алексей Рюмин: тут возражений никаких. У меня :-) Я серверов не касаюсь :-)
спустя 1 час 2 минуты [обр] Алексей Рюмин aka Dwarf(0/864)[досье]

peter eropkin: http://msdn.microsoft.com/scripting/ - мотать страницу вниз до "Windows Script Encoder 1.0 Released".

Владислав Пустынский: :o)

спустя 22 минуты [обр] peter eropkin(0/3)[досье]
Алексей Рюмин aka Dwarf:
про ms script enc понятно
хорошо, а тогда чем можно получить опимизированый код (лапшу), про который говорилось выше?
спустя 36 минут [обр] Алексей Рюмин aka Dwarf(0/864)[досье]
peter eropkin: Это делается ручками :)
спустя 51 минуту [обр] Владислав Пустынский(17/852)[досье]

> хорошо, а тогда чем можно получить опимизированый
> код (лапшу), про который говорилось выше?

peter, Алексей: это в первую очередь делается головой, причём иногда дурной :-) Но первый этап - выбрасвание комментариев и пробелов - можно и автоматизировать :-)

спустя 30 минут [обр] peter eropkin(0/3)[досье]
а есть общеизвестные "автоматизировалки", или каждый пишет для собственных нужд свою?
спустя 2 дня 22 часа [обр] Владислав Пустынский(17/852)[досье]
Чёрт знает, есть ли специализированные... В принципе, подойдёт обычный поисковик "find & replace", поддерживающий многострочный поиск и регулярные выражения.
спустя 6 дней [обр] Андрей Леонов(1/50)[досье]
Верно — качественно оптимизировать можно лишь головой и руками. Но иногда, когда времени нет, можно привлечь и автоматику. Типа "Advanced HTML Optimizer" или какой-нибудь текстовый редактор. С помощью Text Pad?а, например, я часто заменяю двойной пробел, пробел между тегами, и др. бяки, режущие глаз. По поводу комментариев в коде: мусор это, самый настоящий мусор. И ничего, кроме раздражения, это не несет. Мне как-то пришлось делать редизайн странички, которую клепали немцы. Боже мой! Чего они там только не нагородили! Вплоть до таких подробностей, как "Здесь я открываю таблицу" "здесь таблица закрывается". Даже солидные поисковые системы у них полны такого мусора. Посмотрите на код, скажем, mobile.de — а ведь туда народ тысячами ходит, вылизано все должно быть до запятой. Уж если комментарии и необходимы, то можно создать дополнительный тхт-файл, куда их и вписАть в соответствии с нумерацией строк (не в буквально пронумерованных, естесственно) в комментируемой странице. А потом элементарно сравнить. Конечно, такой способ подходит лишь для уже готовых проектов. А еще неподготовленные проекты и нечего расписывать. Там ведь один человек или группа работает. Они этот код рожали и ориентируются в нем хоть закрытыми глазами.
спустя 1 год 2 месяца [обр] Андрей Симонов(0/65)[досье]

Мне тоже захотелось высказать свое мнение по этому вопросу. Вот оно: клиентские сценарии архиважны и архинеобходимы. Но не как навороты (апплет "озеро", или падающий снег), а как инструменты оптимизации страницы.

Пример. Сайт знакомств. Регистрация. Поле формы "Укажи свой возраст". Тип поля - селектор (чтобы клиент не порол отсебятину, а потом поисковик не глючил бы). В этом селекторе 84 опции - от 16 до 99. Неужели я буду эту колбасу набивать в ХТМЛ? Нет, я добавлю скриптик (собственно, строго говоря это будет уже DHTML) и он мне нарисует этот селектор весьма бодро, даже если у клиента х486 проц.

Что касается поддержки JS, то могу привести статистику: он отключен всего у 0,5% пользователей. (Статистика посещений сайта mail.ru, второго в рейтинге top.mail.ru)

спустя 18 минут [обр] Дмитрий Юров(1/411)[досье]
Андрей Симонов, пожалуйста, не пишите глупостей.
Спасибо.
спустя 22 часа [обр] Ilya Muzukin(0/39)[досье]
а что не нравится? Можно сделать селект с картинками и вообще со сложным поведением на DHTML
спустя 3 минуты [обр] Дмитрий Юров(1/411)[досье]
Можно вообще весь текст выводить через document.write().
спустя 42 минуты [обр] Алексей Волков, он же «Росомаха из Флориды»(17/468)[досье]

М Андрей Симонов:
Ilya Muzukin:
Пожалуйста, прекратите флейм. Ваш стиль общения даёт мне прекрасную возможность повлиять на ваше настроение.

Дмитрий Юров:
Участие в беспредметном споре об абсурдном предмете вряд ли имеет смысл.

спустя 6 минут [обр] Ilya Muzukin(0/39)[досье]
Вопрос/предложение модератору - если тема Вам кажется абсурдной просто уберите ее, а то мне на ящик валятся эти авторитетнейшие глубокомысленности о якобы чужой глупости.
спустя 12 минут [обр] Дмитрий Горяинов aka "три галки"(1/542)[досье]
В этом селекторе 84 опции - от 16 до 99. Неужели я буду эту колбасу набивать в ХТМЛ? Нет, я добавлю скриптик (собственно, строго говоря это будет уже DHTML) и он мне нарисует этот селектор весьма бодро, даже если у клиента х486 проц

- ню-ню

элемент "селектор" не предполагает никакого удобства, как только количество элементов перестает быть легко обозримым (имхо - до 20)

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

А из окна справочника передавать в родительскую форму значение по клику на ссылку, с одновременным закрытием окна справочника.

кроме того - опции селектора - это вес страницы, он растет, да

спустя 8 минут [обр] Ilya Muzukin(0/39)[досье]
Вот - предметный разговор! Можно создать селектор со сложным поведением - иерархическая структура(дерево), закладки, как правильно подмечено поиск - Если все это сделать на клиенте будет гораздо удобнее. Можно использовать простой JavaScript(генерить окно-справочник) можно DHTML закладки\деревья можно ява апплет(для всего предыдущего и особых наворотов).
спустя 53 минуты [обр] Александр Самойлов(0/342)[досье]

Дмитрий Горяинов aka "три галки":

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

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

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

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

кроме того - опции селектора - это вес страницы, он растет, да

как он может расти, если опции селектора генерятся скриптом?

Дмитрий Юров:
Если вы советуете кому-то не писать глупостей в будущем (а на мой взгляд, ответ Андрея Симонова достаточно умный), то хотя бы укажите предварительно на, уже написанные им, глупости.
Спасибо.

спустя 55 минут [обр] Дмитрий Горяинов aka "три галки"(1/542)[досье]

Александр Самойлов:

я не стал писать детали, думал, что это понятно, ок

  1. в окно можно передавть фокус
  1. в окне можно проверять наличие родителя и параметры открытия (есть ли такой справочник? есть ли родительском окне поле, в которое нужно вернуть значение? и т.п.)
  1. тут - та же предопределенность значений, только
    1. постраничный просмот (единичный все страницы меньше)
    2. возможность поиска по контексту в поисковой форме

- мне приходилось делать справочники по несколько тысяч значений (регистрационные кода и т.п.)

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

100 позиций селектора, это 100 значений value + 100 надписей для них + 100 тегов

спустя 3 часа 21 минуту [обр] Алексей Волков, он же «Росомаха из Флориды»(17/468)[досье]

Дмитрий Горяинов aka "три галки":
Речь идёт о том, что сами элементы, все эти сто <option> генерятся на клиенте, в локальном режиме самим браузером, а не качаются в виде текста.

Имея конструктор и некий шаблон, по которому у тебя идёт, скажем возрастание, ты можешь сгенерировать нужные элементы скриптом. Т.е. <option value="yearNN">NN</option> можно сгенерировать на клиенте, не передавая весь диапазон в виде кода.

спустя 6 часов [обр] Дмитрий Горяинов aka "три галки"(1/542)[досье]

А как быть с актуализацией?
Или это некий общий набор на любой случай?

Тогда - (имхо) это голая абстракция из серии меню ссылок в ИЕ - никому не нужно но есть.

спустя 4 часа 3 минуты [обр] Ilya Muzukin(0/39)[досье]
http://www.softcomplex.com/products/tigra_tables_pro/demo1.html
http://www.softcomplex.com/products/tigra_tree_menu/
http://www.softcomplex.com/products/tigra_calendar_pro/demo1.html
вот конкретные примеры. Фирма продает клиентские виджеты - много разных, Нужны ли они и насколько?
Powered by POEM™ Engine Copyright © 2002-2005