-
Notifications
You must be signed in to change notification settings - Fork 22
Summer of Code Progressive Web App Client | Project Proposal
Below is the Project Proposal I (@Inf3cti0n95) made for the GSoC'17 for Rocket.Chat PWA
Progressive Web App - the term coined by Chrome Dev team in Dev Summit, which changed how one approached Web Apps. Progressive Web App or PWA in short, Web Apps progressively enhanced to deliver "Native App" like experience. And even better in terms of its Size (few KBs) and Portability (Every Mobile has a Web Browser). Reducing the gap between a Native App and a Web App (a traditional Website). Thus, delivering App-like experience across platforms in few KBs.
As, I believe the proposal was too long (After all, it is a Progressive Web App that I had to plan out. ), Here's the Gist of what will be Implemented in the Rocket.Chat - Progressive Web App.
-
Rocket.Chat’s Basic Functionalities
-
Login System
-
Channel System
-
User System
-
-
Progressive Features
-
Implementing Rocket.Chat’s Real-Time API with WebSockets.
and more…
The project is Simple to express, yet requiring an elegant solution to Implement. The goal of the Project is to Implement a Progressive Web App Client for Rocket Chat which could replace the current Web Client of Rocket Chat.
I have divided the Features into 2 Categories.
-
Essential features for Progressive Web App
-
Additional Features to Boost the User Experience
I have prepared a List of Features that are essential for Making a Web App, a True PWA. Main attributes that a Progressive Web App has are
-
Responsive
-
Independent from Connectivity
-
App like Experience
-
Re-engagement
-
Lightning Fast Performance with Least Code
For making a web app truly give an app like experience, it must be Responsive and work seamlessly in Smartphones. For making it responsive, I would like to suggest the Mobile-First Approach for designing and implementing the UI.
One of the features which makes PWA much interesting is its independence from Connectivity. Using Service Workers for taking over the network, as every network activity that client does passes through the Service Worker and then over to the Network.
So Even if there is no or very poor network. Service Worker can takeover and serve pre-cached resources. Thus, taking an Offline First Approach to push the resource to serve up when there is no network.
Also by using Network Information API, User can be made aware of its Network Status i.e. whether he/she is connected or not. And have app behave accordingly.
For Rocket.Chat PWA, by using the Network Information
-
Showing the user if He/She is online.
-
If the User Sends a Message while Offline - Notifying that He/She is Offline and the Message will be sent when there is Connectivity.
By pre-caching the Common resources like framework code and App Shell, so that when the user visits for the first time it caches all the resources into the memory thus on the second visit, it can serve up the resources from cache memory via Service Worker and no need to bother for Boilerplate Code every time.
PreCaching of the App Shell can be done with tooling provided by Google like
sw-precache, can be used to get all the crucial scaffolding for the web app i.e. the App Shell - on the screen without having to wait for any network responses. Which gives lightning fast load times. And even functions when the user in offline.
For the Rocket.Chat PWA, by Precaching the Important Resources such as the App Shell of the PWA, the React framework code, and Commonly used Vendor Code should be shipped and Cached, Thus making the returning visits Lightning Fast. Since the App Shell and vendor code would be served from cache and Just the Chats Data is required to populate the Chats.
Think of the scenario when A user sends a message and there is no connectivity. And the message is not passed on to the network. Service Workers, under the hood, captures these type of web request and sends it when there is network, and voilà the message is sent even if the browser is not open.
To give Web App place with Native and giving them An App like experience. We will use Web App Manifest. The manifest enables the web app to have a more native-like presence on the user's home screen . As it allows the app to be launched in full-screen mode with a nice Splash Screen in App’s theme color.
This also requires a Service worker to register the manifest and load the resources when the user taps the icon on home screen.
Implementing push notifications for the chats of the user. So the user can be notified of the New / Unread Messages similar to any native app with the use of Push API.
Notifications help to make users re-engage with the app.
With the implementation of PRPL Pattern. PRPL is a pattern for structuring and serving Progressive Web Apps, with an emphasis on the performance of app delivery and launch. It stands for:
-
Push critical resources for the initial URL route.
-
Render initial route.
-
Pre-cache remaining routes.
-
Lazy-load and create remaining routes on demand.
By following the App Shell Architecture the loading the basic components first and make the First Paint and Time to Interaction lightning fast. As we Push just the crucial resource for the route and render it first then populating it with the data which gives users a better User Experience, as they don’t have to wait on a Blank screen.
Also splitting the code based on the required resources and just pushing the required code to the network. Saves a lot of bandwidth.
Precaching of the Remaining routes is handled by Service Workers.
Asynchronously loading the Inner Routes of the App where a User might go from the current page. By Asynchronously loading those routes it makes the transitions from Route to Route Seamless as the Upcoming path would have been preloaded.
For the Rocket.Chat PWA, pushing the critical resources such as the First Route - the Login-in Screen or the Chat’s Appshell to render. And other resources could be lazily loaded. Thus giving the first meaningful paint the least time.
Here, I have discussed some extra features to add to the Chat Client to make it more intuitive and easy to use.
-
Auto Login with Credential Management API.
-
Rich Notifications with Rich Notification API and Vibrations on Notifications with Vibration API.
-
Offline Functionality
-
Capture and Send Image, Audio, Video.
With the Use of Credential Management API which is currently only supported by Chrome Browsers but in the draft with W3C.
Credential Management API gives a huge UX boost while interacting with an App. By providing features such as Storing the Account Credentials with the Google Account (Save Password for Next Visits thing ). Then on the next visit, the Credential Management API automatically gets the User's credentials from the Google Account with which the user is signed in and Automatically login the user. (No click, Nothing direct sign in). This gives a huge UX boost.
However, the user on an Unsupported browser it has the same Login Procedures thus working as a fallback for unsupported browsers.
Rich Notifications API by Chrome again helps in diminishing the thin line between a Web App and a Native App by providing Rich Notifications similar to what Native Android Apps provide.
Rich Notifications are Notifications with Extended Functionalities such as Action Buttons, Images etc.
Thus, with the help on Rich Notification, we can Implement feature such as When a User gets a private message it notifies the user by a notification and gives options to the user whether to ignore the message or to reply to it.
Or, when a user gets an Image in the Private Message. The User can get the Full Image Displayed in the Notification.
The Main Difference I found out between a Native App and Web App, is that when there is no network User won’t be able to see the recent chats that would have been made, while that is possible in Native App. So this feature of Allowing the user to see the Last Chats up till the last network connection. It would add up to the convenience. And making it less of a website and more of an App. As User won’t be able to tell difference that whether he is online or offline. Which would give PWA an edge.
Offline Storage can be handled by APIs like IndexedDB which works great with Service Workers, which means Offline Chats.
As now browsers supports Capturing Audio and Images, implementing Image Capture, Audio Recording and Send with the Help of HTML Media Capture API along with getUserMedia. Which would provide ease of access to the user to Capture Image directly from the phone and send it in chat. Same goes for the Audio and Video.
I would like to propose the following timeline for the Implementation of the Progressive Web App as per the GSoC timeline.
During the Community Bonding, the GRoCers are supposed to be Bonding with the mentor and discuss the project and its direction.
So, I would like to propose the following tasks to be done while Bonding.
- Exploring the INs and OUTs of the Current Rocket.Chat Client
Before Commencing the Plans for PWA, We should be exploring the Current Web Client thoroughly and List down the Features and Issues of the Current System in Details. And thus getting to the core of the Needs of Progressive Web App by empathizing with the Core Team Members, Contributors and the Current Users of Current Rocket.Chat Web Client.
- Exploring the Rocket.Chat Real-Time API
As @karl.prieb has informed we are going to Use the Real-Time API of Rocket.Chat with WebSockets to implement the PWA, Exploring the Rocket Chat Real Time API.
- Getting Around with the Ideas of fellow GSoCers
After getting our heads around the Rocket.Chat and its APIs, We should be listing the Possible Features that are proposed by the GSoCers and the Contributors. And finalizing set a of features which the PWA will end up with.
- Project Architecture
Defining the Clear Architecture and Flow the PWA that would be developed during the GSoC and Future Milestones.
Also, defining the Dividing the App into crucial components. As we are supposed to use React as the Framework for Implementation, I believe splitting the App into Components would be a very efficient way to execute the project. So that we can parallely test out the integration of different units and can tackle the issues with incompatibility between components.
During the first Month of Coding Session, I would like to propose the following schedule for delivering the Basic Running Progressive Web App.
- Implementation of the Rocket.Chat Real-Time API with WebSockets and the Basic Features
First steps to Implementation should start out with the Implementation of the PWA’s API, which would be used extensively for every functionality of the PWA. Thus, I believe defining clear backend working of the PWA should be Implemented initially.
Like Authentication, Channels, User List and Implementation of the Real-time API for Chats
- Defining the UI of the Progressive Web App
Designing is the crucial part of the project. And thus, a Perfect Design and User Interaction should be decided, As most of the PWAs go with the Material Design for their App, we can look into that. Defining UI is a must, before starting onto the actual PWA.
- Implementation of the Basic Progressive Web App Features
As starting off with the Progressive Web App, in the first month of the Coding, I propose to build up the Base for the Progressive Web App to the bare minimum.
-
The App Shell
-
Service Workers for Caching and Placeholder for the Offline
-
Code Splitting, Lazy Loading and PRPL pattern
Building the basic structure which is the most crucial part for the performance of the App, i.e. Implementation of App Shell, implementing service workers for caching the resources, implementation lazy loading of routes and code splitting.
After the implementation of the Performance Standards, We can start coding the Actual Components in a prioritized manner. Thus, ensuring that any component delivered is Up to the Mark in performance.
As the basic app has a lot of crucial decisions and implementations to make, We can have a deviation of 1-2 Weeks from the Actual schedule. But, If the Base is strong, implementation of the later features can be executed in few weeks.
After the Basic Skeleton ready, We can start integrating the modules of Rocket.Chat.
-
Implementing the Login System
-
Implementing the Channels System
-
Implementing the Chat System
-
Implementing the User System
-
Implementing the Capture and Send Image, Audio and Video System.
We can have a deviation of 2-3 Weeks from the Actual schedule. Because as of now I am not aware of the overall complexity of Rocket.Chat internally.
-
Implementing Offline Usage
-
Implementing Rich Push Notifications API
-
Implementing Credential Management API
If there are deviations in schedule these additional features can be filled in after the GSoC program.