Иван Бегтин » юзабилити

Дизайн vs. Информационная архитектура

ivbeg — Wed, 11 Mar 2009 16:31:19 +0000

Чтобы понять разницу между дизайном и информационной архитектурой — мало объяснений нужны и примеры.

Недавно у меня перед глазами такой пример образовался — обновился официальный сайт закупок Воронежской области, http://zakaz.gfu.vrn.ru

Точнее вместо старого сайта появился новый.

Причём к новому сайту в плане дизайна у меня серьёзных претензий нет — доводилось видеть как хуже так и лучше. А по сравнению с федеральным — так просто конфетка.

Но не дизайн определяет то как же информация становится доступной пользователям.

Например:

1. На сайте начисто отсутствует RSS как для отслеживания закупок так и просто для новостей — хотя сложного тут ничего нет.

2. В реестрах организаций нет поиска по инн, названию и так далее

3. У организаций нет пермалинков и нет возможности просматривать закупки по определённому заказчику. Зачем это нужно? Да хотя бы для того чтобы департаменты области, ГУПы и МУПы могли указывать на своих сайтах не просто ссылку на сайт закупок области, а ссылку на свою карточку на сайте где можно просмотреть их заказы

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

5. Интерфейс проведения электронных аукционов сделан на Flash Flex. При том что Flex — это, конечно, модно тем не менее 600 килобайтный рантайм это не так мало. Если скрипты для AJAX’а можно прооптимизироать использовав сжатие — то тут сжатия не получится и вообще

6. Нет инструкций по тому какие браузеры можно использовать. Например, автоподгрузка списков в формочки для AJAX в Chrome у меня не заработали и ещё вопрос нужны ли они когда, например, список организаций будет весьма велик — тут не автоподгрузка нужна, а всплывающая поиска.

—

Все эти частные замечания можно разбить на следующие критерии анализа:

1. Целостность данных — отсутствие пермалинков.

2. Качество представления данных — полнота форм поиска и удобсто навигации.

3. Отсутствие описаний технических требований к клиентскому ПО.

Как резюме, несмотря на сравнительно неплохой внешний вид сайта — информационная архитектура у него хромает.

Постер: выбор графика — русскоязычная версия

ivbeg — Sat, 31 Jan 2009 08:21:01 +0000

Как общественно полезное дело сегодня за час перевёл Chart Chooser от Andrew Abela из ExtremePresentation. Это такой постер позволяющий значительно упростить выбор диаграммы при визуализации данных. Вначале я думал что это займёт максимум минут 10, но оказалось что редактирование текстов в редакторах PDF выдавало то ошибки с кодировкой, то неправильное восприятие ими графических элементов — в итоге я просто связался с автором и попросил у него исходник, а ниже результат перевода.

Можно скачать большой JPG файл, а можно русскоязычную PDF версию . А если понравилось или есть замечания можно отписаться мне тут.

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

Постер по юзабилити (плакат по удобству)

ivbeg — Wed, 28 Jan 2009 07:34:45 +0000

Вот такой плакат рассылают членам UPA. А вчера он пришёл и ко мне.

Пустяк, а приятно. Жаль нет русскоязычной версии.

Посмотрел на портал ТрудВсем.Ру

ivbeg — Tue, 20 Jan 2009 04:07:25 +0000

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

1. Инструкций нет
2. RSS нет
3. Индексирования поисковиками нет и не будет.
4. API нет(!)
5. Вогоны существуют!

Являются ли первые 4 пункта следствием 5-го или наоборот он является производными от них — не скажу ибо незнаю.

P.S. Сегодня наконец-то пришла по почте бумажка с подтверждением, а так с ноября 2008 года я вступил в UPA (Usability Professionals Association)

Про Bfm.ru

ivbeg — Tue, 16 Dec 2008 11:10:43 +0000

Я не знаю кто проектировал и создавал Bfm.ru, но определённо в форме подачи информации которая там используется что-то есть.

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

Ещё одна клавиатурная комбинация в вызове вспомогательной панели — «Ctrl + Alt + H» в которой были бы возможности:

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

Вообще говоря это было бы удобно для любых сайтов.

А что касается bfm.ru, то я, пожалуй, использовать его буду.

Дизклеймер: Автор никак не связан с «БФМ.Ру», не слушает одноимённое радио и слушать не планирует.

Смерть и налоги (Death and Taxes)

ivbeg — Tue, 16 Dec 2008 08:05:11 +0000

