Clients SED: web vs native vs hybrid
Among the developers of mobile applications B2C and B2B segments, the advantages and disadvantages of alternative approaches to the architecture of the client application are widely discussed - make it HTML, native or hybrid (a simple native client that opens the embedded 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 a mobile application for EDS.
First, a few definitions - what's what.
It is clear that for any of the first two types, you can specify the applications for which the choice of one of these architectures will be optimal. However, the very presence of a third, hybrid approach, speaks about the obviousness of choice in many cases.
In our opinion, business applications, and the electronic document management system in particular, are precisely in the area of ​​non-obvious choice.
How to choose an adequate technical strategy? The cited article proposes an assessment on the parameters of cost, functionality and coverage of various platforms.
Estimates of the listed approaches are given in the following table:
')
The product cost and coverage of multiple fragmented platforms are important for the developer, the cost should be as low as possible, and the number of platforms covered should be as large as possible.
The user in the client software does not estimate the cost of development and the availability of applications on the device, which he does not have, namely the functionality, which is worth understanding in more detail.
With regard to the client EDS for the user is important:
1) Receive tasks and documents from the ERMS upon request, or as they become available;
2) Have the opportunity 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 buyer).
At the same time, integration with the native functions of the device — for example, the calendar, call / messenger functions — is much less in demand.
The separation of important and unimportant requirements for the user allows, in the case of the EDS client, to choose a hybrid approach: use the application already available to the user on the device as the native part, and the functional extension of this application.
As such an application, Docsvision developers chose e-mail, just like a browser. These applications are by default in all mobile devices, but can also be installed from stores.
The general scheme of work through the mail in Docsvision is as follows (very approximately):
1) Task Routing Service The ERMS selects an HTML template that matches the type of task and sends it to the user who has e-mail routing mode enabled. In this case, the task ID is encoded as a string in the “subject” field of the letter. The parameters of the task are inserted into the letter template, including if there is a link to the document file in the task, this document can be attached as an attachment.
2) The letter is delivered to the user in the usual way in a familiar application on the device. The HTML body contains a description of the task and all the parameters necessary for processing.
3) Options for completing the task are encoded in the hyperlinks of the letter. When clicking on a hyperlink, a response letter is generated, in which the parameters entered by the user (for example, the “reject” sign) are encoded again in the subject field.
4) The response letter arrives at the server, subject is decoded into termination options. If a file has been attached, it is placed in the task as the result of its execution.
Many may exclaim at this place that this way of interacting with the user for many years! For example, notifications in social networks. We make a small digression.
We regard work with the electronic document management system via mail as performing actions, and not as receiving notifications. Example action:
- Acquaintance with the document;
- Coordination with the choice of options for completion;
- Coordination with the review of the document;
- Execution of the task with the report attached as a file or as text.
The user should not just receive the notification and follow the link, but perform the action. At the same time, the set of scenarios is unlimited. For example, a reconciliation execution may contain the “Reconcile” completion option that was configured during deployment. And the server sending messages should be able to support all the options, insert them into the letter and process on completion.
Thus, the user communicates with the system via e-mail messages, which is very similar to the normal 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 hyperlinks to other EDMS objects in a letter, or, in the case of tasks with complex business logic that cannot be implemented in mail templates, to execute a task by opening a mobile typesetting task in the browser.
The advantages of this approach are obvious:
Those. and the developer is fed and the customer is satisfied.
The updated tab from the MSDN article will now look like this:
Of course, the approach through the use of an e-mail client is not universal, but for EDS, in our opinion, this is optimal. Perhaps for the application that you are developing - too.
In the Docsvision system, such a hybrid client consists of a pair of "Client for Email" (former client for Outlook) and "Light Client".
This is how it looks in the Docsvision system.
iOS:
WinPhone:
Mobile layout web client Docsvision. 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 the laptop:
And so - on the smartphone:
It seems to us that the proposed approach solves the main problems of both the developer and the corporate customer - platform fragmentation combined with BYOD, replication of applications with different UX, reproduction of “inbox boxes” (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 a mobile application for EDS.
First, a few definitions - what's what.
- A web client is an application written in HTML, CSS, and JavaScript and downloaded from the server via the Internet to the device's browser.
- Native client is an application installed on a device using 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 the applications for which the choice of one of these architectures will be optimal. However, the very presence of a third, hybrid approach, speaks about the obviousness of choice in many cases.
In our opinion, business applications, and the electronic document management system in particular, are precisely in the area of ​​non-obvious choice.
How to choose an adequate technical strategy? The cited article proposes an assessment on the parameters of cost, functionality and coverage of various platforms.
Estimates of the listed approaches are given in the following table:
')
The product cost and coverage of multiple fragmented platforms are important for the developer, the cost should be as low as possible, and the number of platforms covered should be as large as possible.
The user in the client software does not estimate the cost of development and the availability of applications on the device, which he does not have, namely the functionality, which is worth understanding in more detail.
With regard to the client EDS for the user is important:
1) Receive tasks and documents from the ERMS upon request, or as they become available;
2) Have the opportunity 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 buyer).
At the same time, integration with the native functions of the device — for example, the calendar, call / messenger functions — is much less in demand.
The separation of important and unimportant requirements for the user allows, in the case of the EDS client, to choose a hybrid approach: use the application already available to the user on the device as the native part, and the functional extension of this application.
As such an application, Docsvision developers chose e-mail, just like a browser. These applications are by default in all mobile devices, but can also be installed from stores.
The general scheme of work through the mail in Docsvision is as follows (very approximately):
1) Task Routing Service The ERMS selects an HTML template that matches the type of task and sends it to the user who has e-mail routing mode enabled. In this case, the task ID is encoded as a string in the “subject” field of the letter. The parameters of the task are inserted into the letter template, including if there is a link to the document file in the task, this document can be attached as an attachment.
2) The letter is delivered to the user in the usual way in a familiar application on the device. The HTML body contains a description of the task and all the parameters necessary for processing.
3) Options for completing the task are encoded in the hyperlinks of the letter. When clicking on a hyperlink, a response letter is generated, in which the parameters entered by the user (for example, the “reject” sign) are encoded again in the subject field.
4) The response letter arrives at the server, subject is decoded into termination options. If a file has been attached, it is placed in the task as the result of its execution.
Many may exclaim at this place that this way of interacting with the user for many years! For example, notifications in social networks. We make a small digression.
We regard work with the electronic document management system via mail as performing actions, and not as receiving notifications. Example action:
- Acquaintance with the document;
- Coordination with the choice of options for completion;
- Coordination with the review of the document;
- Execution of the task with the report attached as a file or as text.
The user should not just receive the notification and follow the link, but perform the action. At the same time, the set of scenarios is unlimited. For example, a reconciliation execution may contain the “Reconcile” completion option that was configured during deployment. And the server sending messages should be able to support all the options, insert them into the letter and process on completion.
Thus, the user communicates with the system via e-mail messages, which is very similar to the normal 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 hyperlinks to other EDMS objects in a letter, or, in the case of tasks with complex business logic that cannot be implemented in mail templates, to execute a task by opening a mobile typesetting task in the browser.
The advantages of this approach are obvious:
- All user-important requirements are fulfilled (push, offline, familiar UI),
- The requirement important for the corporate purchaser is fulfilled - it is cheap, no matter how many devices the user has for working - a single set of licenses is enough for him,
- The development cost is to create a set of simple mail templates that are not dependent on the device platform,
- Application coverage is equivalent to covering a “standard” browser and many mail clients that support rtf or html-layout of messages, i.e. makes up almost 100%.
Those. and the developer is fed and the customer is satisfied.
The updated tab from the MSDN article will now look like this:
Of course, the approach through the use of an e-mail client is not universal, but for EDS, in our opinion, this is optimal. Perhaps for the application that you are developing - too.
In the Docsvision system, such a hybrid client consists of a pair of "Client for Email" (former client for Outlook) and "Light Client".
This is how it looks in the Docsvision system.
iOS:
WinPhone:
Mobile layout web client Docsvision. 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 the laptop:
And so - on the smartphone:
It seems to us that the proposed approach solves the main problems of both the developer and the corporate customer - platform fragmentation combined with BYOD, replication of applications with different UX, reproduction of “inbox boxes” (when you need to look at more and more different boxes to check “what's new?” in various applications).
Source: https://habr.com/ru/post/261969/
All Articles