Недавно мы портировали на Windows 8 относительно объемное бизнес приложение — редактор диаграмм, флоу чартов и другой деловой графики. Изначально этот редактор был написан под платформу Silverlight, но мы его переписали под Windows Runtime и успешно разместились с ним в Windows 8 Store. К сожалению, стандартных контролов нам очень не хватало, поэтому попутно пришлось ещё написать свою библиотеку контролов. И теперь мы готовы поделиться опытом. В этой статье собран ряд нюансов разработки приложений под Windows 8 — от проектирования интерфейса пользователя до технических деталей по работе с DirectX.
С технической точки зрения осуществить портирование оказалось на удивление легко. Хотя нам и пришлось решить некоторые проблемы с совместимостью API (о которых мы надеемся рассказать в следующих постах), большая часть кода на C# и XAML-разметка потребовали только очень простых преобразований, таких, как переименование пространств имен и некоторых членов классов.
Главной же проблемой для нас явилась переработка интерфейса пользователя в стиле Microsoft Design Language (ранее известном как Windows Store UI, ранее известном как Modern UI, ранее также известном как Metro UI). Соответствие этому стилю является как обязательным требованием для прохождения сертификации при размещении приложения в магазине, так и просто правилом хорошего тона, без выполнения которого приложение будет выглядеть чужеродным и непонятным для пользователя.
Если вы смотрели материалы и презентации по принципам построения нового UI, то наверняка обратили внимание, что все примеры достаточно просты с точки зрения интерфейса. Они посвящены приложениям, которые предназначаются исключительно для потребления контента. Поэтому если вы разрабатываете Line-Of-Business приложение, то практически остаетесь один на один с сырыми guidelines, провозглашающими очень красивые принципы типа: «Always put content before chrome», которые совершенно непонятно как применять в реальной жизни.
В этой статье, мы попробуем на примере нашего приложения, проиллюстрировать некоторые дизайнерские решения, которые мы приняли при переходе на новую платформу.
Как уже упоминалось, основной принцип Microsoft Design Language: «Always put content before chrome». Ваше приложение должно позволить пользователю максимально сосредоточится на данных, управляющие элементы не должны его отвлекать. В нашем редакторе мы решили отвести весь экран для отображения редактируемого документа и показывать управляющие элементы только при необходимости.
Посмотрите, насколько выросло пространство, отводимое пользователю непосредственно для работы с документом. Особенно это ценно при работе на планшете, где физические размеры экрана достаточно малы.
Еще один из основополагающих принципов нового UI — «Design for a touch-first experience», что значит «проектируйте все так, чтобы удобно было тыкать пальцем, тогда и мышкой-то уж как-нибудь попадут». Естественно, это накладывает ряд ограничений. Для нас, при разработке графического редактора, наиболее актуальными оказались следующие:
Вот как изменился набор элементов управления выделенным объектом при переходе на новую версию:
В Windows 8 навигацию между равнозначными элементами, которыми несомненно являются открытые для редактирования документы, полагается размещать на верхнем AppBar. AppBar-ы — это такие горизонтальные элементы управления, появляющиеся на экране при скольжении пальца с верхней или нижней кромки экрана на тачскрине, или при щелчке правой кнопкой мыши.
Команды для манипуляции документами также полагается размещать на AppBar-е, причем справа:
Некоторые команды, выполняемые в контексте над выделенными объектами, также можно разместить на нижнем AppBar-е. Обратите внимание, что контекстные команды положено размещать слева, а AppBar должен всплывать автоматически в тех случаях, когда команда становиться актуальной. Например, при выделении объекта соответствующего типа.
В нашем приложении, такое решение использовано для управления режимом выделения множества объектов. В десктопной версии приложения для выделения нескольких объектов достаточно удерживать нажатой клавишу Shift, но в планшетном варианте физическая клавиатура может быть недоступна. Поэтому для одновременного выделения нескольких объектов пришлось предусмотреть специальный режим. Для выхода из этого режима используется контекстный AppBar:
Самым интересным новым элементом является радиальное меню. Это оригинальная замена классического контекстного меню, используется в Microsoft OneNote. Выглядит оно вот так:
Помимо обычных команд, на подуровни этого меню можно помещать достаточно сложные элементы управления, такие как элемент выбора цвета и ползунки:
Очевидные плюсы этого элемента — необычный привлекательный дизайн и минимальное расстояние до каждой команды от места первоначального нахождения указателя курсора (или пальца при работе с тач-скрином). Кроме этого, данный элемент выглядит нормально только в случае, если на одном уровне разместилось не более 8-ми команд. Это заставляет дизайнера интерфейса избегать перегруженных функциями меню и более тщательно проектировать взаимодействие с пользователем. А психологам давно известно, что сознание может эффективно работать не более чем с 7-9 элементами одновременно.
К сожалению, этот замечательный элемент управления отсутствует в стандартной библиотеке. Поэтому нам пришлось написать его самим. В нашей программе он полностью заменил классические контекстные меню и взял на себя часть команд, которые были расположены на риббоне.
Все остальные управляющие элементы мы разместили на всплывающей панели, расположенной в правой части экрана:
Ряд действий (вызов диалога настроек, печать и т.п.) в новом интерфейсе необходимо делать с помощью Charms Bar, который вызывается скольжением пальца с правой кромки экрана. Фактически это аналог описанного выше AppBar, на котором расположены функции управления системой и действия, выполняющиеся однотипно для всех приложений.
Вот как выглядит вызов диалога печати:
Вне всяких сомнений, одной из обязательных возможностей редактора диаграмм должна быть возможность экспорта результата в какой-нибудь графический формат. Под Silverlight это делалось очень просто — можно было взять всё визуальное дерево и отрендерить его в картинку. Почему-то в WinRT такую функциональность убрали. В частности, больше нет метода WriteableBitmap.Render(). Есть класс XamlUIPresenter с помощью которого наверно это как-то можно сделать, но с его использованием в Windows Store не попасть.
Была идея реализовать экспорт через HTML5, но возможностей его растрового canvas-а не хватило для наших векторных потребностей. Поэтому у нас остался только одит путь — использовать DirectX. Как известно, единственный вменяемый способ использовать DirectX под C# — это SharpDX. Эта замечательная open-source библиотека предоставляет полное DirectX API для платформы .NET. Для этих целей есть и другие продукты (SlimDx, MDX и т.п.), но создание нормальных приложений для Windows 8 поддерживает только SharpDx. Если вы раньше никогда не работали с этой библиотекой, то примеры и документация вам помогут. Если вам нужно просто создать 2D-изображение и сохранить его в виде графического файла, то вам пригодится шаблон со Stackoverflow.
Стоит иметь ввиду ещё одну вещь. Хоть авторы SharpDx и хвастаются что все их сборки успешно проходят сертификацию, это не совсем так. Когда мы первый раз пытались пройти сертификацию, то получили сообщения такого типа:
Поэтому старайтесь избегать использования каких-то редких методов. Но если вы всё-таки решили использовать какую-то экзотическую функциональность, то лучше сначала убедиться, что она пройдёт сертификацию в Windows Store.
Как видите, создание версии бизнес-приложения для Windows Store потребует значительной переработки пользовательского интерфейса. К счастью, принятый Microsoft-ом стиль (все очень-очень такое квадратное и со сплошными заливками) значительно облегчает эту задачу для программиста.
С технической точки зрения осуществить портирование оказалось на удивление легко. Хотя нам и пришлось решить некоторые проблемы с совместимостью API (о которых мы надеемся рассказать в следующих постах), большая часть кода на C# и XAML-разметка потребовали только очень простых преобразований, таких, как переименование пространств имен и некоторых членов классов.
Главной же проблемой для нас явилась переработка интерфейса пользователя в стиле Microsoft Design Language (ранее известном как Windows Store UI, ранее известном как Modern UI, ранее также известном как Metro UI). Соответствие этому стилю является как обязательным требованием для прохождения сертификации при размещении приложения в магазине, так и просто правилом хорошего тона, без выполнения которого приложение будет выглядеть чужеродным и непонятным для пользователя.
Если вы смотрели материалы и презентации по принципам построения нового UI, то наверняка обратили внимание, что все примеры достаточно просты с точки зрения интерфейса. Они посвящены приложениям, которые предназначаются исключительно для потребления контента. Поэтому если вы разрабатываете Line-Of-Business приложение, то практически остаетесь один на один с сырыми guidelines, провозглашающими очень красивые принципы типа: «Always put content before chrome», которые совершенно непонятно как применять в реальной жизни.
В этой статье, мы попробуем на примере нашего приложения, проиллюстрировать некоторые дизайнерские решения, которые мы приняли при переходе на новую платформу.
Content Before Chrome
Как уже упоминалось, основной принцип Microsoft Design Language: «Always put content before chrome». Ваше приложение должно позволить пользователю максимально сосредоточится на данных, управляющие элементы не должны его отвлекать. В нашем редакторе мы решили отвести весь экран для отображения редактируемого документа и показывать управляющие элементы только при необходимости.
Посмотрите, насколько выросло пространство, отводимое пользователю непосредственно для работы с документом. Особенно это ценно при работе на планшете, где физические размеры экрана достаточно малы.
Редактирование графических примитивов
Еще один из основополагающих принципов нового UI — «Design for a touch-first experience», что значит «проектируйте все так, чтобы удобно было тыкать пальцем, тогда и мышкой-то уж как-нибудь попадут». Естественно, это накладывает ряд ограничений. Для нас, при разработке графического редактора, наиболее актуальными оказались следующие:
- Интерактивные элементы должны быть банально больше по размеру, чтобы компенсировать меньшую точность тач-интерфейса по сравнению с мышиным.
- Нет режима подсветки. Если в классических интерфейсах можно было показывать управляющие элементы при наведении курсора мыши на объект, то в тач-интерфейсе на объект необходимо кликнуть. Также нельзя использовать изменения формы курсора для того, чтобы подсказать пользователю тип взаимодействия, так как никакого курсора в тач-интерфейсе нету.
- Функционал действий мыши можно значительно расширить, используя мышь в сочетании с зажатыми Ctrl/Shift/Alt. В новой парадигме приходится для каждого действия использовать отдельный управляющий элемент.
- На пальцах нет не только колесика, но еще и правой кнопки. Зато можно касаться экрана несколькими пальцами сразу.
Вот как изменился набор элементов управления выделенным объектом при переходе на новую версию:
| Номер элемента | Зачем нужен | Desktop | Windows 8 |
|---|---|---|---|
| 1 | Управляет размером | Был маленький | Стал большой |
| 2 | Управляет углом поворота | Был маленький | Стал большой |
| 3 | Управляет разными геометрическими свойствами | Был маленький | Стал большой |
| 4 | Служит для соединения элементов | Контекстно появлялся над объектом под курсором | Относится только к выделенному элементу |
| 5 | Служит для удаления выделенных элементов | Можно было нажать на клавишу Del | Появился новый элемент |
| 6 | Служит для создания и перемещения копии | Можно было просто тащить элемент с зажатым Ctrl | Появился новый элемент |
| 7 | Служит для вызова контекстного меню | Можно было кликнуть правой кнопкой мыши | Появился новый элемент |
Навигация и работа с документами
В Windows 8 навигацию между равнозначными элементами, которыми несомненно являются открытые для редактирования документы, полагается размещать на верхнем AppBar. AppBar-ы — это такие горизонтальные элементы управления, появляющиеся на экране при скольжении пальца с верхней или нижней кромки экрана на тачскрине, или при щелчке правой кнопкой мыши.
Команды для манипуляции документами также полагается размещать на AppBar-е, причем справа:
Контекстные действия
Некоторые команды, выполняемые в контексте над выделенными объектами, также можно разместить на нижнем AppBar-е. Обратите внимание, что контекстные команды положено размещать слева, а AppBar должен всплывать автоматически в тех случаях, когда команда становиться актуальной. Например, при выделении объекта соответствующего типа.
В нашем приложении, такое решение использовано для управления режимом выделения множества объектов. В десктопной версии приложения для выделения нескольких объектов достаточно удерживать нажатой клавишу Shift, но в планшетном варианте физическая клавиатура может быть недоступна. Поэтому для одновременного выделения нескольких объектов пришлось предусмотреть специальный режим. Для выхода из этого режима используется контекстный AppBar:
Радиальные меню
Самым интересным новым элементом является радиальное меню. Это оригинальная замена классического контекстного меню, используется в Microsoft OneNote. Выглядит оно вот так:
Помимо обычных команд, на подуровни этого меню можно помещать достаточно сложные элементы управления, такие как элемент выбора цвета и ползунки:
Очевидные плюсы этого элемента — необычный привлекательный дизайн и минимальное расстояние до каждой команды от места первоначального нахождения указателя курсора (или пальца при работе с тач-скрином). Кроме этого, данный элемент выглядит нормально только в случае, если на одном уровне разместилось не более 8-ми команд. Это заставляет дизайнера интерфейса избегать перегруженных функциями меню и более тщательно проектировать взаимодействие с пользователем. А психологам давно известно, что сознание может эффективно работать не более чем с 7-9 элементами одновременно.
К сожалению, этот замечательный элемент управления отсутствует в стандартной библиотеке. Поэтому нам пришлось написать его самим. В нашей программе он полностью заменил классические контекстные меню и взял на себя часть команд, которые были расположены на риббоне.
Всплывающие панели
Все остальные управляющие элементы мы разместили на всплывающей панели, расположенной в правой части экрана:
Сharms (чудо-кнопки)
Ряд действий (вызов диалога настроек, печать и т.п.) в новом интерфейсе необходимо делать с помощью Charms Bar, который вызывается скольжением пальца с правой кромки экрана. Фактически это аналог описанного выше AppBar, на котором расположены функции управления системой и действия, выполняющиеся однотипно для всех приложений.
Вот как выглядит вызов диалога печати:
DirectX
Вне всяких сомнений, одной из обязательных возможностей редактора диаграмм должна быть возможность экспорта результата в какой-нибудь графический формат. Под Silverlight это делалось очень просто — можно было взять всё визуальное дерево и отрендерить его в картинку. Почему-то в WinRT такую функциональность убрали. В частности, больше нет метода WriteableBitmap.Render(). Есть класс XamlUIPresenter с помощью которого наверно это как-то можно сделать, но с его использованием в Windows Store не попасть.
Была идея реализовать экспорт через HTML5, но возможностей его растрового canvas-а не хватило для наших векторных потребностей. Поэтому у нас остался только одит путь — использовать DirectX. Как известно, единственный вменяемый способ использовать DirectX под C# — это SharpDX. Эта замечательная open-source библиотека предоставляет полное DirectX API для платформы .NET. Для этих целей есть и другие продукты (SlimDx, MDX и т.п.), но создание нормальных приложений для Windows 8 поддерживает только SharpDx. Если вы раньше никогда не работали с этой библиотекой, то примеры и документация вам помогут. Если вам нужно просто создать 2D-изображение и сохранить его в виде графического файла, то вам пригодится шаблон со Stackoverflow.
Стоит иметь ввиду ещё одну вещь. Хоть авторы SharpDx и хвастаются что все их сборки успешно проходят сертификацию, это не совсем так. Когда мы первый раз пытались пройти сертификацию, то получили сообщения такого типа:
API D3DCompile in d3dcompiler_45.dll is not supported for this application type. SharpDX.D3DCompiler.dll calls this API.
API D3DCompile2 in d3dcompiler_45.dll is not supported for this application type. SharpDX.D3DCompiler.dll calls this API.
API D3DCompileFromFile in d3dcompiler_45.dll is not supported for this application type. SharpDX.D3DCompiler.dll calls this API.
...
Поэтому старайтесь избегать использования каких-то редких методов. Но если вы всё-таки решили использовать какую-то экзотическую функциональность, то лучше сначала убедиться, что она пройдёт сертификацию в Windows Store.
Заключение
Как видите, создание версии бизнес-приложения для Windows Store потребует значительной переработки пользовательского интерфейса. К счастью, принятый Microsoft-ом стиль (все очень-очень такое квадратное и со сплошными заливками) значительно облегчает эту задачу для программиста.
