Product discovery to edit a project in Web IDE then fork or commit to existing fork
Problem to solve
The Web IDE is only available to users with write access to the repository. This creates an extra step for a user that wants to make a drive by commit to a project because they have to fork the project first before they can even open it in the IDE.
With the introduction of live preview (client evaluation) we want people to be able to open projects that support live preview and experiment with them. Experimenting with a small project shouldn't require the user to fork the project. We should make it possible to open a project, make changes and see them in the live preview and them Fork and Commit in a single action if they want to save their changes.
Intended users
User stories
# | User Story | Persona | Scope |
---|---|---|---|
1 | As a user I want to be able to edit the current file/directory/repository in the Web IDE regardless of having write permissions yes or no / Users do not need to have to fork the project prior to editing | Persona: Software developer and Persona: Product Manager | Current |
2 | Edit current page links should be possible to directly make use of the Web IDE | Community contributor | Current |
3 | As a project owner I want to be able to let people open my projects that support live preview and experiment with them | Project owner | Current |
4 | As a project owner I want to be able to let people sandbox and quickly publish their version of my project | Project owner | Current |
4 | As a user I want to make changes, see them in the live preview, and them Fork and Commit in a single action if I decide to save those changes | Persona: Software developer | Current |
Further details
This allows a project to behave more like a sandbox rather than a heavy repository and encourages people to publish their sample web applications for people to explore on GitLab.
Current flow is as follows. We need to figure out how to unblock the user in case of the flow leading towards the red node:
graph LR
UOP>User opens public project]
UOW[User opens Web IDE]
LI{User logged in?}
WP{Any write permissions to project?}
WB{Write permissions to current branch?}
UL[Required to log in]
UB[User is blocked from making changes]
UB2[User is blocked from making changes]
FPE[Offered the option to fork the project prior to editing]
EP[Editing possible immediately]
EP2[Editing possible immediately]
RNB[Required to create new branch]
UOP-->UOW
UOW-->LI
LI-->|Yes|WP
LI-->|No|UL
UL-->UB
WP-->|Yes|WB
WP-->|No|FPE
FPE-->UB2
WB-->|Yes|EP
WB-->|No|EP2
EP2-->RNB
style UB stroke:#fb9400,stroke-width:4px
style UB2 stroke:#db3b20,stroke-width:4px
style EP stroke:#18aa55,stroke-width:4px
style EP2 stroke:#18aa55,stroke-width:4px
Additional notes:
- The Web IDE button is not shown on the project homepage if the user does not have any write permissions to the project. This while the Web IDE button is shown on blob view pages. This was done so, as to guarantee that we have a consistent environment to show the currently implemented fork bar: fork bar image example on blob view
- The Web IDE button is disabled on merge request pages if the user does not have any write permissions to the project.
Solution
Acceptance criteria
- Always show the Web IDE button on the project dashboard/repository view
- Remove the fork prompt from the blob view
- Always enable the Web IDE button on merge request pages
- Forking is now possible from within the Web IDE
- Forking only works once to your personal namespace (ensures only frontend changed needed)
- User is prevented from making changes within the Web IDE if there is an existing fork
- User is notified of an alternative editing method
- User is notified to be working in a project for which they have no writing permissions
Out of scope
- Solving the usecase of a non-logged in user
- https://gitlab.com/gitlab-org/gitlab-ce/issues/50850 Pushing changes from upstream project to the existing fork
User journey
graph TD
UOP>User opens public project]
UOW[User opens Web IDE]
LI[User is logged in]
WP[User does not have any write permissions to project]
DFE{Does a fork already exist?}
PE[Prevents editing, notifies of state and offers suggestion]
UE[User is able to edit]
UMC[User makes changes]
CSW[Navigates to commit view Web IDE]
UWP[User notified of lack of writing permissions]
URF[User required to create and commit to fork]
UCF[User commits and fork is automatically created]
PF[User is kept up to date on progress fork creation and commit success]
FS{Fork + Commit success?}
WN[Web IDE is changed to fork namespace]
UNS[User notified of success]
UNF[User is notified of failure and offered option to retry]
UOP-->UOW
UOW-->LI
LI-->WP
WP-->DFE
DFE-->|Yes|PE
DFE-->|No|UE
UE-->UMC
UMC-->CSW
CSW-->UWP
UWP-->URF
URF-->UCF
UCF-->PF
PF-->FS
FS-->|Yes|WN
FS-->|No|UNF
WN-->UNS
Permissions and Security
Documentation
What does success look like, and how can we measure that?
Success looks like people hosting web applications that support live preview on GitLab and people experimenting with them, and forking them from the Web IDE. We should try to get baseline Live Preview usage numbers to see if this increases the rate of adoption.