5 составляющих хорошего пользовательского интерфейса

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

1. Насколько быстро можно обучиться работе с интерфейсом? Одно дело, когда смотришь на окошко и сразу же понимаешь, что здесь к чему, и совсем другое – когда нужно почитать мануал. Разница во времени – порядки. Этот параметр особо важен для сайтов. Ещё Стив Круг подметил, что сайты никто не изучает. В самом лучшем случае их просматривают, бегло и по диагонали.
2. Насколько быстро пользователь может решать свои задачи при  помощи интерфейса? Одно дело, когда для выполнения операции нужен один клик, другое – что-то набрать в командной строке. Во втором случае вам необходимо вспомнить название команды, её параметры, да ещё и набрать кучу символов на клавиатуре. Не подумайте, что я противник командной строки, ровно как и не её фанат. Для того чтобы определить, при помощи какого варианта можно решать задачи быстрее, надо взять и посчитать. Посчитать надо нажатия клавиш, количество позиционирований курсора, кликов, двойных кликов, время, которое пользователь будет думать и время, которое будет думать сама система. Модель GOMS вам в помощь. Кстати, время решения задач при помощи интерфейса - единственный параметр, который вам получится посчитать.
3. Насколько система защищена от ошибок. Этот параметр делится на два подпараметра:

• Вероятность возникновения ошибки. Если в программе есть какое-то место, где пользователь может ошибиться, он обязательно ошибётся. Только в одних случаях – с большей вероятностью, в других – с меньшей. Так например, если вы сделаете кнопку два на два пиксела, то вероятность того, что пользователь промахнётся по ней гораздо выше, чем если бы кнопка была бы 20 на 20. Также вероятность того, что пользователь промахнётся мимо кнопки (конечно же нормальных размеров, эдак 50 на 20 пикселов) гораздо ниже, чем вероятность того, что он опечатается, набирая команду в командной строке. Очень хороший способ увеличить вероятность ошибки – это заставить пользователя помнить какие-нибудь вещи. А самый популярный способ перегрузить человеческую память – наплодить режимы. Сколько раз вы забывали переключать раскладку клавиатуры? :)
• Последствия ошибки. Если вы промахнётесь мимо кнопки и попадёте на пустое место, это гораздо менее страшно, чем если вы случайно попадёте по кнопке удаления документа, который вы составляли неделю. Особо досадно будет, когда отменить это удаление будет невозможно. Основной способ, при помощи которого можно улучшить данный параметр – сделать в программе undo/redo. Правда, не для каждой операции такой undo/redo можно сделать. Так например, когда уже отформатирован жесткий диск или взорвался реактор ядерной станции, которой вы управляете, сделать undo уже затруднительно. В этих случаях надо всеми возможными способами уменьшать вероятность возникновения ошибки (см. пункт 3.1).

1. Насколько программа управляема. Программа должна быть управляемой, подконтрольной, полностью слушаться пользователя и делать только очевидные вещи. Кнопки должны нажиматься, галочки включаться и отключаться, программа должна делать минимум неподконтрольных пользователю вещей. В плохо переведённой на русский язык прграммы «Excel 2007» в контекстном меню можно было встретить два пункта под названием «Вставить». Один из них вставлял новую строку, другой – содержимое буфера обмена. Если я печатаю текстовый документ, смотря на клавиатуру (метод слепой печати я так и не освоил), то радостное окошко программы «Download Master», оповещающее о том, что докачался файлик, не должно вероломно отбирать у меня клавиатурный фокус посреди недопечатанного слова. Если я поставил перенести десяток-другой гигабайт файлов с диска на диск и пошёл на обед, я хочу после обеда получить файлы, перенесённые с одного диска на другой. А не сообщение о том, какой-то файлик внезапно оказался с атрибутом «только на чтение», и вопрос, а действительно ли я хочу перенести этот файлик и подождать ещё полчасика?
2. И наконец, эстетическая сторона. Проще говоря, чтоб всё красиво было. Влад Головач в своей книге «Как мыть слона» называет этот параметр сексуальностью интерфейса. Этот параметр я специально сделал самым последним. Он ни в коем случай не должен препятствовать первым четырём, и никогда не должен быть единственным рассматриваемым. Иначе у вас получится красивая позолоченная какашка.

Как видно, из всех параметров количественную оценку можно дать только одному из них. Насчёт остальных можно только говорить в ключе «Если мы расположим элементы вот так, то это повысит скорость обучения». Сказать, что «вот эта вот фишка уменьшит время обучения на полминуты», нельзя. А нельзя потому, что нельзя объективно померить. И это одна из причин, почему обсуждение GUI в большинстве случаев - невероятно холиварное занятие. Вопрос, как снизить остроту таких «священных войн»? Могу посоветовать следующее:

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

