Usabili.ru http://usabili.ru/ блог о веб-разработке Sat, 19 May 2012 10:18:16 +0300 ru dayly 1 askme@usabili.ru BoughCMS Usabili.ruhttp://usabili.ru/images/rss.jpghttp://usabili.ru/100100блог о веб-разработке Большой вопрос о больших разрешениях http://usabili.ru/news/2012/05/13/big_question_about_big_screens.html http://usabili.ru/news/2012/05/13/big_question_about_big_screens.html http://usabili.ru/news/2012/05/13/big_question_about_big_screens.html#comments Sun, 13 May 2012 16:13:00 +0300 Usabili вёрстка интерфейс и взаимодействие Как сказал Якоб Нильсен (Jakob Nielsen) в своей недавней статье «Computer Screens Getting Bigger» — экраны компьютеров становятся больше. (На что кстати сослался Лебедев =)).
Дословно, гуру юзабилити сказал следующее: "Дизайнеры должны начать экспериментировать со способами утилизировать горизонтальное пространство экрана, и создавать веб-страницы с улучшенным взаимодействием для людей с большими и широкоэкранными мониторами. (Они так же должы использовать методы, такие как responsive design, для продолжения поддержки маленьких экранов, которые будут с нами до конца десятилетия)".

И вот вопрос вам, дорогие читатели — как мы можем это сделать?

В моей практике, я использовала несколько простых приёмов:

  • Если у вас есть, каталог товаров — вы можете использовать float или inline-block, чтобы разместить их на экране.
  • Вы можете использовать css media queries или их js-эквиваленты, например чтобы сделать размер текста или картинок больше и т.п.
  • Вы можете просто задать свойства min- и max-width для вашей обёртки контента (такой как body). Я так делаю в вёрстке блога, чтобы задать размер статей между 1000 и 1200px по ширине, для меня 1200 — это предел читабельной ширины строки текста. Так же я делаю для магазинов, чтобы при разрешении 1920px они не выглядели плохо.
  • Если ваш сайт, на самом деле веб-приложение, например онлайн игра, тогда вам нужно принимать целый комплекс мер, который относится к разработке пользовательского интерфейса, особенно оптимизируя сайт под мобильные устройства, так что я спрашиваю не о них.
  • Так же потихоньку разрабатывается свойство css text-size-adjust. Говорят на уровне префиксов кроме мозиллы уже поддерживается в -webkit- и -ms-, возможно можно использовать его.

Итак, вы владелец сайта, например блога, такого как мой, или магазина. Если вам гипотетически потребуется оптимизировать его для использования на мониторах шириной 2000 или 4000px, что бы вы использовали?

Или, представьте, что все дисплеи в мире шириной 4000px (не говорим про планшетки), может ли это изменить всю парадигму сайтостроительства? Какие изменения в интерфейсе браузеров могли бы произойти?

]]> http://usabili.ru/news/comments_rss/152/ 3 Usabili 2012-05-13T16-13-00Z Давайте поговорим о семантике http://usabili.ru/news/2012/05/04/lets_talk_about_semantics.html http://usabili.ru/news/2012/05/04/lets_talk_about_semantics.html http://usabili.ru/news/2012/05/04/lets_talk_about_semantics.html#comments Fri, 04 May 2012 23:40:00 +0300 Usabili вёрстка HTML5 семантика Вступление
У меня чувство досады от того что данные представлены в сети не в виде "данных". Что такое "данные"? Это то что может понять компьютер. ... Я хочу представить себе мир, в котором все разместили свои данные в сети.
Тим Бернерс Ли (Руководитель W3C, 2009, конференция TED).
Семантическая вёрстка — это когда я верстаю таблицами и думаю о таблицах. Или что-то типа того.
Алексей Шилов aka mr.troll.

Четыре года назад мы даже не думали о HTML5 (а многие ждали XTML 2.0).
Три года назад нам сказали, что HTML5 непременно к 2020 году будут использовать.
Два года назад мы узнали, что HTML5 уже можно использовать.
Год назад оказалось, что HTML5 давно все используют.
Сегодня, всё что не имеет доктайпа <!doctype html> выглядит остатками мамонтов  (и пахнет точно так же).

Html5 принёс нам много-много всяких спецификаций и технологий. И хотя главное назначение html5 — это расширение мультимедийных возможностей браузера (в черновиках html5 назывался как Web Applications), всякие video и audio теги, их кодеки, canvas и WebGL, инкапсуляция (sandboxing) ифреймов и объектов, и т.п.  — всё это довольно скучные для обсуждения вещи. То, что действительно интересно обсуждать — это новые семантические теги — nav, article, section, header, footer, и дюжину других.

О семантических тегах

Неделю назад (точнее уже три недели назад) вышла статья "Let’s Talk about Semantics (by HTML5 Doctor)", я настоятельно рекомендую с ней ознакомиться прежде чем читать далее.

Откуда же взялись эти семантические теги? Компании Google и Опера выборочно изучили примерно 4 миллиона популярных страниц в интернете, отчёт о результатах доступен например здесь: http://dev.opera.com/articles/view/mama-markup-report-part-2/.

Вот топ 10 самых популярных значений атрибутов Name и Id :

Name attribute value frequency   Id attribute value frequency
keywords 2,189,708 footer 288,061
description 2,100,858 content 228,661
generator 943,496 header 223,726
robots 937,844 logo 121,351
author 818,017 container 119,877
movie 530,989 main 106,327
quality 504,666 table1 101,677
revisit-after 475,765 menu 96,161
copyright 423,210 layer1 93,920
progid 281,339

В своей статье, HTML5Doctor, нас убеждают в том, что основываясь именно на данных списках и были приняты решения о внесении новых тегов в спецификацию HTML5. Однако, из таблицы видно что это не совсем так. Я очень люблю id="footer" или id="content" — но я никогда не использовала id="article". Значение "article" — находиться на 186 месте в рейтинге значений класса и на 728 месте в рейтинге значений id. Т.е. данные атрибуты используют меньше чем 0.1% вебмастеров из статистики. Я считаю что это очень показательные цифры, я не могу понять почему html5doctor ссылается на них.

