Среди разработчиков мобильных приложений B2C и B2B сегментов широко обсуждаются достоинства и недостатки альтернативных подходов к архитектуре клиентского приложения – делать его на HTML, нативным или гибридным (простой нативный клиент, открывающий встроенный браузер для обмена данными с сервером).
Одна из первых статей Microsoft на эту тему была опубликована на MSDN в 2012 году и не потеряла своей актуальности до сих пор (Choosing between a web and native experience). В этой статье мы рассмотрим использование гибридного варианта мобильного приложения для СЭД.
Для начала несколько определений – что к чему.
Понятно, что для любого из первых двух типов можно указать такие приложения, для которых выбор одной из этих архитектур будет оптимален. Однако само наличие третьего, гибридного подхода, говорит о неочевидности выбора во многих случаях.
На наш взгляд, бизнес-приложения, и система электронного документооборота в частности, – как раз лежат в области неочевидного выбора.
Как выбрать адекватную техническую стратегию? В цитированной статье предлагается оценка по параметрам стоимости, функциональности и покрытия различных платформ.
Оценки перечисленных подходов даются в следующей таблице:
Параметры себестоимости продукта и покрытия множества фрагментированных платформ важны для разработчика, себестоимость должна быть как можно меньше, а количество покрываемых платформ – как можно больше.
Пользователь в клиентском ПО оценивает не стоимость разработки и не доступность приложений на устройстве, которого у него нет, а именно функциональность, с которой стоит разобраться подробнее.
Применительно к клиенту СЭД для пользователя важно:
1) Получать задачи и документы из СЭД по запросу, или по мере появления;
2) Иметь возможность работать с этими объектами без доступа к системе;
3) Иметь привычный ему на его устройстве интерфейс;
4) Цена приложения (для корпоративного закупщика).
При этом интеграция с нативными функциями устройства – например, календарем, функциями звонка/мессенджера – востребованы гораздо меньше.
Разделение важных и неважных для пользователя требований позволяет в случае клиента СЭД выбрать вариант гибридного подхода: использование в качестве нативной части приложение, уже имеющееся у пользователя на устройстве, и функциональное расширение этого приложения.
В качестве такого приложения разработчики Docsvision выбрали электронную почту, как и браузер. Эти приложения есть по умолчанию во всех мобильных устройствах, но и могут быть установлены из магазинов.
Общая схема работы через почту в Docsvision следующая (очень приближенно):
1) Сервис маршрутизации заданий СЭД выбирает соответствующий типу задания HTML шаблон письма и отправляет его пользователю, у которого включен режим маршрутизации через электронную почту. При этом ID задания кодируется строкой в поле «subject» письма. Параметры задания вставляются в шаблон письма, в том числе, если в задании есть ссылка на файл документа, этот документ может быть приложен в качестве вложения.
2) Письмо доставляется пользователю обычным образом в привычное ему приложение на устройство. В HTML-теле письма содержится описание задания и все необходимые для обработки параметры.
3) Варианты завершения задания закодированы в гиперссылках письма. При клике на гиперссылку формируется ответное письмо, в котором введенные пользователем параметры (например, признак «отклонить») кодируются опять-таки в поле subject.
4) Ответное письмо приходит на сервер, subject раскодируется в параметры завершения. Если был приложен файл – он размещается в задании как результат его исполнения.
Многие могут в этом месте воскликнуть, что этому способу взаимодействия с пользователем уже много лет! Например, уведомления в социальных сетях. Сделаем небольшое отступление.
Работу с системой электронного документооборота через почту мы воспринимаем именно как выполнение действий, а не как получение уведомлений. Пример действий:
— Ознакомление с документом;
— Согласование с выбором варианта завершения;
— Согласование с рецензированием документа;
— Исполнение задания с приложением отчета в виде файла или в виде текста.
Пользователь должен не просто получить уведомление и перейти по ссылке, а выполнить действие. При этом набор сценариев неограничен. Например, исполнение согласования может содержать вариант завершения «Повторить согласование», который был настроен при внедрении. И сервер отправки сообщений должен уметь поддерживать все варианты, вставлять их в письмо и обрабатывать при завершении.
Таким образом пользователь как бы общается с системой посредством почтовых сообщений, что очень похоже на обычную работу офисного сотрудника.
Какую роль в этой связке выполняет Web-клиент? Web-клиент в данном случае может использоваться для открытия пришедших в письме гиперссылок на другие объекты СЭД, или, в случае заданий со сложной бизнес-логикой, нереализуемой в почтовых шаблонах – для исполнения задания путем открытия мобильной верстки задания в браузере.
Преимущества такого подхода очевидны:
Т.е. и разработчик сыт, и клиент доволен.
Обновленная табличка из статьи с MSDN теперь будет выглядеть так:
Конечно, подход через использование клиента электронной почты не является универсальным, но для СЭД это, на наш взгляд, оптимально. Возможно, для приложения, которое вы разрабатываете – тоже.
В системе Docsvision такой гибридный клиент состоит из пары «Клиент для электронной почты» (бывший клиент для Outlook) и «Легкий клиент».
Вот, как это выглядит в системе Docsvision.
iOS:
WinPhone:
Мобильная верстка web-клиента Docsvision. Помимо мобильной работы, вы получаете еще и универсальность рабочего места. Утром поработал на ноутбуке, а в поездке на смартфоне.
Так на ноутбуке:
А так – на смартфоне:
Как нам кажется, предложенный подход решает главные проблемы как разработчика, так и корпоративного заказчика – фрагментация платформ в сочетании с BYOD, размножение приложений с разным UX, размножение «ящиков inbox» (когда для проверки «что нового?» надо смотреть все больше различных ящиков в различных приложениях).
Одна из первых статей Microsoft на эту тему была опубликована на MSDN в 2012 году и не потеряла своей актуальности до сих пор (Choosing between a web and native experience). В этой статье мы рассмотрим использование гибридного варианта мобильного приложения для СЭД.
Для начала несколько определений – что к чему.
- Web-клиент – это приложение, написанное на HTML, CSS и JavaScript и загружаемое с сервера через интернет в браузер устройства.
- Нативный клиент – приложение, устанавливаемое на устройство, использующее API операционной системы, и написанное с использованием SDK этой платформы. Например, для Windows Phone это могут быть XAML и C# или Visual Basic, а для iOS, соответственно, Cocoa Touch и Objective-C.
- Гибридный подход подразумевает сочетание первых двух.
Понятно, что для любого из первых двух типов можно указать такие приложения, для которых выбор одной из этих архитектур будет оптимален. Однако само наличие третьего, гибридного подхода, говорит о неочевидности выбора во многих случаях.
На наш взгляд, бизнес-приложения, и система электронного документооборота в частности, – как раз лежат в области неочевидного выбора.
Как выбрать адекватную техническую стратегию? В цитированной статье предлагается оценка по параметрам стоимости, функциональности и покрытия различных платформ.
Оценки перечисленных подходов даются в следующей таблице:
Параметры себестоимости продукта и покрытия множества фрагментированных платформ важны для разработчика, себестоимость должна быть как можно меньше, а количество покрываемых платформ – как можно больше.
Пользователь в клиентском ПО оценивает не стоимость разработки и не доступность приложений на устройстве, которого у него нет, а именно функциональность, с которой стоит разобраться подробнее.
Применительно к клиенту СЭД для пользователя важно:
1) Получать задачи и документы из СЭД по запросу, или по мере появления;
2) Иметь возможность работать с этими объектами без доступа к системе;
3) Иметь привычный ему на его устройстве интерфейс;
4) Цена приложения (для корпоративного закупщика).
При этом интеграция с нативными функциями устройства – например, календарем, функциями звонка/мессенджера – востребованы гораздо меньше.
Разделение важных и неважных для пользователя требований позволяет в случае клиента СЭД выбрать вариант гибридного подхода: использование в качестве нативной части приложение, уже имеющееся у пользователя на устройстве, и функциональное расширение этого приложения.
В качестве такого приложения разработчики Docsvision выбрали электронную почту, как и браузер. Эти приложения есть по умолчанию во всех мобильных устройствах, но и могут быть установлены из магазинов.
Общая схема работы через почту в Docsvision следующая (очень приближенно):
1) Сервис маршрутизации заданий СЭД выбирает соответствующий типу задания HTML шаблон письма и отправляет его пользователю, у которого включен режим маршрутизации через электронную почту. При этом ID задания кодируется строкой в поле «subject» письма. Параметры задания вставляются в шаблон письма, в том числе, если в задании есть ссылка на файл документа, этот документ может быть приложен в качестве вложения.
2) Письмо доставляется пользователю обычным образом в привычное ему приложение на устройство. В HTML-теле письма содержится описание задания и все необходимые для обработки параметры.
3) Варианты завершения задания закодированы в гиперссылках письма. При клике на гиперссылку формируется ответное письмо, в котором введенные пользователем параметры (например, признак «отклонить») кодируются опять-таки в поле subject.
4) Ответное письмо приходит на сервер, subject раскодируется в параметры завершения. Если был приложен файл – он размещается в задании как результат его исполнения.
Многие могут в этом месте воскликнуть, что этому способу взаимодействия с пользователем уже много лет! Например, уведомления в социальных сетях. Сделаем небольшое отступление.
Работу с системой электронного документооборота через почту мы воспринимаем именно как выполнение действий, а не как получение уведомлений. Пример действий:
— Ознакомление с документом;
— Согласование с выбором варианта завершения;
— Согласование с рецензированием документа;
— Исполнение задания с приложением отчета в виде файла или в виде текста.
Пользователь должен не просто получить уведомление и перейти по ссылке, а выполнить действие. При этом набор сценариев неограничен. Например, исполнение согласования может содержать вариант завершения «Повторить согласование», который был настроен при внедрении. И сервер отправки сообщений должен уметь поддерживать все варианты, вставлять их в письмо и обрабатывать при завершении.
Таким образом пользователь как бы общается с системой посредством почтовых сообщений, что очень похоже на обычную работу офисного сотрудника.
Какую роль в этой связке выполняет Web-клиент? Web-клиент в данном случае может использоваться для открытия пришедших в письме гиперссылок на другие объекты СЭД, или, в случае заданий со сложной бизнес-логикой, нереализуемой в почтовых шаблонах – для исполнения задания путем открытия мобильной верстки задания в браузере.
Преимущества такого подхода очевидны:
- Выполняются все важные для пользователя требования (push, offline, привычный UI),
- Выполняется требование, важное для корпоративного закупщика – это дешево, сколько бы устройств ни было у пользователя для работы — ему достаточно единственного набора лицензий,
- Себестоимость разработки сводится к созданию набора простых почтовых шаблонов, не зависящих от платформы устройства,
- Покрытие приложения эквивалентно покрытию «стандартного» браузера и множества mail-клиентов, поддерживающих rtf или html-верстку сообщений, т.е. составляет практически 100%.
Т.е. и разработчик сыт, и клиент доволен.
Обновленная табличка из статьи с MSDN теперь будет выглядеть так:
Конечно, подход через использование клиента электронной почты не является универсальным, но для СЭД это, на наш взгляд, оптимально. Возможно, для приложения, которое вы разрабатываете – тоже.
В системе Docsvision такой гибридный клиент состоит из пары «Клиент для электронной почты» (бывший клиент для Outlook) и «Легкий клиент».
Вот, как это выглядит в системе Docsvision.
iOS:
WinPhone:
Мобильная верстка web-клиента Docsvision. Помимо мобильной работы, вы получаете еще и универсальность рабочего места. Утром поработал на ноутбуке, а в поездке на смартфоне.
Так на ноутбуке:
А так – на смартфоне:
Как нам кажется, предложенный подход решает главные проблемы как разработчика, так и корпоративного заказчика – фрагментация платформ в сочетании с BYOD, размножение приложений с разным UX, размножение «ящиков inbox» (когда для проверки «что нового?» надо смотреть все больше различных ящиков в различных приложениях).
