Разрабатывая анимацию загрузки Windows 7
По мере нашего диалога с пользователями стала понятна заинтересованность пользователей в совершенно разных областях разработки Windows 7. Мы осведомлены о разговорах вокруг процедуры загрузки и, в частности, о том, насколько важна ее скорость. Мы также понимаем, насколько утомительно наблюдать за мерцающими огоньками индикатора активности диска при пробуждении компьютера из режима сна или гибернации. Чтобы улучшить первые впечатления от работы с ОС, мы решили переработать загрузочную последовательность. Звучит довольно просто, хотя, на самом деле, разработке новой последовательности загрузки сопутствует масса инженерных проблем. И нашей задачей было создание визуально привлекательного экрана загрузки без влияния на скорость загрузки системы. Объяснить, с какими проблемами мы столкнулись при разработке, взялась Карэн Вон (Karen Wong), программный менеджер команды Core User Experience. – Стивен
Дизайн
Мы используем понятие «индивидуальность» для идентификации некоторых характеристик программного обеспечения, которые имеют эмоциональную связь с пользователями. «Свет» и «энергия» – лишь некоторые понятия, используемые нами для описания индивидуальности Windows 7. По мере разработки Windows 7 стало очевидно, что для того, чтобы продемонстрировать эти черты Windows 7, мы должны пойти гораздо дальше, чем в случае с Vista.
Мы понимаем, что с точки зрения дизайна, визуальное представление той или иной функции играет ключевую роль в восприятии качества и производительности. В связи с этим мы поставили цель сделать загрузку Windows поистине завораживающей, воспользовавшись понятиями света и энергии. Поэтому форма, в которой эти сущности выражают себя в природе, и стала для нас макетом. Такие понятия, как «биолюминесценция», «натуральный», «непритязательная красота» и «атмосфера» часто мелькали при мозговом штурме. Мы знаем, что в отдельности эти слова звучат несколько избито, но все они очень хорошо отражают задачи Windows 7.
Было создано и обсуждено свыше десятка различных вариантов загрузочной последовательности. Варианты отличались насыщенностью и яркостью цветов, сложностью движений и эффектами освещения. Вот лишь несколько эскизов, рассмотренных нашей командой:
Эскизы вариантов загрузочной последовательности
Окончательный вариант дизайна в Windows 7 символизирует энергию, струящуюся в четырех направлениях в форме света, проецируемого сквозь окно (конечно же, это не просто совпадение, что логотип Windows имеет сходство с окном!). Едва различимая пульсация призвана показать прогресс – еще одна деталь, подчеркивающая индивидуальность Windows 7.
С точки зрения дизайнер эта новая загрузочная последовательность отвечает всем поставленным целям и мы рады представить ее нашими пользователями. Однако, загрузка – это нечто большее, чем просто внешняя привлекательность. С инженерной точки зрения есть ряд проблем, с которыми нам необходимо побороться, поскольку время загрузки компьютера является одной из основных характеристик, по которым пользователи оценивают ОС. Внешняя привлекательность не может ускорить процедуру загрузки. Да и, к слову сказать, многие из вас критически относятся к так называемым «рюшечкам», поэтому мы не стремились сделать загрузочную последовательность подобным украшением. Никакого влияния на производительность
Если бы мы сохранили наследие Vista и просто бы обновили анимацию, приведя ее в соответствие со стилем Windows 7, нам не удалось бы достичь нового уровня производительности и качества, к которым стремились. На самом же деле, для того, чтобы добавить анимацию, потребовалось внести серьезные изменения в код системы.
В загрузчике Vista использовалось изображение с разрешением 640x480, соответственно, и размер файла с зеленым анимированным прогресс-баром был очень невелик. Более того, глубина цвета в загрузчике Vista тоже была мала – всего 16 разрядов на пиксель. В Windows 7 этот параметр был увеличен до 32 разрядов на пиксель, что позволило сделать анимацию более красочной. Обновления индикатора прогресса загрузки Vista осуществлялись через процессор, который восприимчив к параллельным операциям ввода/вывода, а это, в свою очередь, иногда приводило к замираниям анимации. С низким разрешением, ограниченной глубиной цвета и замираниями – мы должны были начать работу с нуля, чтобы создать что-то поистине впечатляющее.
Мы начали работу над загрузчиком Windows 7, используя в своей работе иной механизм воспроизведения анимации. Этот механизм использует указатель на кадровый буфер из прошивки (BIOS или UEFI-прошивки) и изображение с более высоким разрешением (1024 x 768). Механизм анимирует изображение параллельно с тем, как в память загружается ядро и критические драйверы. В связи с тем, что графический драйвер на данном этапе в память еще не загружен и не инициализирован, анимация осуществляется исключительно силами центрального процессора путем обновления кадрового буфера. Мы также сделали дополнительную оптимизацию – добавили процессору возможность использовать комбинированное кэширование для увеличения производительности.
В статье Майкла Фортина (Michael Fortin), посвященной производительности при загрузке, говорится о том, насколько зависимы ранние этапы загрузки от активности ввода/вывода, поскольку на этих этапах происходит загрузка ядра, файлов драйверов устройств и иных системных компонентов. Мы ограничили размер анимации до маленького фрагмента экрана чтобы избежать возникновения любых задержек на ранних этапах загрузки ОС. Большая по размерам анимация потребовала бы загрузки большего набора изображений, что незамедлительно привело бы к увеличению файлового ввода/вывода. Изображения сжимаются за счет включения растровых изображений в качестве ресурсов, которые впоследствии сжимаются с помощью WIM. Сжатие с помощью WIM уменьшает общий размер файла и, как следствие, количество необходимых операций ввода/вывода. Кроме того, снижается и необходимое для установки дисковое пространство. Анимация небольшого фрагмента экрана и использование низкой частоты кадров позволяет процессору сохранять уровень загрузки кадрового буфера на сравнительно низком уровне, и практически не увеличивать времени загрузки системы.
Еще одним изменением, направленным не столько не увеличение производительности, сколько на увеличение качества, было сокращение переходов в графическом режиме. Эти переходы происходят в ходе инициализации графической подсистемы и самой оболочки Windows. В Vista это приводило к тому, что перед появлением приглашения авторизации экран несколько раз мерцал.
После более пристального изучения процесса загрузки системы, вызванного необходимостью добавить новую анимацию, мы были приятно удивлены, что в дополнение к эстетическому наслаждению появилась реальная возможность сократить время полной загрузки системы до момента появления рабочего стола. При запуске компьютера под управлением Vista в загрузочную последовательность входила и анимация логотипа Windows, которая предшествовала появлению экрана авторизации (или рабочего стола, когда выбран режим автоматического входа). В связи с ограничениями архитектуры загрузки Vista эта анимация могла быть воспроизведена лишь после того, как в память были загружены все необходимые компоненты.
Загрузка Vista
Теперь, когда загрузочная заставка стала столь яркой и красочной, необходимость в последующей анимации попросту отпала, поэтому мы решили от нее отказаться. В результате нам удалось сэкономить немного времени.
Загрузка Windows 7
Некоторые из вас спросят, а что же произошло со звуком, сопутствующим загрузке. В Vista этот звук было необходимо синхронизировать с анимацией. Это влияет на производительность некоторых устройств, потому что в таком случае необходимо загружать звуковой стэк системы до начала воспроизведения анимации. Поэтому часто в ожидании загрузки звукового стэка анимация воспроизводилась с задержкой и, соответственно, на загрузку до рабочего стола требовалось больше времени. Теперь же звук воспроизводится асинхронно после появления экрана авторизации. На большинстве из протестированного нами оборудовании звук воспроизводился одновременно с появлением экрана авторизации. Пользователи Vista жаловались, что звук воспроизводился тогда, когда загрузка, по сути, не была завершена. Поэтому в дополнение к очевидному приросту в производительности это изменение позволяет пользователям понять, что их система действительно готова к работе.
Оптимизация загрузочного кода и удаление анимации, добавленной в Vista, позволили нам добавить более высококачественную анимацию загрузки не влияющую на время загрузки ОС. Разработка для широкого диапазона аппаратного обеспечения
В связи с разнообразием конфигураций процедура загрузки от компьютера к компьютеру может существенно отличаться. Мы приняли несколько дизайнерских решений, которые позволят обеспечить наилучший визуальный опыт на широчайшем диапазоне аппаратного обеспечения, хотя время, необходимое на загрузку, все же будет зависеть от используемых устройств.
Так, к примеру, можно заметить, что перед анимацией имеет место некоторая задержка, и продолжительность этой задержки разнится от системы к системе. Чтобы не смущать пользователей, мы включили в загрузочную последовательность текст. После задержки стартует анимация, причем стартует асинхронно с остальными операциями ввода/вывода, сопутствующими загрузке.
Также можно заметить, что размеры флага Windows на мониторах с разными размерами могут несколько отличаться. В связи с техническими ограничениями в Windows 7 загрузочная последовательность выводится в минимальном рекомендуемом разрешении – 1024x768 – и не зависит от истинного разрешения экрана. Сегодня большинство устройств настроены таким образом, чтобы подгонять загрузочную последовательность под размеры экрана, а не центрировать ее. Как следствие, загрузочная анимация растягивается на весь экран даже на тех экранах, чье соотношение сторон отличается от 1024x768. Однако мы протестировали последовательность на мониторах с наиболее распространенными соотношениями стороны, чтобы гарантировать визуальное качество.
Загрузка, перезагрузка и выход из режима гибернации
Мы проделали столько работы, чтобы улучшить удобство загрузки, что мы просто не можем допустить, чтобы она пропала ззря. Поэтому пользователи будут наблюдать эту же последовательность при выходе из режима гибернации. Персонализация
Многие пользователи спрашивают нас, возможно ли использовать иные варианты анимации для индикации процесса загрузки. Это не то, к чему мы стремились в Windows 7. Уже неоднократно говорилось о персонализации различных элементов Windows 7, в частности, о наборах тем. Причина такого решения очень проста: мы не можем гарантировать безопасность системы, разрешив на ранних этапах запуска системы загрузку в память произвольных элементов. На этапе загрузки система должна быть хорошо защищена, поскольку ни антивирусы, ни межсетевые экраны не могут обеспечить безопасности. И хотя мы верим, что все разработчики будут следовать требованиям по размеру изображений и их формату, в целях обеспечения производительности нам не хотелось бы добавлять в систему код, проверяющий соответствие требованиям. Одной из наших целей при разработке Windows 7 было обеспечение разнообразных возможностей для самовыражения пользователей. Каждый должен знать, что его компьютер является его, а не чьей-то собственностью. Надеюсь, вы поймете, почему этому элементу требуется более серьезный подход.
Теперь вы знаете, чем мы руководствовались при разработке Windows 7. Мы хотели, чтобы столь рутинная операция, как загрузка ОС, стала бы более приятной, а судя по отзывам пользователей, появляющимся то тут, то там, мы движемся в верном направлении. В дополнение к нашему стремлению ускорить загрузку компьютера настолько, чтобы большинство не успевало заметить анимации, а если и замечали бы, то это было бы приятное зрелище!
Комментариев (0) 04.06.2009 19:07
Разрабатывая Aero Snap
Эта статья позволит заглянуть за кулисы разработки функции Aero Snap в Windows 7. Мы решили, было бы здорово рассказать о процессе разработки этой функции, и использовавшихся инструментов и методик. Aero Snap представляет собой результат особого рода усилий создателей: вы просто пользуетесь этим интерфейсом, не вызывая его. Как и в случае с другими функциями, Aero Snap – плод взаимодействия, возникший на стыке всех дисциплин программирования. Стефан Хёфнагельс (Stephan Hoefnagels), ведущий дизайнер UХ, расскажет о процессе создания Aero Snap со своей точки зрения. — Стивен
В статье «Пользовательский интерфейс: управляя окнами Windows» и «И еще раз к вопросу управления окнами Windows" рассматривались некоторые интересные сценарии работы, о которых следует упомянуть, не только по нашему убеждению, но и по мнению читателей, при рассмотрении функций Windows 7. В них мы затронули некоторые аспекты типичных конфигураций и цели, которые преследовали при разработке.
В настоящей статье нам хотелось бы пристальнее взглянуть на работу Aero Snap, которую многие из вас уже имели возможность опробовать в сборках Windows 7, распространявшихся на PDC и, конечно же, в бета-версии. Мы коротко обрисуем возможности функции как таковой, но все же главной своей задачей мы видим демонстрацию процесса создания, чтобы можно было увидеть проблемы, с которыми мы сталкивались, и предположениями, на которых мы основывались.
Цели и сценарии
Как объяснялось в предыдущем сообщении, нашей главной целью при разработке Aero Snap было обеспечить пользователя возможностью размещать окна программ именно там, где это необходимо. Мы стремились сократить число щелчков кнопками мыши и усилий по точному позиционированию курсора для выполнения рутинных действий. В общем, мы хотели бы дать возможность уверенно управлять окнами, создавая ощущение, что процедура полностью контролируется. Мы уже касались этого момента в статье, посвященной панели задач Windows 7, и эта тема красной линией проходит через всю нашу деятельность по совершенствованию интерфейса нового рабочего стола.
Перед тем, как мы начнем разговор о воплощении этих целей в дизайне Aero Snap, коротко остановимся вот на чем. В рассматриваемых ниже сценариях вы столкнетесь с тщательной детализацией последовательности действий – например: выбрать окно, щелкнуть по кнопке захвата, изменить размер окна. Такая детализация сделает чтение не самым большим удовольствием. Эти последовательности настолько въелись в кровь и плоть, что многие из нас вообще не замечают, как выполняют их. Почему бы не опустить эти детали вообще? Мы заостряем на них внимание с умыслом, поскольку хотим полностью отдавать самим себе отчет в том, как много действий и движений на самом деле приходится выполнить, прежде чем можно будет сказать: готово! Эти усилия заставляют нас понять то, что обычно остается без внимания. Кроме того, помимо глубокого проникновения в суть проблемы, мы получаем нужный уровень детализации для обоснования принятых решений.
Расположение окон рядом друг с другом
Как многие заметили, выполнение операции drag-n-drop из одного окна в другое часто сопряжено с известными неудобствами. Окна располагаются внахлест, и для размещения их в нужном порядке требуется немало мелких операций с помощью мыши. Обычно это происходит следующим образом: выделить окно, изменить его размер, и поместить на экране так, чтобы значительная его часть была видна как «мишень» для drag-n-drop. Потом следует повторить то же самое для другого окна. Похожие усилия потребуются, например, для визуального сравнения содержимого двух папок, – опять множество ненужных щелчков, растягиваний, скрупулезной расстановки в нужном порядке, переключений между окнами, и курсор наматывает по экрану километры расстояний.
С помощью Aero Snap можно подтянуть окно мышью к границе экрана – и оно займет ровно половину экрана. Повторите ту же операцию со вторым окном. Таким образом, операция выполняется двумя простыми движениями, в то время как прежде для этого требовались десятки!
Рис. 1. Размещение окон рядом друг с другом с помощью Aero Snap перемещением курсора к границе экрана (слева направо, сверху вниз)
Вертикальное увеличение окон
Мы знаем, что пользователи любят разворачивать окна на весь экран. Некоторые любят настолько, что всегда держат все свои окна полностью развернутыми и никогда не переключают их в другие режимы. Конечно, поскольку размеры и разрешения экранов существенно возросли и широкие экраны набирают популярность, разворачивание окна на весь экран уже не выглядит столь привлекательной возможностью и в некоторых случаях вообще теряет смысл. Например, сообщение электронной почты – кому удобно читать длиннющие строки текста, для охвата которых приходится вертеть головой из стороны в сторону? Другой пример – Интернет-серфинг. Содержимое страницы иногда заполняет узкую область в центре, оставляя две трети экрана по обе стороны пустыми.
Теперь с помощью Aero Snap можно увеличить окно только в вертикальном направлении. Растягивая окно до верхней границы, вы тем самым «автоматически» растянете его и до нижней. Прекрасная возможность читать длинные сообщения в блогах!
Рис. 2. Вертикальное разворачивание окна с помощью Aero Snap путём перетаскивания его до верхней границы экрана
Перемещение полностью развернутых окон с экрана на экран
Мы знаем, что существуют пользователи, у которых стоит более одного монитора, и уж наверняка они есть среди читателей нашего блога. Вам, без сомнения, хотелось узнать, как можно перетащить развернутое на весь экран окно на другой монитор. Существует ли путь, более короткий, чем уменьшить окно, поместить курсор мыши на область заголовка окна, протянуть его в желаемое место, снова кликнуть на кнопке «Развернуть»? С помощью Aero Snap вы просто тянете окно за заголовок вниз, перемещаете в нужное место и снова тянете за заголовок к верхней границе экрана, – одним движением. Наконец-то!
Упорядочивание окон на экране ноутбука
Упорядочивание окон на обычном ПК может быть сопряжено с массой неудобств и возни, километрами «мышиных бегов» и прочих малопродуктивных действий. На ноутбуках ситуация усугубляется отсутствием мыши, что требует от пользователя уже прямо-таки ловкости профессионального престидижитатора. Именно для ноутбуков, а также для продвинутых пользователей предусмотрено несколько клавиатурных комбинаций. Удерживайте клавишу Windows и нажимайте клавиши курсора. Возможно, вам захочется попробовать сочетание удерживаемой клавиши Shift и курсорных клавиш, особенно если вы пользуетесь несколькими мониторами.
Процесс создания
Ну, хорошо, – о сценариях работы мы уже поговорили, как и о вариантах их выполнения на практике, и, кажется, достаточно недвусмысленно. Особенно для тех, кто уже попробовал новую технологию, в частности, в бета-версии Windows 7. Все работает так, как и предполагалось. Но как же мы этого добились? В следующей части мы сделаем то, чего обычно не делаем, а именно – покажем вам «кухню» процесса разработки Aero Snap и расскажем о нескольких ухабах, на которых набивали себе шишки по пути к решению. Мы говорим об этом сейчас в основном в свете удобства пользователя и не пытаемся заставить вас оценить масштаб проделанной нами работы. Уверен, у нас еще будет возможность поговорить на эти темы. Итак, давайте же начнем!
Эскизы
Вернемся в начало 2007 года. Установив, что управление окнами может быть одним из объектов оптимизации и определив несколько действующих сценариев, мы приступаем к мозговому штурму для выработки идей. Как сделать процедуру организации окон более эффективной? Менее многоступенчатой? Более увлекательной? Вот какие вопросы мы задавали себе. Мы работали на стыке различных дисциплин, таких, как дизайн, исследования UX, управление разработкой программного продукта и программирование. Во всем этом принимала участие совсем небольшая группа, менее дюжины человек, – для такого объема работ это немного.
Мы сознательно существенно ограничивали себя, стремясь достигнуть результата без разработки какого-то дополнительного органа управления для интерфейса. Представьте себе, например, дополнительную кнопку в заголовке окна, – для одного окна это не проблема, но если речь идет о десятке или более окон на экране, это уже значительно увеличивает беспорядок на нем. Понятно, что подобный вариант нам категорически не нравился. В конце концов, как и было озвучено в докладе о принципах интерфейса на PDC, наша задача – меньше беспорядка, больше ясности.
Множество идей фиксировалось в виде эскизов, которые мы размещали на закрытой для внешних посетителей веб-странице. Перенесённые с досок в кабинетах и коридорах, эти эскизы-ролики длятся по 5 минут каждый. Под этим абзацем вы видите одни из последних образцов, по которым можно проследить идеи, в соответствии с которыми формировалась концепция Aero Snap.
Рис. 3. Ранние идеи в виде эскизов
Создание прототипов на раннем этапе написания основного кода
Накопив достаточное количество вариантов на бумаге, мы сгорали от нетерпения увидеть их программное воплощение. Наступило время прототипов. Помните, мы находились еще в самом начале пути. Мы хотели, чтобы наши прототипы обеспечивали обратную связь, и чтобы с ними можно было работать в обычном, повседневном режиме. Мы решили внедрить идеи, используя еще сырой код, но который уже можно было запускать на рабочих компьютерах. Рисунок ниже изображает прототип «умного изменения размера окна», работающий в Windows Vista. Разумеется, этим прототипам было еще далеко до готовых функций, они лишь едва обозначали воплощение основных задумок, и определенно содержали больше ошибок, чем нужно. Тем не менее, для нас было важно получить опыт взаимодействия, и мы его получили столько, что его хватило для дальнейшего движения в направлении цели.
Рис. 4. Ранний прототип, работающий в Windows Vista, – обратите внимание на иконку в панели задач, созданную прототипом (и на дату, показывающую, когда всё это происходило)
Мы использовали эти ранние наработки и первоначальные отзывы об удобстве их применения для того, чтобы вернутся и дошлифовать их на заключительном этапе процесса. На том, раннем этапе мы старались быть как можно менее предвзятыми и не стеснялись удивляться. Иногда замыслы, на бумаге выглядевшие не особенно ярко, становились настоящими находками после овеществления на программном уровне. С другой стороны, было много такого, что прекрасно выглядело в рисунках, но никак не впечатляло на практике. Поскольку мы ни на чем конкретном не зацикливались, то легко перерабатывали или даже отказывались от некоторых вариантов.
Наконец, прототипы здорово облегчали нам обдумывание деталей дизайна. Вероятно, некоторые из озарений уводили нас в сторону (конечно же, мы непрестанно твердили про себя, что важно распознать настоящее озарение и удержать его). Вот пример из сообщения электронной почты одного из членов нашей команды по поводу очередной версии прототипа функции интеллектуального изменения размеров окна:
«Я вижу, что что-то изменилось. В оригинальной версии изменение размера до максимума увеличивало окно до громадных размеров. Если уменьшить окошко, оно скачком возвращается в нормальное положение. Выглядело так, как будто гиперувеличенное окно и его нормальное состояние отличаются. В новой версии, когда изменяешь размер "суперувеличенного" окна, оно не возвращается к прежнему состоянию. Это, кажется, неплохо, – если "суперувеличенное" окно будет отличаться от обычного возвращения в исходное положение. Мы должны подумать, как закрепить это в дизайне».
После множества прототипов мы остановились на концепции размещения окон рядом друг с другом и вертикальном развертывании. Нам всё отчетливее становилось понятно, чего мы добиваемся.
Подробности дизайна: переходные формы
Наконец, мы довели наши замыслы до ума, создав некий набор взаимодействий и поведенческих реакций, пусть и не полностью конкретизированный. Настало время заполнять анкету с дотошными вопросами. «Что значит расположить окна рядом друг с другом в мире, где все пользуются лишь тремя вариантами расположения – развернутое на весь экран, обычное и свернутое в панель задач? Как на самом деле вы собираетесь получать это новое состояние окна и как потом переходить к какому-то иному?» Эти цитаты из нашей почты – только часть вопросов, на которые нам предстоит ответить.
Рис. 5. Актуальное состояние окон (слева направо): свернутое, обычное, развернутое на весь экран. Поместятся окна по способу «рядом друг с другом» и «вертикально развернутые»?
Давайте взглянем на проблему подробнее. Ниже вы видите два варианта, предложенных в самом начале, – как можно менять состояние окон (для каждого состояния). Какая модель кажется вам более удачной?
Рис. 6. Два варианта перехода между состояниями окон
Ответ на этот вопрос подразумевает и ответы на куда более специальные вопросы, например: «Какие состояния мы хотим напрямую увязать в последовательности и как мы будем переходить от одного к другому?» «Насколько обязательно переходить от вертикально развернутого состояния к развернутому на весь экран?» «Должны ли состояния вертикального развертывания и расположения рядом друг с другом вести себя одинаково, раз они выглядят одинаково?» Ответы на эти вопросы и привели нас к той модели, которая вам знакома, а именно модели В.
Но это еще не все – требуется еще более тщательная проработка деталей, возникают новые вопросы, требующие ответа. «Что если мне нужно перетащить вертикально развернутое окно в сторону?» «Изменить его ширину?» «Стянуть его вниз?»
Скоро вы почувствуете, что погружаетесь в замысловатую паутину последовательности событий, возможных действий и возможных результатов. Чего же следует ожидать при использовании всей системы целиком?
Чтобы помочь вам проследить последовательность принятия решений, мы создали определенную последовательность «наводящих установок», допущений, которые, как мы полагаем, являются верными. Например: «Интуитивный способ отмены действия, запущенного движением мыши – движение мыши в противоположном направлении». Или: «Возвращение к предыдущему – обычному – состоянию окна должно быть предельно облегчено, необходимо избежать большого количества действий и движений, возвращающих окно приемлемое состояние». А также: «Если пользователь определил ширину окна в текущем состоянии, этот размер должен сохраняться во всех случаях, когда это имеет смысл».
Используя эти положения, мы смогли ответить на ряд вопросов, примеры которых приводились выше, прогнозируемым образом и, соответственно, получить прогнозируемые результаты. И хотя обосновать переходные состояния и правила переходов было непросто, в итоге поведение элементов системы соответствует ожидаемому и, надеемся, является интуитивно понятным. Это именно то, к чему мы стремились.
Конфликты
Приведем несколько примеров последовательности проблем для по-настоящему внимательных читателей. Прорабатывая новые промежуточные состояния, мы обнаружили, что некоторые правила, определяющие, что когда должно происходить, конфликтуют друг с другом. Представьте себе такую ситуацию. Два правила в нашей новой модели окон таковы:
1. Перетягивание окна к верхней кромке экрана разворачивает его на весь экран
2. Интуитивный способ отмены действия, запущенного движением мыши – движение мыши в противоположном направлении
Теперь попробуем посмотреть на практике, как это выглядит в нашей сборке Windows 7. Начнем с окна в обычном состоянии. Произведите вертикальное развертывание перетягиванием до верхней границы экрана. Отпустите кнопку мыши. Перетяните (не изменяя размера) окно вниз и снова вверх, одним движением. Отпустите кнопку мыши. Что произошло?
Окно должно быть развернутым во весь экран. В таком случае получается, что выполнено правило 1. Если следовать правилу 2, то окно должно остаться вертикально развернутым. Мы выяснили, что следование правилу 1 больше соответствует тому, как пользователь представляет себе этот сценарий действий.
И это только один пример того, какие решения нам приходилось принимать для каждого промежуточного состояния окна.
На протяжении всего процесса мы старались сохранить все тонкости в существующей модели. Небольшой пример, возможно, знакомый кое-кому из читателей: мы использовали несколько трюков в сценарии перетягивания заголовка окна из видимой области экрана. В предыдущих версиях Windows заголовок окна сворачивался примерно на полпути, – таким образом обеспечивалось достаточное пространство для того, чтобы окно можно было беспрепятственно двигать по экрану, в то же самое время по возможности оптимизировалось пространство по вертикали. В новой версии мы выбрали более осторожный и прямой вариант, когда при обратном разворачивании окна его заголовок остается полностью видимым. В этом варианте можно быть уверенным, что все окна всегда будут легко доступны для манипуляций с ними, в том числе если пользователь работает с сенсорным дисплеем. Для вертикально развернутого состояния окна мы решили сохранить полную видимость заголовка окна, что оставляет положительное общее впечатление.
Раскадровка и другие способы визуализации
Несомненно, диаграммы состояния – всего лишь один из способов получить картину окружающей действительности. Мы использовали различные способы увязать друг с другом отдельные аспекты AeroSnap, основываясь на узнаваемости, доступности и предсказуемости. Мы даже не стеснялись иногда использовать рисование символами ASCII, как видно из приведенного ниже изображения. Мы просто использовали любые инструменты, которые были под рукой в тот момент, для того, чтобы выразить нашу точку зрения. Раскадровки представляют собой отличный способ представить себе процесс использования – в большей степени, чем все остальное. Даже если это всего лишь один из примеров, мы хотим, чтобы вы с ним ознакомились.
Рис. 7. Детали функции показаны в процессе при помощи раскадровки
Случайное срабатывание
Кроме спора вокруг переходов окон из состояния в состояние, бурная дискуссия развернулась вокруг того, когда именно считать переход состоявшимся, иначе говоря, когда именно функция должна сработать. Мы много говорили о случайных срабатываниях, иначе говоря, о срабатывании функции без четкой команды.
Рис. 8. Aero Snap срабатывает от прикосновения курсора к верхней кромке экрана
С самого начала мы стремились добиться того, чтобы Aero Snap не следовал устоявшимся сценариям вроде сокрытия окна за пределами экрана. Вообще, мы не хотели, чтобы Aero Snap плохо отразился на привычном способе управления окнами. Именно поэтому пользователь должен коснуться именно границы экрана, а не границы окна, курсором, для того, чтобы функция сработала.
Однако в то время Aero Snap отличался от нынешнего, каким вы его знаете, весьма значительным, фундаментальным образом. В ранних сборках Aero Snap следовал модели мгновенного срабатывания. Стоило курсору оказаться в верхней части экрана, окно начинало разворачиваться еще тогда, когда осуществлялось его перетягивание, – даже если курсор еще продолжал движение. Обратное движение (непрерывным жестом) восстанавливало окно до нормального состояния. Нам нравилось этот подход, поскольку предпросмотр был довольно отчетливым, то есть предпросмотр представлял собой окно [в процессе трансформации], и отказ от принципа мгновенного срабатывания сделал бы происходящее на экране более скучным, тривиальным.
Поскольку наша функция спроектирована невидимой – отсутствует команда или кнопка для ее запуска – мы ожидали определенное число случайных срабатываний. Мы в каком-то смысле полагались на случайное срабатывание, которое должно было помочь заявить о существовании функции. Впрочем, по прошествии времени и работы с ранними сборками системы стало понятно, что количество случайных срабатываний превышает первоначально ожидавшееся, что вызвало у нас беспокойство. Телеметрия показала, что пользователи в два раза чаще отменяют действие, чем подтверждают его. В ходе изучения пользовательских действий мы наблюдали смущение пользователей, приводившее к такому отношению. Неужели касание окном кромки экрана тому причиной? Или что-то еще?
Вернемся к началу 2008 года. Что же нам делать? Отказаться от функции вообще? Был момент, когда мы едва не решились на это. Конечно, нам нравилось то, что мы придумали, но меньше всего мы хотели осложнять жизнь пользователям. Стремясь найти конструктивное решение, мы принялись совершенствовать дизайн с целью устранить недостатки. Было испробовано много вариантов. Некоторые из них были сосредоточены на повышении плавности переходов от состояния к состоянию, чтобы случайное срабатывание как минимум было плавным. Преимущества осторожности, лежащей в основе таких решений, были очевидны, но результат не удовлетворял нас в достаточной мере для того, чтобы считать это решением проблемы. В других вариантах мы пытались распознать намерения пользователей, основываясь на углах и направлениях движения в пограничной области экрана, на скорости перемещения. Как выяснилось, предсказывать это чрезвычайно сложно. Может быть, следует начинать преобразование после двойного касания пограничной области, подумали мы. Но нам казалось, что такой вариант отрицательно скажется на гибкости и плавности нашей модели.
В конце концов мы остановились на варианте, который вам известен. Пока кнопка мыши не отпущена, никакого перехода не происходит. Таким образом, эффект остается обратимым, и до самого последнего момента с окном ничего не происходит. В добавок мы снабдили функцию плавно анимированным предпросмотром и эффектом изменения формы курсора, которые помогут понять, что происходит. В этом случае пользователь сможет четче определять, когда функция должна сработать, и это позволит извлечь максимум выгоды из ее использования.
Все ли проблемы решены? Не стесняйтесь сообщить нам.
Вид и ощущение
Интересно оглянуться назад и понять, что мы создали элемент интерфейса без всякого интерфейса. Ни с того, ни с сего изменяется окно. Как это должно выглядеть, чтобы не было такого ощущения, что должно происходить?
К счастью, не все так ужасно. Мы уже определили, как должен выглядеть наш элемент на панели задач (мы назвали его «персонализация» и поговорим об этом позже, в другом сообщении). Мы установили, как будут выглядеть стеклянные панели для Aero Peek. Похожую визуализацию мы планировали и для наших предпросмотров. Но как должна тогда выглядеть стеклянная панель? После ряда экспериментов мы остановились на масштабированной анимации на основе превращений, которые претерпевает курсор. Мы также позаботились об анимации для переходов из состояния в состояние. Это можно увидеть собственными глазами в бета-версии: передвиньте окно к верхнему краю экрана, потом в сторону, одним движением, не отпуская кнопку мыши. Вы заметите плавное изменение предпросмотра. Почему мы уделили этому столько времени? Мы уверены, что мелочи, на самом деле, очень важны.
Рис. 9. Эффекты используются для обозначения срабатывания, стеклянные панели – для предварительного просмотра
В заключение добавлю, что некоторые из наших задумок касаются эффектов для обозначения срабатывания. Мы сделали их различимыми, но не очень яркими, чтобы они не противоречили остальным эффектам в Windows 7, среди которых обратная связь от прикосновения.
Комментариев (0) 04.06.2009 17:54
Что такое режим ХР?
После того, как мы объявили о существовании особого режима работы Windows 7 — т.н. «Режим ХР» — мы встретились с Джереми Чапменом во время саммита руководства Microsoft в Лас-Вегасе для того, чтобы выяснить, является ли режим ХР панацеей от проблем с совместимостью программ.
Вопрос: Привет, Джереми. Похоже, я в последнее время беру у тебя интервью довольно часто. Сегодня мы на саммите в Лас-Вегасе анонсировали Windows 7 Release Candidate и режим ХР как вариант, позволяющий приложениям работать внутри Windows XP-сеанса на компьютере с Windows 7. Что ты можешь сказать об этой технологии? Решит ли это все проблемы, с которыми сталкиваются пользователи, переходящие на новую систему с Windows XP или Internet Explorer 6?
Ответ: Режим ХР осуществляет «бесшовную» интеграцию виртуальной машины Windows XP на рабочий стол, примерно так, как мы видим это на примере Microsoft Enterprise Desktop Virtualization (MEDV). В результате чего вы видите программы в меню «Пуск» вашего основного компьютера, хотя на самом деле они работают в фоновой сессии виртуального ПК.
Эти приложения доступны в рабочей среде основной операционной системы, в то время как виртуальная машина остаётся невидимой.
Это позволяет даже обычным пользователям воспользоваться технологиями виртуализации. Изначально всё это звучит очень многообещающе, несмотря на то, что Virtual PC тоже всегда давал такую возможность.
Вопрос: Что значит «изначально»? Поясни, пожалуйста.
Ответ: На первый взгляд, это выглядит, как лёгкий способ исправить ситуацию с совместимостью. В маркетинговом, рекламном смысле это вообще можно представить себе как «серебряную пулю», ставящую последнюю точку в вопросе совместимости. Несмотря на позитивный опыт обычных пользователей, вопросы, которые приходится решать ИТ-персоналу, в основном мало изменились, — похожая ситуация имела место и с Virtual PC в последние 10 лет.
Вопрос: Каковы же эти проблемы, связанные с новой технологией?
Ответ: В первую очередь, это обслуживание двух операционных систем для каждого пользователя в реальном времени. Хотя мы можем автоматизировать и полностью настроить инициализацию основной ОС, отнюдь не так легко настроить инициализацию виртуальной ОС в соответствии с пользовательскими потребностями и ролями. Наконец, по умолчанию учётная запись виртуальной машины имеет права администратора на основной ОС.
Вопрос: Ясно. Существуют ли способы решения этих проблем для ИТ-профессионалов?
Ответ: Безусловно, MED-V (Microsoft Enterprise Desktop Virtualization) позволяет изолировать виртуальную среду от основной ОС. MED-V также предоставляет инструментарий административного контроля за состоянием и событиями виртуальной среды. Это детальный контроль за тем, как реальная и виртуальная среды взаимодействуют друг с другом. Вы можете даже определить, какие веб-сайты или корпоративные веб-приложения должны вызываться внутри браузера виртуальной машины (по умолчанию это Internet Explorer 6). MED-V также автоматически настраивает режим использования виртуальной машиной оперативной памяти в зависимости от того, сколько её установлено на ПК, так, чтобы пользователь не испытывал затруднений в работе. MED-V автоматически распространяет и устанавливает изменения во всех точках доступа, находящихся под его управлением. Наконец, MED-V работает и в Windows 7, и в Windows Vista, и не требует процессорной поддержки виртуализации.
Вопрос: Всё это звучит как прямая рекомендация использовать MED-V в качестве гибкого и настраиваемого решения, но является ли запуск Virtual PC и MED-V единственным вариантом для Windows 7?
Ответ: Если исходить из интересов наилучшей совместимости, наиболее удачным вариантом было бы использовать программы самым обычным способом, без всяких виртуализационных ухищрений, однако это требует от разработчиков переписать используемые программы. Если вы являетесь создателем кода и можете переписать его для устранения проблем — сделайте это. Если вы не можете изменить корпоративное приложение или не зависите от поддержки со стороны — попробуйте так называемые «заплатки совместимости» (shims), чтобы восстановить работоспособность программы. В конце концов, если все эти возможности недоступны для вас, попробуйте вариант виртуализации прежней операционной системы. Если прочие способы себя исчерпали и осталось лишь использовать режим ХР, рекомендую обратить внимание на советы, содержащиеся в инструментарии Windows XP Security Compliance Management, — как обезопасить виртуальную среду с помощью групповых политик и создать и управлять нужной конфигурацией с помощью System Center Configuration Manager.
Вопрос: Итак, для кого же предназначен режим ХР?
Ответ: Для индивидуальных пользователей, небольших компаний, чьи компьютеры не управляются централизованно, режим ХР представляет наиболее адекватный способ заставить несовместимые с новой системой приложения снова работать. Вам потребуется заново установить такие программы вручную, но их работоспособность будет обеспечена, по крайней мере, до тех пор, пока вы не переведёте на новую систему всё, что необходимо.
Вопрос: Итак, виртуальная среда предназначена для переходного периода, чтобы несовместимые приложения можно было использовать. Что следует учесть при работе с виртуальной Windows XP?
Ответ: Мы ещё не говорили об оборудовании. Как минимум, ваш процессор должен поддерживать аппаратную виртуализацию — Intel VT или AMDV — и вы должны включить её в BIOS вашего ПК. Большинство оборудования бизнес-класса, выпущенного в последние 2 — 3 года, несёт эти возможности на борту, но что касается нетбуков и более старых ПК, то они не отвечают этим требованиям. Кроме того, виртуальная машина интенсивно использует оперативную память, поэтому вам, вероятно, потребуется ПК с 2 или более гигабайт оперативной памяти.
Вопрос: Хороший совет. Где можно подробнее узнать о режиме Windows XP?
Ответ: Прочтите сообщение Скотта Вудгейта (Scott Woodgate) в блоге Windows Team и его Вопросы и Ответы на PressPass. Также можно ознакомиться с Q&A по Virtual PC на Springboard.
Ответ: Спасибо за то, что уделил нам время, Джереми, и до встречи в Редмонде на будущей неделе!
Стивен Л. Роуз (Stephen L. Rose)
Комментариев (0) 10.06.2009 15:53
