Матчасть

Делай, а не спрашивай

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

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

Например, коллега Павел Коноплицкий в своем посте «Делая интернет-платежи простыми и удобными. Перепроектирование системы A1Pay» (эта же статья для тонких ценителей хабрабабра: http://habrahabr.ru/blogs/ui/123859/) рассказывает нам о своем опыте перепроектирования уже работающего интернет-ресурса. Среди прочих проблем, присутствовавших в интерфейсе, Павел выделил отсутствие подтверждения при удалении объектов.

Вот, что он пишет:

У важных операций, когда данные не могут быть восстановлены (например удаление), отсутствовало подтверждение. Было сформулировано следующее правило:

Подтверждение удаления

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

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

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

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

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

Подобное решение уже используется на ряде сайтов и сервисов. Например, Вконтакте:

Вконтакте-Удаление поста

Такой подход к удалению данных избавляет интерфейс от вышеперечисленных проблем и не считает человека за дурака.

Стандартный
Книги

Джеф Раскин. Интерфейс: новые направления в проектировании компьютерных систем

От издателя:

Книга эта непростая и подойдет не каждому. Автор анализирует то, к чему мы все давно привыкли до автоматизма, и объясняет, что интерфейс многих современных программ далек от совершенства. Как его улучшить, в каком направлении двигаться дальше? Попробуйте найти ответы вместе с самым известным специалистом в этой области — Джефом Раскиным, создателя проекта Apple Macintosh.

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

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

Раскин Д.Интерфейс.Новые направления в проектировании компьютерных систем

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

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

— Якоб Нильсен (Jacob Nielsen)

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

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

Читать онлайнКупить

Об авторе

Джеф РаскинДжеф Раскин

Независимый консультант по разработке компьютерных интерфейсов и систем (www.jefraskin.com). Он изобрел компьютеры Apple Macintosh и Canon Cat. Среди его клиентов такие транснациональные компании, как Hewlett-Packard, IBM, Motorola, NCR, Xerox, Ricoh, Canon, McKesson и AT&T. Он опубликовал свыше 500 статей в более чем 40 периодических изданиях, таких как Wired, Forbes ASAP, IEEE Spectrum, Nature, Quantum. Раскин преподавал в Калифорнийском, Стэндфордском университетах и других учебных заведениях. Он часто вел семинары, выступал по радио и телевидению и участвовал в большом количестве конференций.

Стандартный
Видео

Дмитрий Сатин. Исследование и вовлечение пользователей

16 марта 2011 года состоялась открытая лекция Дмитрия Сатина, Генерального директора USABILITYLAB на тему: «Исследование и вовлечение пользователей».

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

Лекция прошла в рамках открытых лекций программы профессиональной переподготовки «Менеджмент в сфере электронного бизнеса и интернет-проектов» Высшей школы бизнес-информатики НИУ ВШЭ.

Стандартный
Книги

37signals. Getting Real: Более умный, быстрый и легкий способ для создания успешного веб-приложения

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

Getting Real

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

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

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

— Глава 9. «Создание интерфейса»

Мотивирующие тезисы изложены в очень простой и сильной форме.

Getting Real — это отказ от вещей, представляющих реальность (диаграммы, графики, схемы, стрелочки и модели) и создание реальной вещи.

Getting Real — это значит «меньше». Меньше массы, меньше программного обеспечения и его возможностей, меньше бумагомарания — словом, меньше всего того, что является несущественным (а большая часть того, что, как вам кажется, критически важно, на самом деле таковым не является).

Getting Real значит оставаться небольшим и шустрым.

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

Getting Real — это итерации и снижение стоимости изменений.

Getting Real — это запуск и постоянное улучшение. То есть подход, идеальный для веб-приложений.

Getting Real — это создание того, в чём нуждается клиент и исключение того, что ему не нужно.

Книга обязательна к прочтению любому разработчику ПО, вне зависимости от специализации.

Читать книгу онлайн

Об авторах

37signalsАвторы книги — сотрудники небольшой компании 37signals: Джейсон Фрид (Jason Fried), Дэвид Хейнемайер Хансон (David Heinemeier Hansson), Мэтью Линдерман (Matthew Linderman).

Стандартный
Видео

Дурацкие интерфейсы

Интересная и забавная видео-подборка ошибок в интерфейсах, которую собрал Дмитрий Сатин.

Стандартный
Видео

iA Writer

Хорошим примером минималистичного дизайна интерфейсов и правильных взглядов на разработку программного обеспечения является текстовый редактор iA Writer от Information Architects, Inc.

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

Стандартный
Статьи

Это не адаптивная веб-разработка, это — адаптивный веб-дизайн

Автор: Франциско Инхосте (FRANCISCO INCHAUSTE)
Оригинал: http://www.getfinch.com/finch/entry/its-not-responsive-web-building-its-responsive-web-design/ (11 августа 2011)

elasticman

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

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

mediaqueries

Mediaqueri.es — свежая галерея, специализирующаяся на адаптивном дизайне.

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

Круги АВД

Большая часть постов в интернете оставила меня в сомнениях относительно того, что мы подразумеваем, когда говорим об АВД, и что он есть на самом деле. Для того, чтобы разобраться, я попробовал разделить обсуждения и мнения по группам. Назовем их кругами — так, как это сегодня делают все крутые парни, группирующие что-либо. Представляю вашему вниманию: Круги Адаптивного Веб-Дизайна.

Круг «АВД — это метод»

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

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

Для этого круга считается нормальным задвинуть такую фразу: «Известно, что люди приходят посмотреть содержание сайта разными способами. Поэтому, вместо того, чтобы заниматься гаданием на кофейной гуще или разрабатывать 15 версий одного сайта (и потом каждый раз соглашаться на доработку чего-то нового), давайте просто сделаем эту хрень адаптивной» [1].

Круг «АВД — это философия»

Для этого круга характерна следующая точка зрения: АВД спасает нас от фиксированной ширины и грехов типа «наилучшее отображение в [Название_Бразуера]». Один из самых больших сторонников АВД, Джефри Зельдман (JEFFREY ZELDMAN) дает такое определение:

«…это очередной этап эволюции в веб-разработке и проектировании взаимодействия. Как с практической точки зрения, так и для всей индустрии
в целом.»

Люди из этого круга считают, что это не просто инструмент или практический метод. Это философия для всего, что связано в веб-дизайном. Что подразумевается под этим? Имеется ввиду сущность АВД. Он является неотъемлемой частью веб-дизайна. В общем случае, когда мы разрабатываем сайт, нам не надо решать, применять АВД или нет — он просто должен быть. Без вариантов. И если ваш дизайн не адаптивный, то, как сказал Энди Кларк (ANDY СLARKE):

«Это уже не веб-дизайн, а что-то другое. Если вы не учитываете в своей работе врожденное непостоянство веба, то вы не веб-дизайнер, а кто-то другой. Веб-дизайн — это адаптивный дизайн, а адаптивный веб-дизайн — это веб-дизайн, и никак иначе.»

Круг «АВД — это тренд»

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

Как правило, критики АВД опираются на техническую сторону вопроса, а также на практичность применения такого подхода с точки зрения бизнеса. Это, в свою очередь, заставляет переосмыслить многие вещи, такие как платформа для содержания и затраты на редизайн. Критики также аргументируют тем, что технологии типа @media-queries и javascript до сих пор не поддерживаются браузерами во многих мобильных устройствах.

Несмотря на то, что рассматриваемый метод (философия) еще очень молод, эта группа не слишком ему рада.

Дизайнерский взгляд

Большинство обсуждений АВД уделяет слишком большое внимание техническим аспектам. Это не адаптивная веб-разработка, это — адаптивный веб-дизайн. Смотреть сайт в превосходном качестве на любом экране звучит красиво. Самый простой дизайнерский ответ на вопрос о пользе АВД звучит так: «все зависит от …». Очевидно, что это беспроигрышный вариант. Поэтому далее я попытаюсь сформулировать свое мнение, дав другой ответ.

«Но что значит быть по-настоящему „адаптивным“? Я считаю, что это обязывает понимать человека по другую сторону экрана и, самое главное, контекст, в котором он находится.»
— Джеймс Пирс (JAMES PEARCE)

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

Каждое устройство имеет форм-фактор и относится к определенному классу устройств [2]. Например, смотря телевизор, вы можете откинуться назад и с расстояния в 10 футов взаимодействовать с ним, используя пульт управления.

«Хотя и существует возможность использовать всего один интерфейс для работы с более, чем одним классом устройств, разработка такого интерфейса обычно приводит к существенным компромиссам или рахитичному опыту взаимодействия, который не позволяет воспользоваться преимуществами, делающими каждый из классов превосходным (или наоборот: к богатым функциональным возможностям, которые не загружаются или ломаются на слабых устройствах).»
— Люк Вроблевски (LUKE WROBLEWSKI)

Хорошо известно, что надо проектировать сайты с учетом специфики мобильных устройств. Но при этом большинство считает хорошей идеей сделать что-либо для персонального компьютера, затем вырвать некоторые элементы, что-то поменять местами и в итоге назвать это пригодным для мобильных устройств. И, раз уж мы об этом заговорили, какой, черт побери, смысл вкладывается в слово «мобильность» в наши дни? Многие из нас думают, что это когда люди в движении или постоянно находятся в отвлекающей обстановке. Однако, данные, иллюстрирующие домашний комфорт, противоречат этому [3]:

  • 93% людей используют свои смартфоны дома;
  • 62% людей используют свои смартфоны для просмотра видео-каналов;
  • 39% людей используют свои смартфоны, когда сидят на толчке.

IPad рассматривается скорее как «портативное», чем «мобильное» устройство, поскольку люди не всегда берут его с собой. И при этом, в большинстве случаев люди ожидают полную функциональность, а не урезанную или модифицированную версию [4].

«Больше 10 лет создания веб-сайтов потребовалось сообществу разработчиков на то, чтобы понять, что конкретные знания о наших посетителях действительно очень важны. Почему сегодня, когда некоторые браузеры помещаются в нашем кармане и имеют сенсорные экраны вместо курсора, мы решили, что больше не нуждаемся в хорошей информации о пользователях?»
— Мэтт Генри (MATT HENRY)

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

Панацеи нет

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

  • Является ли продукт/содержание желанным для потребителя?
  • Готов ли заказчик, и есть ли возможность донести то видение, которое мы проектируем?
  • Готовы ли клиенты попробовать наш новый продукт/услугу вместо текущего решения?

Изображение взято с сайта Yiibu.

Иногда мне кажется, что мы (наша отрасль) очень похожи на определенный тип правительства, которое совершенно оторвано от жизни обычных людей. Самый широкий канал интернета и последняя версия браузера — далеко не для каждого это находится в списке жизненных приоритетов. Мы же, как правило, предпочитаем разрабатывать что-либо для новых устройств, таких как iPhone, потому что там мы действительно можем использовать интересные штуки-дрюки и изучать самые современные технологии. Если даже iPhone имеет слабое проникновение в секторе мобильных устройств [5].

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

«Дизайн — это размышление о содержании и его подаче. Фокусируйтесь на картине в целом. Макет — это еще не дизайн.»
— Люк Вроблевски (LUKE WROBLEWSKI)

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

[1] Mobile-first Responsive Web Design, Брэд Фрост (BRAD FROST)
[2] Networked Consumer Device Platforms, Люк Вроблевски (LUKE WROBLEWSKI)
[3] The Myth of Mobile Context
[4] Five Lessons From a Year of Tablet Research
[5] Rethinking the Mobile Web

Стандартный
Практика

3.3 Косвенные данные

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

Для начала условимся, что все абоненты компании «Сибирские Сети» пользуются автоматизированной системой расчетов. В реальности, это, конечно, не так. Часть аудитории по разным причинам даже и не догадывается о существовании подобного сервиса. Как правило, такие люди имеют небольшой опыт использования интернета и/или пользуются им время от времени. Однако, это не является аргументом для того, чтобы не учитывать эту аудиторию при проектировании. Каждый имеет право на качественное обслуживание.

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

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

Паспорт 211.ru

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

Собранные данные приведены в отдельном документе. Здесь же продублируем лишь конечные графики.

Возраст абонентов, как и ожидалось, имеет нормальное распределение:

Распределение по возрасту

По половому разделению преобладают мужчины:

Гендерное распределение

Большинство представляет собой семейных людей, но при этом не менее значимой является группа, которая «в поиске»:

Семейное положение

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

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

Распределение по городам

Выводы:

  • Преобладающий возраст абонентов равен20-30 лет.
  • 2 из 3 абонентов мужского пола.
  • 2 из 3 абонентов проживают в Новосибирске.

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

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

Форум

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

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

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

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

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

Стандартный
Практика

3.2 Ограничения и условности

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

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

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

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

— Алан Купер об интерфейсе. Основы проектирования взаимодействия.

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

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

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

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

Стандартный
Видео

Вебинары UX Russia

Крайний вебинар сообщества UX Russia посвящен юзабилити в email-маркетинге:

Удивительно, но компании в массе своей мало внимания уделяют своим email-рассылкам, мучая ими своих клиентов, и теряя лицо. На что нужно обратить внимание, чтобы рассылки нравились читателям, и не отпугивали их?

Архив вебинаров удобно расположился на Youtube.

Стандартный
Статьи

П.И. Браславский, Е.А. Вовк, М.Ю. Маслов. «Фасетная организация интернет-каталога и автоматическая жанровая классификация документов»

Из аннотации к статье:

Объем и разнообразие ресурсов интернета приводят к сложности иерархических схем классификации универсальных интернет-каталогов. В качестве возможного решения этой проблемы предлагается подход на основе фасетной классификации (ФК). Каталог «Яндекс», построенный с использованием ФК, имеет фасет «жанр» наряду с другими. В работе описывается разработка автоматической процедуры классификации документов по жанрам; приводятся и обсуждаются результаты тестирования процедуры. Делается вывод об эффективности полученной процедуры, формулируются предложения по дальнейшему развитию и применению метода.

Читать полную версию онлайн

Стандартный
Книги

Влад В. Головач. Дизайн пользовательского интерфейса: искусство мыть слона

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

Влад Головач. Дизайн пользовательского интерфейса

Онлайн-книга Влада Головача «Дизайн пользовательского интерфейса: искусство мыть слона» относится к числу редких отечественных книг по этой тематике.

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

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

  • Ничего готового нету; готовыми вещи становятся вынужденно.
  • День, когда вы только добавили что-то хорошее, но не исправили что-то плохое, — потерянный день.
  • Всё недостаточно хорошее — плохое. Поскольку улучшить можно всё, всё — плохо.
  • Записывайте всё, в частности, совершенные вами ошибки. Нет лучшей гарантии, что вы их не повторите.
  • Планируйте как можно меньше, начинайте проектировать интерфейс как можно раньше, зато переделывайте почаще.
  • Перед тем, как приступать к работе, узнайте, что хуже всего сейчас и начните с решения именно этой проблемы.
  • Если вы не превращаете свои знания в конкретные проектные шаги — это бесполезные знания.
  • Не задавайтесь общими, принципиальными проблемами, пока вы хотя бы трижды не нашли их частное решение.
  • Занимайтесь только той оптимизацией интерфейса, которая улучшает продукт.
  • Лучше принести заказчику приятный сюрприз, чем неприятное открытие.
  • Не менее трети всех интерфейсных решений либо работают гораздо хуже ожидаемого, либо вообще неработоспособны.
  • Повесьте перед своим рабочим местом табличку «В моих интерфейсах есть проблемы, о которых я ничего не знаю».
  • Без тестирования сделать действительно хороший интерфейс можно только случайно и только если интерфейс маленький.
  • Интерфейс хорош, если он:
    • «удобный», «простой» и «юзаб(и)(e)льный»;
    • обладает высокими эргономическими показателями;
    • оптимизирован под своих пользователей;
    • оптимизирован под задачи пользователей;
    • оптимизирован под мотивы пользователей;
    • обладает высокими показателями юзабилити;
    • адекватен деятельности пользователей;
    • коммерчески успешен.
  • Полезно составить список мотивов целевых пользователей и просто сравнить их со списком задач. Даже это помогает лучше оценить адекватность и полноту списка задач.
  • Хороший интерфейс — это сексуальный интерфейс. Сексуальный интерфейс — это интерфейс, который хочется иметь.
  • Проверяйте на оправданность все интерфейсные операции, удаляйте необязательные и исправляйте слишком уж трудоемкие.
  • Вы делаете довольным заказчика, для чего вам нужно сделать хороший интерфейс для пользователей.

В заключение автор приводит небезынтересный с практической точки зрения список из 8 вопросов, которыми должен задаваться проектировщик все время работы над проектом:

  1. Можно ли ускорить взаимодействие пользователя с этим интерфейсом?
  2. Где в этом интерфейсе места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты?
  3. Что в этом интерфейсе не способствует обучению? Что пользователю нужно знать, чтобы успешно взаимодействовать с этим интерфейсом? Есть ли в этом перечне что-то, чего сам интерфейс не сообщает пользователю? Эти три вопроса нужно задавать себе по очереди. Если после ответов видно, что интерфейс надо менять, остальные вопросы нужно задать себе снова после переделки. Если на все три вопроса удалось дать отрицательный ответ, переходим к следующей порции вопросов из остальных концепций качества:
  4. Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим?
  5. Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей?
  6. Совместим ли этот интерфейс со средой, в которой работают пользователи?Если и по этим вопросам всё хорошо, переходим к проверке, как выполняются в интерфейсе задачи пользователей.
  7. Соответственно, этот вопрос звучит как «Есть ли задачи, которые неэффективно отрабатываются интерфейсом?». Как правило, достаточно проговорить вслух (а ещё лучше написать), как в этом интерфейсе пользователь выполняет все свои задачи (лучше всего писать о себе, а не о абстрактном пользователе, например «Из меню Документ я открываю окно настроек зета-преобразования, ввожу значение 40 в поле Количество человеков, затем открываю…»). Как правило, такая проверка выявляет множество несоответствий или попросту пропущенных кусков. Если это произошло, возвращаемся к самому первому вопросу. Если нет, задаем себе последний вопрос:
  8. Сексуален ли этот интерфейс и можно ли его сделать ещё сексуальнее?

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

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

Скачать или читать онлайн

Об авторе

Влад ГоловачВлад Головач
Вместе с Александром Белышкиным основал Usethics, первую в России юзабилити-компанию. По всей видимости, спроектировал больше интерфейсов, чем кто-либо другой в России (и руководил разработкой ещё большего числа интерфейсов). Автор первой оригинальной русскоязычной книги о дизайне программных интерфейсов (более недоступна; это её вторая, полностью переработанная версия).

Стандартный
Практика

3.1 Брошенная проблема

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

С одной стороны мы имеем вполне сносный раздел «Мой интернет» на ресурсе passport.211.ru.

Раздел "Мой интернет"

Здесь можно узнать

  • текущий баланс,
  • историю платежей, списаний и авторизаций,
  • сделать обещанный платеж.

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

Вход в биллинговую систему

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

Биллинговая система

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

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

Давным-давно, еще до того, как «Сибирские Сети» стала действительно региональной телекоммуникационной компанией (купив новокузнецкий «City Net» и расширив зоны обслуживания), в этой компании была установлена и запущена в эксплуатацию автоматизированная система расчетов «СмартАСР» от ООО «АкадемСофт».

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

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

Очевидно, что сегодня компания «Сибирские Сети» не делает ставки на устаревший и полузабытый личный кабинет внутри самой системы расчетов, а продвигает к использованию среди абонентов современный раздел «Мой интернет» на внутреннем ресурсе passport.211.ru.

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

Итак, задача: редизайн личного кабинета пользователя в биллинговой системе компании «Сибирские Сети».

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

Стандартный
Книги

Алан Купер. Психбольница в руках пациентов

От издателя:

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

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

Алан Купер. Психбольница в руках пациентов

Картинка взята отсюда: http://store.artlebedev.ru/books/lebedevs-choice/cooper/

Книга Алана Купера «Психбольница в руках пациентов» одна из тех, что может навсегда изменить ваше представление об окружающем мире. Я бы поставил ее в один ряд с книгой Джима Кемпа «Сначала скажите НЕТ», Алана Карра «Легкий способ бросить курить», Роберта Чалдини «Психология влияния» и другими не менее знаковыми книгами в моей жизни.

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

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

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

Несмотря на то, что книга была написана десять лет назад в Америке, она как никогда актуальная для современной России и, в частности, Сибири.

Позволю себе привести пару цитат:

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

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

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

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

Купить — Скачать — Читать онлайн

Об авторе

Алан КуперАлан Купер (Alan Kooper)

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

Купера иногда называют отцом «Visual Basic», хотя большая часть работы по «Visual Basic» была сделана группой внутреннего развития компании «Microsoft». Купер был ведущей силой за VB 1.0 и инициатором использования IDE для создания GUI через обращение к системе в API.

Оригинальные программы Купера были названы «Tripod», а позднее «Ruby». Они были предназначены как инструмент конечного пользователя, но развитие в «Microsoft» привело к тому, что «Visual Basic» стал инструментом для программистов.

К выдающимся работам Алана Купера можно отнести «Основы проектирования взаимодействия» и «Психбольница в руках пациентов».

Стандартный