Так откуда же появились новые теги? Если ответить коротко — они просто придуманы редактором спецификации html5 Яном Хиксоном (Ian Hickson). Когда я спросила его об этом два года назад, он ответил примерно следующее:

Element names in HTML have little relationship to the usage of those names
in reality, to be honest. I wouldn't pay too close attention to the
meaning of the element names in common conversation; only their definition
in the spec matters.
- Ian Hickson (16 Mar 2010)

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

Также есть множество веб-разработчиков, которые считают, что в вёрстке названия как-то связаны с той ролью, которую выполняет тег. Я сама вкладываю в термин "семантика" именно такое значение. Было бы логично предполагать, что если тег a — означает anchor, h1 — заголовок первого уровня, abbr — аббревиатуру, то и тег menu — можно было бы использовать для меню, nav — для любого обособленного блока со ссылками на другие страницы и навигации по сайту, header — как шапку страницы, article хмм... как статью, а section — какую-то часть содержания, например той же статьи. Однако же можно привести примеры вёрстки, где, по спецификации, данные теги будут обозначать совершенно другое, и наоборот, можно привести примеры, где все значения соответствуют совершенно другим тегам.
Например тот же Ян Хиксон не рекомендует использовать тег <menu type="list"> для разметки меню. Вместо этого советуется <nav><ul></ul></nav> и т.п. Так же по спецификации возможно не рекомендуется использовать <nav> для разметки такой навигации как "хлебные крошки" и формы поиска, хотя для меня это было бы семантично (о чём я не раз писала три года назад тут и тут).

Что же я думаю по поводу новых семантических тегов? У них есть ряд положительных свойств:

  • В будущем можно действительно улучшить обработку и индексацию данных тегов поисковыми роботами и другими программами.
  • Ну, по крайней мере это лучше чем div.

Но есть и ряд и недостатков:

  • Названия элементов — не связаны с их значением. Например article — это любой объект который сам по себе представляет какой-то контент, а section — это группирующий элемент, например когда нужно связать много <article> воедино. (Тут важно группировать по смыслу, а не как визуальную обёртку ). Вместо <article> безусловно лучше был бы <zoidberg>.
  • Никто честно не говорит вслух — почему верстальщик должен использовать семантические элементы вместо div? Единственный ответ — "для поисковых роботов". Самому верстальщику — долгие раздумья, над тем какой тег использовать, приносят больше вреда чем пользы, imho. (За исключением конечно того, что таблицы надо верстать таблицами, а списки — списками. Прочие тривиальные вещи объяснял, например, Вадим Макеев, однако его объяснение про html5 не очень внятное). Веб-браузерам довольно всё равно какую кашу из тегов написал верстальщик. Прочие браузеры, типа машин Брайля — в России например составляют 0% от общего числа. Поэтому вёрстка html5 тегов — важна для роботов, и только.
  • Описания довольно размыты и их толкование во многом субъективно. В html 4.01 было меньше разночтений.
  • Очень мало примеров. В идеале — нужно создать сайт, html5samples — где собрать типовые примеры вёрстки различных сайтов. Блога, Каталога, Магазина и т.п. С подсветкой при наведении того, какие теги использовались и описанием почему. Если бы были конкретные примеры — тогда бы и html5doctor.com был бы не нужен. Вот Bruce Lawson например сделал html5 тему для wordpress, уже хоть что-то.

В html есть клёвые "стерильные" элементы div и span названия которых ничего не значат. (С большой натяжкой div можно расшифровать как division). Я считаю эти имена лучше подходят для html тегов чем "семантические" названия.

WAI-ARIA и Микроформаты

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

<div style="font-size:30px;">some big big caption</div>

Несмотря ни на что — это полноценная html разметка. А затем вуаля

<div style="font-size:30px;" role="heading" aria-level="2">some big big caption</div>

Разметка показывает, что теперь это осмысленный заголовок второго уровня (конечно для тех же целей есть <h2>).

Либо у вас был такой код:

<h3>Елена Лунная</h3>
<address>askme@usabili.ru</address>

Который легко можно превратить в визитную карточку

<div class="vcard">
    <h3 class="fn n">
        <span class="given-name">Елена</span>
        <span class="family-name">Лунная</span>
    </h3>
    <address class="email">askme@usabili.ru</address>
</div>

У микроформатов преимуществ гораздо больше:

  • Нет никакой иллюзии в том что они используются в основном для поисковиков и других ботов.
  • Описания микроформатов всегда конкретны. Т.е. на каждый случай — свой микроформат.
  • Они отлично документированы.
  • В составлении микроформатов (например от Schema.org) активно участвуют сами поисковые системы — как следствие они уже хорошо поддерживаются ими.
  • Их проще понять

Из недостатков:

  • Их сложнее запомнить (если под рукой нет ссылки на wiki)
  • Они занимают больше места чем теги. (Однако когда не было CSS, всевозможное оформление занимало ещё больше места в html коде).

Эксперимент

Итак... После статьи на html5doctor я решила поставить небольшой эксперимент, касающийся в основном html5 тегов. Я сделала вот такой макет страницы каталога онлайн магазина:

 

и спросила некоторых известных людей как бы они её сверстали, по пунктам. Текст письма был примерно такой:

I have a question about semantic markup online store pages .
I'm wondering which tags you would use for the following items (see
attachment picture):
1) a horizontal menu of links to different pages
2) the entire block containing the page header (logo, cart block, and a
horizontal menu).
3) the block containing the search filters (the most important
navigation in curtain shop)
4) one filters block
5) block containing shop items
6) block of one items (which includes photo, item title, etc.)
7) pagination
8) page footer.

Can I quote your answer in my blog?

Thank you.

Данный вопрос я послала разным веб-евангелистам. Многие конечно не ответили (например html5doctor, работа у них такая, не отвечать на вопросы) — это нормально. Однако не ответил кое-кто кто обещал — это досадно. Впрочем я не буду называть тех кто не ответил, лучше поприветствуем тех кто смог ответить. Итак:

Ответы

Привожу в оригинале, думаю здесь все знают английский.

Lea Verou
Web designer & developer, specializing in front-end development

