«Лево-право, право-лево…» © Фунтик

Т. е. вывод какой? Виновата физиология, а не мозги (у востока — наоборот).

Посмотрим правде в глаза… человека:

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

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

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

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

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

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

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

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

Ещё использование колонок для разделения контента и инструментов (сервисов, пользовательского меню и т. д.) тоже является хорошей практикой.

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

В этой статье я прочитаю до конца (она ещё ниже заканчивается), а направо даже не посмотрю.

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

Существуют следующие виды элементов управления в веб-проектах:

1. Контент-ссылки
2. Контролы

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

1. Ссылки
2. Иконки
3. Ссылки с иконками
4. Кнопки
5. Табы
6. Навигационное меню

Контролы — это те ссылки, которые подразумевают какие-либо действия: добавить, удалить, изменить, искать, отправить и т. д. Внешний вид может быть:

1. Ссылки
2. Иконки
3. Ссылки с иконками
4. Кнопки

И кстати говоря, кнопки могут быть тоже разные:

1. С текстом
2. С иконкой
3. С текстом и иконкой
   1. Иконка сверху
   2. Иконка слева
   3. Иконка справа

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

1. Позитивные
2. Негативные
3. Нейтральные
4. Бонусы

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

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

И конечно же, нельзя контент-ссылки и контролы оформлять одинаково.

Примеры того, как не надо делать:

Раз

Два

Три

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

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

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

Если раскрыть значение этих блоков, то схема приобретает такой вид:

Фактически мы говорим о том, что изначально пользователь выбирает, чей контент он хочет посмотреть: свой, своих друзей, групп в которых он состоит, или вообще публичный контент (это не всегда бывает). Причём здесь речь идёт только о контенте, который совпадает у всех «Кто?» есть на веб-сервисе.

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

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

Что же происходит в различных социальных сетях? А сами посмотрите. Это вам всё для затравочки. Продолжение будет о том, как организована навигация, а в особенности контролы.

Развитие социальных сервисов

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

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

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

Перспективы развития латвийского интернета

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

1. Отсутствие информации — потенциальные инвесторы плохо осведомлены о возможностях веба и перспективности веб-проектов, а если и осведомлены, то не желают идти на риск, главным образом вкладываясь в проверенные в мировой практике темы. До недавнего времени было стабильнее и выгоднее вкладываться в какое-нибудь строительство. Хотя в последнее время ситуация с недвижимостью на столько дестабилизировалось, что возможно инвесторам стоит обратить внимание на сферу веб?
2. Отсутствие специалистов — большинство хороших специалистов (дизайнеров, программистов, верстальщиков, иллюстраторов, менеджеров веб-проектов) работают на зарубежный рынок, так как локальный у нас слишком мал, чтобы «развернуться». Как правило, специалисты не слишком хотят делиться знаниями, а если хотят, то только со специалистами такого же уровня. В большинстве учебных заведений преподают поверхностные знания веб‑технологий, но не дают полноценного взгляда на эту сферу. Поэтому большинство современных специалистов в области Веб в Латвии — самоучки.

Развитие проекта Электронной Библиотеки

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

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

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

1. Если пользователь не смог найти книгу, то должна быть возможность отправки запроса. Ориентируясь на эти данные руководство библиотеки могло бы расширять свой «арсенал».
2. Добавить изображение обложки книги. Часто визуальный поиск дает наибольший эффект, если пользователь не помнит точное название или автора книги.
3. Пользователю нужно дать право писать комментарии и рецензии к книгам и формировать общую ленту рецензий. Это даст возможность новым читателям оценить необходимость в той или иной книге.
4. Как минимум для каждой книги добавить кнопку «Я прочитал», как максимум — давать оценку книге. Таким образом можно вести рейтинг книг и показывать самые популярные.
5. Ну и если вышеперечисленные пункты реализовать, то нужен отдельный домен и современный, удобный дизайн.
6. Поиск по различным критериям; указание адреса библиотеки, в которой можно книгу найти и заказать; учетная карточка пользователей; учет выданных книг на руки и отслеживание должников — это в каком-то виде уже работает.

Способы реализации

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

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

Есть третий вариант, который мы хотели бы вам предложить.

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

