Песочница →
Как адаптировать сервис под мобильные платформы
С тем, что мобильный и планшетный рынки является одними из самых быстрорастущих, сегодня не будет спорить никто. Это хороший момент, у многих есть шанс переломить ситуацию и выиграть второй раунд, а для многих нерасторопных есть все шансы остаться только в большом вебе.
В связи с этим появились даже радикальные подходы, когда предлагается делать дизайн в первую очередь для мобильных платформ, а потом уже задумываться о большом вебе (http://www.lukew.com/resources/mobile_first.asp). Это красивая концепция, но суровая правда жизни в том, что многие сервисы уже существуют в веб варианте и им необходимо шагнуть в мобильный мир.
Давайте разберемся как адаптировать существующий сервис под мобильные платформы. Сразу оговорюсь, что планшеты оставляем за скобками, там разговор особый. Второй момент мы берем в расчет современные touch телефоны.
В данной статье мы не рассматриваем собственно графический дизайн приложения. Рассматриваем этап, который предшествует работе с дизайнером интерфейса.
В первую очередь, мобильные вариант отличается пользовательскими целями и сценариями. Мобильный сервис это практически всегда про здесь и сейчас. Что будет завтра или было вчера вас интересует заметно реже:
Убирайте из первого релиза все, что касается историй планирования, долгого просмотра, выбора и т.д. В комментариях, будут крики, что неправда, я почти все делаю на мобильном. Это, конечно, правда для небольшой части аудитории. И для первого релиза, эти сценарии лучше рассмотреть и отложить на будущее. Когда их реализуете в 1.0+ не забудьте сравнить частоту их использования в сравнении с текущими.
Во вторую очередь, телефон это еще куча дополнительной информации о пользователе:
Модные LBS сервисы, скорее имеют смысл, не как отдельные сервисы, а как определенное дополнение к любому существующему сервису. Используйте положение пользователя, чтобы отфильтровать ненужную ему информацию и не задавать ему глупых вопросов.
Телефон рядом с хозяином, занчит вы всегда можете напомнить ему о чем-то важном и он это заметит. Например, очень полезно напомнить, о том, что завтра резкое похолодание или дождь, если сервис погодный. Телефон это лучший вариант для напоминаний сегодня.
Про запись фоток, голоса — это скорее всего будут совершенно отдельные сценарии, которых нет в большом варианте вашего сервиса. Это действительно целое направление для новых возможностей.
Подумайте на досуге, ведь еще полно всяких интересных штук: акселерометр, альтиметр, гироскоп и т.д.
В-третьих: интернет. В мобильном он медленнее, значительно медленнее и его может не быть.
Халявного инета не будет, стоит уехать в другую область или страну, вас ждет роуминг. И к сожалению помрет он не скоро. Но даже если у вас полностью оплачен сервис, инет начинает пропадать даже в пределах больших городов. Современные базовые станции часто обеспечивают очень плохой сигнал в закрытых дворах даже в центре города. Про загородные трассы молчу.
Отсюда вывод ваше приложение должно выживать без интернета. Пусть не на 100% функциональности, но приложение должно остаться полезным.
Последний момент, сервис остается один. Мобильный вариант это продолжение веба, веб продолжение мобильного. Пользователь в этом случае пользуется одним сервисом, а не двумя разными. Сервис должен помнить, где остановился пользователь, что смотрел или искал последним, что отложил себе в закладки. Рассмотрите сценарии, которые затрагивают обе платформы. Без этой связки ваш сервис уже сегодня будет серьезно уступать конкурентам.
Итог:
Я буду очень благодарен любым дополнениям или комментариям по этой теме.
В связи с этим появились даже радикальные подходы, когда предлагается делать дизайн в первую очередь для мобильных платформ, а потом уже задумываться о большом вебе (http://www.lukew.com/resources/mobile_first.asp). Это красивая концепция, но суровая правда жизни в том, что многие сервисы уже существуют в веб варианте и им необходимо шагнуть в мобильный мир.
Давайте разберемся как адаптировать существующий сервис под мобильные платформы. Сразу оговорюсь, что планшеты оставляем за скобками, там разговор особый. Второй момент мы берем в расчет современные touch телефоны.
В данной статье мы не рассматриваем собственно графический дизайн приложения. Рассматриваем этап, который предшествует работе с дизайнером интерфейса.
В первую очередь, мобильные вариант отличается пользовательскими целями и сценариями. Мобильный сервис это практически всегда про здесь и сейчас. Что будет завтра или было вчера вас интересует заметно реже:
- в мобильном вы смотрите погоду на сегодня, чтобы решить брать зонт или нет
- вы читаете текущую почту или сообщения, а не копаетесь в истории
- вы смотрите какие пробки сейчас, а не планируете как добраться завтра в гости
Убирайте из первого релиза все, что касается историй планирования, долгого просмотра, выбора и т.д. В комментариях, будут крики, что неправда, я почти все делаю на мобильном. Это, конечно, правда для небольшой части аудитории. И для первого релиза, эти сценарии лучше рассмотреть и отложить на будущее. Когда их реализуете в 1.0+ не забудьте сравнить частоту их использования в сравнении с текущими.
Во вторую очередь, телефон это еще куча дополнительной информации о пользователе:
- вы знаете, где он находится с хорошей точностью
- вы знаете, что телефон всегда рядом с хозяином (ну Андроид еще иногда у розетки)
- вы можете спокойно снимать фотки и записывать голос
Модные LBS сервисы, скорее имеют смысл, не как отдельные сервисы, а как определенное дополнение к любому существующему сервису. Используйте положение пользователя, чтобы отфильтровать ненужную ему информацию и не задавать ему глупых вопросов.
Телефон рядом с хозяином, занчит вы всегда можете напомнить ему о чем-то важном и он это заметит. Например, очень полезно напомнить, о том, что завтра резкое похолодание или дождь, если сервис погодный. Телефон это лучший вариант для напоминаний сегодня.
Про запись фоток, голоса — это скорее всего будут совершенно отдельные сценарии, которых нет в большом варианте вашего сервиса. Это действительно целое направление для новых возможностей.
Подумайте на досуге, ведь еще полно всяких интересных штук: акселерометр, альтиметр, гироскоп и т.д.
В-третьих: интернет. В мобильном он медленнее, значительно медленнее и его может не быть.
Халявного инета не будет, стоит уехать в другую область или страну, вас ждет роуминг. И к сожалению помрет он не скоро. Но даже если у вас полностью оплачен сервис, инет начинает пропадать даже в пределах больших городов. Современные базовые станции часто обеспечивают очень плохой сигнал в закрытых дворах даже в центре города. Про загородные трассы молчу.
Отсюда вывод ваше приложение должно выживать без интернета. Пусть не на 100% функциональности, но приложение должно остаться полезным.
Последний момент, сервис остается один. Мобильный вариант это продолжение веба, веб продолжение мобильного. Пользователь в этом случае пользуется одним сервисом, а не двумя разными. Сервис должен помнить, где остановился пользователь, что смотрел или искал последним, что отложил себе в закладки. Рассмотрите сценарии, которые затрагивают обе платформы. Без этой связки ваш сервис уже сегодня будет серьезно уступать конкурентам.
Итог:
- разделите сценарии, что для мобильного, а что для большого сервиса.
- подумайте, какие сценарии теперь затрагивают обе платформы
- какая информация из мобильного поможет сервису быть умнее
- подумайте про мир с плохим интернетом
- делайте как можно простой сервис, не добавляйте информацию или действия, если не уверены на 100% что они необходимы
Я буду очень благодарен любым дополнениям или комментариям по этой теме.
04.03.2012 22:55+0400