Архив категории «Прочее»

  • Ambilight для тэга video

    В некоторых топовых моделях телевизоров Philips есть такая прикольная штука, как Ambilight. По сути, это светодиодная подсветка телевизора, которая меняет цвет в зависимости от цвета картинки. Смотреть кино на таком телевизоре — одно удовольствие.

    На флэше уже есть реализации такой подсветки, ну а чем мы — фронтовики — хуже? Дабы в очередной раз разобраться, на что способны современные браузеры, на свет появился очередной эксперимент:

    Ambilight для тэга <video> (Firefox 3.5, Opera 10.5, Safari 4, Google Chrome 4)

    Далее рассмотрим, как это было сделано.

    Алгоритм

    Прежде, чем начать что-то писать, нужно составить алгоритм, по которому будет работать наша подсветка.

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

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

    Определяем цвет диода

    Для удобства предположим, что в нашем «телевизоре» всего по 5 светодиодов с каждой стороны. Соответственно, нужно взять фрагмент кадра, разделить его на области по количеству диодов и найти усреднённый цвет в каждой области — это и будут цвета подсветки:

    get-color

    Чтобы получить изображение текущего видео-кадра, достаточно отрисовать его в <canvas> через метод drawImage():

    var canvas = document.createElement('canvas'),
    	video = document.getElementsByTagName('video')[0],
    	ctx = canvas.getContext('2d');
    
    // обязательно выставляем размер холста
    canvas.width = video.width;
    canvas.height = video.height;
    
    // рисуем кадр
    ctx.drawImage(video, 0, 0, video.width, video.height);
    

    Текущий кадр получили, теперь нужно узнать, какого цвета пиксели сбоку изображения. Для этого воспользуемся методом getImageData():

    /** Ширина области, которую будем анализировать */
    var block_width = 50;
    
    var pixels = ctx.getImageData(0, 0, block_width, canvas.height);
    

    В объекте pixels есть свойство data, в котором содержатся цвета всех пикселей. Причём хранятся они в немного необычном формате: это массив RGBA-компонетнов всех пикселей. К примеру, чтобы узнать цвет и прозрачность первого пикселя, нужно взять первые 4 элемента массива data, второго пикселя — следующие 4 и так далее:

    var pixel1 = {
    	r: pixels.data[0],
    	g: pixels.data[1],
    	b: pixels.data[2],
    	a: pixels.data[3]
    };
    
    var pixel2 = {
    	r: pixels.data[4],
    	g: pixels.data[5],
    	b: pixels.data[6],
    	a: pixels.data[7]
    };
    

    Нам нужно разделить все полученные пиксели на 5 групп (по количеству светодиодов, которое мы выбрали ранее) и проанализировать каждую группу по очереди:

    function getMidColors() {
    	var width = canvas.width,
    		height = canvas.height,
    		lamps = 5, //количество светодиодов
    		block_width = 50, // ширина анализируемой области
    		block_height = Math.ceil(height / lamps), // высота анализируемого блока
    		pxl = block_width * block_height * 4, // сколько всего RGBA-компонентов в одной области
    		result = [],
    
    		img_data = ctx.getImageData(0, 0, block_width, h),
    		total = img_data.data.length;
    
    	for (var i = 0; i < lamps; i++) {
    		var from = i * width * block_width;
    		result.push( calcMidColor(img_data.data, i * pxl, Math.min((i + 1) * pxl, total_pixels - 1)) );
    	}
    
    	return result;
    }
    

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

    function calcMidColor(data, from, to) {
    	var result = [0, 0, 0];
    	var total_pixels = (to - from) / 4;
    
    	for (var i = from; i <= to; i += 4) {
    		result[0] += data[i];
    		result[1] += data[i + 1];
    		result[2] += data[i + 2];
    	}
    
    	result[0] = Math.round(result[0] / total_pixels);
    	result[1] = Math.round(result[1] / total_pixels);
    	result[2] = Math.round(result[2] / total_pixels);
    
    	return result;
    }
    

    Итак, мы получили цвета для светодиодов, но они слишком тусклые: ведь диоды светят очень ярко чтобы добиться достаточного уровня свечения. Нужно увеличить яркость цветов, а также увеличить насыщенность, чтобы добавить глубины свечению. Для этих целей очень удобно пользоваться цветовой моделью HSV — hue, saturation, value, — достаточно домножить два последних компонента на некий коэффициент. Но цвета у нас хранятся в модели RGB, поэтому сначала конвертируем цвет в HSV, увеличиваем яркость и насыщенность, а затем обратно конвертируем в RGB (формулы конвертирования RGB→HSV и обратно легко находятся в интернетах):

    function adjustColor(color) {
    	color = rgb2hsv(color);
    	color[1] = Math.min(100, color[1] * 1.4); // насыщенность
    	color[2] = Math.min(100, color[2] * 2.7); // яркость
    	return hsv2rgb(color);
    }
    

    Рисуем свечение

    Светодиоды — это всенаправленные источники света. Для их отображения лучше всего подходят радиальные градиенты: для каждого диода свой градиент. Однако для достижения хорошего визуального результата придётся делать очень много сложных расчётов: нужно учитывать позицию диода, диаметр и затухание свечения, смешивание соседних цветов и так далее. Поэтому мы немного сжульничаем: нарисуем обычный — линейный — градиент, а сверху наложим специальную маску, которая создаст ощущение правдоподобного свечения.

    Градиент рисуется просто: сначала создаём его с помощью createLinearGradient(), а потом добавляем цвета через addColorStop() и отрисовываем его:

    // для свечения создаём новый холст
    var light_canvas = document.createElement('canvas'),
    	light_ctx = light_canvas.getContext('2d');
    
    light_canvas.width = 200;
    light_canvas.height = 200;
    
    var midcolors = getMidColors(), // полчаем усреднённые цвета
    
    	grd = ctx.createLinearGradient(0, 0, 0, canvas.height); // градиент
    
    for (var i = 0, il = midcolors.length; i < il; i++) {
    	grd.addColorStop(i / il, 'rgb(' + adjustColor(midcolors[i]).join(',') + ')');
    }
    
    // рисуем градиент
    light_ctx.fillStyle = grd;
    light_ctx.fillRect(0, 0, light_canvas.width, light_canvas.height);
    

    Получим что-то вроде этого:

    gradient

    Маска

    Маску мы нарисуем в фотошопе. Есть замечательный фильтр Lightning Effects (Filters→Render→ Lightning Effects…), который позволяет создавать источники света. Заливаем слой белым цветом и вызываем этот фильтр примерно с такими настройками:

    lightning

    Получим вот такое световое пятно:

    spot

    Меняем режим наложения на Lighten, дублируем, крутим, меняем масштаб, играемся с прозрачностью, правим уровни и получаем вот такой результат:
    spot-grid

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

    result

    Но самое главное — мы легко сможем менять внешний вид и интенсивность свечения, не прибегая к программированию.

    Свечение для левой стороны готово, осталось проделать то же самое для правой стороны, добавить плавную смену подсветок и написать контроллер, который с определённым интервалом будет эту подсветку обновлять. Расписывать это — долго и нудно, проще посмотреть исходник.

    UPD: как показал эксперимент, далеко не у всех нормально работает HD-видео (изначально размер ролика был 1280×544), снижение разрешения до 592×256 решило проблему.

    Метки: , , ,
  • Автоматическое копирование файлов на FTP/SSH в Eclipse

    В последнее время все чаще и чаще слышны просьбы веб-разработчиков сделать удобную работу в любимом редакторе/IDE, чтобы изменившиеся файлы автоматически попадали на удаленный сервер. Самый простой способ решить эту задачу — редактировать файлы напрямую на сервере. Хотя это вполне рабочее решение, у него есть ряд недостатков, самый большой из которых: отсутствие локальной копии файла. В случае, если ваш коллега через 5 минут закачает свою, исправленную и дополненную версию файла, можно быть уверенным, что ваши изменения потеряются безвозвратно. Более того, этот способ годиться только для мелких исправлений, на 5—10 минут. Если же нужно решить какую-то более глобальную задачу, дней на 5, например, вам в любом случает придется держать локальную копию проекта, чтобы спокойно переводить его в нерабочее состояние.

    Самый правильный способ решения задач с синхронизацией файлов, который проповедуют все маститые разработчики — использовать систему версионного контроля (VCS), вроде SVN или Git. Рабочий процесс в этом случае выглядит следующим образом. Разработчик локально, у себя на компьютере, вносит необходимые изменения и делает коммит в репозиторий. В этот момент у репозитория срабатывает хук (некий скрипт), который берет изменившиеся файлы и закачивает на продакшн-сервер. Это идеальное решение для командной работы, когда необходимо объединять свои исправления с чужими. И еще, как бонус: нет необходимости бегать по 10 разным папкам и вручную копировать изменившиеся файлы на сервер. Достаточно нажать всего на одну кнопку — и абсолютно все необходимые файлы оказываются на сервере. Многих, почему-то, пугает такая «сложность», хотя на настройку окружения требуется времени не больше, чем на очередной перекур или чтение новостей.

    Ну ладно, оставим это на совести каждого конкретного человека. Недавно у меня возникла, скажем так, промежуточная задача. Весь проект лежит в SVN, автоматом закачивается на продакшн — все работает просто замечательно. Только сайт написан на Java, и для его локального запуска требуется ой как много ресурсов, особенно если параллельно работает Eclipse, фотошоп и виртуальная машина с виндой. Обычный рефреш страницы занимал минуту. И я озадачился тем, чтобы над проектом можно было работать локально, а вот проверять его можно было на удаленном dev-сервере. То есть я правлю файл, сохраняю его, при необходимости делаю build (объединение и минификация JS и CSS) и все изменившиеся файлы автоматически попадают на dev-сервер, без каких-либо лишних телодвижений. Решение оказалось довольно простым и элегантным, возможно, сработает и для других редакторов и IDE. Итак:

    1. Под *nix системы есть замечательный проект под названием FUSE, который позволяет монтировать удаленный сервер как обычную папку в локальной файловой системе. На Маке я использовал MacFuse + оболочку MacFusion для настройки FTP/SSH-серверов. На винде можно использовать платный WebDrive или NetDrive для этих же целей.
    2. Устанавливаем FUSE или WebDrive/NetDrive, настраиваем подключение к серверу и монтируем его как локальную папку.
    3. Для Eclipse ставим плагин FileSync, задача которого — автоматически синхронизировать проект с какой-нибудь внешней папкой. Синхронизация одностронняя: копируются файлы из проекта в папку, но не из папки в проект.
    4. Идем в настройки проекта (Project → Properties) в секцию File synchronization и настраиваем синхронизацию для проекта (пример с сайта разработчика):

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

    5. Не забываем включить автобилд (Project → Build Automatically), чтобы при любом изменении ресурсов проекта файлы автоматически синхронизировались, и опцию General → Workspace → Refresh automatically в настройках Eclipse, чтобы файлы, добавленные вне Eclipse (например, картинку новую скопировали) автоматически появлялись в проекте.

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

    UPD: Решение от Neolord для работы со стандартным синхронизатором из Aptana.

  • Установка Aptana на Eclipse Galileo 3.5

    UPD: вышла Aptana 1.5, которая без проблем ставится на Eclipse 3.5 из update site: http://update15.aptana.org/studio/24896/ (спасибо Vii за ссылку). Так что все остальное тут написанное можно рассматривать как еще один способ установки плагинов.

    Вышел новый Eclipse Galileo 3.5, а в месте с ним появились очередные проблемы с совместимостью со старыми плагинами. Одна из самых неприятных проблем для меня — Aptana ни в какую не хочет ставится из update site. Как выяснилось, эта проблема вполне решаемая.

    1. Качаем любой дистрибутив Eclipse Galileo и распаковываем его.
    2. Качаем альфа-версию Aptana Andretti по секретной ссылке. Скачивать лучше zip-архив, а не установщик. Также распаковываем его.
    3. Запускаем Aptana Andretti. При первом запуске появится окошко Install Additional Features, в самом низу выбираем опцию Do not show again. Закрываем Aptana.
    4. Из той папки, где у вас находится Aptana, берем папки plugins и features и копируем их в папку dropins той директории, куда вы распаковали дистрибутив Eclipse.
    5. Запускаем Eclipse. Он при запуске спросит, какой workspace хотите использовать. Нужно выбрать тот, который был создан Aptana (папка Aptana Studio Workspace где-то внутри стандартной директории с документами), иначе при каждом запуске Eclipse будут вываливаться ошибки. Насколько я понял, их вызывает тот самый Install Additional Features, который пытается запуститься при запуске (поэтому нужно было выбрать Do not show again). Отключается это некой переменной, хранящейся внутри .metadata рабочего пространства, которую пока лень искать.
    6. Для надежности в настройках отключаем Welcome Screen (Aptana → My Aptana → Never display after startup) и перезапускаем Eclipse. Должно все работать как надо.
    Метки: , ,
  • Firefox: редактируем textarea во внешнем редакторе

    Наконец-то добрались руки до поля поиска расширений для Firefox. Хотелось найти что-нибудь такое, что позволит редактировать содержимое полей во внешнем редакторе, а то уже запарился в CMS голый текст писать. Первый же запрос вывел на замечательный плагин It’s All Text!, который как раз делает то, что нужно. Этот плагин добавляет кнопочку edit в правом нижнем углу у <textarea>, позволяя открыть и редактировать содержимое поля в любимом редакторе.

    Пользователям Mac OS придется немного поплясать с бубном: Firefox не позволяет открыть app-бандлы напрямую. Для этого нужно написать небольшой скрипт. Создайте файл, например edit_in_coda.app (расширение обязательно app, иначе плагин не позволит выбрать скрипт) и написать там следующее:

    #!/bin/sh
    open -a Coda "$@"
    

    Затем в консоли нужно выставить этому файлу права на исполнение:

    chmod +x edit_in_coda.app
    

    Теперь вот правлю текст в Coda Espresso (там гораздо удобнее), в котором через Zen Coding можно быстро писать XML/HTML. Красота!

    Метки: ,
  • СЕО-порно

    Я уже привык ко всякого рода сеошным извращениям на сайте, чтобы поднять его повыше в результатах поиска, но этот пример просто убил меня. В Яндексе по запросу «скачать аудиокниги» на первом месте появляется замечательный сайт mp3-kniga.com с не менее замечательным вступительным текстом:

    Аудиокниги скачать бесплатно теперь может каждый. Наш сайт - лучшее место для того чтобы лицензионные аудиокниги скачать. Скачайте лицензионную аудиокнигу, хотя бы одну аудиокнигу скачайте и вы уже никогда не сможете оторваться от столь увлекательного занятия как прослушивание аудиокниг. Ведь нет ничего проще чем аудиокниги скачать бесплатно?

    Там еще слева опрос «в тему», ага.

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

    PS: есть еще примеры подобного маразма на сайтах?

    UPD: компания Арманд ненавязчиво объясняет, как правильно писать слово Peugeot (спасибо biseptol).

    Метки: ,
  • Подключение entity в XSL-шаблон

    Я очень люблю использовать XSL в качестве шаблонизатора — более гибкого механизма для вывода HTML/XML не придумаешь. А еще я использую Eclipse в качестве основной среды разработки: хоть он тяжелый и глючный, собака, но он единственный удовлетворяет большинство моих потребностей (никуда не перелезу, пока там не появится аналог PyDev и Mylyn).

    Шаблоны, которые я использую, построены на кастомных энтити. Так как XSL-переменные нельзя использовать в атрибуте match шаблона, это довольно удобный способ их эмулировать:

    <!ENTITY navigation "/document/system/navigation[@type = 'root']">
    ...
    <xsl:template match="&navigation;">
    	<ul id="nav">
    		...
    	</ul>
    </xsl:template>
    

    Все энтити хранятся в отдельном файле (entities.dtd), которые я подключаю вот так:

    
    <!DOCTYPE xsl:stylesheet SYSTEM "entities.dtd">
    
    <xsl:stylesheet version="1.0" xmlns="http://www.w3.org/1999/xhtml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    	...
    </xsl:stylesheet>
    

    В «штатном» Eclipse XSL editor это приводит к тому, что перестает code complete по XSL-тэгам — это баг всего Web Tools Project, связанный с тем, что при одновременном использовании XML Schema и внешнего файла с энтити предпочтение по code complete отдается последнему. Поиск решения этой проблемы привел меня к довольно интересному открытию. Теперь энтити я подключаю вот так:

    <!DOCTYPE xsl:stylesheet [
    	<!ENTITY % core SYSTEM "entities.dtd">
    	%core;
    ]>
    

    Это не только восстанавливает работу code complete, но и добавляет следующее преимущество: можно создавать локальные энтити в каждом файле и матчить на них шаблоны:

    <!DOCTYPE xsl:stylesheet [
    	<!ENTITY % core SYSTEM "entities.dtd">
    	%core;
    	<!ENTITY my_entity "/path/to/element[@with = 'very complex expression']">
    ]>
    ...
    <xsl:template match="&my_entity;">
    	сделать что-нибудь
    </xsl:template>
    
    <xsl:template match="&my_entity;[@some_attr = 'true']">
    	сделать что-нибудь другое
    </xsl:template>
    
    Метки: , ,
  • Техсуппорт по-русски

    Недавно один из клиентов переслал мне письмо, пришедшее на 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. На флэшовых сайтах пользователь не может стандартными средствами увеличить размер шрифта, не может сохранить понравившуюся картинку на рабочий стол, не может использовать любимый плагин для автоматической прокрутки длинных текстов. Много чего из того, к чему он привыкал годами, нельзя сделать на флэшовых сайтах. Зато можно увидеть, как прикольно выезжает картинка, да. Или подолгу пялиться на прелоудер после каждого клика.

    ***

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

    Метки:
  • Пузырьки

    Пузырьки

    По-настоящему оценят страничку владельцы Маков.

    Метки:
  • Аякс ради аякса

    В последнее время наблюдаю абсолютно нездоровое стремление некоторых разработчиков делать сайты полностью на аяксе. Это когда нет переходов на разделы сайтов, они просто подгружаются на текущую страницу. Типичный пример использования технологии только ради того, чтобы сказать: она тут используется. Я не нашел ни одной проблемы, которую мог бы решить такой подход.

    Может, это я старею? Может, действительно за этим будущее и пора бы уже менять принципы создания сайтов? Вооружившись последним файрфоксом и файербагом решил проверить «под микроскопом» приведенные примеры. Действительно ли это наше будущее, или всего лишь очередной оральный вау-импульс для начинающих гиков?

    Основная проблема таких сайтов — сохранение истории навигации по сайту. Посмотрим, как это работает с точки зрения пользователя.

    1. Сайты, где используется раздражающая уже на пятом разе анимация, удалось завалить довольно быстро: достаточно быстро перейти по истории на 2—3 шага вперед/назад. В половине случаев я видел только крутящийся прелоудер, во второй половине случаев слетала история навигации. То есть я переходил куда угодно, но не туда, куда ожидал.
    2. Когда я хожу по истории обычных, олдскульных сайтов, браузер запоминает, где я закончил просматривать страницу. Угадайте с трех раз, какую часть страницы я видел на анимированных сайтах?
    3. Следующий пример поведения. Когда я захожу на сайты я обычно открываю интересующие меня страницы в новых табах с помощью Command-click. Естественно, некоторые разработчики плевать хотели на разные модели поведения пользователя, поэтому на одном сайте страницы загружались в том же окне при любом клике на ссылку.
    4. Даже не удивился, что кое-где перемещение по истории сопровождалось новым обращением на сервер. Такая вот экономия на траффике.

    Это те проблемы, которые я увидел как обычный пользователь. Теперь посмотрим, что я получу от такого подхода как разработчик. Иду на форум. Как и ожидалось, разработчики поимели целый букет проблем, которых раньше просто не было: начиная от неправильной инициализации скриптов при загрузке, заканчивая отслеживанием страниц с помощью Google Analytics.

    ***

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

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

← cтарое