Практика

3.12 Дополнительные сценарии

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

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

Это смена тарифного плана и оплата услуг при помощи бонусной системы провайдера.

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

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

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

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

Дополнительные сценарии

Исходя из представленных ограничений, составим дополнительные сценарии:

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

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

Иван предпочитает покупать ежемесячную скидку в 10% для своего тарифа. Система ежемесячно (перед списанием средств со счета) в автоматическом режиме списывает необходимое количество бонусов.

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

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

Люся тратит бонусы на розыгрыши и другие цели. Она не использует их как средство оплаты интернета.

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

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

Адаптивный веб-дизайн

Автор: Этан Мэркотт (ETHAN MARCOTTE)
Иллюстрации: Кевин Корнэлл (KEVIN CORNELL)
Оригинал: http://www.alistapart.com/articles/responsive-web-design/ (25 мая 2010)

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

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

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

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

Но жизнь меняется, возможно, даже быстрее, чем мы бы этого хотели. Ожидается, что мобильный интернет обгонит по популярности выход в интернет с обычного компьютера в течении ближайших трехпяти лет. Две из трех самых популярных игровых приставок уже имеют веб-браузеры (причем один из них весьма не плох). Мы проектируем для мышек и клавиатур, для Т9-клавиатур, для игровых джойстиков и устройств с сенсорными экранами. Проще говоря, мы находимся лицом к лицу с таким множеством устройств, способов ввода данных и браузеров, какого раньше никогда не было.

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

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

Мы можем изолировать мобильные версии сайтов по разным поддоменам, отдельно огородить «сайты не под iPhone». Но что дальше? «Сайт под iPad»? «Сайт под N90»? Можем ли мы на самом деле продолжать брать на себя обязательства по поддержке каждого нового устройства с уникальными параметрами взаимодействия?

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

Гибкая основа

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

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

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

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

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

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

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

Начинаем реагировать

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

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

В своей книге «Интерактивная архитектура» Майкл Фокс (MICHAEL FOX) и Майлс Кемп (MILES KEMP) описывают этот более гибкий способ организации пространства как «многозвенную систему, к которой кто-то подключается для общения; постоянный и конструктивный обмен информацией».

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

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

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

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

Знакомьтесь, это — Media Query

Еще со времен CSS 2.1 наши таблицы стилей имеют некоторое представление об устройствах отображения благодаря media types. Если вы когда-либо писали таблицу стилей для печати, то основная суть вам уже известна:

<link rel="stylesheet" type="text/css" href="core.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

В надежде, что мы будем создавать дизайн страниц для вывода не только на экран или принтер, CSS-спецификация предоставила нам список допустимых media types, каждый их которых соответствует определенному классу устройств.

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

Следует поблагодарить W3C за то, что он включил media queries в состав спецификации CSS3, тем самым улучшив перспективность media types. Media queries позволяют нам ориентироваться не только на определенный класс устройств, но и в режиме реального времени проверять их физические характеристики.

Например, после недавнего роста и улучшения мобильного WebKit, media queries стали популярной клиентской техникой отдачи специализированных таблиц стилей для iPhone, Android-телефонов и ему подобных. Чтобы добиться этого, мы можем добавить media query в атрибут media для соответствующей таблицы стилей:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />

Media query состоит из двух частей:

  1. media type (screen)
  2. и, собственно, сам запрос в скобках, содержащий конкретную media feature (max-device-width) и ее точное значение (480px) для проверки.

Мы как бы спрашиваем устройство о том, меньше или равно его разрешение по горизонтали (max-device-width), чем значение в 480 пикселей.

Если тест пройден успешно (т.е., мы просматриваем верстку на устройстве с маленьким экраном, как, например, у iPhone), то устройство подгрузит себе файл shetland.css. В противном случае ссылка на эти таблицы стилей будет проигнорирована.

Дизайнеры и раньше экспериментировали с макетами, поведение которых зависело от разрешения экрана. В основном эти опыты опирались на такие JavaScript-решения, как великолепный скрипт Кэмерона Адамса (CAMERON ADAMS).

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

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

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />

Кроме того, мы не ограничены в добавлении media queries только в тег link. Мы можем добавить их непосредственно в CSS-код, как часть правила @media:

@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

