Многие компании задумываются о разработке мобильных клиентов для своих сервисов для Windows Phone и Windows 8. В большинстве случаев мобильные клиенты для iOS/Android уже написаны и задача компании — портировать их на мобильные платформы Windows. О том, с какими вопросами / проблемами / особенностями могут столкнуться компании и разработчики мне бы хотелось поговорить в этой статье.
Сделайте также!
Самая частая постановка задачи, с которой нам приходилось сталкиваться, звучит таким образом: вот клиент для Android/iOS, сделайте так же.
Это самая распространенная ошибка, которая в долгострочной перспективе может может стоить разработчикам большой головной боли, а заказчику — непредвиденных затрат.
Если говорить в целом, то разработка (хорошего) мобильного приложения должна состоять из нескольких важных этапов:
постановка задачи;
создание прототипа. Это может быть как бумажный вариант в виде схемы взаимодействий или приложение-заглушка с тестовыми данными — не важно. В процессе создания прототипа происходит процесс нахождения оптимального варианта реализации основных сценариев работы, нахождение структурных и логических проблем, обсуждение юзабилити приложения;
работа над графикой и дизайном приложения;
разработка приложения;
работа над оптимизацией скорости работы приложения;
тестирование;
подготовка для публикации приложения в магазине;
публикация приложения;
сбор аналитики и получение обратной связи;
исправление недочетов и выпуск обновлений.
Как ни странно, разработка занимает важное, но не ключевое значение. Также могу с уверенностью сказать, что внешний вид тоже не всегда — важный компонент. Более важным является юзабилити, соответствие гайдлайнам и удобство выполнения основных сценариев (у среднего приложения их должно быть не больше пяти).
Главный совет: проектируйте приложение под конкретную платформу. Очень важно понимать, что экономия ресурсов для проектирования «нативных» интерфейсов может обернуться негативно для их создателей или заказчиков. Стандартные решения для одной платформы являются абсолютно не стандартными для другой.
Давайте рассмотрим несколько примеров. Например, приложение Корреспондент для Windows Phone:
Давайте сравним эти скриншоты с скриншотами для iOS и Android:
Думаю, что если убрать верхнюю панель из скриншотов, то неискушенный пользователь вряд ли сможет различить, для какой платформы было разработано приложение.
Желание компаний повысить узнаваемость бренда понятна. Но не ценой юзабилити приложения для конечного пользователя. Поэтому лучше предоставить пользователю нативное приложение для конкретной платформы.
Сравните с приложением LinkedIn:
И брендирование присутствует и сразу понятно, для какой платформы сделано приложение.
К этому же пункту можно отнести необходимость использования стандартных элементов управления, даже несмотря на то, что есть большой соблазн сделать «не как у всех».
Например, приложение UC Browser, содержит довольно таки интересное решение для навигации, но совершенно не вписывается в общий подход. При нажатии на кнопку открытия меню появляется вот такая панель с табами внутри application bar:
Я до сих пор не решил, насколько это было оправданно или нет (с точки зрения разработчика и пользователя), но сам факт, что мне пришлось задумываться об этом, говорит о том, что проектирование, возможно, нужно было сделать по другому.
Что важно знать о интерфейсе Modern UI aka Metro
Windows Phone и Windows 8 аутентично цифровые плафтормы в отличии, от, например iOS. Что это значит легко объяснить на примере клнижной полки для iOS, где поведение человека при чтении журнала или книги «имитируется» из реальной жизни — мы идем на книжную полку, достаем журнал, открывает и листаем. Для Windows Phone этот процесс выглядит совершенно оторванным от «реальной» жизни и изначально ориентирован на цифровой мир, где такого понятия как «книжная полка» нет.
Второе отличие от iOS/Andoid — акцент на контенте и ориентация на действие. В Windows Phone и Windows 8 номера телефонов и электронные адреса будут написаны маленькими шрифтами, а действия «позвонить» или «отправить email» — большими. Большие шрифты и отступы — еще одна фишка Metro. Это тоже нужно учитывать при проектировании интерфейсов.
Другие особенности платформ
Перед планированием приложений на Windows Phone и Windows 8 необходимо учитывать несколько аспектов.
1. Android, в большей степени, завязан на экосистему Google, iOS — на экосистему Apple, Windows Phone и Windows 8, следовательно, на экосистему Microsoft. Это может быть как и преимуществом, так и недостатком. Например, вам будет проще работать с офисными документами, но вместо тесной интеграции с dropbox вам предложат использовать skydrive.
2. Ограничения платформы. Windows Phone достаточно строгая платформа. Есть четкие ограничения на время запуска приложения, размеры загружаемых файлов в зависимости от типа интернет соединения, количества фоновых операций и т.д. Из-за подобных ограничений даже «родной» для Windows Phone Skype не всегда работает так, как этого ожидают от полноценного мессенджера.
3. Специфические требования к сценариям в Windows 8. В Windows 8 есть так называемые контракты — Search, Share и другие, с помощью которых выполняются такие сценарии как «поиск по приложению», «поделиться чем-то с социальных сетях или открыть файл в другом приложени». Отдельно необходимо сказать о Settings и Share — в Windows 8 они должны быть в боковой панели и только в ней. Дублирование функциональности внутри приложения очень не желательно.
4. Навигационная модель в Windows Phone и Windows 8 отличаются. Если в Windows Phone навигация, в основном, линейная (нелинейная навигация разрешается лишь в исключительных случаях и тщательно тестируется), то Windows 8 более лоялен к навигационной модели. Более того, вам необходимо задуматься над возможностью быстрого доступа к основным экранам приложения из любого экрана.
5. Windows Phone 7.5 vs. Windows Phone 8. Нужно помнить, что сейчас есть несколько основных версий Windows Phone:
Mango — Windows Phone 7.5 (512 МБ памяти);
Mango — Windows Phone 7.8 (512 МБ памяти) — еще не вышло обновление;
Tango — Windows Phone 7.5 (256 МБ памяти);
Apollo — Windows Phone 8.
Если вы решили поддерживать 7.x платформу, то вам необходимо подумать, будете ли вы поддерживать Tango устройства (бюджетные), которые более чувствительны к потребляемой приложениями памяти. Если же вам нужны NFC или in-app purchases (IAP), то вам необходимо сразу ориентироваться на Windows Phone 8.0 или поддерживать две версии приложения (7.x и 8.x).
Кроссплатформенность между Windows Phone 8 и Windows 8
Несмотря на то, что Windows Phone поддерживает NDK, полностью на С++ нельзя создавать приложения. Вы можете создавать компоненты, работать с Direct-X и подключать внешние библиотеки, но не-игровые приложения все также нужно писать на C#/VB.NET (работа с XAML возможна только с помощью этих языков).
Приложения для Windows 8 можно писать в том числе и на С++. Для Windows 8 также является важным вопрос компиляции для различных архитектур — x32, x64, ARM. Этот вопрос достаточно объемный, возможно, отдельно напишем об этом статью.
Создать 100% кроссплатформенное приложение для Windows Phone и Windows 8 нельзя, несмотря на то, что у них общее ядро. Навигация, UI компоненты, работа с камерой, speech sdk, навигационная модель — это те вещи, которые отличаются. Сторонние библиотеки также должны быть скомпилированы под конкретную платформу из-за чего для Windows 8 не все привычные библиотеки будут доступны.
И, опять таки, отличие между Windows Phone и Windows 8 — в Windows 8 работа с локальным хранилищем немного отличается + отсутствует SQL CE (движок базы данных), из-за чего data layer также необходимо переписывать, а лучше всего изначально абстрагироваться от конкретных реализаций движка хранения данных.
Спасибо за внимание!
P.S. Если у вас есть интересные предложения по следующим темам публикаций — просьба сообщить мне любым удобным способом.
admin 
АДМИНКА
НАВИГАЦИЯ
СВЯЗЬ С НАМИ
РАДИО
ЛУЧШИЕ ЧАТЫ
СЧЁТЧИКИ