Hi Elena,
Keep in mind that the following is just my personal opinion. In semantics, quite often there is no definite correct answer, just many justified opinions.

On 21/4/12 16:07, Елена Лунная wrote:

I have a question about semantic markup online store pages . I'm wondering which tags you would use for the following items (see attachment picture): 1) a horizontal menu of links to different pages

<nav role="navigation"> with an unordered list inside.

2) the entire block containing the page header (logo, cart block, and a horizontal menu).

<header role="banner">

3) the block containing the search filters (the most important navigation in curtain shop)

<aside> 

4) one filters block

<section> 

alternatively: <section> with many <aside>s for the blocks.

5) block containing shop items

<div role="main">

6) block of one items (which includes photo, item title, etc.)

<article> 

7) pagination

<ul role="navigation"> 

8) page footer.

<footer role="contentinfo">

Can I quote your answer in my blog?

Sure! 

Thank you.

You're welcome.

Cheers,
Lea

Ian Hikson
Редактор спецификации HTML5, бывший веб-евангелист Opera Software, ныне сотрудник Google Inc.

 

I have a question about semantic markup online store pages. I'm wondering which tags you would use for the following items

I assume you mean for the purposes of styling and rendering in different
browsers, such as for browsers used by users with specific accessibilty
needs, e.g. speech synthesis browsers, braille browsers, etc.

1) a horizontal menu of links to different pages

For the question of semantics, the issue of horizontal vs vertical isn't relevant. A menu of links to different pages sounds like "a section of a page that links to other pages or to parts within the page: a section with navigation links", which is the definition of <nav>.

2) the entire block containing the page header logo, cart block, and a horizontal menu.

For just random collections of things which you need to group purely for stylistic reasons, and not for semantic reasons, use the <div> element.

3) the block containing the search filters (the most important navigation in curtain shop)

If it's just a section of the page, then <section>.

4) one filters block

If by "block" you mean "a set of form controls optionally grouped under a common name", then <fieldset> is the right element.

5) block containing shop items

That depends on what they really are. If it's a list, then if it's ordered
in a special order, then <ol>, otherwise <ul>. If it's a separate section,
then <section>. If it's something you could imagine syndicating, then
<article>. If it's a table of items with rows and columns, then <table>.
There's no one answer.

6) block of one items (which includes photo, item title, etc.)

Depends on what the container is.

7) pagination

A link to the next page would use <a>.

8) page footer.

If by "footer" you mean "information about the section such as who wrote it, links to related documents, copyright data, and the like", then <footer>.

Can I quote your answer in my blog?

Sure, but the answers really depend on one's specific circumstances and the only real way to get an answer is to read the spec.
http://developers.whatwg.org/

Для полноты эксперимента, стоит также ответить какие теги использовала бы я. (До того как я получила ответы от Лии и Яна).

1) горизонтальное меню ссылок на разные страницы сайта
<nav><ul> или <menu type="list">
2) весь блок шапки страницы содержащий логотип, блок корзины и горизонтальное меню.
<header>
3) блок содержащий поисковые фильтры — является самой важной навигацией по каталогу
<aside>
4) блок одного фильтра
<div>
5) блок содержащий товары
<section>
6) блок одного товара (содержит фотку, название и т.п.)
<article>
7) постраничную навигацию
<nav><ul>
8) подвал страницы.
<footer>

Как видно — мне больше близок вариант Лии, хотя, идея Яна про fieldset  — интересная. В варианте Лии использование атрибутов role — тоже очень правильное, нужно их обязательно использовать.

Данным опросом, я хотела показать, что чем больше базовых html элементов становиться доступно, тем больше подходящих элементов можно использовать, тем более субъективным получается выбор элементов, то тем более вариативной может быть вёрстка одной и той же страницы. Например кто-то использует <header> а кто-то <div>. Однако, поскольку ответов пришло не так много, нельзя сказать однозначно, какой вариант был бы более распространён среди гуру.

Благодарности

Special thanks for help with article to Lea Verou and Ian Hikson. You made the most valuable part.

Спасибо коллеге mr.troll за вычитку и помощь в подготовке. А также всем кто дочитал до конца.

]]> http://usabili.ru/news/comments_rss/150/ 9 Usabili 2012-05-04T23-40-00Z Задачка про вёрстку http://usabili.ru/news/2012/04/28/151.html http://usabili.ru/news/2012/04/28/151.html http://usabili.ru/news/2012/04/28/151.html#comments Sat, 28 Apr 2012 00:07:00 +0300 Usabili вёрстка Итак. Кто из моих дорогих читателей любит сложные задачи? В награду, обещаю вам большую статью с моими скучными рассуждениями о семантике html5-элементов в начале недели. =)

Задание простое, но интересное. Художница нарисовала рамку диалога, для новой онлайн игры. (ссылка http://usabili.ru/news_imgs/151/border7.png ). Требуется сверстать её на прозрачном фоне, примерно вот так:

Blablabla blablabla blablabla balballa bla abl abl


Какой-то текст диалога тут
  1. Рамка должна растягиваться по высоте и ширине. Либо в зависимости от контента, либо при заданной ширине и высоте контейнера.
  2. Не обязательна поддержка IE. (т.е. вы можете использовать любые современные CSS технологии: мультибекграунды, border-image и т.п)
  3. Чем меньше html-тегов тем лучше (Надеюсь у вас получиться сделать что-то элегантнее чем таблица на 9 ячеек =)).
  4. Чем меньше отдельных файлов графики — тем лучше. (ну, про "css спрайты" вы в курсе).
  5. Без яваскриптов
  6. Сам контейнер будет всегда с position:absolute (это может упростить вам задачу)

Через неделю подведём итоги.

P.S. Кстати я снова открыла комментирование статей без регистрации.

]]> http://usabili.ru/news/comments_rss/151/ 14 Usabili 2012-04-28T00-07-00Z Gmail окончательно перешёл на новый интерфейс http://usabili.ru/news/2012/04/20/gmail_okonchatelno_pereshol_na_novij_interfejs.html http://usabili.ru/news/2012/04/20/gmail_okonchatelno_pereshol_na_novij_interfejs.html http://usabili.ru/news/2012/04/20/gmail_okonchatelno_pereshol_na_novij_interfejs.html#comments Fri, 20 Apr 2012 00:38:00 +0300 Usabili о поисковиках Нравиться вам это или нет, но возможность перейти на старый интерфейс Гмайла утрачена навсегда. Мой аккаунт в очередной раз форсированно перевели на новый интерфейс, увы в этот раз отказаться нельзя. Мне правда не хватает старого интерфейса. Клёвых контрастных тем, скруглённых уголков вокруг основных блоков и вокруг сообщений.

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

Что касается выделения основных блоков-то в интернете довольно много замечаний на эту тему, например — вот. Пример оттуда:

Старый дизайн: Новый дизайн:

В старом интерфейсе письма в цепочке более обособлены, а в новом сливаются в один текст.

Из того что мне нравиться в гмайле — переделанный поиск по почте, фильтр, более хорошо структурированный функционал и т. п. Т. е. верхние 100 пикселей шапки:

Мне даже нравятся иконки, вместо текста, которые так обругали многие, включая лебедева.

Хотя с отключёнными изображениями данный интерфейс бедноват. Ощущение что чего-то не хватает (хотя где-то в настройках можно таки вернуть текст на кнопки):

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

Также, среди багов, некоторые жалуются на непонятные иконки расширенного форматирования:

При переходе от расширенного интерфейса к не расширенному — появляются лишние переводы строк. В windows у меня всегда присутствует вертикальный скрол, даже при просмотре коротких писем.

А какие впечатления от нового интерфейса у вас?

]]> http://usabili.ru/news/comments_rss/149/ 4 Usabili 2012-04-20T00-38-00Z Майкрософт планирует обновление IE до версии 9.0.5 на Windows XP через windows update http://usabili.ru/news/2012/04/01/ie-9-0-5-available-in-xp-via-windows-update.html http://usabili.ru/news/2012/04/01/ie-9-0-5-available-in-xp-via-windows-update.html http://usabili.ru/news/2012/04/01/ie-9-0-5-available-in-xp-via-windows-update.html#comments Sun, 01 Apr 2012 02:30:00 +0300 Usabili IE9 Как вчера сообщила команда разработчиков Internet Explorer, в этом посте, компания Майкрософт пересмотрела своё мнение относительно поддержки своего браузера в Windows XP. По заявлению Гери Галахера (Ceri Gallacher) доля рынка IE слишком быстро падает среди пользователей старой системы. Цитирую:

The main problem of legacy oses users is inability to update their Internet Explorer. This the reason for a growing popularity of ie-rivals such as Chrome and Firefox.

— Ceri Gallacher, Program Manager, Internet Explorer

Обновление для Экплорера можно будет загрузить в windows update уже в ближайшее время.

Напомню что доля использование IE в россии критически упала с момента выхода Windows 7, если так продолжится и дальше, то веб-мастерам можно будет вообще не проверять свои сайты в IE.

]]> http://usabili.ru/news/comments_rss/148/ 6 Usabili 2012-04-01T02-30-00Z Дизайн и культ Карго http://usabili.ru/news/2012/03/29/cargo_cult.html http://usabili.ru/news/2012/03/29/cargo_cult.html http://usabili.ru/news/2012/03/29/cargo_cult.html#comments Thu, 29 Mar 2012 23:59:43 +0300 Usabili веб-дизайн Я абсолютно согласна с мнением Сами_знаете_кого, который определяет дизайн (§ 149), как решение какой-то задачи, а не создание красивой картинки, если только задача — не состоит в том чтобы создать красивую картинку.

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

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

Случаются и дизайнеры не понимающие своей работы. Если на выходе получается красивая картинка, но не решающая задачу — приходится переделывать. Бывает что и дизайнеры верят в культ карго. Здесь спасает подробное тз, но даже после него дизайнер должен задать вопросы. Если вопросов нет — обязательно что-то выйдет не так. Подобный порядок работы совершенно не ограничивает творчество дизайнера, я считаю. Это не творческие рамки, а просто объяснение условий задачи.

P. S. Я редко пишу в бложик, потому что хочу писать только интересный и уникальный контент, а если дать материалу «настояться», оказывается что не всегда он интересный и уникальный. Плюс писать надо по делу — после вычитки и сокращения текста, оказывается длинные размышления можно неплохо сжать до нескольких параграфов. Надеюсь вам нравится =)

P. P. S. Расскажите, а какие сюрпризы вы посоветуете разместить на личных сайтах на первое апреля?

]]> http://usabili.ru/news/comments_rss/147/ 0 Usabili 2012-03-29T21-24-00Z 8 марта http://usabili.ru/news/2012/03/08/8_march.html http://usabili.ru/news/2012/03/08/8_march.html http://usabili.ru/news/2012/03/08/8_march.html#comments Thu, 08 Mar 2012 18:20:48 +0300 Usabili Этому блогу исполняется три года. Ура!

Мне интересно стало взглянуть на продуктивность моего блоговедения:

  • 1 год — 96 статей — 681135 знаков
  • 2 год — 28 статей — 170058 знаков
  • 3 год — 21 статья — 178819 знаков

Количество статей с каждым годом падает, но я надеюсь, что качество растёт. Я лично за три года сильно выросла над собой в вопросах вёрстки, яваскриптов и взаимодействия с пользователями. (Я даже узнала что такое non-replaced inline elements =)).

Я долго думала что бы такое на восьмое марта сделать: выложить результаты исследований UX, показать интересные js-разработки, или просто написать что-то про технологии.

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

  • Рейчел Нейборз (Rachel Nabors) — http://rachelnabors.com/ — работает UX консультантом, рисует прикольные комиксы и просто ведёт интересный блог.
  • Лия Вероу (Lea Verou) — http://lea.verou.me/ — безумно талантливый веб-разработчик, создатель скрипта prefixfree, сервисов Dabblet (аналог jsfiddle) и CSS3test.com (тест поддержки css3), веб-евангелист, борец с проприетарными css префиксами, и любительница семантики. У Лии великолепный живой слог статей, клёвые эксперементы с css-анимацией и многое другое.
  • Настя Манно — http://www.mannodesign.com — блог Насти посвящён дизайну, и представляет из себя смесь уроков фотошопа и подборок разных вдохновляющих плюшек, который очень приятно посмотреть, чтобы отдохнуть от всяких хтмлаяксовых сложностей. Хотя периодическое появление рекламных ссылок немного печалит. =)

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

А кого хотите попиарить вы? Публикуйте ссылочки в коментариях, и напишите пару слов о них.

]]> http://usabili.ru/news/comments_rss/146/ 1 Usabili 2012-03-08T11-17-00Z Всех мужчин с праздником! http://usabili.ru/news/2012/02/23/145.html http://usabili.ru/news/2012/02/23/145.html http://usabili.ru/news/2012/02/23/145.html#comments Thu, 23 Feb 2012 14:17:28 +0300 Usabili Традиционно поздравляю всех мужчин сегодня. Поздравляю не только "защитников отечества", просто потому, что про Всемирный день мужчин или Международный мужской день сами мужчины-то обычно не знают. Желаю всем творческих успехов, здоровья и любви.

]]> http://usabili.ru/news/comments_rss/145/ 1 Usabili 2012-02-23T00-13-00Z Как протестировать взаимодействие с пользователем http://usabili.ru/news/2012/02/08/hotwo_test_ux.html http://usabili.ru/news/2012/02/08/hotwo_test_ux.html http://usabili.ru/news/2012/02/08/hotwo_test_ux.html#comments Tue, 07 Feb 2012 20:56:11 +0300 Usabili Иногда, нужно узнать на какие ссылки чаще всего кликают пользователи. Сделать это можно используя яндекс.метрику, которая показывает "тепловые карты" сайта. Однако яндекс.метрика как и любой скрипт аналитики довольно громоздка. Но что делать, когда нужно маленькое и точечное решение? Тут нам поможет location.hash, т.е. та штука которую можно передать после знака # в адресной строке. Моей задачей было узнать, как на страницы нужного типа попадает посетитель, если на неё ведут ссылки двух типов. Одному типу ссылок я добавила хеш-метку, другой остался нетронутым.
Далее, после того как пользователь попадает на страницу - мне необходимо передать статистические данные для записи. Это сделать довольно просто:

// Используется JQuery
$(window).load(function(){
        ...
        // Интернет эксплорер не передаёт хеш, так что исключаем его из статистики.
        if(!$.browser.msie)
            $.get('http://usabili.ru/labs/.....?page='+escape(window.location+'|'+document.referrer));
});

Тут надо заметить что переменная window.location уже содержит в себе хеш. И вуаля. Статистика собрана. Реферер нам нужен чтобы не учитывать прямые заходы на страницу с поисковых систем, а учитывать только с конкретных внутренних страниц.

Влияние на поисковики

Отдельно хочу отметить, что использование символа # в ссылках - совершенно не влияет на поисковую оптимизацию. Хеш - совершенно игнорируется яндексом, и в общих случаях не воспринимается гуглом!

Для того чтобы хеш воспринимался гуглом - необходимо сильно постараться. Это можно сделать если ваш сайт - использует ajax для навигации, в таком случае вам необходимо начинать все хеши с восклицательного знака. Например так #!page=something. Подробнее про индексирование аякса можно почитать тут:

P.S. Я непременно опубликую результаты тестов примерно через неделю, они уже довольно интересны. =)

]]> http://usabili.ru/news/comments_rss/144/ 0 Usabili 2012-02-08T20-02-00Z Мастерство авторизации http://usabili.ru/news/2012/02/04/mastery_of_authorization.html http://usabili.ru/news/2012/02/04/mastery_of_authorization.html http://usabili.ru/news/2012/02/04/mastery_of_authorization.html#comments Mon, 06 Feb 2012 14:50:59 +0300 Usabili советы javascript интерфейс и взаимодействие браузеры Есть ли что-нибудь более сложное и увлекательное чем регистрация и авторизация? У меня уже накопилась целая подборка: «Основные ошибки проектирования процесса авторизации», «Пользователь важен для вас? Просто дайте ему зарегистрироваться», «Комментарии open_id, улучшены». Что ж, сегодня я намерена продолжить эту тему.

Пароль должен сохраняться в браузере

Всегда важно предоставлять вашим пользователям пользоваться автоматическим сохранением пароля в браузере. На десктопах это позволяет сэкономить несколько секунд, а на мобильниках несколько минут. Попробуйте например набрать несколько раз пальцем на тачскрине логин типа askme@usabili.ru и пароль типа ">pf,bkbnbvj,bkmybrjd-pkj". Поэтому это очень важный момент. К сохранению в браузере я отношу и плагины менеджеров паролей, типа roboform.

Форма логина должна проверяться без перезагрузки

Когда вы ошибаетесь в наборе логина и пароля — очень раздражает, если каждый раз вам приходится загружать новую страницу на которой написано только то что вы ошиблись, или использовали недопустимый символ. Поэтому логично делать проверку авторизации аяксом, вида form onsubmit="somecheck();return false;".

В самой функции somecheck() делается ajax запрос, проверяется результат, и, в случае успеха, делается редирект в закрытый раздел через self.location="/some".

Пару месяцев назад, мы с коллегами столкнулись с досадным багом в хроме. Хром не предлагает сохранить пароль если onsubmit формы возвращает false. Баг с ноября 2009, уже полгода имеет статус fixed, хотя работает до сих пор. Примеры тут: простой и сложный. В сложном примере на секунду появляется таки запрос сохранения, но тут же пропадает. В dev-версии хрома (18) сложный пример работает как надо.

Решением было обнулять функцию сабмита формы, а затем сабмитить её. Разумеется при этом action формы должен вести куда надо.

document.getElementById('login_form').onsubmit=function(){return true;};
document.getElementById('login_form').submit();