«Школа веб-технологий» предлагает обществам, организациям и компаниям заказать любую веб-разработку, будь то веб-сайт или специализированный сервис. Отличие от заказа у других разработчиков будет состоять в том, что наши ученики осваивают веб-технологии у профессиональных преподавателей-практиков и любая разработка ведется под их руководством. Соответственно, цена за разработку будет низкая, а качество — высокое.

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

• Контактная информация
• Форма заявки на учебу

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

Ни в коем случае не используйте подчёркивание в качестве декоративного оформления каких либо элементов кроме ссылок.

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

Удалённое и добавленное содержимое

Элементы <del> и <ins> существуют для указания в тексте удалённого и обновлённого содержимого.

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

Картофель — 0,80 0,79 €.

В результате получаем: Картофель — 0,80 0,79 €.

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

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

Дополнительные строчные элементы

Вообще, в тексте может быть достаточно много различных строчных элементов (code, samp, var, kbd, tt и другие), которые могут отличаться от основного текста, не только начертанием, но гарнитурой и даже размером шрифта.

Существует достаточно много способов отформатировать специфический элемент в тексте не изменяя его гарнитуры. Например, по-умолчанию элемент <code>, который предназначен для отображения исходного кода программы, имеет моноширинный шрифт. Так как <code> является строчным элементом, то он может быть вставлен в строку среди текста. Если шрифт текста отличается от <code>, то появляется неприятный контраст гарнитур.

Рекомендуется все строчные элементы используемые среди текста отображать той же гарнитурой и тем же размером кегля, что и у основного текста. Если нужно выделить, то рекомендую воспользоваться стандартными средствами для изменения начертания (font-style, font-weight, font-variant), цветом, цветом фона, границами элемента. Но ни в коем случае не менять гарнитуру.

Форматирование в редакторах

Текстовые редакторы в современных CMS системах дают возможность отформатировать текст по нашему вкусу. И это очень плохо. Почему? Ну представьте себе, что вы создали дизайн сайта, настроили отображение основных элементов текста, а администратор сайта, при размещении материала стал злоупотреблять возможностями текстового редактора: покрасил текст в розовый цвет, добавил синий фоновый цвет, увеличил шрифт, сделал его наклонным и центрированным. Ужас!

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

К примеру, если смотреть на TinyMCE:

• Термины и их значения, список вопросов и ответов — принцип одинаковый (текстовые редакторы ими пренебрегают);
• Сноски — как в Википедии. Можно использовать вместе с элементом <dfn> для обозначения терминов. Возле термина ставится номер сноски (<sup>), а внизу страницы помещается строка с описанием термина или пояснением какого-то момента в тексте;
• Примечания, дополнения, определения. Важные и довольно часто необходимые элементы, которые можно оформлять в виде плашек или помещаться в рамки;
• Важные примечания, дополнения, определения. Возможно каждому элементу можно задавать уровень важности и от этого будет выбираться оформление;
• Содержание статьи, например в виде списка «якорей», генерируемый автоматически по количеству заголовков в тексте;
• Предусмотреть варианты вставки иллюстраций, видео и аудио материалов с определёнными размерами, расположением и отступами;
• Правильное оформление цитат, удалённого и обновлённого содержимого со всеми необходимыми атрибутами.
• Эпиграф

От чего следует отказаться в WYSIWYG-редакторах:

• Подчёркивание (underline);
• Горизонтальное выравнивание (text-align);
• Выбор гарнитуры (font-family);
• Выбор кегля (font-size);
• Отступ/Выступ (indent/outdent);
• Выравнивание, размеры, качество, отступы, цвета фона и рамок иллюстраций и других медиа-файлов;
• Выбор цвета шрифта и фона;
• Смайлики (они допустимы только в переписке);
• Изменение размеров и цвета горизонтального разделителя;
• Слои (div { position: absolute });
• Любое изменение стилей

Любое оформление должно быть спроектировано, нарисовано дизайнером и записано верстальщиком в CSS файл. В редакторе должен быть выбор классов и элементов по их смысловому значению. Администратор вообще не должен задумываться о том, как это будет выглядеть.

Жду предложений по дополнению списков.

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

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

Например, зайдя на сайт hp я могу выбрать Латвию и посмотреть продукты продаваемые на территории моей страны, но не могу выбрать русский язык, который является родным для 30% населения. Мне приходится выбирать Российскую локализацию. В этом случае может возникнуть проблема в том, что тот или иной продукт, который я для себя присмотрю не будет доступен в Латвии.

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

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

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

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

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

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

Владельцы среднего и мелкого бизнеса мотивируют своё мнение относительно цен на сайты слухами о том, что какой-то мифический «студент» за 50—100 Ls (100—200 $) и всего за три дня может сварганить им сайтик (на основе знаний полученных в институте на примитивных занятиях, громко названных «Web-dizains», на которых в течение полугода преподают HTML версии этак 3.2), а «такая-то студия Web-дизайна» (в которой работают те же студенты или выпускники), чуть дороже (150—200 Ls) «напрограммирует» Web-сайт в короткие сроки и даже с CMS-системой.

Конечно, студенту тоже хочется кушать, опять же учёбу надо оплачивать и возможно этот заказ — предел его мечтаний. Нарежет картинок, сверстает сайт в таблицах корректно работающий только в IE и с кодировкой windows-1251 (рус.) или windows-1257 (лат.). Я уже не говорю о грамматике и типографике содержимого сайта, которое в спешном порядке поручили набрать секретарше, только потому, что она единственный человек на фирме работающий на компьютере.

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

А что там делать-то? Сел, да нарисовал. Логотип — туда, текст — сюда, картинки, кнопочки и готово.

Не люблю таких клиентов и стараюсь от них избавляться (нет я не убиваю их, просто говорю “До свидания”).

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

Чаще всего именно из-за малой доли таких вот клиентов, крупным Web-студиям приходится искать клиентуру «за бугром».

Я бы обругал заказчиков, которым наплевать на то, что о них будут говорить парнёры клиенты и поставщики, увидев на их сайте какую-то летающую херню, типа грубо вырезанного дирижабля, на флеше с большой надписью «Welcome!», которые экономят деньги считая web-дизайн баловством, не достойным больших затрат и больших сроков исполнения. Но что толку? Народ никогда не поумнеет, пока кто-то из партнёров не перестанет шептать о том, как классно сделать сайт самому, на сервисе теплейтов или о том, какой умный парнишка, одноклассник его дочки, за ночь может сделать крутой сайт с летающими надписями и горящими факелами, пока не перестанет в поисковике писать запросы “web сайт дешево”. Да, и в конце концов не перестанет умничать:

Вот когда ты будешь строить большие красивые дома, тогда и будешь меня учить как делать сайты

О вкусах

Вкуса в Web-дизайне нет ни у кого. Люди могут лишь ориентироваться на собственные ощущения, которые не так уж и просто выразить. Заказчик может только лишь сказать «нравится» или не «нравится», тем более что Web-дизайн достаточно молодой вид искусства (всё-таки я считаю его искусством, а не ремеслом, как некоторые) и вкусы относительно него ещё не достаточно сформировались (и не известно сформируются ли вообще, судя по напичкиванию новыми технологиями) в что-то конкретное, как например, в моде, полиграфии или дизайне интерьера. Немного надёргано из кино/телевидения, полиграфии, анимации, дизайна среды, а так же фотографии и живописи.

Большинство известных web-дизайнеров не могут прийти к единому определению Web-дизайна. Часть из них приверженцы декоративного стиля, часть — юзабилисты. Остальные же пробуют найти золотую середину. В определениях всё ещё очень зыбко. Как только кто-то пытается сказать всем как правильно, найдутся сотни тех, кто против и приведут кучу доводов. Так же бывает с молодыми жанрами музыки и живописи.

P. S. что-то backlinks перестали обновляться. Странно что WP сделали бэклинки используя Google Blog Search, вместо Technorati.

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

Первые два заголовка (Arial, Trebuchet MS) выглядят очень топорно. Последние два (Times New Roman, Georgia) — более эффектно и приятно. Нет эффекта громоздкости.

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

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

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

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

Monotype

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

Напоследок

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

Ничего более быстрого не нашёл, как взять пример с моего блога.

1. Посетитель должен понимать, что это именно переключение языков и не должен разгадывать ребус из нафантазируемой вами визуализации.
2. Переключение языков должно указывать на название языка, а не на страну, откуда произошёл данный язык или где чаще употребляется.
3. Блок с языковым меню должен быть виден сразу, а не после “сгиба”.

Знакомых буков не нашёл, полез в гугл

Если пользователь не найдёт как посмотреть содержимое сайта на его родном языке, то он возможно и не захочет читать информацию на этом сайте и будет искать её дальше. Чаще всего блок с языками находится в верхней части сайта, но есть исключения.Изначально всё зависит от количества языков. Вполне подходит горизонтальное меню до 5 языков. Если их больше 5, то скорей всего нужно выход искать в вертикальном расположении языков. Тут может быть два способа:

• Блок вертикального меню с сылками
• Выпадающий select

В первом случае, при большом количестве языков, блок может быть очень растянут вниз. Это нормально, если – это основа сайта – интернациональность.Во-втором случае, выпадающий контрол достаточно компактен, но заставляет посетителя щёлкать два раза для достижения результата, хотя с другой стороны позволяет использовать клавиатуру. Этот вариант вызывает много негативных откликов, в основном из-за спорного удобства элемента select(хотя, даже Гигант не гнушается его использованием).Во всех случаях, важно, чтобы список языков начался до “сгиба”, иначе посетитель может даже не начать прокручивать сайт. Так, что можем показать пальцем на сайты Apple и Skype.

Флажки в топку

Государственный флаг является одним из государственных символов. Wikipedia

Флаги государств таких как Соединённое Королевство, Соединённые Штаты Америки, Россия, Латвия очень часто используются на web-сайтах средней паршивости, для обозначения языка. Начнём с того, что в Латвии живёт 30% русских, а русскоговорящих ещё больше. Так, почему же, для того чтобы прочитать содержимое сайта на своём родном языке я должен выбирать флаг России? Опять же, во многих странах очень большое количество русскоязычных и англоговорящих (неговоря уже об испанском и португальском языках). И другие “почему?”:

• Почему для обозначения английского языка используется, например, флаг Великобритании, а не США, Автсралии, Южно-Африканской республики?
• Какой флаг должны выбирать жители Бельгии, Люксембурга, Швейцарии, Канады?
• А курды, например, не имеют собственного флага, и живут они в Турции, Ираке и других странах.
• Какой флаг нужно определить для арабского языка? Страны, в которых говорят на арабском, занимают пол-Азии.

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

Страны

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

• При выборе России, я могу прочитать и точно понять всю информацию, но за контактами мне нужно лезть на Microsoft Latvia.
• при выборе Латвии, я могу просмотреть сайт только на латышском языке, что-то не пойму, но зато вся информация будет касаться только этой страны: распрастраняемые продукты, контакты.

В общем, чтобы полностью удовлетвориться, мне нужно посетить сразу два сайта.Почти идеальное решение проблемы реализовано на сайте Adobe, где в выборе локализации указана страна вместе с языком. В итоге, мы видим по три пункта меню для Бельгии, Люксембурга и Швейцарии, а так же два пункта для Гонконга. Но всё равно есть одна ошибка, о которой ниже.

Выбор языков (именно языков)

Если выбор страны не актуален и не связан с деятельностью в различных странах, то лучше всего писать полное название языка: русский | latviešu | english или склонённый вариант по-русски | latviski | englishКак видите, английский язык не склоняется, поэтому одинаков в обоих случаях. Конечно, есть вариант использования ISO-сокращений, но я считаю этот вариант не удобным из-за обилия латинских символов, которые больше похожи на список доменных имён верхнего уровня. Кроме того, нужно знать ISO-обозначение своего языка. Некоторые могут быть не знакомы с ISO стандартами. Хотя этот способ более компактный. !!! Ни в коем случае нельзя писать названия языков на том языке, который в данный момент активен. Пример: krieviski | latviski | angliski Кто-нибудь из россиян знает, что “по-русски” на латышском языке пишется “krieviski”? Думаю, очень малое количество. Adobe, написали название языков и стран на английском языке. Хоть английский язык и международный (считается), но я не уверен, что все будут довольны поиском своего языка по их английским названиям (учитывая какие, например, французы шовинисты).

Flash сайты

Независимость flash-based сайтов от истории браузера и адресной строки не позволяет переключать языки и оставаться на той же странице. Это нужно делать в рамках flash, чем разработчики чаще всего пренебрегают. Поэтому на таких сайтах предлагается выбрать язык перед тем как просматривать информацию на сайте. Flash-сайт не делают для корпоративных проектов. Чаще это презентационные или имиджевые сайты, на которых нет потребности в переключении языков внутри сайта.