Make GitLab a PWA

We should aim to make GitLab a PWA!

Started here: https://gitlab.com/gitlab-org/gitlab-ce/issues/18669#note_32135215

This may not be as simple as a hybrid app, it might not even be as simple as having a very good mobile dev put together a native app but the biggest win IMO is that the work to make GitLab a valid PWA is work that is maintained within one code base and therefore is code that improves the experience for everyone using that software, no matter what device they're on. For example, sure, desktops don't have a "home screen", so they might not be able to have that benefit, but they would still benefit from the high performance standards of a PWA and modern patterns like offline support and service workers.

---

I decided to convert the checklist (https://developers.google.com/web/progressive-web-apps/checklist) to a GFM tasklist.

---

Key: - [ ] [title] | [further description]

• Site is served over HTTPS | Use Lighthouse to verify Served over HTTPS

• Pages are responsive on tablets & mobile devices | Use Lighthouse to verify Yes to all of Design is mobile-friendly, although manually checking can also be helpful. Check the Mobile Friendly Test

• The start URL (at least) loads while offline | Use Lighthouse to verify URL responds with a 200 when offline.

• Metadata provided for Add to Home screen | Use Lighthouse to verify User can be prompted to Add to Home screen is all Yes.

• First load fast even on 3G | Use Lighthouse on a Nexus 5 (or similar) to verify time to interactive <10s for first visit on a simulated 3G network.

• Site works cross-browser | Test site in Chrome, Edge, Firefox and Safari

• Page transitions don't feel like they block on the network

• Each page has a URL | Ensure individual pages are deep linkable via the URLs and that URLs are unique for the purpose of shareability on social media by testing with individual pages can be opened and directly accessed via new browser windows.

• Site's content is indexed by Google | Use the Fetch as Google tool to preview how Google will see your site when it is crawled.

• Schema.org metadata is provided where appropriate

• Social metadata is provided where appropriate | Open a representative page in Facebook's crawler and ensure it looks reasonable. Check that Twitter Cards meta data is present (for example ) if you feel it would be appropriate.

• Canonical URLs are provided when necessary

• Pages use the History API | For single page apps, ensure the site doesn't use fragment identifiers. For example everything after the #! in https://example.com/#!user/26601.

• Content doesn't jump as the page loads | Load various pages in the PWA and ensure content or UI doesn't "jump" as the page loads.

• Pressing back from a detail page retains scroll position on the previous list page | Find a list view in the app. Scroll down. Tap an item to enter the detail page. Scroll around on the detail page. Press back and ensure the list view is scrolled to the same place it was at before the detail link/button was tapped.

• When tapped, inputs aren't obscured by the on screen keyboard | Find a page with text inputs. Scroll to put the text input as low on the screen as you can make it. Tap the input and verify it is not covered when the keyboard appears.

• Content is easily sharable from standalone or full screen mode | Ensure from standalone mode (after adding the app to your home screen) that you are able to share content, if appropriate, from within the app's UI.

• Site is responsive across phone, tablet and desktop screen sizes | View the PWA on small, medium and large screens and ensure it works reasonably on all.

• Any app install prompts are not used excessively | Check the PWA doesn't use an app install interstitial when loaded

• The Add to Home Screen prompt is intercepted | Check the browser doesn't display the A2HS at an inopportune moment, such as when the user is in the middle of a flow that shouldn't be interrupted, or when another prompt is already displayed on the screen.

• First load very fast even on 3G | Use Lighthouse on a Nexus 5 (or similar) to verify time to interactive <5s for first visit on a simulated 3G network (as opposed to the 10s goal for baseline PWAs)

• Site uses cache-first networking | Set the network emulation to the slowest setting and browse around the app. Then, set the network emulation to offline and browse around. The app should not feel faster when offline than on a slow connection.

• Site appropriately informs the user when they're offline | Emulate an offline network and verify the PWA provides an indication that you are offline.

• Provide context to the user about how notifications will be used | Visit the site, and find the push notifications opt-in flow When you are shown the permission request by the browser, ensure that context has been provided explaining what the site wants the permission for. If the site is requesting for the permission on page load, ensure it provides very clear context simultaneously for why the user should enable push notifications.

• UI encouraging users to turn on Push Notifications must not be overly aggressive. | Visit the site and find the push notifications opt in flow. Ensure that if you dismiss or decline to turn on push notifications that the site does not re-prompt in the same way within the same session.

• Site dims the screen when permission request is showing | Visit the site and find the push notifications opt-in flow. When Chrome is showing the permission request, ensure that the page is "dimming" (placing a dark overlay over) all content not relevant to explaining why the site needs push notifications.

• Push notifications must be timely, precise and relevant | Enable push notifications from the site and ensure the use cases they're using the push notifications for are: Timely — A timely notification is one that appears when users want it and when it matters to them. Precise — A precise notification is one that has specific information that can be acted on immediately. Relevant — A relevant message is one about people or subjects that the user cares about.

• Provides controls to enable and disable notifications | Enable push notifications from the site. Ensure there is some place on the site that allows you to manage your notifications permissions or disable them.

• User is logged in across devices via Credential Management API

• User can pay easily via native UI from Payment Request API.

changed the description

Is a GitLab mobile app still something we want?

@lbennett should we group the checklist items by independent issues (e.g. https://gitlab.com/gitlab-org/gitlab-ce/issues/30754), and which ones are out of scope (probably Payment Request API)

For initial setup, I've found https://workboxjs.org/ is pretty great

@ClemMakesApps I'm pretty anti-app unless there is a specific use-case that is impossible on web. Leads to code/UI fragmentation, more complex maintenance, and leaves you at the mercy of App Stores for releases/updates.

@ClemMakesApps Not sure, but my #1 (closed) point in my discussion on #18669 (moved) is that PWA == high-quality modern application so thought that this is a great moonshots direction that we can chip away at over the upcoming years.

should we group the checklist items by independent issues

We certainly should!

I'm pretty anti-app unless there is a specific use-case that is impossible on web. Leads to code/UI fragmentation, more complex maintenance, and leaves you at the mercy of App Stores for releases/updates.

@psimyn Perfect explanation!

marked the checklist item Site is served over HTTPS | Use Lighthouse to verify Served over HTTPS as completed

marked the checklist item Site works cross-browser | Test site in Chrome, Edge, Firefox and Safari as completed

marked the checklist item Each page has a URL | Ensure individual pages are deep linkable via the URLs and that URLs are unique for the purpose of shareability on social media by testing with individual pages can be opened and directly accessed via new browser windows. as completed

marked the checklist item Site's content is indexed by Google | Use the Fetch as Google tool to preview how Google will see your site when it is crawled. as completed

changed the description

marked the checklist item Social metadata is provided where appropriate | Open a representative page in Facebook's crawler and ensure it looks reasonable. Check that Twitter Cards meta data is present (for example ) if you feel it would be appropriate. as completed

marked the checklist item Push notifications must be timely, precise and relevant | Enable push notifications from the site and ensure the use cases they're using the push notifications for are: Timely — A timely notification is one that appears when users want it and when it matters to them. Precise — A precise notification is one that has specific information that can be acted on immediately. Relevant — A relevant message is one about people or subjects that the user cares about. as completed

changed the description

marked the checklist item Push notifications must be timely, precise and relevant | Enable push notifications from the site and ensure the use cases they're using the push notifications for are: Timely — A timely notification is one that appears when users want it and when it matters to them. Precise — A precise notification is one that has specific information that can be acted on immediately. Relevant — A relevant message is one about people or subjects that the user cares about. as incomplete

Related: #33392 (moved)

Google Lighthouse acts as a performance and feature checklist for PWAs that Google has been recommending in many of their recent talks on progressive web apps.

More info: https://developers.google.com/web/tools/lighthouse/

I question the value of implementing gitlab as an actual PWA (with service workers, home screen metadata, and the ability to load it offline), but I do think a lot of the performance guidelines that Google is pushing along with the PWA concept are worth trying to hold ourselves to.

Even if we aren't targeting mobile phones like many PWAs, it wouldn't be a bad thing to target good performance over a slow 3G network connection for example.

@mikegreiling I agree. For me, the home screen stuff is just the small "reward" for building a PWA. The important thing about PWA is not the flashy new things you can do, but the quality of the application that it promotes. I think this becomes clear when you use lighthouse or read the PWA checklist and can see how focused on simply defining a high quality application it is.

That said, I still believe out your examples, the service workers do have a clear value. For a start, they can be used for perf improvements, but also fills some UX gaps that the web has that are actually useful for an app like GitLab.

marked this issue as related to #35915 (closed)

moved to gitlab#10390

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue