Насколько я помню, в случае с сервером, приложение сначала запрашивает у сервера только идентификаторы продуктов, а потом по этим идентификаторам забирает информацию о них с сервера Apple и показывает их пользователю. Таким образом происходит проверка соответствия того, что содержится на вашем сервере тому, что вы внесли через iTunes Connect.
По-поводу меню для нескольких разнородных объектов. Считаю, что надо выводить только общие для всех элементов команды. Чтобы победить проблему изменяющегося меню, можно показывать стандартное для конкретного элемента контекстное меню, только с задизейбленными «необщими» позициями. ИМХО, такая практика используется и достаточно успешно.
Чем больше размышляю на эту тему, тем меньше вижу потребности в таком сервисе в этом виде:
в тех немногих городах России (больших и малых), где пользовался такси, машина приходит моментально в любое время дня и ночи. В Европе такси на каждом шагу и телефонный заказ отрабатывает на 100%.
Остаются пара городков (Москва, возможно Питер), где система может оправдать себя.
Вот, ребята из Сан-Франциско реализовали такое, но позиционируют сервис другим образом:
1. Заказ престижных машин.
2. Оплата поездки через приложение.
Эти фишки выдвинуты у них на первые места и они работают как luxury-service, поскольку конкурировать с «народным» сервисом им нечем.
В Европе точно так же. Звонишь — через 10 мин подъезжает такси со счетчиком. Тарифы, правда, повыше: посадка ок. 2 евро, и ок. 1 евро — километр. Ну и насчет электромобилей я не слыхал.
Прикол в том, что, в отличие от фотошопа, Expression Blend является частью IDE и не позволит соорудить такое, что потом невозможно будет закодировать. В этом большое преимущество таких средств прототипирования.
Ну а в целом, меня укрепляет мысль о том, что вокруг стали появляться инструменты разработки для дизайнеров. Как вы думаете, для чего они, как не для ранних прототипов? И если разработчики IDE включают рабочее место дизайнера в среду, значит, может быть расчитывают на какой-то тренд?
В том-то и дело, что прототип сейчас можно сделать без программирования. Инструментом, сильно напоминающим по подходам и сложности, к примеру, фотошоп или иллюстратор.
Логика простая:
1. Клиент передает функциональные требования.
2. Команда разработчиков превращает это в ТТ и начальную версию ТЗ.
3. Дизайнер UI воплощает это в первый прототип.
4. Прототип «крутится» в команде, помогая исправлять ТЗ. Прототип, естественно, тоже меняется.
5. Прототип тестится и обсуждается с заказчиком.
6. ТЗ фиксируется.
Вопрос в том, сколько времени и ресурсов понадобится на весь цикл. У меня ощущение, что недели будет достаточно.
Не очень понимаю распределение функций. Мне кажется так:
1. Графический дизайнер. Внешний вид, цветовая гамма, иконки, брендинг.
2. Дизайнер UI. Удобство использования, общая логика работы с интерфейсами приложения, эргономика элементов управления и пр.
3. Архитектор. Структура данных, общая архитектура приложения.
4. Разработчик. Код. Программная реализация всего, что наворотили Архитектор с Дизайнером UI.
Поясните, кто такой «дизайнер взаимодействия», может тогда все встанет на свои места.
Даже не думал предлагать замещать «подготовку документации прототипированием»! Просто высказываю предположение, что РАБОТАЮЩИЙ прототип очень сильно может помочь подготовить качественное ТЗ, покажет ошибки и заблуждения разработчиков и клиентов и внесет ясность в то, каким приложение будет на выходе в самом начале проекта.
Все правильно. Вот если ТЗ попадет к дизайнеру UI на этапе первых версий, он, в процессе создания прототипа, может найти там ошибки и принять участие в дополнении этого документа. И прототип в этом случае является рабочим инструментом для продумывания ТЗ всеми заинтересованными лицами проекта.
Да, это не то, что хотелось бы обсудить ;-).
Графический дизайн — чтобы было красиво, дизайн интерфейса — чтобы было удобно. Удобно — это чтобы пользователь быстро выполнил все задачи, которые хотел выполнить в приложении.
В прототипе пользователь видит, какие задачи он может решить с помощью приложения и насколько быстро/удобно.
Если у прототипа есть красивый графический дизайн — это замечательно, но можно и без него обойтись на начальном этапе.
В том-то и дело, что современные среды разработки (IDE) обеспечивают рабочее место, в том числе и дизайнеру интерфейсов — человеку, далекому от алгоритмов и программирования, зато владеющему вопросами usability, эргономики приложения. В процессе проектирования интерфейса он должен сформировать ключевые блоки приложения, распределить функционал по экранам и детализировать по каждому экрану функциональные и информационные элементы. О графическом дизайне речи не идет и, по-хорошему, UI-дизайнер не должен им заниматься.
Я имел в виду разработку мобильных приложений. Конкретнее, не веб-приложений, а native applications, работающих на смартфоне. Собственно, глобальные проекты, в которых надо реализовать приложение на нескольких мобильных платформах, я бы тоже оставил за кадром — обсуждать это интересно, но проблемы там несколько другие.
В таком контексте дизайнер, находящийся «в теме» и создавший работоспособный прототип, находится в ключевой точке проекта, позволяя корректировать на основании работы с этим прототипом ТЗ, совершенствуя и добавляя сценарии использования и исправляя ошибки usability.
Таким образом, функционирующий прототип на этапе согласования ТЗ (начальной фазе проекта) помогает:
1. Окончательно сформировать ТЗ, обнаружить и исправить ошибки в нем, проработать и зафиксировать детали.
2. Показать заказчику примерный функциональный облик будущего приложения и получить его approve.
3. Внести полную ясность по задаче в команду разработчиков.
Мне кажется, что дизайнер UI просто обязан полностью владеть идеей продукта и «приоретизацией различных частей программы». И реализовывать прототип именно в ключе «почти готового приложения». Прелесть в том, что мокап можно 100 раз изменить при обсуждениях в команде и 100 раз — при обсуждении с заказчиком. И при этом никто не будет плакать, потому что пропадает полгода совместных усилий по проекту и срываются сроки.
Есть классное, но недоделанное приложение interface для проектирования непосредственно на телефоне. А вообще, думаю, можно приспособиться Xcode юзать, используя в основном Interface Builder.
Яндексбудете рассказывать или про rbtaxi.ru/?в тех немногих городах России (больших и малых), где пользовался такси, машина приходит моментально в любое время дня и ночи. В Европе такси на каждом шагу и телефонный заказ отрабатывает на 100%.
Остаются пара городков (Москва, возможно Питер), где система может оправдать себя.
Вот, ребята из Сан-Франциско реализовали такое, но позиционируют сервис другим образом:
1. Заказ престижных машин.
2. Оплата поездки через приложение.
Эти фишки выдвинуты у них на первые места и они работают как luxury-service, поскольку конкурировать с «народным» сервисом им нечем.
Ну а в целом, меня укрепляет мысль о том, что вокруг стали появляться инструменты разработки для дизайнеров. Как вы думаете, для чего они, как не для ранних прототипов? И если разработчики IDE включают рабочее место дизайнера в среду, значит, может быть расчитывают на какой-то тренд?
Логика простая:
1. Клиент передает функциональные требования.
2. Команда разработчиков превращает это в ТТ и начальную версию ТЗ.
3. Дизайнер UI воплощает это в первый прототип.
4. Прототип «крутится» в команде, помогая исправлять ТЗ. Прототип, естественно, тоже меняется.
5. Прототип тестится и обсуждается с заказчиком.
6. ТЗ фиксируется.
Вопрос в том, сколько времени и ресурсов понадобится на весь цикл. У меня ощущение, что недели будет достаточно.
1. Графический дизайнер. Внешний вид, цветовая гамма, иконки, брендинг.
2. Дизайнер UI. Удобство использования, общая логика работы с интерфейсами приложения, эргономика элементов управления и пр.
3. Архитектор. Структура данных, общая архитектура приложения.
4. Разработчик. Код. Программная реализация всего, что наворотили Архитектор с Дизайнером UI.
Поясните, кто такой «дизайнер взаимодействия», может тогда все встанет на свои места.
Графический дизайн — чтобы было красиво, дизайн интерфейса — чтобы было удобно. Удобно — это чтобы пользователь быстро выполнил все задачи, которые хотел выполнить в приложении.
В прототипе пользователь видит, какие задачи он может решить с помощью приложения и насколько быстро/удобно.
Если у прототипа есть красивый графический дизайн — это замечательно, но можно и без него обойтись на начальном этапе.
В таком контексте дизайнер, находящийся «в теме» и создавший работоспособный прототип, находится в ключевой точке проекта, позволяя корректировать на основании работы с этим прототипом ТЗ, совершенствуя и добавляя сценарии использования и исправляя ошибки usability.
Таким образом, функционирующий прототип на этапе согласования ТЗ (начальной фазе проекта) помогает:
1. Окончательно сформировать ТЗ, обнаружить и исправить ошибки в нем, проработать и зафиксировать детали.
2. Показать заказчику примерный функциональный облик будущего приложения и получить его approve.
3. Внести полную ясность по задаче в команду разработчиков.