Конечная страница не должна получать лишних POST параметров

 Дело в том, что когда страница содержит данные, переданные методом POST, то при обновлении страницы (например нажав F5) браузер сначала спросит хотите ли вы отправить данные ещё раз. Это ненужный пользователю вопрос. Чтобы этого избежать нужно не сразу посылать пользователя на конечную страницу, а посылать на другую, которая сделает редирект на нужную. В таком случае не будет лишних POST параметров. Пример можно увидеть в действии при авторизации в этом блоге.

Пароль должен быть по-желанию открыт пользователю

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

Якоб Нильсен — один из известнейших юзабилистов в мире, с 1995 года писал о безопасности паролей и человеческом факторе (Human Factors of Password Security), и в 2000 писал (Security & Human Factors), и в 2009 писал (Stop Password Masking). Много всего хорошего о паролях, и в частности о том, что звёздочки у паролей пользователям-то не нужны. Но почему-то никто не воплощает его слова в реальность. Даже в мобильных (!!!) браузерах нет настройки "показать мне все мои пароли", это искренне бесит. А ведь на многих сайтах для регистрации просят "подтвердить пароль" (пожалуйста, не менее 6 символов, используйте цифры и буквы разного регистра) — господи дай этим людям мозгов. В большинстве настроек андроида пароли тоже скрываются, хотя казалось бы...

It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

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

Итак, что тянуть резину, давайте сделаем это! Вот какой концепт получился у меня — http://usabili.ru/labs/browser_bugs/test_visible_passwd.html. Это кроссбраузерная (Chrome, Opera, Firefox) реализация незамаскированного пароля. Важно именно то, что браузер здесь запоминает пароль, хотя пароль может вводиться открытым текстом. Для того чтобы любой браузер вообще предлагал сохранять пароль — необходимо чтобы пароль был полем type="password", при загрузке страницы.

Просто так менять яваскриптом тип поля ввода — нельзя. Чтобы поменять его — необходимо пересоздать весь элемент. Для этого воспользуемся такой функцией:

function changeInputType(oldObject, oType) {
	var newObject = document.createElement('input');
	newObject.type = oType;
	if(oldObject.size) newObject.size = oldObject.size;
	if(oldObject.value) newObject.value = oldObject.value;
	if(oldObject.name) newObject.name = oldObject.name;
	if(oldObject.id) newObject.id = oldObject.id;
	if(oldObject.tabIndex) newObject.tabIndex = oldObject.tabIndex;
	if(oldObject.placeholder) newObject.placeholder = oldObject.placeholder;
	if(oldObject.className) newObject.className = oldObject.className;
	oldObject.parentNode.replaceChild(newObject,oldObject);
	return newObject;
}

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

Однако есть одна особенность. В файрфоксе и опере — вызов .submit() формы — не вызовет диалог сохранения пароля. Однако этот диалог — вызывается если кликнуть по кнопке сабмита данной формы вызвав .click();. Таким образом, для кроссбраузерной реализации, перед сабмитом формы — мы должны кликнуть по кнопке сабмита. Общий алгоритм в вашей аякс-проверке должнен получиться примерно такой:

if(auth_success) {
	changeInputType(document.getElementById('password'), 'password');
	document.getElementById('login_form').onsubmit=function(){return true;};
	document.getElementById('login_button').click();
	document.getElementById('login_form').submit();
	return true;
}

Кнопку переключения маскировки можно оформить иконками, как это предложено Лебедевым. Например так:

Так же проставить полям атрибуты tabindex и placeholder.

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

А что думаете вы?

]]> http://usabili.ru/news/comments_rss/143/ 2 Usabili 2012-02-04T06-47-00Z Про файрфокс http://usabili.ru/news/2012/02/01/142.html http://usabili.ru/news/2012/02/01/142.html http://usabili.ru/news/2012/02/01/142.html#comments Wed, 01 Feb 2012 09:19:17 +0300 Usabili браузеры Вчера вышел 10й файрфокс. Для большинства разработчиков, это конечно не новость. Уверена, что все как и я давно следят за планом выхода на офф сайте: https://wiki.mozilla.org/Features/Release_Tracking. А те кто не следит, успели прочитать обзор на хабре.

Чтож, хотя это никому не интересно, я выскажу своё отношение к браузеру.

Файрфокс для меня и моих коллег - является инструментом №1 в работе. Кроме удобных расширений, типа web-developer toolbar, httpfox, и html validator браузер имеет ряд нативных инструментов, таких как подсветка кода, удобный style editor в nightly версиях и доступный в свежем релизе инспектор html. Так же огромным плюсом является низкое потребление памяти. Например для одинаковых 20 вкладок фф потребляет 330 мб, а свежий хром 585, т.е. почти в 2 раза больше. (В опере 383). Файрфокс более старый и привычный браузер, хотя UX-сотрудники mozilla всячески пытаются сделать его непривычным и отбить нелояльных пользователей.

Что касается частой смены релизов, которое так обсуждают на хабре, в духе "Опять новый фарфокс, вот в советское время он так часто не выходил", то я считаю частую смену мажорной версии нормальным решением. И кстати соответсвующим духу mozilla, вспомним, что браузер Netscape - пропустил выход 5й версии когда вышел ie6. Если почитать например про нумерацию версий программного обеспечения в википедии, то можно найти ряд ещё более экзотических примеров. Например Опера, по абсолютно глупым причинам с 10й версии указывает в строке User-agent - версию 9.80. А так, я считаю всем уже всё равно какой цифры браузер. Хотя конечно правильнее было бы выпускать одну версию в квартал, как планировалось, а не одну версию в 6 недель как сейчас. Мне кажется, что в будущем файрфокс либо будет именовать версии номером года и месяца (как убунта например), либо придумает новое название, как photoshop cs.

Какие-то революционные перемены должны произойти и в быстродействии. По моим субъективным меркам Файрфокс является весьма медленным браузером по сравнению с Оперой и Хромом. Дело в том, что несмотря на то что файрфокс выигрывет в скорости на ряде математических действий - работа с Dom и CSS у него поставлена весьма плохо.

Одним из таких изменений должен стать проект electrolysis, который на начальном этапе позволил сделать Out-of-process plugins, а в конечной позволит сделать Out-of-process tabs, как это сделано в хроме. Т.е. быстродействие конкретной вкладки перестанет зависеть от других вкладок и вообще от их количества.

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

Что касается прочего быстродействия, то разработчикам нужно перестать гнаться за количеством багов, а смотреть на качество. В баглисте текущего релиза  http://www.mozilla.org/en-US/firefox/10.0/releasenotes/buglist.html всего несколько багов затрагивающих быстродействие. Складывается впечатление что разработчикам проще писать новый код, чем вносить правки в старый. Неужели проще было вводить поддержку html5-элемента <bdi>, чем ввести поддержку input[type=number], или сделать хотя бы черновую поддержку других input элементов? Почему поддержка <video> и <audio> появилась довольно быстро несмотря на сырость, а по каким-то вопросам идёт многолетнее ожидание окончательной спецификации?

Ну и конечно заявление о том что большинство дополнений файрфокс теперь по-умолчанию совместимо с файрфокс - для меня звучит как шутка. =)

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

Спасибо моим коллегам за помощь в написание статьи.

]]> http://usabili.ru/news/comments_rss/142/ 0 Usabili 2012-02-01T07-49-00Z Микроформаты, Schema.org и W3C http://usabili.ru/news/2012/01/30/Schema.org_is_valid.html http://usabili.ru/news/2012/01/30/Schema.org_is_valid.html http://usabili.ru/news/2012/01/30/Schema.org_is_valid.html#comments Mon, 30 Jan 2012 12:23:52 +0300 Usabili Cтандарты семантика вёрстка о поисковиках Неделю назад, мой друг и коллега Джелу спросил меня, как я отношусь к разметке Schema.org и правильно ли в целях продвижения использовать разметку для картинок которую предлагает яндекс в разделе справки — «Schema.org для Яндекс. Картинок».

Я до этого не обращала внимания что там нового у яндекса, а оказалось новый формат разметки они уже с ноября прошлого (2011) года поддерживают. А ввели его Google, Microsoft и Yahoo аж в июне. Что ж, обычные микроформаты сказала я, глянув один раз на пример. Глянув на пример второй раз я заметила что микроформаты как раз необычные. И более того, используют кажущуюся невалидной с точки зрения html разметку. Об этом я и хочу сегодня рассказать, надеюсь статья будет интересной.

Микроформаты от Microformats.org

Я думаю что вам всем знакомы такие микроформаты типа hcard, hProduct и т.п. большая часть которых написана Тантеком Селиком (Tantek Çelik)  (известным веб-идеологом, редактором спецификации CSS и других). Они позволяют добавить семантическую аннотацию к тем элементам разметки которые вы используете посредством имён классов. Например так:

<div class="vcard">
 <div>
   <span class="category">Кафе</span>
   <span class="fn org">Ромашка</span>
 </div>
 <div class="adr">
   <span class="locality">г. Солнечный</span>,
   <span class="street-address">просп. Романтиков, д. 21</span>
 </div>
 <div>Телефон: <span class="tel">+7 (890) 123-45-67</span></div>
 <div>Мы работаем <span class="workhours">ежедневно с 11:00 до 24:00</span>
   <span class="url">
     <span class="value-title" title="http://www.romashka-cafe.some"> </span>
   </span>
 </div>
</div>

Данная разметка как видно полностью валидна с точки зрения html, и так же доступна для стилизации через css. Подробнее о микроформатах можно почитать в хелпе яндекса.

Микроформаты от Schema.org

Данный вид микроформатов заметно отличается, как видно из примера:

<span itemscope itemtype="schema.org/ImageObject">
  <h2 itemprop="name">Винни-Пух</h2>
  <img src="vinni.jpg" itemprop="contentURL" />
  <span itemprop="description">Винни-Пух залезает на дерево.</span>
</span>

Он не использует классы, для элементов разметки, а вместо них использует новые, пока ещё не валидные атрибуты. Говоря слово "пока", я должна перейти к ответу на самый главный вопрос в статье.

Валидна ли вёрстка от Schema.org?

И отвечая на этот непростой вопрос, я хочу сказать, "Да, вёрстка валидна". Теперь постараюсь ответить почему.

Дело в том что эта схема, вовсе не выдумка поисковых систем. Данный метод для семантической аннотации структурированных данных в HTML, впервые предложил никто иной как Хикси (Ян Хиксон, действующий редактор стандарта разметки html5). И предложил он это ещё три года назад в рассылке группы whatwg. Очень рекомендую к прочтению:

[whatwg] Annotating structured data that HTML has no semantics for
Ian Hickson, Май 2009

В данный момент, он же, под пишет полноценную спецификацию W3C касательно микроформатов - www.w3.org/TR/microdata/

Данная спецификация представляет собой модуль, расширяющий спецификацию HTML, (примерно как сейчас выходят новые модули к CSS), одним из нововведений которого, являются 5 новых глобальных атрибутов:

Напомню, что это атрибуты которые могут применяться к любому тегу. В текущей спецификации html всего 14 глобальных атрибутов.

Что касается поддержки в браузерах, то в ней пока нет смысла, в них ничего не развалится. Для xml разметки логический атрибут itemscope, должен записываться как обычно, в виде itemscope="itemscope".

Интереснее с поисковыми системами. Пока что именно для них микроформаты и предназначены. Здесь хочется поздравить соотечественников, в рабочую группу Schema.org, с ноября месяца, наряду с Гугл, Микрософт (bing) и Яху, входит и Яндекс. Соответственно данные микроформаты в полной мере распознаются данными поисковиками и учитываются в поиске.

Данные глобальные атрибуты уже добавлены в ряд неофициальных валидаторов разметки, но пока не попали в официальный validator.w3.org. Однако повторюсь, уже сейчас я признаю эту разметку полностью валидной.

Узнать какие схемы использует в поиске яндекс можно в соответствующем разделе хелпа. Замечу, что хотя это не сказано открыто, вместо <div> или <span> вы можете использовать любые (блочные и строчные) элементы. Проверить вашу разметку микроформатов можно тут: http://webmaster.yandex.ru/microtest.xml.

Что же ещё готовит спецификация?

Для браузеров, спецификация готовит ряд функций для работы с DOM: http://www.w3.org/TR/microdata/#microdata-dom-api примерно реализующие предпосылки 2009 года (см. ссылку ранее). Возможности стилизации используя CSS пока не предполагается, автор делает упор на разграничения классов используемых для CSS и семантики.

Спецификации от Schema.org и Microformats.org - не взаимоисключающие, вы можете использовать их на одной странице, например микроформаты hcard и ImageObject.

Дополнительные ссылки:

]]> http://usabili.ru/news/comments_rss/140/ 3 Usabili 2012-01-30T16-32-00Z Феерические глупости http://usabili.ru/news/2012/01/25/silly_bug_hunting.html http://usabili.ru/news/2012/01/25/silly_bug_hunting.html http://usabili.ru/news/2012/01/25/silly_bug_hunting.html#comments Thu, 26 Jan 2012 16:03:05 +0300 Usabili вёрстка браузеры CSS Cтандарты Сегодня, мой друг и коллега Cavin прислал мне ссылку на статью с хабра — «Браузеры запутались в блочной модели для таблиц». Я считаю, что эта статья в полной степени показывает мои мысли о том, что в россии специалистов любого профиля очень мало.

Сама статья о том что автор, якобы нашёл баг в отображении браузерами табличной вёрстки. Причём основное внимание внимание обращается на отличия в хроме, и особенно на глюки с шириной. Исходный код страницы здесь. Статья набрала 67 комментариев и 61 добавление в избранное!

Но, позвольте, ежу ведь понятно что дивы (слева) никогда не будут отображаться так же как ячейки (справа). Единственный баг который мне бросается просто в глаза - это  баг файрфокса в отображении свойства box-sizing:border-box, для элементов с типом отображения table-cell, баг известный и старый (bug 338554), смотрите так же bug 243412 где изложена точка зрения мозиллы на этот счёт.

Что касается всего остального - отображение браузеров полностью соответствуют спецификации. Неужели сложно прочитать два параграфа из неё?

http://www.w3.org/TR/CSS2/tables.html#width-layout

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

Я считаю, люди, которые умеют верстать, либо ушли работать в серьёзные компании, типа яндекса, оперы и т.п., либо у них просто нет времени сидеть на хабре. Или быть профессионалом уже не модно?

Если вы делаете багрепорт - ссылайтесь на спецификацию!

Автор в примере даже использует атрибут cellspacing для таблиц. Фееричнее всего смотрится рассуждение о возможности использования border-collapse: collapse вкупе со ссылкой на http://htmlbook.ru/html/table/cellspacing ! Зайдём на страницу, что написано? "Аналог CSS: border-spacing". Вуаля! Почему об этом не сказал никто из полусотни комментаторов? Как могут люди всерьёз считать, что отображение таблиц в десктопных браузерах отличаться между операционными системами в одних и тех же версиях! 

Всем кто не знает сообщаю:

В одной версии одного десктопного браузера - между системами может изменяться лишь сглаживание картинки (зависит от настроек Antialias шрифтов в системе, поддержки direct2d и рендеринга через видеокарты). К нему относится лишь хинтинг и алиасинг шрифта, и всевозможные тенюшечки. Также изменятся могут всякие кнопочки и скролбары, в зависимости от настроек темы.

Исключением из вышеописанного правила, являлся только IE5.5 под винды и мак, но это было два разных браузера вообще, просто с одним названием.

Что касается браузеров мобильных - в определённых режимах работы они могут сознательно нарушать спецификацию, компактно сжимая всё содержимое страницы до нужных пользователю размеров. В этом режиме сложно что-то предугадать или находить несоответствия (они сознательны). Однако могу сказать что это поведение будет длиться недолго, и с массовым появлением ёмкостных экранов, мобильные браузеры используют полноценный zoom правильной страницы.

]]> http://usabili.ru/news/comments_rss/141/ 19 Usabili 2012-01-25T05-01-00Z Убираем баннеры с википедии http://usabili.ru/news/2012/01/18/adblock_wikipedia.html http://usabili.ru/news/2012/01/18/adblock_wikipedia.html http://usabili.ru/news/2012/01/18/adblock_wikipedia.html#comments Wed, 18 Jan 2012 23:48:45 +0300 Usabili Свободе слова настала SOPA. Примерно на это как бэ намекает нам википедия:

18 января (UTC-5) на 24 часа в знак забастовки отключена Википедия на английском языке. День выбран в связи с заседанием Конгресса, на котором должен обсуждаться законопроект SOPA. Сообщество Википедии на русском языке поддерживает коллег и призывает всех тех, кто видит этот текст, помочь в противодействии принятию закона.

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

Но использование сплеш скрина который закрывает сайт после загрузки сайта - это моветон и чёрное seo. Я решила бороться с этим через следующие правила фильтрации AdBlock:

|http://en.wikipedia.org/w/index.php?title=Special:BannerController*
|http://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:BannerController*

 Расширение Adblock, если кто не в курсе служит для блокировки рекламы в Firefox и Chrome. Данные фильтры - возвращают доступ к английской википедии. Ну и заодно убирают грустные лица создателей с российской версии.

Я считаю что когда википедия ограничивает мой доступ к статьям про Римский календарь, Делитель нуля, Процедурное программирование, Разделение ответственности, Дамаст, ECMAScript, Объекты первого класса, Boot to Gecko, Божественный объект, Прокрастинацию, Songket, Эритрею, Напалм, SATA и сериал Рим, тогда это хуже чем любая SOPA!

С прошедшими праздниками вас!

]]> http://usabili.ru/news/comments_rss/139/ 2 Usabili 2012-01-18T23-13-00Z С новым годом! http://usabili.ru/news/2011/12/31/happy_new_2012.html http://usabili.ru/news/2011/12/31/happy_new_2012.html http://usabili.ru/news/2011/12/31/happy_new_2012.html#comments Sat, 31 Dec 2011 21:14:41 +0300 Usabili  Поздравляю всех с новым годом, желаю чтобы ваши проекты всегда были успешными, приносили много профита и знаний, и было время заняться здоровьем. 

С праздником!

]]> http://usabili.ru/news/comments_rss/138/ 0 Usabili 2011-12-31T21-12-00Z