Конечно, в этой маленькой статейке невозможно рассказать об интерфейсах всё. Поэтому, читайте книжки, думайте головой, следуйте здравому смыслу и не ссорьтесь :)

Сколько лет уже прошло с тех времён, когда появился первый пользовательский интерфейс, а делать интерфейсы качественно научились очень немногие программисты. Мне доводилось пользоваться банкоматами где-то пяти разных банков, и в каждом из них я видел такие вещи, на которые без слёз и мата невозможно смотреть. Почему после того, как я положил деньги на счёт, банкомат говорит мне «Отмена» вместо «Вернуть карточку»? Почему когда я снимаю 1100 рублей, а в банкомате закончились сторублёвые купюры, он выплёвывает карточку и говорит «Транзакция завершилась неудачей. Код ошибки 508.»? Почему он не объяснил мне причину неудачи на человеческом языке? Почему сбербанковский банкомат при малейшем сбое программы (а сбоит она часто), забирает карточку и заставляет меня на следующий день в рабочее время переться в отделение с паспортом?

Да что там банкомат. Даже самые распространённые программы, которыми пользуются миллионы людей, очень далеки от идеала. Каждый второй учебник по юзабилити пишет о том, что в Windows совсем не используется самое козырное для мыши место – по краю экрана. Для того чтобы спозиционировать мышку на край экрана, надо просто передвинуть мышь до упора. А что сделали в Виндовс? Нечувствительный к мыши бордюрчик ровненько по краю. Правда, в последних версиях ситуацию частично поправили.

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

Ладно, если убогий интерфейс будет причиной того, что я еще полчасика подожду, пока файлы скопируются. А ведь были случай, когда интерфейс, который наваял рукожопый проектировщик, стоил жизни людей. Например, львиная доля падежа самолётов – это незащищённый от ошибок интерфейс рабочего места диспетчера или пилота. То кнопка выключения автопилота окажется рядышком с подставкой для ноги, то система предложит маршрут, лежащий прямиком через ближайшую скалу. Причина этих аварий – плохой интерфейс, а официальная отмазка – человеческий фактор. Да что далеко ходить? Авария на Чернобыльской АЭС – ярчайший пример незащищённости интерфейса от шаловливых и часто ошибающихся ручек оператора, а «Официальная причина», как и обычно в таких случаях - человеческий фактор. Правда, если верить министру атомной энергетики, сейчас пульты управления атомных станций защищены от некорректных действий оператора прям до зубов. Хорошо, если так.

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

На самом деле, книжек по проектированию пользовательского интерфейса написано очень много. Я бы посоветовал начать с книги Влада Головача «Дизайн пользовательского интерфейса»

В этой книге автор вкратце рассказывает о том, что такое хороший интерфейс и даёт кучу рецептов, как сделать так, чтобы вашей программой можно было пользоваться. Книга очень практичная и конкретная, за что я её очень люблю. Она очень распространена в сети, и скачать её можно много откуда. Например, отсюда: http://rutracker.org/forum/viewtopic.php?t=263562 Только не спутайте с другой книжкой автора, которая называется «Дизайн пользовательского интерфейса. Искусство мыть слона». Хотя, та тоже ничего.

Ещё можно почитать книгу Алана Купера «Об интерфейсе»

Признаюсь честно, эту книгу я не читал, но её рекомендуют очень многие, в том числе и Влад Головач. Книжка эта стоит у меня в очереди на прочтение. Как прочитаю – обязательно поделюсь впечатлениями.
Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/4562908/

Ещё есть очень красочная, весёлая и увлекательная книжка Стива Круга «Не заставляйте меня думать».

Книжка посвящена, в основном, веб-сайтам, но несмотря на это, в ней есть очень много мыслей, которые будут полезны и разработчиков desktop-приложений. Основная мысль книги – то, что никто не читает мануалы к программам, а мануала к сайту в принципе быть не может. Открыв сайт, человек моментально должен понять, как с этим работать. Как сделать легко читаемый интерфейс – как раз и рассказывает эта замечательная книга.
Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/3795618/

Ещё можно почитать статейки Джоэла Спольски. Они очень невелики по объёму и находятся вот здесь: http://russian.joelonsoftware.com/uibook/chapters/1.html

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

В этой книге автор объяснит вам, что всё плохо, что в области юзабилити – поле не паханое, а также расскажет, почему так всё происходит.
Предупреждение! В первой половине книги автор долго талдычит одно и потому же. Поэтому первую половину лучше читать по диагонали. Но зато вторая половина намного более содержательна, и читать её можно полностью. Также автор говорит обидные вещи в адрес программистов. Как пишут пишут на lurkmore<ссылка>, если вы начнёте ощущать боль в нижней части спины, следует смириться с фактом, что вы хомо логикус :) И ещё эта книжка не даёт практически никаких конкретных рецептов, разве что разбирает несколько интересных примеров. Но зато хорошо описывает процесс в общих чертах и более-менее вправляет мозги в нужную сторону.

Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/4710758/

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