Или как часть директивы @import:

@import url("shetland.css") screen and (max-device-width: 480px);

В любом случае эффект один и тот же. Если устройство проходит тест, заданный нашим media query, то соответствующий CSS-код применяется к верстке.

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

Адаптация, реакция и преодоление

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

.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
width: 31.121642969984202211%;             /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}

Я специально опустил ряд типографических свойств, чтобы сфокусироваться на блочной модели. Каждый элемент с классом .figure занимает примерно треть от ширины родительского контейнера. К тому же последнее изображение в каждом ряду имеет нулевой правый внешний отступ (li#f-mycroft, li#f-winter).

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

Для начала сделаем поток контента на нашей странице линейным, когда область просмотра по ширине становится меньше заданного порогового значения, скажем, в 600 пикселей. Для этого в конце нашей таблицы стилей добавим следующий блок @media:

@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

Если вы посмотрите на новый вариант страницы с нашим примером в современном браузере, при этом сделав ширину окна менее 600 пикселей, то media query отключит свойство текучести у основных структурных блоков и поставит их в одну линию друг над другом.

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

@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 48.341232227488151658%;          /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

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

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

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

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

@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 13.902053712480252764%;          /* 88px / 633px */
}
}

Теперь наши изображения работают прекрасно во всем спектре разрешений, оптимизируя свои размеры и взаимное расположение в зависимости от ширины окна браузера или разрешения экрана.

Указав большее значение для min-width в новом media query,
мы можем расположить наши изображения в один ряд.

И это только начало.

Используя media queries в нашем CSS-коде, мы можем изменить не только расположение нескольких изображений. Мы можем внедрять новые/альтернативные варианты дизайна, тонко настроенные под различные диапазоны разрешений. Мы можем делать навигацию более заметной на широких экранах, или перемещать ее в позицию над логотипом для устройств с небольшим экраном.

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

Но адаптивный дизайн не ограничивается изменениями в раскладке страницы. Media queries позволяют нам заниматься невероятно тонкой настройкой этих изменений. Мы можем:

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

Технические моменты

Следует отметить, что media queries имеют хорошую поддержку во всех современных браузерах.

Браузеры Safari 3+, Chrome, Firefox 3.5+ и Opera 7+, а также Opera Mobile и мобильный WebKit, имеют встроенные парсеры media queries (в старых версиях этих браузеров такой поддержки нет). И хотя Microsoft взяла на себя обязательства по поддержке media queries в 9 версии Internet Explorer, на данный момент их реализацией этот браузер похвастаться не может*.

*На момент написания статьи Internet Explorer 9 еще не вышел в релиз. В 9-ойверсии браузера от Майкрософт обещанная поддержка была полностью реализована. — Прим. переводчика.

Однако, если вас интересует реализация поддержки возможностей media queries в старых браузерах, то вот вам JavaScript-овые лучики надежды:

  • jQuery-плагин 2007 года выпуска предлагает несколько ограниченную реализацию media queries, в которой используются только свойства min-width и max-width, добавляемые в тег link.
  • Недавно разработанная библиотека css3-mediaqueries.js, которая обещает «научить IE 5+, Firefox 1+ и Safari 2 парсить, тестировать и применять CSS3 Media Queries» путем подключения их через блоки @media. Несмотря на то, что версия библиотеки еще только «1.0», мне она показалась довольно стабильной, и я планирую следить за ее дальнейшей разработкой.

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

Только вперед

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

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

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

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

Об авторе

Этан Мэркотт — веб-дизайнер и разработчик, которого глубоко волнуют красивый дизайн, элегантный код, а также их взаимное пересечение. На протяжении нескольких лет Этан имел удовольствие работать с такими заказчиками, как the Sundance Film Festival, Stanford University, New York Magazine and The Today Show.

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

Его последняя книга называется «Адаптивный веб-дизайн».

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

3.11 Функциональные требования и информационная архитектура

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

Функциональные требования

Разрабатываемая система должна:

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

Превращаем выявленные функциональные требования в информационную архитектуру.

Информационная архитектура

1. Авторизация

  • логотип,
  • форма авторизации,
  • ссылки на главный сайт провайдера.

2. Сервисы

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

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

Стандартный
Матчасть

S.M.A.R.T-подход при постановке целей проектирования

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

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

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

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

