Примечание: ниже находится частичный пересказ статьи «Banner Blindness: Old and New Findings». В ней рассматривается текущее положение рынка банерной рекламы в интернете и предлагаются наиболее эффективные способы размещения рекламы.

Проблема

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

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

В 1997 году на рынке интернет-рекламы была подобная ситуация: большим успехом пользовались объявления, похожие на диалоговые окна (с двумя кнопками ОК и Отмена). Естественно, они были только картинками, но это не мешало пользователям на них усердно кликать (ведь они пытались нажать ОК или Отмена). Этот метод обмана посетителей ресурса занимает третье место среди наиболее ненавидимых рекламных методов.

Примечание: ниже находится перевод статьи «Bring on the tables», в которой рассматривается использование таблиц по прямому назначению и некоторые методы по увеличению их доступности.

UPD: текст статьи полностью убран в связи с его неконтролируемыми преобразованиями с момента публикации.

Примечание: ниже находится перевод статьи «The Attention Economy: An Overview», в которой рассматривается проблема экспоненциального роста объема информации и возможное ее решение в виде создания платформы для анализа пользовательских предпочтений.

Информационный бум

Ни для кого не является тайной, что мы живем в эпоху информационного бума. Стремительное появление новой информации в интернете — это как палка о двух концах. Мы и получаем больше сведений, и тонем в обилии новостей, блогов, подкастов, фотографий, видео и модных страницах на MySpace. И проблема только ухудшается по мере того, как все больше и больше людей открывают для себя интернет. В качестве иллюстрации можно рассмотреть два графика, представленные ниже. Первый из них демонстрируют стремительный рост блогосферы в целом, а второй — числа статей и заметок, опубликованных на блоге, посвященным техническим новинкам, — TechCrunch:

Примечание: ниже представлен перевод двух последовательных статей «The window.onload Problem — Solved!» и «window.onload (again)», посвященных оптимизации исполнению скриптов при загрузке страницы, эта проблема была предварительно затронута в статье: «Как JavaScript тормозит Веб (и что с этим делать)?»

Для начала определимся с самой проблемой. Событие window.onload используется программистами для старта их веб-приложения. Это может быть что-то довольно простое, например, выпадающее меню, а может быть и совсем сложное, как пример, запуск почтового приложения. Суть проблемы заключается в том, что событие onload срабатывает только после того, как загрузится вся страница (включая все картинки и другое бинарное содержимое). Если на странице много картинок, то можно заметить некоторую задержку между загрузкой страницы и тем моментом, когда она начнет фактически работать. На самом деле, нам нужно только узнать способ определить, когда DOM полностью загрузится, а не ждать еще и загрузку картинок.

читать дальше на webo.in →

Примечание: ниже представлен перевод заметки «Exploiting the iPhone», в которой раскрываются некоторые детали не так давно обнаруженных и уже исправленных уязвимостей в iPhone и предлагается пара практических советов по избежанию их в будущем.



Обновление: Apple выпустила обновление, которое устраняет обнаруженные уязвимости. Чтобы узнать подробности обнаружения одной из уязвимостей, просто зайдите в наш блог.

Подробности на BlackHat: Charlie Miller представил детали эксплоита на BlackHat, прошедшей в Лас-Вегасе 2 августа. Эта презентация также доступна по этому адресу.

Предварительное техническое описание: предварительный документ, описывающий атаку, доступен по этому адресу. Полная версия ожидается после 2 августа (прим.: по всей видимости, ее так и не выложили).

Статья в New York Times: история о проделанной работе была опубликована в New York Times.

Примечание: ниже перевод заметки «Same Niche, Different Blogs: Why Not?», в которой приводятся плюсы и минусы создания второго, альтернативного, блога наряду с уже существующим. Статья довольно общая, и вместо двух блогов ее рассуждения, в принципе, применимы к любым двум проектам, которые ведет один человек.

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

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

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.

Примечание: ниже перевод статьи «Event delegation without a JavaScript library», посвященной обзору методов по назначению обработчиков событий в JavaScript и их возможной оптимизации, она дополнена моими комментариями и практической частью.

Большинство статей и примеров, которые я видел в последнее время по переопределению событий, основывались на какой-либо распространенной библиотеке. Например, в своей хорошо известной статье Chris Heilmann применяет YUI-библиотеку, а в прошлом месяце Dan Webb в своей презентации на media использовал prototype.

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

читать дальше на webo.in →

Примечание: ниже перевод статьи «Boost Your Hyperlink Power». В ней освещается использование атрибутов rel и rev, а также некоторые микроформаты.

Часть HTML-тегов и атрибуты мы используем каждый день в свой работе. Заголовки, параграфы, списки и картинки являются основой разметки каждого веб-разработчика. Но наиболее распространенным элементом, наверное, будет ссылка — простой тег, который связывает воедино все страницы, создавая ту самую беспорядочную структуру, которую мы называем Всемирная Сеть Интернет (WWW).

Ссылка как она есть

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

   <a href="http://allinthehead.com/">

Атрибут href находится в открывающем теге a, между открывающим и закрывающим тегами находится текст для описания ссылки:

   <a href="http://allinthehead.com/">Drew McLellan</a>

«Ну и что», — скажите вы. — «Это я все и так знаю», — и будете абсолютно правы! Но у ссылки есть еще кое-что, кроме атрибута href.

Примечание: ниже перевод статьи Jeffrey Zeldman «E-mail is not a platform for design». В ней рассматривается текущая поддержка со стороны email-клиентов HTML-разметки писем. Статья во многом спорная и неоднозначная.

После стольких лет процветания интернета HTML-письма по-прежнему вызывают сильное отвращение (still sucks). Вы можете подумать, что я имею в виду «HTML-письма не отображатся корректно в некоторых email-клиентах» Однако, это лишь часть истины. Компании тратят сотни часов простых верстальщиков для создания HTML-разметок, которые могут не работать в Eudora или в Gmail или прекратить отображаться в Outlook.

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

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

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

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

читать дальше на webo.in →

Примечание: Luke Wroblewski является страшим дизайнером интерфейсов в Национальном Центре Приложений для Суперкомпьютеров, (NCSA), в котором появился первый широко распространенный графический браузер, NCSA Mosaic. В этом центре он проектировал интерфейсные решения для Hewlett-Packard, IBM, и Kellogg's и участвовал в совместной разработке Среды Взаимодействия для Открытого Портала (OPIE). Ниже перевод его статьи о выборе правильной разметки для отображения форм на веб-страницах.

«Поля для ввода данных должны быть организованы в логические группы, чтобы ваш разум смог воспринять разметку формы как цепочку связанных между собой полей»

–HTML: the Definitive Guide

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

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

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «Simply said...How To Blog», в которой автор описывает собственный успешный стиль ведения блога и дает несколько практических советов по организации работы.

Однажды я получил письмо от одной из своих читательниц (Celeste), в котором та писала:

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

Примечание: ниже перевод статьи «Ajax Best Practices: Don't Break Bookmarks», посвященной решениям, позволяющим пользователям корректно добавлять в закладки страницы сайта, сделанного при помощи AJAX-методов. Я постарался дополнить ее по мере сил, опираясь на обсуждение предыдущей статьи из серии.

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

Сейчас уже никого не удивишь ссылками на любимые ресурсы, которые авторы публикуют в своих блогах. Некоторые даже размещают рекламные банеры или надписи «я [люблю] этот сайт», самостоятельно рисуют дополнительные логотипы. Настоящие фанаты могут покупать футболки и другую атрибутику, на которой изображено полюбившееся название или лого.

Но американский тинейджер Joe Tamargo пошел еще дальше. Он решил увековечить любимые сайта прямо на себе.

Примечание: ниже перевод статьи «Reporting bugs — a how-to guide», в которой приводится ряд нехитрых действий, которые могут помочь как пользователю, так и разработчику справиться с ошибками на сайте или в веб-приложении. В свете постоянного появления в Рунете проектов со статусом «бета», статья может быть особенно полезна.

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

Примечание: ниже перевод статьи «Fixing The Web — Part 1», в которой поднимаются наиболее актуальные вопросы, касающиеся текущего положения вещей в Вебе.

Нуждается ли Веб в исправлениях?

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

Естественно, Веб играет роль, прежде всего, глобального информационного источника, но насколько хорошо при этом функционируют сами Веб-технологии? Чтобы ответить на этот вопрос, мы должны рассмотреть ряд проблем, которые существуют в Вебе:

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

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