July 7, 2015 at 14:34EDS clients: web vs native vs hybrid
Among the developers of mobile applications of B2C and B2B segments, the advantages and disadvantages of alternative approaches to the architecture of the client application are widely discussed - to make it HTML, native or hybrid (a simple native client that opens a built-in browser for exchanging data with the server).
One of the first Microsoft articles on this topic was published on MSDN in 2012 and has not lost its relevance so far ( Choosing between a web and native experience ). In this article, we will consider the use of a hybrid version of the mobile application for EDMS.
First, a few definitions - what’s what.
It is clear that for any of the first two types, you can specify applications for which the choice of one of these architectures will be optimal. However, the very presence of a third, hybrid approach indicates the non-obviousness of choice in many cases.
In our opinion, business applications, and the electronic document management system in particular, are precisely in the field of non-obvious choice.
How to choose an adequate technical strategy? The cited article proposes an assessment of the cost, functionality and coverage of various platforms.
Estimates of the above approaches are given in the following table:
The parameters of the product cost and coverage of many fragmented platforms are important for the developer, the cost should be as low as possible, and the number of covered platforms - as large as possible.
The user in the client software does not evaluate the cost of development and the availability of applications on a device that he does not have, namely the functionality that is worth exploring in more detail.
In relation to an EDMS client, it is important for the user to:
1) Receive tasks and documents from the EDMS upon request, or as they appear;
2) Have the ability to work with these objects without access to the system;
3) Have an interface familiar to him on his device;
4) Application price (for corporate purchaser).
At the same time, integration with the device’s native functions - for example, calendar, call / messenger functions - is much less popular.
Separation of important and unimportant requirements for the user allows, in the case of an EDS client, to choose a hybrid approach: use the application that the user already has on the device as a native part and the functional extension of this application.
As such an application, Docsvision developers chose email, as did the browser. These applications are by default in all mobile devices, but can also be installed from stores.
The general scheme of work through mail in Docsvision is as follows (very approximate):
1) The EDS task routing service selects an email template that matches the type of HTML job and sends it to a user who has routing via email enabled. In this case, the task ID is encoded by a line in the “subject” field of the letter. Job parameters are inserted into the letter template, including, if the task has a link to a document file, this document can be attached as an attachment.
2) The letter is delivered to the user in the usual way in the familiar application on the device. The HTML body of the letter contains a description of the task and all the parameters necessary for processing.
3) Options for completing the task are encoded in the letter hyperlinks. When you click on the hyperlink, a response letter is generated in which the parameters entered by the user (for example, the sign “reject”) are encoded again in the subject field.
4) A response letter arrives at the server, subject is decoded into completion parameters. If a file was attached, it is placed in the task as a result of its execution.
Many can exclaim in this place that this method of user interaction has been around for many years! For example, notifications on social networks. Let's make a small digression.
We perceive the work with the electronic document management system through mail as the execution of actions, and not as the receipt of notifications. Example actions:
- Familiarization with the document;
- Coordination with the choice of completion option;
- Coordination with the review of the document;
- Execution of the task with the application of the report in the form of a file or in the form of text.
The user should not just receive a notification and follow the link, but perform an action. The set of scenarios is unlimited. For example, execution of reconciliation may include the “Repeat reconciliation” completion option that was configured during deployment. And the message sending server should be able to support all the options, insert them into the letter and process it upon completion.
Thus, the user, as it were, communicates with the system through e-mail messages, which is very similar to the usual work of an office employee.
What role does the web client play in this bundle? In this case, the Web client can be used to open the hyperlinks that came in the letter to other EDMS objects, or, in the case of tasks with complex business logic that cannot be implemented in mail templates, to complete the task by opening the mobile page layout of the task in the browser.
The advantages of this approach are obvious:
Those. and the developer is full and the client is satisfied.
The updated label from the article with MSDN will now look like this:
Of course, the approach through the use of the email client is not universal, but for the EDMS this, in our opinion, is optimal. Perhaps for the application you are developing, too.
In Docsvision, such a hybrid client consists of a pair of “Client for Email” (former client for Outlook) and “Light Client”.
Here's what it looks like in a Docsvision system.
iOS:
WinPhone:
Mobile layout of the Docsvision web client. In addition to mobile work, you also get the versatility of the workplace. In the morning I worked on a laptop, and on a trip on a smartphone.
So on a laptop:
And so on a smartphone:
It seems to us that the proposed approach solves the main problems of both the developer and the corporate customer - fragmentation of platforms in combination with BYOD, reproduction of applications with different UX, reproduction of “inbox” (when you need to look at more and more different boxes to check “what's new?” in various applications).
One of the first Microsoft articles on this topic was published on MSDN in 2012 and has not lost its relevance so far ( Choosing between a web and native experience ). In this article, we will consider the use of a hybrid version of the mobile application for EDMS.
First, a few definitions - what’s what.
- Web client is an application written in HTML, CSS and JavaScript and downloaded from the server via the Internet to the device’s browser.
- A native client is an application installed on a device that uses the operating system API and written using the platform’s SDK. For example, for Windows Phone it can be XAML and C # or Visual Basic, and for iOS, Cocoa Touch and Objective-C, respectively.
- A hybrid approach involves a combination of the first two.
It is clear that for any of the first two types, you can specify applications for which the choice of one of these architectures will be optimal. However, the very presence of a third, hybrid approach indicates the non-obviousness of choice in many cases.
In our opinion, business applications, and the electronic document management system in particular, are precisely in the field of non-obvious choice.
How to choose an adequate technical strategy? The cited article proposes an assessment of the cost, functionality and coverage of various platforms.
Estimates of the above approaches are given in the following table:
The parameters of the product cost and coverage of many fragmented platforms are important for the developer, the cost should be as low as possible, and the number of covered platforms - as large as possible.
The user in the client software does not evaluate the cost of development and the availability of applications on a device that he does not have, namely the functionality that is worth exploring in more detail.
In relation to an EDMS client, it is important for the user to:
1) Receive tasks and documents from the EDMS upon request, or as they appear;
2) Have the ability to work with these objects without access to the system;
3) Have an interface familiar to him on his device;
4) Application price (for corporate purchaser).
At the same time, integration with the device’s native functions - for example, calendar, call / messenger functions - is much less popular.
Separation of important and unimportant requirements for the user allows, in the case of an EDS client, to choose a hybrid approach: use the application that the user already has on the device as a native part and the functional extension of this application.
As such an application, Docsvision developers chose email, as did the browser. These applications are by default in all mobile devices, but can also be installed from stores.
The general scheme of work through mail in Docsvision is as follows (very approximate):
1) The EDS task routing service selects an email template that matches the type of HTML job and sends it to a user who has routing via email enabled. In this case, the task ID is encoded by a line in the “subject” field of the letter. Job parameters are inserted into the letter template, including, if the task has a link to a document file, this document can be attached as an attachment.
2) The letter is delivered to the user in the usual way in the familiar application on the device. The HTML body of the letter contains a description of the task and all the parameters necessary for processing.
3) Options for completing the task are encoded in the letter hyperlinks. When you click on the hyperlink, a response letter is generated in which the parameters entered by the user (for example, the sign “reject”) are encoded again in the subject field.
4) A response letter arrives at the server, subject is decoded into completion parameters. If a file was attached, it is placed in the task as a result of its execution.
Many can exclaim in this place that this method of user interaction has been around for many years! For example, notifications on social networks. Let's make a small digression.
We perceive the work with the electronic document management system through mail as the execution of actions, and not as the receipt of notifications. Example actions:
- Familiarization with the document;
- Coordination with the choice of completion option;
- Coordination with the review of the document;
- Execution of the task with the application of the report in the form of a file or in the form of text.
The user should not just receive a notification and follow the link, but perform an action. The set of scenarios is unlimited. For example, execution of reconciliation may include the “Repeat reconciliation” completion option that was configured during deployment. And the message sending server should be able to support all the options, insert them into the letter and process it upon completion.
Thus, the user, as it were, communicates with the system through e-mail messages, which is very similar to the usual work of an office employee.
What role does the web client play in this bundle? In this case, the Web client can be used to open the hyperlinks that came in the letter to other EDMS objects, or, in the case of tasks with complex business logic that cannot be implemented in mail templates, to complete the task by opening the mobile page layout of the task in the browser.
The advantages of this approach are obvious:
- All important user requirements are fulfilled (push, offline, familiar UI),
- The requirement that is important for the corporate purchaser is being fulfilled - it’s cheap, no matter how many devices the user has for work - a single set of licenses is enough for him,
- The cost of development comes down to creating a set of simple email templates that are independent of the device platform,
- Coverage of an application is equivalent to coverage of a “standard” browser and many mail clients that support rtf or html-layout of messages, i.e. almost 100%.
Those. and the developer is full and the client is satisfied.
The updated label from the article with MSDN will now look like this:
Of course, the approach through the use of the email client is not universal, but for the EDMS this, in our opinion, is optimal. Perhaps for the application you are developing, too.
In Docsvision, such a hybrid client consists of a pair of “Client for Email” (former client for Outlook) and “Light Client”.
Here's what it looks like in a Docsvision system.
iOS:
WinPhone:
Mobile layout of the Docsvision web client. In addition to mobile work, you also get the versatility of the workplace. In the morning I worked on a laptop, and on a trip on a smartphone.
So on a laptop:
And so on a smartphone:
It seems to us that the proposed approach solves the main problems of both the developer and the corporate customer - fragmentation of platforms in combination with BYOD, reproduction of applications with different UX, reproduction of “inbox” (when you need to look at more and more different boxes to check “what's new?” in various applications).