Death and Taxes — отличная визуализация того на что идут федеральные деньги в США. Конечно, создание такой «штуки» это творческий процесс, его нельзя перенести на любую другую страну неглядя, но как пример формы подачи информации показателен.

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

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

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

Между данными и их представлением. Информационные

ivbeg — Sun, 30 Nov 2008 12:18:00 +0000

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

Далее несколько заметок тезисами.

Общие определения

1. Между данными и их представлением всегда есть промежуточный слой. Его можно назвать “информационный договор” (information contract). Этот слой определяет, то как именно изначальные, первичные данные предстают перед конечными потребителями информации.

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

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

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

5. Информационная модель, в рамках которой присутствует информационный договор или их множество, называется “модель информационного договора” (information contract model).

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

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

8. Например, в ситуации выбора форм представления рекламы организацией, к которой имеются некий логотип,слоган. В этом случае публикация рекламы в прессе, на стендах или по телевидению – всё это формы представления, в рамках одного информационного договора в котором участвуют первичные данные (логотип, слоган) и формы их представления.

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

Формы представления информация

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

2. В материальном мире форма может быть также и объектом. Например, форма приданная стеклу в виде стакана станет объектом – стакан, но и останется одной из форм представления стекла, наряду с окнами или линзами.

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

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

5. Фотография отпечатка ноги на песке – будет формой формы и, также, материальным объектом.

Потребители информации

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

2. Если в списке 100 записей, обе формы представления будут приемлемы. Если в списке 100 миллионов записей, просмотр данных как списка будет бесполезен.

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

4. Потребители информации (information consumers) – являются теми, пользователями и информационными системами которые должны или желают получать необходимые им данные.

5. Потребность в информации выражается в сценариях, которыми потребители информации привыкли с ней работать. Эти сценарии информационного потребления (information consumption scenarions) определяют требования к формам информационного представления.

6. Под сценарии информационного потребления будут подпадать все сценарии связанные с представлением и изменением информации. Как альтернатива существующие модели пользовательского взаимодействия дополняются схемами информационного потреблениями (information consumption schemes) определяющими решение информационных потребностей.

Шаблоны и правила

1. Несмотря на условную бесконечность информации, число форм её представления конечно. 2. Конечность форм определяется конечностью сценариев информационного потребления, что, в свою очередь, ограничено числом органов чувств, каналов передачи информации (визуализация, речь, запахи и так далее), пропускной способностью данных каналов, физическими ограничениями каждого человека по объёмам потребляемой информации в единицу времени, социальным и культурным мироустройством и неравномерным распределением информационных потоков.

3. Шаблоны, или правила, представления информации проистекают непосредственно из конечности форм. Можно на тысячи языков произнести слова “Добрый день”, но шаблон будет один: звук -> язык -> слово в трансляции на выбранный язык.

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

Вопросы

1. Структуры данных можно формировать от ожиданий потребителей информации и ожидаемых ими форм её представления.

2. Формы представления можно формировать от данных, когда ещё неизвестны сценарии потребления информации.

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

4. Вопросы к данным:

- Можно ли оценить имеющиеся объёмы данных? Если да то каковы оценки?

- Являются ли эти данные статическими или же они могут менятся?

- Если данные могут менятся, то каковы правила их изменения? Могут ли они удалятся? Только ли они добавляются?

- Какова частота этих изменений и какой их объём? Можно ли разделить эти изменения по типам и оценить их частоту ?

- Предусматривает ли модель данных учёт их изменения?

- Может ли структура данных менятся?

- Какова форма модели данных? Простая – список, дерево атрибутов или же сложная совокупность различных взаимосвязанных объектов.

- Являются ли отдельные элементы структуры модели элементарными или базовыми?

- Обладают ли отдельные элементы структуры модели множественностью возможных форм представления?

- Обладают ли отдельные элементы структуры модели неявными связями внутри модели?

5. Вопросы к формам представления:

- Является ли форма конечной – представляемой потребителю или промежуточной, частью обобщающей формы?

- Является ли форма простой или сложной, включающей другие формы?

- Является ли форма связанной с информационным объектом данных 1 к 1 или же построена на множестве объектов?

- При связи формы 1 к 1 является ли форма полной, а то есть содержащей все элементы информационного объекта?

- Является ли форма представления машиночитаемой восстановимой формой, по которой можно полностью реконструировать информационный объект?

Веб, списки и уникальность страниц

ivbeg — Wed, 22 Oct 2008 03:25:20 +0000

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

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

Рассмотрим несколько примеров.

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