А ты читаешь Джоэла Спольски?

Если не читаешь – бегом читать! Такие короткие, но очень содержательные и полезные статьи о программировании и всём, что с ним связано без воды и ваты – явление в сети очень редко.
Почитать эти статьи можно
здесь: http://local.joelonsoftware.com/mediawiki/index.php/Russian
еще вот здесь: http://russian.joelonsoftware.com/index.html
и ещё вот здесь, но на английском: http://www.joelonsoftware.com/
и ещё он из своих статей книжки сделал:
http://www.ozon.ru/context/detail/id/2820575/
http://www.ozon.ru/context/detail/id/4878099/

Несмотря на то, что считаю статьи Джоэла великолепными и более чем достойными прочтения, не согласен с ним по некоторым вопросам, а именно:
- Не считаю стремление довести программу до идеала хорошим для программиста качеством. Более того, считаю перфекционизм детской болезнью.
- Не считаю, что рассадить программистов по отдельным кабинетом - самый лучший вариант.
- Не считаю, что писать подробные спецификации нужно всегда и везде.
- Не считаю Excel одной из лучших когда-либо созданных программ.
- Не считаю .Net и Java-программистов недопрограммистами.
- Совсем не обожаю C++. Более того, программируя на C#, разочаровываюсь в плюсах с каждым годом всё больше.
А так, во многом согласен с автором.

Закодировался

Придумал новое значение слову "Закодировался" - очень долго программировал.

Несерьёзные доклады на серьёзные темы

Пересмотрел кучу видео Максима Дорофеева – одного из менеджеров лаборатории Касперского и офигенного докладчика на тему управления проектами и тестирования программ. В работах автора больше привлекает не то, о чём рассказывается, а КАК рассказывает автор. Рассказывает он понятно, интересно, а главное, невероятно позитивно. Предлагаю вашему вниманию особо понравившуюся мне работу – доклад об автоматизации тестирования «Обезъянки против роботов». Когда смотрел – валялся под столом.

TestLabs Part II

View more webinars from Maxim Dorofeev

Test Labs09 Dorofeev M Part III

View more webinars from Maxim Dorofeev

P.S. Когда писал, понял, что манера изложения чем-то напоминает растаманские сказки Дмитрия Гайдука :) 

Если повернуть монитор на 90 градусов

Уже три месяца, как работаю на мониторе, повёрнутом на 90 градусов.

(пропорции обозначенных панелей меняются в зависимости от потребностей и настроения)

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

Для того, чтобы больше строк вмещалось на экран, некоторые программисты сворачивают панельку с аутпутом, списком ошибок, call stack-ом и значениями переменных (watch list). Далее, когда требуется посмотреть на что-либо из вышеперечисленного, щёлкают на свёрнутой панельке и ждут, когда всё это развернётся. В общем, лишние щелчки мыши и ожидания, когда же панелька красиво и плавненько выплывет. Мне не нравится. Кстати, никто не знает, как сделать так, чтобы панельки в Вижуал студии выплывали не плавно и тормозно, а резко и быстро?

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

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

А как вы поворачиваете монитор (мониторы) и как размещаете на нём (них) панельки?

Как вы олаживаете пограмму?

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

1. Аналитический. Мы вспоминаем, как должен работать алгоритм, смотрим на то, что написали и видим несоответствие наших мыслей и написанного кода.

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

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

Так например, среди способов, применяемых мною для отладки, я могу выделить наиболее часто применяемый:
1. Ищем точку, где программа работает. Для этого можно: поставить точку остановки в том месте, где программа ещё не успела сглючить, упростить входные параметры, выкинуть часть кода, заменить часть программы более тупыми алгоритмами или заглушками, откатиться в программе контроля версий до той ревизии, где всё работало и т.д. В общем, определиться с координатой, по которой вы будете осуществлять поиск и найти точку на выбранной оси, где всё работает. Назовём эту точку «A».
2. Аналогичным способом ищем точку, где программа не работает. Назовём эту точку «B».
3. Берём точку где-нибудь посередине. Назовём эту точку «C». Проверяем, работает ли программа в точке C.
4. Если программа в точке C не работает, сужаем диапазон поиска до AC. Если работает – сужаем до CB. Переходим к пункту 3, но с новым, более узким диапазоном поиска. И так до тех пор, пока не мы не найдём ошибку аналитическим путём.

А какие способы поиска ошибок вы знаете и применяете на практике?