Категория со cтатьями по проектированию пользовательских интерфейсов. Основная масса посвещена интерфейсам в вебе. Рассказывает об основных элементах веб интерфейсов таких как: радиобатонны, чекбоксы, выпадающие списки и поля ввода текста. Затрагивает тему прототипирования интерфейсов, в том числе и бумажное прототипирование. Много материала посвящено дизайну интерфейсов — UI, и созданию правильного пользовательского опыта — UX, который поможет создать интуитивно понятный интерфейс сайта.
05 Янв 2012, 14:00, написал Максим Шайхалов в разделе «Интерфейс»
Разговоры о так называемой «простоте», стали необычайно популярными. Появился довольно распространенный подход «сделать проще» — и создать интерфейс лучшего качества. Некоторые не совсем правильно понимают этот принцип простоты. Они считают, что если, сузить рамки проекта, или сократить его функциональность, можно достичь этой самой простоты. Однако, это не так.
Чтобы сделать что-либо более простым, существуют два способа:
Первый заключается именно в сокращении рамок проекта. О нем как раз говорилось выше.
Действительно, таким образом можно достичь некоторой простоты в удобстве использования продукта, но, чаще всего, цель проекта становится трудно достижимой.
Второй способ заключается в том, чтобы сконцентрировать свое внимание на главном. В этом случае убирать ничего не нужно, а возможно даже придется добавлять функциональности. Главным образом вам необходимо скоординировать фокус. Благодаря этому, пользователи смогут гораздо более гибко и быстро использовать ресурсы для достижения своих целей.
На сегодняшний день многие компании уверены, что простота — это сокращение доступных функций устройства, однако это отнюдь не является истиной. Дело в том, чтобы совместить простые кнопки с технически сложным устройством. Вспомним хотя бы пример iPod-a. Это был первый плейер, который стал доступен для потребителя. До модели iPod classic все плейеры были лишь отражением их технической новизны и сложного устройства, поэтому они были ориентированы исключительно на человека, разбирающегося в технических новинках. Компания Apple подошла к вопросу иначе и сразу завоевала лидирующие позиции.
Из этого можно сделать элементарный вывод. Простота помогает добиваться успеха.
02 Дек 2011, 8:00, написал Максим Шайхалов в разделе «Интерфейс»
При локализации текста особое внимание надо уделить гибкости макета – чем более гибким он будет, тем лучше будет и конечный результат. Текст должен плавно перетекать, по возможности следует избегать размещать небольшие фиксированные блоки, или хотя бы не размещать их слишком плотно. Особую аккуратность надо проявить при проведении точного позиционирования текста в макете. Содержимое страницы следует разделять так, чтобы при переводе была возможность легко адаптировать шрифт и межстрочные интервалы. Не следует забывать об этом и в процессе проектирования баз данных, при задании длины текстовых полей.
Самые сложные тексты – на английском и китайском.
Так как текст, написанный на английском и китайском языках обычно очень компактен, перевод с них обычно получается намного шире. Например, когда был сделан перевод на разные языки пользовательского интерфейса «Flickr». Наиболее часто при просмотре фотографий встречается сообщение о количестве просмотров – «392 просмотра». Можно попробовать сравнить длину слова «просмотр» в переводе на различные языки с длиной оригинала на английском. Например, если взять за основу, что длина английского «views» равна 1, то его корейский аналог «조회» будет иметь длину 0,8; китайский «次 检视» — 1,2; португальский «visualizações» — 2,6; французский «consultations» — 2,6; немецкий «-mal angesehen» — 2,8; итальянский «visualizzazioni» — 3.
В связи с большой шириной иероглифов каждый китайский или корейский символ равен двум символам на английском. В данном случае увеличение длины слова на итальянском языке в 300% — обычное дело.
Компанией «IBM» в 1994 опубликовано специальное «Руководство по проектированию локализированных приложений», в котором можно найти средние значения того, как соотносится длина переводов с английского языка на другие. Например, если в английском слове меньше 10 символов, то его длина при переводе увеличится в 200-300%; от 11 до 20 символов – 180-200%; от 21 до 30 символов – 160-180%; от 31 до 50 символов – 140-160%; от 51 до 70 символов – 130-140%; от 70 символов и больше – 70-150%. Из этого можно сделать вывод, что обычно переведенный текст занимает больше места, чем исходный. Кроме того, чем меньше будет исходное сообщение, тем большей будет вероятность его существенного увеличения при переводе. Поэтому, такой вариант развития событий тоже необходимо учитывать, так как при увеличении длины слова, переведенный текст может оказаться «зажатым» в тесном пространстве, например, рядом с полем формы или внутри какого-либо графика. Конечно, не все сообщения или строчки после адаптации увеличиваются в длине, но в случае возникновения такой проблемы переводчик должен найти способ решить ее. Для примера, в интерфейсе «Flickr» перевод аббревиатуры «FAQ» выглядит как «FAQ» на французском и немецком языках, а на португальском и испанском это будет «Perguntas freqüentes» и «Preguntas frecuentes» соответственно.
Нужно иметь в виду, что проблема с расширением текста не является особенностью интерфейсов, в которых оригинальный текст написан на английском или китайском языке. Допустим, если исходный вариант текста на испанском выглядит как «Idioma de la interfaz», то при переводе его на английский длина текста сократится до «Interface language», а на малайский – увеличится до «Bahasar pegantar untuk penelusuran». Также как и значительное увеличение, уменьшение количества символов тоже плохо повлияет на общий вид страницы – на ней появится избыточное пустое пространство.
Если текст переводится целыми абзацами, то, скорее всего, его относительное расширение будет меньшим. Но ситуации, которые потребуют внимания все же будут, поэтому расслабляться не стоит. Например, возможно ли будет отобразить на «первом экране» все задуманные элементы? Сохранится ли желаемый вариант выравнивания, если текстовые блоки будут расти по высоте с разными скоростями?
31 Окт 2011, 13:00, написал Максим Шайхалов в разделе «Интерфейс»
Ползая по чужим портфолио и рассматривая чужие работы, я заметил, что вообщем-то, хорошие ребята допускают глупейшие ошибки взаимодействия с пользователем. Они умеют рисовать красиво, но не проектируют правильно.
Одна из таких ошибок — перепутать кнопку с ссылкой. Я думаю, картинка с заглавии статьи наиболее точно описывает человека, столкнувшегося на сайте с таким оформлением. Что мы видим? Активная ссылка (т. е. ссылка на страницу на которой мы находимся) оформлена так же как и кнопка заказа. Лично я бы попробовал понажимать кнопку «Безлимитные карты».
Ссылка — это другая страница, на которую ссылаются с текущей. Как правило она выражается существительным. В далекой древности, когда не было интернетов ссылки можно было найти в книгах и научных работах. Они отсылали читателя к другим работам для более полного раскрытия темы.
— как правило, это элемент действия. Надпись на кнопке должна быть в форме глагола и соответствовать тому, что сделает пользователь. На кнопке не должно быть абстрактных надписей в виде «Отправить» («Submit» в английском варианте).
Есть, конечно, также псевдоссылки, но не стоит путать их с кнопками. Это не кнопка, выглядящая как ссылка. Разница с псевдоссылками состоит в том, что нажатие кнопки ведет к отправке данных (например: кнопка «Заказать» отправляет данные о заказе, «Оставить комментарий» отправляет комментарий на сайт). В то время когда нажатие на псевдоссылку приводит к действию внутри страницы.
Однако «Заказать» может быть и ссылкой, если она ведет на страницу с контактами.
Вывод: ссылка — это не кнопка, а кнопка — это не ссылка. Поэтому, они не должны выглядеть одинаково. Эти два элемента интерфейса не могу заменять друг друга. Дизайнер должен понимать логику работы сайта и интуитивно знать где какой элемент применить.
25 Окт 2011, 13:00, написал Максим Шайхалов в разделе «Интерфейс»
Между дизайнером и заказчиком очень часто возникает недопонимание. Очевидно, что дизайнер является профессионалом в своем деле, а заказчик может и вовсе не разбираться в данном вопросе. Между тем принимать решение все же надо. Как же понять, хорош ли предложенный дизайн или же он является абсолютно сумбурным, неудобным для пользователей и будет отталкивать посетителей?
Конечно, сложно в небольшой статье преподать все хитрости дизайна, но все же постараемся вооружить читателя некоторыми критериями для оценки и корректировки предложения дизайнеров.
Чем раньше, тем лучше
Дизайн создается не один день, а для досконального оттачивания каждого элемента и связки его с программной частью продукта уходит и вовсе колоссальное время. Потому, если вы хотите принимать живейшее участие в процессе, лучше вмешаться сразу, на стадии создания эскиза. Позже внести какие-то изменения будет довольно проблематично и очень трудоемко. Что, конечно же, вряд ли будет воспринято с восторгом.
Если уже готов макет, то лучше вносить небольшие правки, а после запуска проекта и его пилотного прогона можно будет подумать о том, существует ли необходимость в глобальных изменениях.
Не заставляйте пользователя думать
Современный пользователь — существо чрезвычайно занятое. Он не будет тратить даже 5 секунд на то, чтобы сообразить, как добиться того или иного результата — он попросту покинет ресурс или закроет программу. Кроме того, хотя вам, возможно, хочется собрать, как можно больше информации о своих пользователях или посетителях, избавьте их от необходимости заполнять бесконечные анкеты или подтверждать сделанный выбор. Поверьте, они будут благодарны.
17 Окт 2011, 11:06, написал Максим Шайхалов в разделе «Интерфейс»
Этот пост будет немного необычен т.к. представляет из себя этакий видеопост т. е. подборку видео уроков от Lynda.com по быстрому прототипированию средствами Fireworks CS5. Линдоновские уроки мне на самом деле очень нравятся и как обещают на сайте — реально работают.
До этого я показывал как нарисовать прототип на бумаге. Теперь переходим к непосредственной работе на компьютере.
26 Сен 2011, 13:00, написал Максим Шайхалов в разделе «Интерфейс»
Все давно уже знают и помнят заветные кнопки «Ок» и «Отмена», которые позволяют нам соглашаться с тем или иным текстом в диалоговом окне. Обратите внимание — соглашаться с текстом окна, т. е. необходимо сначала прочитать текст, потом подумать и решить, что обозначают те или иные кнопки и какую именно надо нажимать.
Печатаем какой-нибудь важный текст и решили его закрыть. Перед тем, как завершиться, программа из Windows спросит, сохранить ли этот текст.
И получается так, что мы сначала обращаем внимание на кнопки, которые безмолвно говорят нам «Да», «Нет» или «Отмена», но об истинном значении этих кнопок мы узнаем, лишь прочитав диалоговое окно. Неудобно, особенно если работаешь с какой-нибудь новой программой, и диалоговые окна в ней сначала нужно изучить, а это — драгоценное время.
А если бы на кнопках вместо безликих коллег из Windows были бы надписи, например, «Сохранить», «Не сохранять» или «Отменить», то по одному взгляду на кнопки можно будет знать, что они значат.
Теперь перейдем от диалоговых окон Windows к аналогичным из Mac OS X.
Если использовать текстовый редактор и попытаться выйти, предварительно не позаботившись о сохранении текста в файле, то мы увидим диалоговое окно, которое по смыслу схоже с тем, что было в Виндовс, но объясняется все, что произойдет по нажатию той или иной кнопки до мельчайших деталей. Внимание приковывают кнопки — понимаешь, что нужно делать, с первого взгляда. Все кнопки содержат в себе смысл, выражаемый действием — «Сохранить», «Не сохранять» и «Отменить». Существенно повышается работоспособность, скорость и эффективность работы, ведь теперь не нужно будет читать текст диалогового окна целиком, а узнавать все по надписям на кнопках.
Кнопки сами подсказывают юзеру смысл их создания. И хоть это лишь простой пример, но подобный прием нужно использовать везде, где только можно, ведь это действительно сэкономит огромное количество такого драгоценного времени.
08 Сен 2011, 13:00, написал Максим Шайхалов в разделе «Интерфейс»
Во многих приложениях, иконки используются для иллюстрации специфических функций — они могут быть использованы для всего, от информирования до действий. Но если пользователь не понимает, иконки, то какой в них смысл?
При дизайне, вы стараетесь рисовать/использовать изоморфные иконки — то есть пиктограммы, которые взяты из реальной жизни (например, мусорное ведро, кисть, ластик и т. д). Пока вы можете подобрать несколько достойных метафор, эти значки будут работать. Но что делать если нет метафоры из реальной жизни?
В качестве примера, я собираюсь использовать значок ссылки. «Ссылку?» — скажите Вы. «Все знают как выглядит значок ссылки!» Какая первая иконка приходит вам на ум, когда вы думаете о вставки ссылки в электронной почте, блоге или любимой CMS? Цепь? Земной шар? ...? Да, есть несколько различных иконок для вставки ссылок, и вы можете подумать, что все они логичны. Но не обязательно.
Как это делают большие парни?
Примеры иконок ссылок в различных веб-приложениях и программах
Как вы можете видеть, большинство CMS и приложения используют цепочки. Только одна иконка действительно отделяется от остальных — Facebook, который использует значок листков. И я думаю, он несет еще меньше смысла чем, цепочки.
29 Авг 2011, 12:30, написал Максим Шайхалов в разделе «Интерфейс»
Я был на совещании несколько недель назад, где был спор о том, какую кнопку лучше использовать: «Новый» или «Добавить». Истина же в том, что эти команды разные и не взаимозаменяемы. Самым простым способом объяснения может служить этот пример интерфейса:
11 Июл 2011, 12:00, написал Максим Шайхалов в разделе «Интерфейс»
Многие из вас могут быть знакомы с использованием многоточий в меню, но вы знаете правила, когда их использовать?
Посмотрите на меню «Файл» Firefox на скриншоте ниже. Некоторые из этих пунктов меню (например, «Открыть файл ...») имеют многоточия, а другие (например, «Новое окно») нет.
Firefox, меню Файл, показаны многоточия
Многоточие используется, чтобы обозначить, что программе будет необходимо открыть окно, чтобы запросить дополнительную информацию, прежде чем она сможет выполнить команду.
08 Июн 2011, 13:00, написал Максим Шайхалов в разделе «Интерфейс»
Многие сайты используют черный текст на светлом фоне, потому что его легко читать. Однако, белый текст на темном фоне также может иметь свои преимущества. Знание, когда использовать одно из решений поможет сделать ваши проекты лучше.
