Два месяца назад Хенрик Энерот, дизайнер из шведской веб-студии Antrop, написал замечательный пост — Redesigning the browser window — о том, как должен выглядеть современный браузер.
Нам этот текст очень понравился – именно такие идеи заметно улучшают интернет для обычного пользователя. В Рунете на этот пост мало кто отозвался, а поскольку нам хочется найти единомышленников, которым идеи Хенрика тоже по душе, мы решили его перевести полностью для пользователей Хабра.
Как вы знаете, недавно Apple выпустила льва из клетки, Mac OS X Lion. Реакция на новую операционку была неоднозначная. Авторы Gizmodo.com, например, назвали X Lion «эппловской Вистой». А владелец Winsupersite.com Поль Туррот хоть и дал положительный отзыв, но с явной неохотой. В AppStore X Lion получает в основном высокие оценки; около 8% пользователей поставили три звезды и менее.
Большинство плохих отзывов — это жалобы на стабильность, производительность и совместимость с используемыми приложениями. У некоторых, однако, возникли трудности с новой системой жестов. Вот что пишет один из пользователей: «Почему я должен учиться скролить не в том направлении, в котором я скролю вот уже 20 лет?»
Я установил Lion на прошлой неделе, и пока она мне вполне по душе. При этом я тоже вижу ряд проблем, главная из которых – смесь старой и новой парадигм взаимодействия с пользователем.
Это не обзор Mac OS X Lion. Вообще-то я собираюсь проанализировать один конкретный вопрос, который возник у меня во время работы с этой ОС, и предложить решение.
В этой версии операционки Apple решила скрестить характерное для iOS прямое управление (см. Direct manipulation в Wikipedia — прим.пер.) с более традиционным для десктопа поведением программ. Так, среди прочего, родилась идея полноэкранной работы приложений на десктопе.
Полноэкранные приложения работают весьма неплохо, за редкими исключениями. Mail, iCal и iPhoto особенно хороши для использования всей видимой области экрана — отображаемый ими контент прекрасно масштабируется.
А вот просмотр сайтов в Safari на Apple Cinema Display – это тот случай, когда полноэкранный режим не так хорош, как хотелось бы. Посмотрите:
Полноэкранный режим Safari работает прекрасно на лэптопах, однако на экранах большего размера все выглядит не так уж и здорово. На большом экране интерфейс становится почти непригодным для использования. Самое главное – что с табами на таком экране работать невозможно. Пятно высотой в 20 пикселей под адресной строкой на картинке выше – это панель вкладок. Пытаться кликнуть по нему – примерно как играть в дартс курсором мыши.
Эта проблема Safari очень похожа на те, что решаются с помощью адаптивного веб-дизайна (responsive web design – см. cтатью на Smashing Magazine – прим. пер.). Идея адаптивного веб-дизайна — в том, что программисты и дизайнеры ищут способы создания сайтов, которые бы динамически адаптировались практически к любому размеру экрана, от смартфонов до мониторов с высоким разрешением. Вместо того, чтобы создавать сайты под одно конкретное разрешение или под небольшой диапазон разрешений.
Современный пользователь рассчитывает, что используемые им приложения будут корректно отображаться на полном экране. При этом у полного экрана может быть какое угодно разрешение. Так что пора более тщательно изучить принципы адаптивного дизайна и начать применять их к созданию десктопных приложений точно так, как мы начинали это делать с веб-сайтами.
При создании приложений мы сталкиваемся с проблемой размеров экранов и разрешений. Особенно, когда речь идет о браузерах. Их интерфейс напоминает нам о тех днях, когда ради покупки монитора с размерами и разрешением Кубика Рубика нужно было отречься от своего первенца. Тогда мы просто не могли себе позволить сделать панель вкладок и адресную строку хоть чуточку больше. Так постепенно интерфейс браузеров стал абсолютно минималистичным, при том что размеры экранов давно уже выросли.
Неудобство просмотра страниц в Safari на Apple Cinema Display говорит о том, что в своих стараниях сделать интерфейс браузера все более минималистичным мы, кажется, достигли переломного момента.
Размер экрана, разумеется, все еще важен для просмотра сайтов в интернете. Многие сайты «длиннее», чем высота нашего экрана. И чем меньше элементов пользовательского интерфейса будет размещено по вертикали, тем лучше. Но ведь большинство экранов в наши дни – широкоформатные, так почему же мы не задействуем левую и правую стороны экрана для повышения эффективности?
Зачем вместо этого мы запихиваем всё на полоску в верхней области экрана?
Современные браузеры задействуют левую часть экрана под ограниченный набор своих возможностей: история просмотра, закладки, Reading List в Safari в ОС Lion. Этому месту можно найти лучшее применение, например – разместив там вкладки браузера. Панели закладок и прочая подобная ерунда используются несравнимо реже, чем вкладки. Мысль, я понимаю, не новая, но почему-то всё никак не приживается.
Решив исследовать, как мог бы выглядеть и работать левосторонний интерфейс браузера, я нарисовал несколько мокапов в программе Antetype. Заранее простите, подробностей будет очень много.
В мокапах используется графика в стиле iOS/OS X (поскольку сам я — пользователь Mac). Но пусть вас это не смущает. Вся концепция прекрасно подойдет для Linux, Windows и BeOS.
Вот, что у меня получилось. Картинки кликабельны.
Немного приблизим.
Есть несколько плюсов левостороннего расположения табов, помимо появления свободного места по вертикали. Первый плюс – вкладки стали гораздо крупнее. При этом на одном экране браузера их поместится достаточно много — тем более, если речь идет о полноэкранных режимах, как в Lion.
Во-вторых, больший размер табов позволяет обогатить их графикой и дополнительными описаниями. Это упрощает задачу выбора вкладки среди остальных. Они перестают быть неразличимыми серыми пятнами на фоне других неразличимых серых пятен.
Если цвета слишком отвлекают, то имело бы смысл разрешить пользователю уменьшить контрастность панели вкладок, когда она неактивна. Так же, наверное, стоит добавить опцию сделать панель более компактной или убрать ее полностью.
Больше никакого
Как видите, я взял на себя смелость убрать адресную строку. Действие, которое напрашивалось само собой, разве нет? Google вот тоже экспериментирует с этим.
Как часто вы меняете URL сайта, после того как ввели? Как правило, навигация по уже загруженной странице – это переход по ссылкам, и иногда – ввод пароля. Поэтому едва ли изменение URL является первостепенной задачей. Конечно, эта опция должна быть доступна по запросу, например, при нажатии ⌘+L (CTRL+L в Windows и Linux).
Новые табы, как вы догадались, создаются с помощью горячих клавиш или по клику на «New Tab». В строке можно ввести адрес или поисковый запрос.
В наше время разделять адресную и поисковую строки нет никакого смысла. Известен ли мне точный адрес сайта или я просто в общих чертах представляю, что хочу найти – и то, и другое лишь две различные стартовые точки, ведущие к одной цели. Так давайте объединим их, как это уже сделали некоторые браузеры.
В этом примере мы ищем «ux design principles» — то, чем сегодня занимаются все продвинутые чуваки.
И результат.
Оповещения. Наверное, вы заметили цифры рядом с названиями вкладок Facebook, Twitter и LinkedIn. Это счетчики уведомлений. Посмотрим правде в глаза: от веб-приложений сегодня никуда не деться.
Есть такие сайты, которые обновляются динамически в момент их использования, или даже когда соответствующая вкладка неактивна. Пусть они уведомляют нас о произошедших изменениях одинаковым способом. В случае с Твиттером можно отображать число упоминаний пользователя, а в случае с Gmail — число непрочитанных писем.
Описания. Подзаголовок или описание таба в основном просто повторяют то описание, которое выбрал для сайта его владелец. Однако для некоторых случаев браузер может выбирать более эффективный подзаголовок. Например, для вкладки Google подзаголовком может стать поисковая фраза, это упростит поиск таба среди ему подобных.
Названия. В большинстве случаев название сайта – самая важная информация, отображаемая на заголовке вкладки. Но не всегда. Когда вы читаете статью, ее заголовок важнее, чем название сайта. Это стоит отразить на вкладке.
Насколько я знаю, стандарт HTML не отделяет понятие «название страницы» от «названия сайта». Поэтому встречаются заголовки страниц вроде «The Medium Is The Message — Smashing Magazine». Где два информационных объекта объединены в одну строку.
Я не говорю, что, форматируя заголовок страницы таким образом, Smashing Magazine делает что-то не так. Вообще-то, это даже хорошо, потому что большинство браузеров показывают в табе только первую часть фразы (из-за размера вкладки).
И если бы заголовок таба выглядел как «Smashing Magazine — The Medium Is The Message», то не видя его целиком, вы бы в результате не отличили эту статью от других возможно открытых у вас статей этого сайта.
Поэтому разумнее разделить эти два названия и предоставить браузеру решать, как лучше их отобразить. Если название сайта, единое для всех его страниц, можно отделить от названия страницы или статьи (а эта информация меняется от страницы к странице), то браузер может принимать решение самостоятельно: когда отображать заголовок статьи, а когда – название сайта.
Вот как может выглядеть вкладка, если название статьи имеет приоритет по сравнению с названием сайта:
Ненадолго отвлечемся и посмотрим на нервную систему человека, конкретнее – на контекстно-зависимую модель работы мозга. Её изучение помогает понять, как люди систематизируют информацию.
Суть контекстной модели: все ваши эмоции, воспоминания и опыт хранятся контекстно. Если вы замечали, что радостные воспоминания легче приходят на ум, когда вы счастливы, то вам уже знакома контекстуальная природа мозга в действии.
Контекст – это режим, обстановка, частью которой считает себя нервная система. При нахождении в определенном «режиме» какая-то конкретная информация более доступна, чем другая, которую мозг считает менее релевантной (т.е. более удаленной от текущего контекста).
Чем больше информация удалена от текущего контекста, тем более затруднен к ней доступ, вплоть до момента, когда воспоминания практически неразличимы (так, например, бывает с психологически травмированными людьми).
Для проектирования взаимодействия с пользователем важно понимать, как люди систематизируют свои впечатления и опыт с точки зрения контекстов. Что актуально для пользователей в конкретном контексте, и как происходит переключение от одного контекста к другому. Тогда вы сможете исключить все, что не относится к текущему контексту и сфокусироваться только на том, что важно для пользователя именно сейчас. При этом по мере необходимости помогая ему быстро переключаться между контекстами. И такая стратегия более оправдана, чем создание огромного интерфейса, включающего в себя сразу все. Пользуясь им, пользователь вынужден управлять переключением между контекстами самостоятельно, без помощи интерфейса.
С точки зрения контекстов современные браузеры, мягко говоря, далеки от идеала. К примеру, я могу сначала ходить по социальным сетям, в которых зарегистрирован, а затем начать искать сайты с информацией о веб-дизайне. Для меня это два совершенно разных контекста, но браузер об этом не имеет понятия.
В конце дня у меня в браузере открыто как минимум полдюжины контекстов, что, разумеется, создает бардак в табах. Тогда я закрываю браузер и начинаю все с нуля, ведь это проще, чем разбираться во всех этих вкладках.
Mozilla тоже экспериментирует с группами вкладок как со способом представления контекстов. Однако их решение не кажется мне особо интуитивным. Я, похоже, в этом не одинок. По запросу «Mozilla tab groups» поиск Google первым делом выдает раздел помощи на сайте Mozilla и страницу «Где же группы вкладок?». Хотя, как мне кажется, в целом они поняли идею верно, просто надо её немного доработать.
Дизайн левосторонней панели вкладок можно улучшить, добавив к нему управление контекстами. Группировка табов — хороший способ это осуществить. Но все должно быть интуитивно понятно. Чтобы создать группу, перетащим одну вкладку на другую. Как-то так:
Вы можете дать группе название, при этом браузер автоматически предложит свой наиболее вероятный вариант (об этом дальше). Можно назвать группу, например, «Social Networking» (социальные сети). Обратите внимание, что после группировки счетчики Фейсбука и Твиттера суммировались.
При развернутом просмотре содержания группы всю избыточную информацию стоит удалить или сделать менее заметной.
Давайте добавим к этой группе и LinkedIn.
После этого мы таким же образом сгруппируем Smashing Magazine и Daring Fireball и назовем новую группу «Design».
Теперь есть куда сохранять всё то интересное, что найдется по теме «UX design principles». И ни при каких обстоятельствах информация из этой группы не перемешается с табами из «Social Networking».
Должна быть возможность закрыть группу. Закрытые группы освобождают место для построения нового контекста (изучения другой темы) и особо не мешают. Счетчик группы «Social Networking» продолжает обновляться в фоновом режиме.
Если у вас нашлось время сгруппировать страницы (и даже дать им названия), похоже, вы достаточно заинтересованы в их содержимом. И наверняка захотите продолжить пользоваться этими контекстами еще не одну браузерную сессию. А хотите ли вы создавать эти контексты каждый раз заново после перезагрузки браузера? Нет.
Вероятно, должен быть какой-то способ сохранять контексты. Например:
За неимением более подходящего термина, назову верхнюю панель «Палитра групп». Смысл палитры групп заключается в следующем: возможно, вы хотите сохранить группы, но при этом не хотите, чтобы они всегда отображались в панели вкладок. Поэтому необходимо, чтобы существовало место, где группы вкладок будут храниться постоянно, и откуда они могут быть восстановлены.
Когда вы перетащите группу на палитру групп, она будет храниться там, пока вы её сами не удалите. Все производимые с группой изменения будут автоматически влиять и на сохраненную в палитре групп версию. Маленькая машина времени (история сохранений) позволит откатиться на любую предыдущую версию группы без особых усилий или найти любую вкладку, которая когда-то была частью группы.
Продолжаем сохранять группы.
Обе группы сохранены.
Возможно, при создании группы она должна автоматически сохраняться. Если я потрудился создать группу и придумал ей название, то я скорее всего хотел бы её сохранить. Однако я не уверен на 100%. Сложно строить догадки о разумности установок по умолчанию, не протестировав их на пользователях.
Группы должны следовать за пользователем повсюду. Помните, они контекстны пользователю, а не браузеру. У синхронизации групп с облаком будет ряд преимуществ (не считая очевидного: лёгкой доступности из любого места).
На бэкенде разработчик браузера может относиться к именам групп как к тегам для сайтов, включенным в данную группу. Когда сохраненных групп станет много, можно будет выделить наиболее присваемые имена и использовать эту информацию для различных целей:
Эта концепция ещё не до конца сформировалась. У меня есть длинный список дополнений и вопросов к интерфейсу, которые возникли по мере рисования этих эскизов. На большинство из них нельзя дать ответы без минимального исследования поведения пользователей. И, наверняка, я пока не учел кучу разных подводных камней и крайних случаев.
Сложно предугадать как, например, люди будут использовать группы. Захотят ли они, скажем, делиться группами или создавать группы совместно с другими пользователями. Не уверен. Разные браузеры уже пытались внедрять социальные функции, большая часть из которых особо не прижилась (как мне кажется).
Думаю, что основные принципы данной концепции легко применимы для iPad и других девайсов. Левосторонняя панель табов может появляться, если провести двумя или тремя пальцами по экрану слева направо, а палитра групп – если провести сверху вниз.
Основа пользовательского интерфейса также требует разработки. Я не знаю, как лучше представить группы. Я пробовал разные варианты, вот, например:
Если у вас есть свое мнение или критика по данному поводу, и вы хотите их донести до меня, то в Твиттере я @henrik_eneroth или пишите на henrik.eneroth@antrop.se. А можно просто оставить комментарий к посту.
98% прототипов были сделаны в программе Antetype, форматирование изображений выполнялось в Pixelmator или Photoshop и еще разные мелочи в Omnigraffle.
Огромное спасибо Роберту Ландбергу за его отзывы и предложения в процессе разработки всего этого.
И еще. Эти идеи созданы, чтобы быть распространенными по всему миру. Берите их и делайте с ними все, что хотите, с коммерческой выгодой или без неё. Я обещаю, что не буду подавать на вас в суд, поскольку я против актов глупого и ненужного насилия, которые зарубают инновации на корню.
Нам этот текст очень понравился – именно такие идеи заметно улучшают интернет для обычного пользователя. В Рунете на этот пост мало кто отозвался, а поскольку нам хочется найти единомышленников, которым идеи Хенрика тоже по душе, мы решили его перевести полностью для пользователей Хабра.
Перестройка окна браузера
Как вы знаете, недавно Apple выпустила льва из клетки, Mac OS X Lion. Реакция на новую операционку была неоднозначная. Авторы Gizmodo.com, например, назвали X Lion «эппловской Вистой». А владелец Winsupersite.com Поль Туррот хоть и дал положительный отзыв, но с явной неохотой. В AppStore X Lion получает в основном высокие оценки; около 8% пользователей поставили три звезды и менее.
Большинство плохих отзывов — это жалобы на стабильность, производительность и совместимость с используемыми приложениями. У некоторых, однако, возникли трудности с новой системой жестов. Вот что пишет один из пользователей: «Почему я должен учиться скролить не в том направлении, в котором я скролю вот уже 20 лет?»
Я установил Lion на прошлой неделе, и пока она мне вполне по душе. При этом я тоже вижу ряд проблем, главная из которых – смесь старой и новой парадигм взаимодействия с пользователем.
Это не обзор Mac OS X Lion. Вообще-то я собираюсь проанализировать один конкретный вопрос, который возник у меня во время работы с этой ОС, и предложить решение.
Полноэкранный кайф?
В этой версии операционки Apple решила скрестить характерное для iOS прямое управление (см. Direct manipulation в Wikipedia — прим.пер.) с более традиционным для десктопа поведением программ. Так, среди прочего, родилась идея полноэкранной работы приложений на десктопе.
Полноэкранные приложения работают весьма неплохо, за редкими исключениями. Mail, iCal и iPhoto особенно хороши для использования всей видимой области экрана — отображаемый ими контент прекрасно масштабируется.
А вот просмотр сайтов в Safari на Apple Cinema Display – это тот случай, когда полноэкранный режим не так хорош, как хотелось бы. Посмотрите:
Полноэкранный режим Safari работает прекрасно на лэптопах, однако на экранах большего размера все выглядит не так уж и здорово. На большом экране интерфейс становится почти непригодным для использования. Самое главное – что с табами на таком экране работать невозможно. Пятно высотой в 20 пикселей под адресной строкой на картинке выше – это панель вкладок. Пытаться кликнуть по нему – примерно как играть в дартс курсором мыши.
Эта проблема Safari очень похожа на те, что решаются с помощью адаптивного веб-дизайна (responsive web design – см. cтатью на Smashing Magazine – прим. пер.). Идея адаптивного веб-дизайна — в том, что программисты и дизайнеры ищут способы создания сайтов, которые бы динамически адаптировались практически к любому размеру экрана, от смартфонов до мониторов с высоким разрешением. Вместо того, чтобы создавать сайты под одно конкретное разрешение или под небольшой диапазон разрешений.
Современный пользователь рассчитывает, что используемые им приложения будут корректно отображаться на полном экране. При этом у полного экрана может быть какое угодно разрешение. Так что пора более тщательно изучить принципы адаптивного дизайна и начать применять их к созданию десктопных приложений точно так, как мы начинали это делать с веб-сайтами.
Переделка окна браузера под полноэкранный режим
При создании приложений мы сталкиваемся с проблемой размеров экранов и разрешений. Особенно, когда речь идет о браузерах. Их интерфейс напоминает нам о тех днях, когда ради покупки монитора с размерами и разрешением Кубика Рубика нужно было отречься от своего первенца. Тогда мы просто не могли себе позволить сделать панель вкладок и адресную строку хоть чуточку больше. Так постепенно интерфейс браузеров стал абсолютно минималистичным, при том что размеры экранов давно уже выросли.
Неудобство просмотра страниц в Safari на Apple Cinema Display говорит о том, что в своих стараниях сделать интерфейс браузера все более минималистичным мы, кажется, достигли переломного момента.
Размер экрана, разумеется, все еще важен для просмотра сайтов в интернете. Многие сайты «длиннее», чем высота нашего экрана. И чем меньше элементов пользовательского интерфейса будет размещено по вертикали, тем лучше. Но ведь большинство экранов в наши дни – широкоформатные, так почему же мы не задействуем левую и правую стороны экрана для повышения эффективности?
Зачем вместо этого мы запихиваем всё на полоску в верхней области экрана?
Современные браузеры задействуют левую часть экрана под ограниченный набор своих возможностей: история просмотра, закладки, Reading List в Safari в ОС Lion. Этому месту можно найти лучшее применение, например – разместив там вкладки браузера. Панели закладок и прочая подобная ерунда используются несравнимо реже, чем вкладки. Мысль, я понимаю, не новая, но почему-то всё никак не приживается.
Решив исследовать, как мог бы выглядеть и работать левосторонний интерфейс браузера, я нарисовал несколько мокапов в программе Antetype. Заранее простите, подробностей будет очень много.
В мокапах используется графика в стиле iOS/OS X (поскольку сам я — пользователь Mac). Но пусть вас это не смущает. Вся концепция прекрасно подойдет для Linux, Windows и BeOS.
Мокапы
Вот, что у меня получилось. Картинки кликабельны.
Немного приблизим.
Есть несколько плюсов левостороннего расположения табов, помимо появления свободного места по вертикали. Первый плюс – вкладки стали гораздо крупнее. При этом на одном экране браузера их поместится достаточно много — тем более, если речь идет о полноэкранных режимах, как в Lion.
Во-вторых, больший размер табов позволяет обогатить их графикой и дополнительными описаниями. Это упрощает задачу выбора вкладки среди остальных. Они перестают быть неразличимыми серыми пятнами на фоне других неразличимых серых пятен.
Если цвета слишком отвлекают, то имело бы смысл разрешить пользователю уменьшить контрастность панели вкладок, когда она неактивна. Так же, наверное, стоит добавить опцию сделать панель более компактной или убрать ее полностью.
Больше никакого рок-н-ролла адрес-бара
Как видите, я взял на себя смелость убрать адресную строку. Действие, которое напрашивалось само собой, разве нет? Google вот тоже экспериментирует с этим.
Как часто вы меняете URL сайта, после того как ввели? Как правило, навигация по уже загруженной странице – это переход по ссылкам, и иногда – ввод пароля. Поэтому едва ли изменение URL является первостепенной задачей. Конечно, эта опция должна быть доступна по запросу, например, при нажатии ⌘+L (CTRL+L в Windows и Linux).
Новые вкладки
Новые табы, как вы догадались, создаются с помощью горячих клавиш или по клику на «New Tab». В строке можно ввести адрес или поисковый запрос.
В наше время разделять адресную и поисковую строки нет никакого смысла. Известен ли мне точный адрес сайта или я просто в общих чертах представляю, что хочу найти – и то, и другое лишь две различные стартовые точки, ведущие к одной цели. Так давайте объединим их, как это уже сделали некоторые браузеры.
В этом примере мы ищем «ux design principles» — то, чем сегодня занимаются все продвинутые чуваки.
И результат.
Другие подробности: оповещения, описания и названия
Оповещения. Наверное, вы заметили цифры рядом с названиями вкладок Facebook, Twitter и LinkedIn. Это счетчики уведомлений. Посмотрим правде в глаза: от веб-приложений сегодня никуда не деться.
Есть такие сайты, которые обновляются динамически в момент их использования, или даже когда соответствующая вкладка неактивна. Пусть они уведомляют нас о произошедших изменениях одинаковым способом. В случае с Твиттером можно отображать число упоминаний пользователя, а в случае с Gmail — число непрочитанных писем.
Описания. Подзаголовок или описание таба в основном просто повторяют то описание, которое выбрал для сайта его владелец. Однако для некоторых случаев браузер может выбирать более эффективный подзаголовок. Например, для вкладки Google подзаголовком может стать поисковая фраза, это упростит поиск таба среди ему подобных.
Названия. В большинстве случаев название сайта – самая важная информация, отображаемая на заголовке вкладки. Но не всегда. Когда вы читаете статью, ее заголовок важнее, чем название сайта. Это стоит отразить на вкладке.
Насколько я знаю, стандарт HTML не отделяет понятие «название страницы» от «названия сайта». Поэтому встречаются заголовки страниц вроде «The Medium Is The Message — Smashing Magazine». Где два информационных объекта объединены в одну строку.
Я не говорю, что, форматируя заголовок страницы таким образом, Smashing Magazine делает что-то не так. Вообще-то, это даже хорошо, потому что большинство браузеров показывают в табе только первую часть фразы (из-за размера вкладки).
И если бы заголовок таба выглядел как «Smashing Magazine — The Medium Is The Message», то не видя его целиком, вы бы в результате не отличили эту статью от других возможно открытых у вас статей этого сайта.
Поэтому разумнее разделить эти два названия и предоставить браузеру решать, как лучше их отобразить. Если название сайта, единое для всех его страниц, можно отделить от названия страницы или статьи (а эта информация меняется от страницы к странице), то браузер может принимать решение самостоятельно: когда отображать заголовок статьи, а когда – название сайта.
Вот как может выглядеть вкладка, если название статьи имеет приоритет по сравнению с названием сайта:
Контекстные группы вкладок
Ненадолго отвлечемся и посмотрим на нервную систему человека, конкретнее – на контекстно-зависимую модель работы мозга. Её изучение помогает понять, как люди систематизируют информацию.
Суть контекстной модели: все ваши эмоции, воспоминания и опыт хранятся контекстно. Если вы замечали, что радостные воспоминания легче приходят на ум, когда вы счастливы, то вам уже знакома контекстуальная природа мозга в действии.
Контекст – это режим, обстановка, частью которой считает себя нервная система. При нахождении в определенном «режиме» какая-то конкретная информация более доступна, чем другая, которую мозг считает менее релевантной (т.е. более удаленной от текущего контекста).
Чем больше информация удалена от текущего контекста, тем более затруднен к ней доступ, вплоть до момента, когда воспоминания практически неразличимы (так, например, бывает с психологически травмированными людьми).
Для проектирования взаимодействия с пользователем важно понимать, как люди систематизируют свои впечатления и опыт с точки зрения контекстов. Что актуально для пользователей в конкретном контексте, и как происходит переключение от одного контекста к другому. Тогда вы сможете исключить все, что не относится к текущему контексту и сфокусироваться только на том, что важно для пользователя именно сейчас. При этом по мере необходимости помогая ему быстро переключаться между контекстами. И такая стратегия более оправдана, чем создание огромного интерфейса, включающего в себя сразу все. Пользуясь им, пользователь вынужден управлять переключением между контекстами самостоятельно, без помощи интерфейса.
С точки зрения контекстов современные браузеры, мягко говоря, далеки от идеала. К примеру, я могу сначала ходить по социальным сетям, в которых зарегистрирован, а затем начать искать сайты с информацией о веб-дизайне. Для меня это два совершенно разных контекста, но браузер об этом не имеет понятия.
В конце дня у меня в браузере открыто как минимум полдюжины контекстов, что, разумеется, создает бардак в табах. Тогда я закрываю браузер и начинаю все с нуля, ведь это проще, чем разбираться во всех этих вкладках.
Mozilla тоже экспериментирует с группами вкладок как со способом представления контекстов. Однако их решение не кажется мне особо интуитивным. Я, похоже, в этом не одинок. По запросу «Mozilla tab groups» поиск Google первым делом выдает раздел помощи на сайте Mozilla и страницу «Где же группы вкладок?». Хотя, как мне кажется, в целом они поняли идею верно, просто надо её немного доработать.
Группы вкладок, левосторонний стиль
Дизайн левосторонней панели вкладок можно улучшить, добавив к нему управление контекстами. Группировка табов — хороший способ это осуществить. Но все должно быть интуитивно понятно. Чтобы создать группу, перетащим одну вкладку на другую. Как-то так:
Вы можете дать группе название, при этом браузер автоматически предложит свой наиболее вероятный вариант (об этом дальше). Можно назвать группу, например, «Social Networking» (социальные сети). Обратите внимание, что после группировки счетчики Фейсбука и Твиттера суммировались.
При развернутом просмотре содержания группы всю избыточную информацию стоит удалить или сделать менее заметной.
Давайте добавим к этой группе и LinkedIn.
После этого мы таким же образом сгруппируем Smashing Magazine и Daring Fireball и назовем новую группу «Design».
Теперь есть куда сохранять всё то интересное, что найдется по теме «UX design principles». И ни при каких обстоятельствах информация из этой группы не перемешается с табами из «Social Networking».
Должна быть возможность закрыть группу. Закрытые группы освобождают место для построения нового контекста (изучения другой темы) и особо не мешают. Счетчик группы «Social Networking» продолжает обновляться в фоновом режиме.
Сохранение групп
Если у вас нашлось время сгруппировать страницы (и даже дать им названия), похоже, вы достаточно заинтересованы в их содержимом. И наверняка захотите продолжить пользоваться этими контекстами еще не одну браузерную сессию. А хотите ли вы создавать эти контексты каждый раз заново после перезагрузки браузера? Нет.
Вероятно, должен быть какой-то способ сохранять контексты. Например:
За неимением более подходящего термина, назову верхнюю панель «Палитра групп». Смысл палитры групп заключается в следующем: возможно, вы хотите сохранить группы, но при этом не хотите, чтобы они всегда отображались в панели вкладок. Поэтому необходимо, чтобы существовало место, где группы вкладок будут храниться постоянно, и откуда они могут быть восстановлены.
Когда вы перетащите группу на палитру групп, она будет храниться там, пока вы её сами не удалите. Все производимые с группой изменения будут автоматически влиять и на сохраненную в палитре групп версию. Маленькая машина времени (история сохранений) позволит откатиться на любую предыдущую версию группы без особых усилий или найти любую вкладку, которая когда-то была частью группы.
Продолжаем сохранять группы.
Обе группы сохранены.
Сохранение по умолчанию?
Возможно, при создании группы она должна автоматически сохраняться. Если я потрудился создать группу и придумал ей название, то я скорее всего хотел бы её сохранить. Однако я не уверен на 100%. Сложно строить догадки о разумности установок по умолчанию, не протестировав их на пользователях.
В облаке
Группы должны следовать за пользователем повсюду. Помните, они контекстны пользователю, а не браузеру. У синхронизации групп с облаком будет ряд преимуществ (не считая очевидного: лёгкой доступности из любого места).
Подбор имени группы
На бэкенде разработчик браузера может относиться к именам групп как к тегам для сайтов, включенным в данную группу. Когда сохраненных групп станет много, можно будет выделить наиболее присваемые имена и использовать эту информацию для различных целей:
- Браузер будет предлагать имя для группы, основываясь на ее содержимом. По мере создания большего числа групп пользователями во всем мире браузер будет предлагать все более подходящие имена;
- Улучшение результатов поисковой выдачи;
- Возможность предложить пользователю дополнительные страницы и другие ресурсы на основании того, что уже включено в группу. По запросу, конечно — пожалуйста, не надо дергать пользователя.
И наконец (не совсем)
Эта концепция ещё не до конца сформировалась. У меня есть длинный список дополнений и вопросов к интерфейсу, которые возникли по мере рисования этих эскизов. На большинство из них нельзя дать ответы без минимального исследования поведения пользователей. И, наверняка, я пока не учел кучу разных подводных камней и крайних случаев.
Сложно предугадать как, например, люди будут использовать группы. Захотят ли они, скажем, делиться группами или создавать группы совместно с другими пользователями. Не уверен. Разные браузеры уже пытались внедрять социальные функции, большая часть из которых особо не прижилась (как мне кажется).
Думаю, что основные принципы данной концепции легко применимы для iPad и других девайсов. Левосторонняя панель табов может появляться, если провести двумя или тремя пальцами по экрану слева направо, а палитра групп – если провести сверху вниз.
Основа пользовательского интерфейса также требует разработки. Я не знаю, как лучше представить группы. Я пробовал разные варианты, вот, например:
Будем на связи
Если у вас есть свое мнение или критика по данному поводу, и вы хотите их донести до меня, то в Твиттере я @henrik_eneroth или пишите на henrik.eneroth@antrop.se. А можно просто оставить комментарий к посту.
98% прототипов были сделаны в программе Antetype, форматирование изображений выполнялось в Pixelmator или Photoshop и еще разные мелочи в Omnigraffle.
Огромное спасибо Роберту Ландбергу за его отзывы и предложения в процессе разработки всего этого.
И еще. Эти идеи созданы, чтобы быть распространенными по всему миру. Берите их и делайте с ними все, что хотите, с коммерческой выгодой или без неё. Я обещаю, что не буду подавать на вас в суд, поскольку я против актов глупого и ненужного насилия, которые зарубают инновации на корню.