3.10 Контекстные сценарии взаимодействия

Ну вот, смотри, Саша Реушкин. Ты все ждал, когда это произойдет. Именно в этот момент мы переходим от исследований и анализа первичных данных к непосредственному проектированию и можем немного пофантазировать.

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

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

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

Контекстные сценарии использования

  1. Иван становится клиентом компании «Сибирские Сети». При заключении договора в офисе компании (или сдаче приемке монтажных работ у Ивана дома) сотрудники провайдера сообщают ему о существовании биллинговой системы и ее преимуществах.
  2. При подключении Иван вносит свой первый платеж на свой счет в биллинговой системе. Если его подключение попадает под действие какой-либо промо-акции, он не вносит деньги на счет и пользуется определенный период времени услугами провайдера бесплатно.
  3. Провайдер выдает Ивану некий ключ доступа к системе. Иван может поделиться этим ключем со своей семьей или друзьями напрямую или опосредованно, разрешая им доступ к системе.
  4. Находясь дома, Иван знакомится с системой, получая от нее контекстную полезную помощь для новичков. В процессе знакомства система осуществляет собственную настройку для работы с Иваном самым удобным и предпочтительным для него образом.
  5. Система предлагает настроить автоматическое списание средств с любого стороннего счета Ивана за услуги провайдера. Иван указывает параметры своей зарплатной карты. Евгений разрешает системе доступ к своему интернет-кошельку в платежных системах Яндекс.Деньги и WebMoney. Люся ничего не указывает, поскольку предпочитает платить наличными.
  6. Проходит определенный период использования услуг и наступает момент, когда баланс счета Ивана начинает приближается к нулю.
  7. Первым делом система пытается самостоятельно сделать платеж, пытаясь списать средства с банковской карты Ивана. Эту операцию она совершает заблаговременно, рассчитывая, что для конца оплаченного периода остается не менее 3 дней.
  8. Списываемая сумма зависит от тарифного плана и равна ежемесячному платежу. Платеж проходит успешно, и система оповещает Ивана о переводе денег.
  9. У Евгения эта операция не завершается успехом, поскольку ни на одном из его электронных кошельков, проверенных системой последовательно, не оказывается достаточной суммы денег для списания. Система оповещает Евгения о невозможности совершить автоматический платеж и ожидает от него дальнейших действий.
  10. Евгений очень занят делами и не успевает вовремя внести деньги на счет в биллинговой системе, в следствии чего интернет у него отключается. Заметив отсутствие связи поздно вечером, Евгений решает совершить обещанный платеж, чтобы внести требуемую сумму на следующий день. Он заходит на страницу биллинговой системы и совершает обещанный платеж.
  11. На следующий день Евгений пополняет свой счет в одном из интернет-кошельков, снова заходит на страницу биллинговой системы и гасит задолженность. Система принимает платеж и сообщает экранным сообщением, что все прошло успешно.
  12. Когда баланс Люси подходит к критической границе, она получает уведомление о том, что скоро интернет может быть отключен. При этом она также сообщает ей, что мультикасса, через которую Люся привыкла вносить деньги, временно не работает.
  13. Люся обращается к системе за информацией о текущем состоянии счета и за помощью в поиске альтернативных путей оплаты. Система предлагает Люсе другую ближайшую мультикассу, которая точно работает. Люся узнает адрес и совершает внесение средств при помощи предложенной точки отплаты. Сразу же после проведения платежа система уведомляет Люсю, что ее он совершен успешно.
  14. Однажды летом Иван решает поехать в отпуск на целый месяц. Он обращается к биллинговой системе и указывает срок своего отсутствия. В указанный период система переходит в режим ожидания и не производит списание средств, а доступ к услугам провайдера блокируется.
  15. Иван возвращается немного раньше, чем планировал. Он вновь обращается к системе и переводит ее в нормальный режим функционирования.

***

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

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

Стандартный
Матчасть

Управление информационным резонансом

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

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

Стандартный
Матчасть

Правило про комок седых волос

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

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

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

Метод очень прост. Хорошие посты на хабре, как правило, имеют минимум комментариев.

Сравните, для примера, хороший пост о проектировании интерфейсов с плохим постом о проектировании интерфейсов.

Стандартный