Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

[Home]

Child pages
  • Openmrs Lite Module proposal
Skip to end of metadata
Go to start of metadata

Abstract

This project aims to provide a modified UI atop (or in place) of the reference application, sufficiently reducing the size of the pages and associated resources. It will take direction from the existing reference application for which pages or views should be modified or replaced.

Objectives

  1. Identify the heaviest / most resource-laden page views in the reference application
  2. Establish a style guide for a low-bandwidth skin
  3. Implement replacements for login, app list, registration, and visit dashboards
  4. Load a visit dashboard within a "reasonable" time over a 2G connection
  5. Provide instructions on how to write a low-bandwidth version of existing or new views

About 80% of the time it takes to display a webpage is shared between performing client side processing and loading resources

My Ideas on Implementation

1)Reduce the number of HTTP requests for each page but we should also check by simply reducing the resources payload may increase  and  it is difficult to cache lager resources

2)reduce the size of the payload needed to fulfill the request so that even the users having the slower networks will be easy to accessible

3)we have to optimize the scripting on client side

4)compression and minification

Compression:compression such as g zip can reduce payloads it includes all the text based responses like html,css ,java script

Minification:minification is mainly applied to scripts so that it reduces spaces,comments,newline characters.

4)By having low resolution images it will be good

5)using  ajax

6)It is faster to retrieve pages or resources from local storage than to request the server

7) Based on the system location, retrieving details of all the patients and then storing it in the client database and retrieving only when the client searches.

8)if we search for a patient we get the whole profile of the patient,so if the doctor want to view patient recent visits that to under low bandwidth it takes lot of time.Its better to separate them if the user has low bandwidth connection

My Proposal Timeline:

22nd April – 18th May: Community bonding period and also survey time to find out what are the most frequently used pages in the implementations.

19th May – 25th May: Identify Resource Laden Pages in them and prioritizing them in the order of usability.

26th May – 31st May: Devising a style guide to create a Project plan order (Like creating low resolution images, reducing the amount of data displayed, granulize the number of user interactions for data retrieval etc.). The main idea would be to granulize the user interaction process and only display what is required/ queried from, similar to the phone version of Facebook/Gmail where not every detail is displayed as in the Desktop version. This will be a continuous process throughout the Project.

1st June – 15th June:   creating a basic OpenMRS Lite module to display our Lite Login Page instead of regular login in our test scenario.

16th June – 30th June:  Replacements for app list, registration, and visit dashboards similar to the previous work (these are just the assumed frequent page interactions these might be different depending on the requirement). Based on pages using the REST API/DWR services depending on the requirement.

1st July – 25th July: Replacements for other Identified Pages in the order of Priority and usage.

26th July – 10th August:  Extensive testing of Module in different environments.

10th August – 18th August: Buffer Time for Code cleaning and adding the documentation for the module.

I did some homework regarding which are the heavy resources laden pages.

activevisits.png

homePageNetwork.png

homePageNetwork.png

activelistPageSpeed.png

loginPage.png

loginPageSpeed.png

 

  • No labels

1 Comment

  1. Please include your proposal's timeline in this document if possible. Thanks.