Для того чтобы далее было проще описать ситуацию я введу термин LISA (Last In. Shift All) -построение списка элементов при котором любой новый элемент становится первым сдвигает номера остальных.

Предположим, у нас уже есть 100 опубликованных новостей, 10 страниц по 10 новостей на одной странице. Что произойдёт после того как мы добавим ещё одну новость? Появится 11 страница и полностью изменится содержимое всех остальных 10 поскольку добавленная новость сдвинет все предыдущие на одну позицию в отсортированном списке.

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

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

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

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

Возьмём другой пример — каталог организаций рассортированных в алфавитном порядке по имени. Организаций обычно бывает много, пусть у нас их будет порядка 2000 по 25 на странице, всего 80 страниц. Что происходит когда добавляется новая организация — технически, в базу попадает просто новая запись, но форма представления меняется таким образом что новая запись сдвигает все последующие за ней ровно на единицу и число сдвинутых записей зависит от имени новой. Такие формы списков можно назвать LISP (Last in. Shift part). Тем самым получая новый элемент списка мы можем предсказать каким будет сдвиг списка в целом, но мы не можем предсказать какой же элемент мы получим и как придётся сдвигать, не зная содержимого элемента. Понятно также что это распространяется не только для списков с алфавитной сортировкой по именам, а ко всем постраничным спискам с сортировкой отличающейся от сортировки по последнему идентификатору или по последней дате. В этом случае поисковые машины при повторном индексировании будут обходить уже не все страницы, а только затронутые сдвигом. На уникальность ссылки для пользователей влияние также будет зависеть от того как именно элемент сдвигает все остальные.

Надо отдать должное что в случае LISP списков, некоторые ресурсы предпринимают дополнительные усилия по по организации работы с ними. Например, список печатных СМИ на сайте Федерального агенства по печати и массовым коммуникациям отличается двойной сортировкой. На первом уровне записи рассортированы по первым буквам названий и лишь на втором они разбиты постранично в рамках выбранной буквы. Если, к примеру, добавлять новое СМИ, то изменится не более чем страниц под определённую букву, это от 1 до 10 страниц, но не никак не несколько сотен.

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

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

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

Заметка в Юзабилити бюллетене

ivbeg — Wed, 10 Sep 2008 06:26:13 +0000

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

e-Gov. Типовые технические проблемы

ivbeg — Thu, 31 Jul 2008 11:38:47 +0000

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

Вот текущий список:

1. Справочники и классификаторы

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

Где найти последнюю редакцию ОКОГУ, ОКВЭД, ОКЕИ, ОКАТО или одного из множества других общероссийских справочников? А также как обеспечить автоматическое их обновление при изменении законодательства.

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

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

А вот получить справочники с сайта Федерального агенства по техническому регулированию и метрологии, www.gost.ru — это задачка для крепких нервами и подготовленных к неудачам. Мои попытки приводили лишь к тому что ссылки на документы (PDF) там есть, но при их открытии выдаются ошибки. Да и там в структурированном виде их нет в любом случае. Альтернативный вариант — отслеживание публикаций изменений в Консультанте и вручное их внесение собственные справочники.

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

2. ЭЦП и корневой удостоверяющий центр

У ЭЦП есть две ощутимые проблемы.

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

Проблема вторая — это поддержка работы по сертифкатам лишь ограниченным числом приложений. Например, мне до сих пор не удалось найти ни одной государственной системы/cайта позволяющей авторизацию и подпись документов с помощью ЭЦП и работающей на Linux или хотя бы на Firefox в Windows. Это же одно из существенных ограничений по внедрению СПО на рабочих местах в органах гос. власти.

3. Законы и те кто их пишет

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

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

Похожая ситуация с раскрытием информации о стандартах. Отсутствие требований к _форме публикации информации_ приводит к тому что документы на protect.gost.ru размещаются со следующими «нюансами»:

Документы недоступны поисковым системам на индексирование путём запретов в robots.txt;
Документы публикуются в виде постраничных(!) сканов;
На каждой отсканированной странице сознательно стоит водяной знак затрудняющий автоматическое распознавание;
Сохранение страниц сознательно затруднено — можно обратить внимание что они показываются через background-image в CSS.

Вопросы о том почему нельзя получить документы в виде текстов, справочники в формате CSV или XML — можно считать риторическими. Законы соблюдаются? Соблюдаются. Информация есть в онлайне? Есть.

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

Ссылки на другие мои публикации по теме юзабилити и сайтов госорганов: