Часть 2: Google Chrome для разработчиков

Начало: “Часть 1: Google Chrome”

Есть несколько сюрпризов, которые преподнесла Google разработчикам. Ничего нового не сделали, но, в принципе минимальный набор функций предложили. Первые две касаются и разработчиков и пользователей.
Во-первых, поле ввода теперь подсвечивается, если находится в фокусе. Есть небольшой косяк с выпадающим списком – он подсвечивается только после выбора элемента из списка и только, если фокус остался на этом элементе. При выборе же подсветка просто мигает один раз вокруг элемента. Checkbox не выделяются. Цвет подсветки, похоже, не меняется и сливается с фоном цвета #eaaf3f. Не критично, я думаю, страшненький всё-таки цвет в больших объёмах.

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

Вторая, позаимствованная функция (из движка WebKit – «сердца» Safari и прямого потомка KHTML), – это возможность изменять размер многострочного текстового поля. Размер можно задать любой. Разумеется, изменение размеров поля сразу же сказывается на разметке страницы. Поэтому такие игры на страницах с поломанной или насыщенной разметкой приведут к заметным искажениям. Страничка нормально расширяется вниз, но вправо приводит к искажениям. Почему то показалось, что лучше бы расширение поля сделали независимым от разметки, так чтобы расширяемое поле просто закрывало существующие элементы, а-ля поле в отдельном слое.

Кстати сделать поле меньше чем исходный размер не получится.
По-умолчанию в Chrome встроен HMTL Inspector, напоминающий Firebug. В версии 0.2 инспектор не предоставляет никаких возможностей для изменения текста страницы, только просмотр. Скорее всего это ограничения беты.


Click!

Так же как и в Firebug инспектор в Chrome можно вызвать для конкретного элемента. Инспектор откроется в отдельном окне, поделённым на две части. При открытой консоли на три. Слева будет DOM дерево, справа все данные по выбранному элементу. Минус в том, что стили будут собраны в одну кучу, и, в случае, когда используется несколько CSS файлов будет не ясно, откуда какой стиль взят.

Теоретически имеется возможность привязать окно HTML инспектора к главному (хотя по хинту не понятно, что имеется ввиду под главным окном), но у меня так и не получилось это сделать. HTML инспектор ни в какую не хотел прилеплять себя ни к одному из окон Chrome. Еще одной загадкой осталась закладка “Resources”, я не смог найти ни одного сайта, для которого её содержимое было бы не пустым. Кажется, это еще одна функция на будущее, вероятно, будут показаны объекты, изображения и другие файлы, динамически подгружаемые или запускаемые на странице. Интересно что будет показано в случае всяких Flash плееров (Конечный файл то находится за ними и напрямую не доступен в общем случае).


Click!

Кстати, “Search” тоже не работает и не очень понятно к чему он относится – к поиску по элементам в DOM или к поиску по атрибутам выбранного элемента. Будет приятно, если он будет контекстный, и в зависимости от фокуса, будет искать в разных частях инспектора.

Есть несколько приятных особенностей панели атрибутов элемента:

  • Реализована неплохая идея по визуализации цветов. Рядом с цветом появляется квадратик, показывающий цвет.
  • По выделенному элементу возможен поиск в выбранном поисковике, НО(!) страница поиска открывается прямо в окне инспектора, и при этом назад вернуться невозможно (в контекстном меню таких функций нет, а в системном меню окна она неактивны), только открыв и закрыв окно инспектора.

    Click!
  • перегруженные стили зачеркиваются
  • можно посмотреть дополнительные свойства элемента, фактически вообще все параметры, которые как-либо привязаны к элементу в DOM модели, но и тут еще есть над чем работать.
    Click!

Поработав с Chrome уже три дня, я всё больше утверждаюсь во мнении, что множество положительных отзывов связаны не столько с браузером сколько с Google. Если бы этот же браузер вышел под именем небольшой компании, никто бы и внимания не обратил. Пока Chrome сыроват, не столько шустр как обещалось (что естественно, быстрый JS движек всё-таки взаимодействует с медленным WebKit’ом), по функциональности ничего особенного. С другой стороны это только начало и видно, что оставлено множество выходов на дополнительные функции – плагины, поиск, инструменты для разработчиков, специальные фишки для пользователей и интересная система безопасности, но это уже отдельная история.

Начало “Часть 1: Google Chrome”

Bits Du Jour Returns

Роджером Томассон (Roger Thomasson) предложил в очередной раз поучаствовать в Daily Deals на Bits Du Jour, но уже с другим продуктом Perfect Clock. Она уже была опубликована там этой весной. Судя по всему, на данный момент, она была наиболее продаваемой, потому как Роджер предложил внести её в план на осень. Обычно публикации там приходится ждать до пяти месяцев.

Часть 1: Google Chrome

Часть 2: Google Chrome для разработчиков

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

Все эти события прошли мимо меня, пока я был в отпуске. Ну и ладушки.

Поскольку появление нового инструмента в руках пользователей всегда влечет определенные проблемы для тестирования, браузер пришлось отыскать и установить. Сейчас он (официальный сайт Google Chrome) занимает третью позицию в Google (PR 0), вторую в Yahoo, третью MSN, видимо дальние позиции в Live Search и Yandex, первую в Majestic 12, а Alexa почему то найти не удалось. Хорошие показатели, на мой взгляд после восьми дней жизни.

Инсталятор, скачиваемый на компьютер, меньше полумегабайта. Правда, при установки он скачивает из Сети порядка 20 Мегабайт данных. Устанавливается не в привычные “Program Files”, а в “Documents and Settings”. Прямо скажем очень странное решение. Занимает после установки около пятидесяти мегабайт, при этом сам инсталлятор не удаляется и лежит в папке “[Version]\Installer”. Вероятно, установка следующих версий будет приводить к накоплению данных.

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

Первым не очень понятным фактом стало то, что запущенный Chrome загружает процессор от 2 до 7% постоянно. Такого поведения не наблюдается у Internet Explorer, Firefox и Opera. Простая загрузка браузера с пустой страницей не приводит к постоянной нагрузке на процессор. Что же делает при этом Chrome? При беглом осмотре понятно не стало – к файлам обращается в меру, при этом в своей директории, реестр использует не больше остальных, в Сеть тоже постоянно не ломится. Исходный код скачивать поленился, возможно, позже всё же пересилю себя.

Интерфейс и функциональность.

Стандартный интерфейс, как и у других браузеров, только сильно урезанный или без лишних элементов, смотря с какой точки зрения подходить. Если браузер воспринимать именно как инструмент для простого просмотра страниц, то очень хорошо. У меня же вызвало смешанные чувства. Такого же эффекта можно добиться в Firefox, IE и Opera нажав F11, разница лишь в том, что при этом браузеры основной тройки разворачиваются на весь экран.


Click!

Куда интереснее поведение адресной строки при вводе ссылки.

Click!

Во-первых шрифт и поле ввода больше, чем у других браузеров. Во вторых цветами отделается домен, символы разметки, пути до страницы на сайте и имена файлов. Немного необычно, но приятно. При вводе адреса Chrome показывается в выпадающем списке возможные результаты, основанные на уже существующей истории пользователя и наиболее близких имен доменов в базе Google. Так же предлагается поискать введенную фразу в выбранном поисковике (по умолчанию Google) и посмотреть всю историю по страницам, попадающую под введенное в адресную строку. Пожалуй, этим можно было удивить в прошлом году, пока не вышел браузер Firefox 3.0. Но всё-таки хорошо, что такая возможность есть уже в первых версиях, потому как ни IE, ни Opera этого пока не сделали (поиск идет по локальной истории).В новом пустом табе (по Ctrl + T например) по умолчанию отображаются наиболее часто посещаемые сайты, а так же список недавних закладок.

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

Совсем другой разговор, если обратить внимание на табы. Все стандартные действия поддерживаются (переключение по Ctrl + цифра, Shift, Ctrl, Shift & Ctrl + Click), табы можно менять местами, а так же вообще вытаскивать их в отдельное окно и вкладывать отдельные окна друг в друга. Анимация табулек при перетаскивании и вложении сделана приятно.

При этом, как обещает Google, зависание одного таба не скажется на остальных. Подвесить Chrome удалось легко. Было достаточно загрузить небольшой PDF документ. Пока он полностью не загрузился окно Chrome зависло и переключится на другие табы и отдельные окна не получалось. Другие приложения работали нормально. Так получается из-за того, что на самом то деле табы не являются самостоятельными процессами и запускаются от процесса ядра (это видно через Process Explorer). В результате, когда повисает главный процесс – повисает и всё остальное. Но с другой стороны, если правильно угадать, то можно убить дочерний процесс, подвесивший всё приложение, тогда действительно на других табах это не скажется. У Internet Explorer таже история, если открывать страницы не в табах, а в отдельных окнах.

Другая возможность – создание ярлыков. Любая страничка может быть помещена на рабочий стол, в меню «Пуск» или на панель быстрого запуска. В отличии от простого drug-and-drop для других браузеров, в Chrome существует дополнительный пункт меню который позволяет создать сразу все ярлыки. При этом иконка берется из favicon.ico сайта.


Click!

Запускаются такие ярлыки в отдельном окне Chrome, вообще без навигации. Впрочем, с помощью меню в заголовке окна можно переключиться в нормальный режим. Чем то напоминает Active Desktop, только окна нормальные, а не «утопленные» на заднем плане.Любопытно сделан контекстный поиск по странице. По «Ctrl + F» панелька для ввода появляется чуть ниже строки адреса. При вводе текста показывается количество соответствий и текущее положение.

История посещений и загрузок показываются в отдельном окне в виде веб страниц, с возможностью поиска. Лично мне понравилось, потому как довольно удобно использовать. К сожалению, интерактивного поиска нет (как в Firefox в истории посещений). Функция удобная, когда нет уверенности в точном названии страницы.Интересно еще и то, что иногда количество процессов было больше чем процесс ядра + количество открытых табов и окон Chrome.Я заметил еще одну приятную особенность. При открытии новых окон, они появляются не как обычно правее и ниже родительского, а чуть ниже верхней грани, по середине заголовка.

Click!

Ребята из Google добавили любопытную функцию в браузер – диспетчер задач. Вызвать диспетчер можно из контекстного меню заголовка браузера.

Производительность и стандарты.

Чисто субъективно я не заметил никакой разницы между браузерами в плане скорости загрузки страниц. Страницы с видео роликами, так или иначе, подтормаживаются при загрузке. Не было чудес и при загрузке «Google Analytics» – так же заметны подтормаживания при смене периода.Очень хорошо почувствовал разницу в скорости обработки страницы при изменении размеров текста с помощью «Ctrl + Колёсико Мышки» и Ctrl + «+/- ». Chrome работает очень быстро, практически без задержек. Но, в Chrome возможность увеличения и уменьшения текста ограничена, в отличие от Firefox. Вместе с тем, на мой взгляд, увеличение лучше работает в Internet Explorer и Opera – не портит разметку, и при этом позволяет увеличить страницу, так что на картинках будут видны пикселы.

При старте Chrome в пике съедал 40% процессора (у меня стоит AMD Athlon 3500+ 64 bit с 1 GB Dual памяти и водруженной поверх XP 32 bit с SP3). Для сравнения Firefox потреблял 35%, Internet Explorer -60%, Opera – 50%. Как уже говорилось, дальше в режиме простоя Chrome потреблял от 2 до 7% процессора. Но у Chrome наблюдается сильное преимущество по переключению контекста между потоками, хотя это не очень точно.

Тут мне стало интересно, как поведет себя Chrome при открытии нескольких табов и окон. Методику я выбрал самую простую:

– Для каждого браузера (Chrome, Firefox 2, Internet Explorer 7, Opera 9.5) открывается 10 пустых табов (то есть свежие инсталляции, без истории закладок и плагинов).
– Открывается 10 табов с одним и тем же ресурсом (я выбрал главную страницу Youtube)
– Открывается 10 отдельных окон с Youtube (окна с пустыми страницами я опустил, ничего особенного предварительные тесты не показали).
– Каждый тест повторяется 10 раз и берутся усредненные значения, если не окажется, что есть очевидные пики.Условия проведения замеров одинаковые для всех браузеров (Windows XP SP3, 32bit, Athlong 3500+, 1GB Dual RAM).В результате я получил 6 табличек cо значениями для физической и виртуальной памяти.
Потребление физической памяти на пустой выглядело так, при открытии табов:

Физическая память (MB)

Вкладки 1 2 3 4 5 6 7 8 9 10
Chrome 29* 33 33 35 36 38 38 39 40 42
Firefox 35 36 36 36 36 37 37 37 37 37
Internet Explorer 23 27 28 30 30 31 32 33 34 35
Opera 21 21 22 22 22 22 23 23 23 23

Виртуальная память (MB)

Вкладки 1 2 3 4 5 6 7 8 9 10
Chrome 21** 23 25 27 29 32 33 33 33 39
Firefox 26 26 27 27 27 27 27 27 27 28
Internet Explorer 17 20 21 22 22 23 24 25 26 26
Opera 18 18 18 19 19 19 19 20 20 20

А вот так память потреблялась при загрузке главной страницы Youtube, опять-таки 10 табов в одном окне:

Физическая память (MB)

Вкладки 1 2 3 4 5 6 7 8 9 10
Chrome 40 80 101 122 149 157 165 187 207 252
Firefox 44 49 54 59 67 70 72 78 81 91
Internet Explorer 39 51 60 71 78 88 99 108 115 127
Opera 35 39 47 53 58 63 70 77 84 89

Виртуальная память (MB)

Вкладки 1 2 3 4 5 6 7 8 9 10
Chrome 32 61 76 89 107 117 123 139 154 193
Firefox 35 39 44 50 59 61 63 68 72 82
Internet Explorer 31 42 51 62 70 81 91 99 108 118
Opera 32 37 44 51 56 61 68 75 82 87

Распределение памяти при открытии десяти табов с Youtube оказалось следующим:

  • Chrome – нерегулярно до 30% CPU, по разным процессам.
  • Firefox – постоянное использование около 20% с пиками до 50%.
  • Internet Explorer – от 20% до 50%
  • Opera – использование CPU колебалось в районе 30%

Интересно так же то, что распределение памяти между процессами было неоднородным и отличалось в пределах до 5 мегабайт для табов, плюс два процесса по 50 мегабайт (плюс минус 3). В отличие от Firefox и Internet Explorer, память не росла безостановочно.
Распределение памяти в случае 10 разных окон.

Физическая память (MB)

Окна 1 2 3 4 5 6 7 8 9 10
Chrome 41 80 101 125 138 145 167 179 204 224
Firefox 44 51 59 66 78 83 92 102 107 114
Internet Explorer 39 83 123 165 204 246 288 330 373 414
Opera 34 42 49 54 61 69 77 83 91 95

Виртуальная память (MB)

Окна 1 2 3 4 5 6 7 8 9 10
Chrome 33 62 78 94 102 110 125 131 150 165
Firefox 34 42 49 56 68 73 83 92 98 104
Internet Explorer 32 37 100 132 166 200 234 267 300 332
Opera 31 40 46 53 59 67 75 81 90 93

В общем и целом Chrome показал себя довольно прожорливым браузером по памяти (но в случае с окнами – намного лучше, чем Internet Explorer), но наиболее нетребовательным к процессору. При теперешнем росте объемов памяти, в принципе, не существенно. Браузер действительно должен работать быстрее, чем остальные. Пока память не закончится, конечно.

Но всё-таки, реально отдельные процессы создает только Internet Explorer, в Chrome (повторюсь), так или иначе всё завязано на главный процесс ядра.

По стандартам всё очень даже неплохо:

    Acid3

  • Chrome – 79
  • Opera 9.5 – 84
  • Firefox 2 – 52
  • Firefox 3 – 71
  • Internet Explorer 7.0 – я не понял сколько, картинка была сбита полностью

Acid2
Chrome, Firefox 3, Opera 9.5 – прошли.

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

Закончу эту часть рассказа такой вот картинкой :)

Часть 2: Google Chrome для разработчиков

РИТ 2008 постфактум

На прошлой неделе в Москве прошла конференция РИТ 2008. Ничего сверхъестественного не проходило, но о некоторых моментах хочется рассказать.

Конференця проходила в экспо-центре “Крокус-экспо” на 66 километре МКАД. Для меня это уже было интересно, потому как в Питере за КАД уже лес и малые города. В Москве же это оказалось густо застроенным районом. Сам центр очень порадовал размерами и планировкой. Для РИТ было выделено примерно 1/8 всего пространства первого комплекса, но при этом совсем не ощущалось, что приехало полторы тысячи человек. Проблемы с кислородом были только в закрытых конференц-залах, особенно во втором. Хотя это деление условно, поскольку от первого конференц-зала он был отделен подвижной растяжкой.


Основная площадь конференции

Добираться до РИТ предлагалось несколькими способами, в том числе на специальных автобусах. Вот тут то и произошла первая неприятность. Оказавшись у метро “Тушинская” в 9 утра никаких автобусов найти не удалось. Хотя обещали, что автобусы будут ходить с 8:30. После нескольких звонков Павлу Рогожину удалось получить ценные указания “50 метров от Макдональдса в сторону области”. Больше Павлу я не звонил. Те самые пятьдесят метров в сторону области установил опытным путем в течении минут 20 прогулок в разные стороны. Прохожие советом помочь не могли и лишь мило улыбались на вопрос “Где тут у вас область”. На второй день, впрочем, тоже была оказия с автобусами, их банально не хватало. Но тут ничего не попишешь, организовать сбор огромного числа людей очень не просто и можно промахнуться. Посмотрим, что будет в следующем году.

Очень порадовала регистрация. Отдельные очереди по первым буквам фамилий. Хотя тут организаторы попались на логике. Очереди людей с фамилиями на А-Б, С-Т оказались очень большими. Но девушки очень быстро работали и стоять пришлось не долго. Вещмешок с рекламой Microsoft внутри себя содержал стандартный набор блокнотиков, ручек и рекламок. У меня в него удачно поместился ноутбук (надо отметить, что на конференцию я приехал прямо с поезда и ноут был в рюкзаке, вперемешку с другими вещами – совсем не хотелось постоянно вытряхивать содержимое рюкзака, чтобы его убрать. Ну а в руках таскать – неудобно).

Стив Балмер на РИТ не приехал. Хотя по объявлениям на сайте РИТ 2008 должен был. Странным образом новость об этом вообще куда то пропала. Вместо туловища собравшимся показали видео обращение (опять-таки не живое), которое одинаково могло быть адресовано, что интернетчикам, что сборщикам сахарного тростника.

Асхат Уразбаев, Обзор методологии Scrum

Первый день особо не запомнился, отчасти из-за ночи в вагоне, отчасти из-за качества докладов. Из первого дня я запомнил только рассказ Алексея Лагутина о технологиях поиска и индексации изображений. Хотя он больше говорил о том, что много проблем с этим. Он показал несколько формул и общее представление о том каким образом колеса от машин и мордашки девушек индексируются я получил. Сергей Гринкевич очень неплохо рассказал об управлении качеством, очень неплохой и толковый доклад, который поможет лучше понимать данную тему любому начинающему тестировщику. Было очень интересно послушать Асхата Уразбаева. По некоторым причинам Scrum не прижился, проще говоря идеология была полностью дискредитирована некомпетентностью человека который пытался ввести эту практику в разработки. А вот речь Асхата изменила мою точку зрения о Scrum и на второй день я посетил почти все доклады по этому направлению. Но просветления окончательно не достиг.

Алекс Могилевский

А вот второй день задался хорошо. Начало положил Александр Москалюк с рассказом об инфраструктуре Фейсбука. Просто, четко, с упором на интересные решения и находки. Чувствовалось, что человек рассказывает не только что-то делает в Facebook, а понимает зачем и какое будет развитие в будущем. Я большую часть технологий, о которых он говорил не знал, но после этого короткого доклада получил достаточно начальной информации о том для чего и какая технология может быть применена. Родилось несколько идей как улучшить сетевую инфраструктуру у себя, потому как нагрузка намного ниже (при похожем трафике), а вот ресурсов тратится больше, да и работает медленнее. Очень было интересно слушать Алекса Могилевского (он на фотографии выше), рассказывающего о Internet Explorer 8. Да, были косяки, не всегда IE отрабатывал так как надо и кажется, даже, подвисал. Но КАК он говорил! Его слушали, временами зал взрывался от хохота. Алекс очень легко уходил от каверзных вопросов, а временами просто честно говорил о политических причинах того или иного решения. Проводя параллели с “западными” специалистами с которыми я общаюсь создается впечатление, что причиной столь удачных докладов является именно западная культура и стиль работы. Фактически не получается человеку достичь какого то высокого уровня, если он не умеет говорить и доступно рассказать, что он делает и почему это хорошо.

Игорь Ашманов

В общем и целом, по моему ощущению “наши” проигрывали докладчикам с “запада” (в ковычках потому как все русскоговорящие) . Пока ни появился Игорь Ашманов и ни стал рассказывать о кризисах роста. Да, да, многие из присутствующих всё, что он говорил и так видят и знают, но проблема в том, что все бусинки проблем мало кто может увязать в одну цепочку и понять, как надо уходить от или выходить из кризиса. Ашманов не говорил делайте вот так и всё, он приводил примеры и рассказывал, что можно сделать так чтобы не только кризис роста закончился (кстати, тут стоит прочитать самого Ашманова “Жизнь внутри пузыря“). Слушать было очень интересно, потому что твои собственные разрозненные наблюдения постепенно складываются в одну картину. Это еще не разрешение кризиса, но уже шаг к тому, чтобы из него выйти… если, конечно, не остановиться на полдороги.

После доклада толпа вопрошающих еще минут 20 терзала Ашманова, но послушать, что спрашивали и что он отвечал не получилось. Подходы были забиты.

Параллельно с докладами Microsoft тихонько наливал кофе разработчикам, раздавал значки и подставочки с логотипом MSDN… и полнофункциональную лицензионную версию Microsoft Expression Studio. Лично для меня в этом комплекте была единственная интересная вещь – это Expression Blend. Пока еще трудно позиционировать этот инструмент для проектирования интерфейсов (на P4 2800 программа очень сильно тормозит, нормально идет на Core 2 Duo) – мало элементов интерфейса в стандартной поставке и заточен под C#. Через какое то время он может стать очень серьезным инструментом для повышения скорости разработки и соответствию прототипам дизайнеров. Но, пока, просто любопытно.

Второй день, окончание, вид из глаз =)

История развития интерфейса Microsoft Office

На сайте MIX: The Next Web Now появился видео ролик (презентация) рассказывающий о истории эволюции интерфейса Microsoft Office, а так же о том, как создавался интерфейс для Office 2007. Рассказывает обо всем Дженсен Харрис – один из дизайнеров пакета Office 2007.

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

Посмотреть ролик можно на сайте MIX: The Story of the Ribbon там же можно и скачать его в разных форматах (WMV, iPod). В любом случае потребуется установить SilverLight. Можно так же скачать его и из блога Харриса, но на сам сайт MIX лучше зайти, там есть еще много интересных видео.

Тестирование шаблонов web-страниц

В блоге QA Focus, поддерживаемой организацией UKOLN, опубликован документ “Layout Testing with Greeked Pages”. В нём описываются основные принципы тестирования дизайна web страниц в условиях, когда еще неизвестен ни контент, ни конкретное количество элементов навигации, управления, но нужно протестировать сам дизайн. Сам принцип использования «греческого» текста для юзабилити тестирования был изложен еще в 1998 году Якобом Нильсеном (Jakob Nielsen). Сам по себе способ очень прост и состоит из трёх этапов. Перед которыми следует разработка самого прототипа и определение количества и вида элементов, которые должны присутствовать на странице.

1. Наполнение контентом готового дизайна. Для этого не обязательно делать верстку страницы, достаточно графического прототипа. Для наполнения контентом, в том числе определения заголовков элементов навигации, используется кусок текста из трактата Цицерона «О пределах добра и зла»:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

Хотя, как пишет Артемий Лебедев, этот текст очень сильно отличается от оригинала текста, и стоит быть осторожным при использовании онлайн генераторов “Lorem Ipsum”, поскольку неизвестно кем и почему изменялся этот текст и что действительно означают эти изменения и почему dolorem ipsum стал lorem ipsum.

2. Тестирование. Подготовленный дизайн проект, вариантов должно быть не менее двух, раздается группе людей, которые будут проводить юзабилити тестирование. При этом порядок следования прототипов рекомендуется изменять, чтобы исключить психологические аспекты. Количество людей должно быть не менее шести, по рекомендации Нильсена, но, на мой взгляд, стоит взять, по меньшей мере, дюжину. Будет очень хорошо, если тестовая группа будет содержать людей разного возраста и пола. Каждый человек, из тестирующей группы, работая с прототипом должен распознать заложенные дизайнером элементы на странице. После этого он выставляет оценку каждому прототипу. Шкала оценок может быть как от 0 до 5, так и от -3 до 3 и так далее – все зависит от фантазии и интерпретации данных. Соответственно эта оценка объективной, скорее всего, не будет, но она поможет определить общее настроение пользователей.

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

Прототип Определено элементов Субъективная оценка
1 N % (например 65%) # (например 5 из 10)
2 M % (например 70%) # (например 6 из 10)

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

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

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

Видимая простота вредит продажам

Сегодня наткнулся на очень интересную статью Дона Нормана “Простота слишком перехвалена” (Don Norman, “Simplicity Is Highly Overrated“) и следующий за ней очерк Джоэля Сполски (Joel Spolsky, “Simplicity“). Норман рассказывает о своих наблюдениях по поводу того, как люди покупают высоко-технологичные вещи. Как оказалось покупателю куда интереснее взять что-либо (от тостера до автомобиля) напичканное электроникой и элементами управления, чем то же самое, и выполняющее те же функции, но одной кнопкой. Например, что вы выберете – кофеварку с ЖК экранчиком или без? А если экранчик будет цветной? В результате и появляется вывод, что “Простота слишком перехвалена”. Покупателю нужно то что выглядит сложным и многофункциональным, в случае выбора между одинаковым товаром . Сполски переносит это в область разработки программного обеспечения.

Мне не понятно, откуда взят принцип “80/20” – 80% пользователей используют, только 20% функций программы. Но вместе с тем правильна, на мой взгляд, мысль о том, что чем больше функций в программе, тем более она привлекательна для покупателя, даже если ему не нужна и половина возможностей. Хотя даже, если в программе реализовано огромное количество функций, доступных пользователю, это не является залогом привлекательности – принципа «всё одной кнопкой» никто не отменял. В результате для любой программы, если есть желание сделать её успешной, нужно проводить исследования по тему – кто и как использует предложенную функциональность.

То есть, для shareware проектов подойдёт такой сценарий:

1. Задумка

2. Реализация первой версии (с минимально необходимым набором функций)

3. Подготовка web-сайта с разделами after install, feedback, after uninstall. Последние два для сбора отзывов от пользователей.

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

5. Наращивание функциональности.

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

When a new version comes out with new features, we see a sudden, undeniable, substantial, and permanent increase in revenue.

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