## Goal Introduce a customizable, widgets based GitLab homepage. GitLab is an AI powered DevSecOps platform. When someone opens gitlab.com there is nothing that would reflect the capabilities of the product. While there are various options for the homepage, neither one reflects the capabilities of the product, and the majority does not serve its users well. Improving the GitLab homepage can help with first time experiences. Today, many users use browser bookmarks and the browser history to find regularly visited pages. There is no option for users to set up custom homepages. While GitLab offers plenty of data, the data is scattered throughout the product and different users need slightly different homepages. ### Not in scope - group homepage - project homepage It might make sense to add a similar area at the top of group and project homepages, but this is not in scope for this epic. ### RICE A quick [RICE score](https://about.gitlab.com/handbook/product/product-processes/#using-the-rice-framework): 833 - Reach: 10/10 - Impact: 1/3 - Confidence: 100/100 - Effort: 1.2 (low effort) ### The potential - Not in scope for the MVC - Learn GitLab widget to fight the complexity of GitLab - Observability and product analytics on the side of MR lists relevant to every single user to show the power of DevOps - Company default dashboard - ~"GitLab Premium" - Company specific custom widgets - ~"GitLab Ultimate" ### Ownership Following the everyone can contribute GitLab approach, the MVC will likely be owner by ~"group::environments" (where the idea comes), but given the foundational aspect of the feature, beyond MVC the feature-set should be owned by ~"group::foundations". If there is interest and bandwidht in ~"group::foundations" to contribute it to the product, even the MVC can be moved. ## MVC Proposal Very similar to the following image  Changes from the mockup: - each widget needs to be designed following the MVC design guidelines (see below) - the top-level banner should be moved into a widget - we need a markdown widget The homepage content would be defined as code in the UI (textarea). The default definition would be something like the following: ```yaml # The homepage configuration starts with a top level homepage key. homepage: # The content is defined in columns. Columns are an array. columns: # Each column must contain a widgets attribute - widgets: # Widgets are a list. Each widget has a type and might have various attributes - type: issue list attributes: title: Priority issues # on of group or project is optional, if omitted all the issues across GitLab are queried group: gitlab-org/ci-cd/deploy # The filter can be copied from an issue list view following the `?` in the url filter: scope=all&utf8=✓&state=opened&label_name[]=group%3A%3Aenvironments&assignee_username[]=nagyv-gitlab - type: MR list attributes: title: Release post MRs # on of group or project is optional, if omitted all the MRs across GitLab are queried project: gitlab-com/www-gitlab-com # The filter can be copied from an issue list view following the `?` in the url filter: scope=all&utf8=✓&state=opened&assignee_username=nagyv-gitlab&label_name[]=release post item - widgets: - type: tip of the day - type: markdown attributes: title: Hello world! content: | Székely deszkások, szevasztok! Vajdasági falfirkászok, szevasztok! - type: homepage feedback ``` What needs to be done? - a new homepage option under user preferences - a new homepage on the homepage - The edit homepage buttons pushes the dashboard down and renders the textarea at the top allowing an almost in-line editing experience. - 3-4 widgets to start with - issue list - MR list - markdown - dedicated feedback widget (stretch) - the YAML definition needs a well defined schema for validation in the editor area - rollout with a release post item Not in scope: - visual content editor - documentation outside the content of the editor; the default content should be self-documenting ### MVC widget design guidelines - Each widget might have a required title. We might make it optional later. The required title can simplify the design. - Each widget has its own internal state and related views (e.g. loading view) - Loading views use a [skeleton loader](https://design.gitlab.com/components/skeleton-loader) - List views (e.g. issues, MRs) don't have pagination. Instead they render a link to show the related list page. - List views should show the total count - List views should show a maximum of 15 items - Dynamic views (e.g. issues, MRs) have a refresh button and show the time of last load. Configurable auto-refresh is out of scope for the MVC. - All links open on a new tab. - Each widget needs to report the MAU they have ## Success metrics - frequency of opening the homepage by the random 1% (the control group is the rest of gitlab.com) - number of users switching to the homepage - ratio of users editing the homepage (every edit counts, we add a markdown view with our own custom text to foster edits) - feedback received