Посты с тэгом «мысли вслух»

  • Техсуппорт по-русски

    Недавно один из клиентов переслал мне письмо, пришедшее на support@ от одного недовольного пользователя, который заявлял, что не может выполнить какие-то действия на сайте. Причина: появляется сообщение, что в его браузере чего-то сделать нельзя. Я был крайне удивлен этим, так как сам лично контролирую поддержку проекта и таких сообщений на сайте не должно быть в принципе.

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

    значит, объясняю, как решаются такие вопросы:

    [...]

    если все везде работает — пишете любому клиенту «ставь последнюю версию браузера и не парь нам мозги, все везде должно работать»

    если что-то где-то не работает — ставите на заглавник определитение браузера и пишете тем, кому не повезло, что им не повезло — сразу, чтобы они время не теряли

    [...]

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

    И дело тут совсем не в том, что на банальную просьбу выслать URL и название браузера я получил нравоучения о том, как жить дальше. А в том, что такой «консультант» с порога предлагает писать пользователям «ставь последнюю версию браузера и не парь нам мозги», даже не исследовав проблему.

    К моему великому сожалению такая модель поведения типична для российский веб-разработчиков. Если где-то что-то не работает, то клиент обязательно должен разбиться в лепешку: поставить все обновления системы, десять раз перезагрузится, отключить все файерволы и антивирусы, проапгрэйдить свой компьютер, купить шаманский бубен, наконец (видел такой в магазине «Экспедиция»). И все это для того, чтобы 5 минут посмотреть на очередной шедевр подпольного сайтостроения Васи Пупкина. У разработчика, видите ли, в инкубаторных условиях все работает, а если клиент, не дай бог, нажал кнопки не в той последовательности — то виноват, конечно же, сам клиент.

    Потому что разработчик провозгласил себя священной коровой, которой все обязаны. Не работает кнопка? А в моем SuperMegaBrowser 0.6 alpha все работает замечательно, поставьте его себе. На странице все разъехалось? Ничего не знаю, у меня сайт валидный, должно везде работать, а если не работает — значит, у вас говеный браузер. У вас IE6? Сначала обновитесь хотя бы до IE7, а потом заходите на сайт. И мне плевать, что в вашем банке другие браузеры использовать нельзя, и что вы хотите купить на сайте, который сделал Я, телефон за 1000$. Идите ко всяким лузерам, которые не думают о валидности и верстают таблицами.

    Почему разработчики до сих пор не могут понять, что клиентов абсолютно не волнует размер мозолей на руках от постоянной дрочки на валидатор? Что дизайнерам пофигу, как вы сверстаете макет: таблицами или дивами. Что на дворе сейчас XXI век и инетрнет заполнен не гиками, а обычными пользователями, которые понятия не имеют, что такое HTML или JavaScript. Зато эти пользователи очень здорово умеют нажимать на кнопку «Купить» и следовать пошаговой инструкции, как расстаться с деньгами.

  • Почему сайты на флэше — это плохо

    Давно хотелось поделиться соображениями и опытом использования флэша на сайте. А также объяснить позицию Студии Лебедева в этом вопросе.

    Предыстория

    Когда-то давно студия начала отказываться от использования флэша для создания анимационных эффектов. Поначалу на это даже обращали внимание в описании проекта, а потом JavaScript-эффекты воспринимались как само собой разумеющееся.

    Из-за этого у многих людей возникло ощущение, что студия ненавидит флэш. Это в корне не верно — к флэшу студия относится так же, как и к любой другой технологии. А именно: применяет её там, где это действительно необходимо.

    У студии особый подход к созданию сайтов, приходится учитывать массу факторов, порой не заметных даже профессионалу: начиная от разного размера шрифта в браузере пользователя, заканчивая возможным желанием заказчика добавить ещё 10 пунктов в горизонтальное меню. Молчу про то, что все сайты должны растягиваться, причем растягиваться должен не только контентный блок, как это привыкли делать на Западе, а вообще весь сайт. В какой-то момент мы поняли, что заточить флэш-ролики под эти нужды гораздо сложнее и дольше, чем сделать анимации на JS.

    Так в чем проблема?

    Хочу сразу оговориться: в этой заметке я не затрагиваю промо-сайты вроде dexter.ru или Mitsubishi Lancer Sportback — это как раз примеры правильного использования флэша для создания нужного вау-эффекта у пользователя. Речь пойдет о тех случаях, когда флэш используют для моргающего и прыгающего меню, а также о сверхидиотских случаях создания информационных ресурсов полностью на флэше ради двух-трех примитивных эффектов (вспомните хотя бы top4top).

    Итак, какие же сложности возникают при использовании флэша?

    Наиболее актуальная и коварная проблема — внедрение флэша на страницу и использование альтернативного контента на случай отсутствия флэш-плагина. Да-да, я знаю, что есть SWFObject, но он не решает очень серьезную проблему, о которой многие даже не догадываются.

    В свое время я довольно много поработал с большими компаниями (несколько тысяч сотрудников). И практически у всех этих компаний была одна особенность: они активно боролись с распиздяйством своих сотрудников в рабочее время. Руководство искренне верило в то, что на работе нужно работать, а не видео смотреть и в игрушки играться. А в чем нынче распространяется весь развлекательный контент? Правильно, во флэше. Поэтому суровые админы таких компаний просто блокируют подобные файлы на уровне корпоративного файервола.

    Как это выглядит на практике с точки зрения веб-разработчика. После загрузки страницы SWFObject радостно сообщает: «Флэш-плагин у пользователя есть!». Разработчик без тени сомнения заменяет html-меню на флэшовое: это ведь так просто, написал swfobject.embedSWF() и все само работает. Но не тут-то было: между браузером пользователя и интернетом стоит злобный файервол, который, сверившись со своим черным списком, просто блокирует доступ к swf-файлу. В итоге пользователь остался и без html, и без флэша. И это при том, что у него может стоять самая последняя версия флэш-плагина.

    It’s always lupus

    Ещё одна проблема, которая возникает при использовании флэшовых компонентов на сайте, это их «чужеродность» по отношению к html. Для флэша необходимо создать некую прямоугольную область, в пределах которой будет происходить вся анимация. Например, для того, чтобы переместить картинку размером 100×100 из левого верхнего угла браузера в правый нижний необходимо создать блок размером со страницу. Естественно, в этот момент будет заблокирован весь интерфейс сайта без видимых на то, с точки зрения пользователя, причин.

    Зато на флэше проще делать сайты

    Одна из самых тупых отмазок, которые сегодня можно услышать. Обычно в таких случаях флэшер за 10 секунд создает какой-нибудь полупрозрачный градиентный блок со скругленными уголками и текстом внутри и с надменным видом спрашивает у бедного html-кодера: «Ну и сколько тебе времени нужно, чтобы это кроссбраузерно заверстать?».

    Что ж, давайте вернемся, так сказать, к самым примитивным вещам, о которых мы даже не думаем. Вот я верстаю простейший сайт: одна колонка шириной 70%, располагается по центру экрана. Контента в этом сайте уже на три экрана. Что делает браузер в таком случае? Показывает мне вертикальную прокрутку. Я могу прокрутить страницу любым известным мне способом: колесом мыши, пробелом, стрелками вверх/вниз, подергать за ползунок, в конце концов. То есть я уже на подсознательном уровне, ни секунды не задумываясь, листаю документ и получаю необходимую информацию.

    Что же происходит на флэшовом сайте? Начнем с того, что если контент не поместится в видимую область экрана, то не произойдет ровным счетом ничего, если об этом не позаботился флэшер. То есть флэшеру нужно воссоздать механизм прокрутки документа. Другой вопрос, как он воссоздаст этот механизм. Как правило, все ограничивается лишь созданием говеного скроллбара, который является единственным способом прокрутить документ. Флэшер помещает меня — пользователя — в абсолютно чужеродную среду, где мои инстинкты больше не действуют. Вместо того, чтобы получать удовольствие от проекта, мне необходимо сосредоточится на процессе получения необходимой информации. Это такая сломанная машина времени: меня хотят отправить в светлое будущее, но попадаю я в мрачное прошлое, когда мышек с колесиком ещё не изобрели.

    Дальше — больше. Простейшее желание вставить нумерованный список или таблицу в середину текста оборачивается настоящей головной болью для флэшера. Потому что у него есть TextField, который способен отображать только обычный текст и картинки, но никак не структуры данных. Чтобы создать хоть сколько-нибудь интересный текстовый эффект, нужно потратить несколько часов работы флэшера, а не 5 минут кодера на работу с CSS. Именно поэтому отличить флэшовые сайты от нефлэшовых можно по абсолютно уебанской текстовой работе — всем лень тратить время на то, что уже много лет нормально работает в браузерах.

    Можно долго хвастаться тем, что десятый флэш плеер умеет круто работать с 3D графикой, только он до сих пор не в состоянии открыть ссылку в новом табе по моему требованию. Сколько лет существуют табы в браузерах? Это — наглядный пример нарушения так называемого user experience. На флэшовых сайтах пользователь не может стандартными средствами увеличить размер шрифта, не может сохранить понравившуюся картинку на рабочий стол, не может использовать любимый плагин для автоматической прокрутки длинных текстов. Много чего из того, к чему он привыкал годами, нельзя сделать на флэшовых сайтах. Зато можно увидеть, как прикольно выезжает картинка, да. Или подолгу пялиться на прелоудер после каждого клика.

    ***

    Действительно ли проще и быстрее делать качественные сайты на флэше? Как вы считаете?

    Метки:
  • SVG вместо Canvas

    По наводке товарища Bolk решил проверить, насколько сложно генерировать графику в SVG и использовать ее в качестве фона у элемента. Оказалось, совсем не сложно (смотреть надо в Опере и Сафари): создаем строчку, содержащую код SVG, кодируем на лету алгоритмом base64 и вставляем как background у элемента. Код кодировщика совсем небольшой, взял его отсюда и вынес в отдельный namespace. У Firefox есть встроенные методы: window.atob() и window.btoa(), но они вроде как сломаны во второй версии браузера.

    Какия я вижу плюсы и минусы при использовании SVG и Canvas:

    • У сanvas есть метод toDataURL(), который позволяет получить нарисованную картинку в формате data: URL. Этот метод не работает в Safari.
    • С другой стороны, Firefox упорно требует перевести документ в XHTML-режим для отображения SVG (для справки: переключение в XHTML-режим выполняется не доктайпом, а заголовком Content-Type: application/xhtml+xml, который должен послать сервер). Я пока не готов это делать — и так проблем с браузерами хватает, не хочу создавать новые.
    • У SVG объективно больше возможностей. Хотя бы работа с текстом.
    • Некоторые вещи гораздо проще нарисовать/стереть в canvas.
    • В SVG гораздо проще модифицировать уже «нарисованные» объекты.
    • Safari оказался довольно чувствительным к сгенерированной SVG-картинке в качестве фона у элемента: если этому элементу добавить border, то SVG не отобразится.
    • Вопрос о производительности и потребляемых ресурсах пока остается открытым.

    Хочу найти универсальный способ рисования графики, работающий во всех (кроме IE) браузерах и внедрить в rocon. Это нужно потому, что встроенные в Safari и Firefox методы рисования далеки от идеала, иногда нужно и вручную нарисовать уголки. Например, ни один из браузеров не добавляет скругленные уголки картинкам, Safari сносит башню от бордюров разной толщины, да и рисует он не совсем корректно.

    Метки: