Янв 05 2012

Как правильно упрощать

Категория: ИнтерфейсыМаксим Шайхалов @ 14:00

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

Чтобы сделать что-либо более простым, существуют два способа:

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

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

stream thumb Трудности перевода

В связи с большой шириной иероглифов каждый китайский или корейский символ равен двум символам на английском. В данном случае увеличение длины слова на итальянском языке в 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». Также как и значительное увеличение, уменьшение количества символов тоже плохо повлияет на общий вид страницы – на ней появится избыточное пустое пространство.

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

Осложнения

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

Сочленённые существительные

В некоторых языках германской группы (финский, немецкий, голландский) часто бывают случаи, в которых несколько последовательных слов при переводе с других языков становятся одним большим. Например, английское словосочетание «Input processing features» на немецком приобретает вид «Eingabeverarbeitungsfunktionen». Английский текст, при необходимости, без усилий можно разбить на отдельные строчки, тогда как немецкое «супер-слово» создаст значительную проблему в макете.

Ширина символов

Восточные и некоторые другие языки имеют более сложное начертание символов, чем латиница. Это приводит к такой проблеме, когда длина слова в строчке неизменна или даже меньше в переводе, чем в исходном варианте, но она все равно занимает больше пространства, чем в оригинале, за счет большей высоты символов. Например, «desktop» на английском, в японском переводе будет выглядеть «デスクトップ».

Высота символов и междустрочные интервалы

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

enlineheight thumb Трудности перевода

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

Использование аббревиатур

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

via w3.org

Читать дальше →

Теги: , , ,


Окт 31 2011

Кнопка или ссылка

Категория: ИнтерфейсыМаксим Шайхалов @ 13:00

links or button thumb Кнопка или ссылка

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

Одна из таких ошибок — перепутать кнопку с ссылкой. Я думаю, картинка с заглавии статьи наиболее точно описывает человека, столкнувшегося на сайте с таким оформлением. Что мы видим? Активная ссылка (т. е. ссылка на страницу на которой мы находимся) оформлена так же как и кнопка заказа. Лично я бы попробовал понажимать кнопку «Безлимитные карты».

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

button thumb Кнопка или ссылка — как правило, это элемент действия. Надпись на кнопке должна быть в форме глагола и соответствовать тому, что сделает пользователь. На кнопке не должно быть абстрактных надписей в виде «Отправить» («Submit» в английском варианте).

Есть, конечно, также псевдоссылки, но не стоит путать их с кнопками. Это не кнопка, выглядящая как ссылка. Разница с псевдоссылками состоит в том, что нажатие кнопки ведет к отправке данных (например: кнопка «Заказать» отправляет данные о заказе, «Оставить комментарий» отправляет комментарий на сайт). В то время когда нажатие на псевдоссылку приводит к действию внутри страницы.

Однако «Заказать» может быть и ссылкой, если она ведет на страницу с контактами.

cap thumb Кнопка или ссылка Вывод: ссылка — это не кнопка, а кнопка — это не ссылка. Поэтому, они не должны выглядеть одинаково. Эти два элемента интерфейса не могу заменять друг друга. Дизайнер должен понимать логику работы сайта и интуитивно знать где какой элемент применить.

Теги: , , ,


Окт 25 2011

Как оценить дизайн?

Категория: ИнтерфейсыМаксим Шайхалов @ 13:00

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

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

Чем раньше, тем лучше

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

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

Не заставляйте пользователя думать

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

Чем проще, тем лучше

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

Сокращаем путь к результату

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

Удобная группировка

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

Иконки могут быть сложными для понимания

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

Добивайтесь однозначности

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

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

Отдаем предпочтение функционалу

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

Читать дальше →

Теги: , , , ,


Окт 17 2011

Быстрое прототипирование в Fireworks CS5 (видеоуроки)

Категория: ИнтерфейсыМаксим Шайхалов @ 11:06

lynda thumb Быстрое прототипирование в Fireworks CS5 (видеоуроки)

Этот пост будет немного необычен т.к. представляет из себя этакий видеопост т. е. подборку видео уроков от Lynda.com по быстрому прототипированию средствами Fireworks CS5. Линдоновские уроки мне на самом деле очень нравятся и как обещают на сайте — реально работают.

Внимание: все уроки на английском.

Начнем!

Читать дальше →

Теги: , ,


Следующая страница →