История о гибкости интерфейсов Часть 2

Продолжаю рассуждать вслух...

Что же делать создателям интерфейсов, когда количество кнопочек, галочек, виджетов и прочего переходит границы разумного и создают комбинаторный взрыв вариатов показа? Из того, что сейчас в сети есть - не так уж много вариантов работает:
 - решить что создатели лучше знают какие и где кнопки пользователям нужны - все остальное скрыть
 - сделать набор из нескольких вариантов, и где-то спрятать выбор предпочитаемого, пример - gmail, есть несколько вариантов типа старый,новый,мобильный и выбор между ними
 - сделать один/два варианта и сделать конструктор интерфейса - blogspot, с его конструктором блога

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

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

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

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

Взглянем на google-analytics - сколько пользователей, которые смотрят в нем статистику своего сайта и не читают их блог, знают о том что посещаемость можно измерять 12 разными способами, не считая фильтрации траффика?

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

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

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

История о гибкости интерфейсов

некоторые мысли вслух по поводу интерфейсов...

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

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

Рассмотрим на почти-выдуманном примере: вот смотрю на меню над полем редактирования - много кнопочек, менюшек, всплывающих окон настройки и тому подобного. Несложно представить себе пользователей - "Хочу менять цвет", "Хочу менять шрифт", "А мне списки нужны", "А я..." и так далее. Кто-то посмотрел на все эти пожелания и сделал большую панель скопировавшую функционал текстовых редакторов. Часть пользователей обрадовалась - "О, как в ворде", часть осталась недовольна - "я просил только цвет, зачем мне это все", еще часть возмутилась - "за идиотов держите? мы сами html написать можем."...  Одну проблему поменяли на другую. Следующий вопрос - оно того стоило? Простое исследование аудитории, статистики пользования и прочее показало - стоило, но оставшихся недовольных тоже надо как-то порадовать.


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

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

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

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

Заканчивая пример с панелью - через некоторое время оказалось, что слово Font можно вполне заменить на один символ F, а кнопку "выравнивание" придется вернуть - оказывается, ее снесли зря.

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