When creating new projects from a template or by importing existing data, the user experience is not conducive to the discoverability of these features or an easy understanding of the flow.
"Create from Template" and "Import Project" options are hidden behind tabs, which leads to two potential user experience issues:
The user doesn't notice the tabs and doesn't consider these options before creating the new project. This problem is exaggerated by the fact that, once the project is created, it is no longer possible to apply a template or perform an import.
The user may notice the tabs but may assume that they will still have a chance to apply a template or an import, given that the tabs pattern looks a lot like one that may "walk" the user from tab to tab before the project is finally created.
Similar to an online checkout experience. See the example image below:
The Solution
A new UX flow that offers all 4 project creation options as equal choices and forces a conscious decision on which "adventure" to choose.
Additional solution discovery of this flow: #25647
This is the text to be used for each one of the choices, below the new icons:
Create new project
Create a blank project to house your files, plan your work, and collaborate on code, among other things.
Create from template
Create a project pre-populated with the necessary files to get you started quickly.
Import project
Migrate your data from an external source like GitHub, Bitbucket, or another instance of GitLab.
Run CI/CD for external repository
Connect your external repository to GitLab CI/CD.
Telemetry
We should collect metrics on the tab/panel clicks to be able to measure user interaction from both variants, to be able to accurately measure whether there's an improvement in engagement or not.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@hdelalic I made this simple wireframe to lay out some ideas on how we can restructure the current flow, but keep it as MVC as possible while still making it more useful and more user friendly.
@hdelalic@dmoraBerlin Would this be offered alongside the existing flow which has all the inputs in one page? I and I'm sure others would appreciate an "expert mode" where we don't have to click through multiple flows to create or import a project.
@dennis my thoughts would be to make sure there is a way for people to keep the functions needed, with out losing anything. And yet offering something simple for the "majority" (?) of users who don't need the "expert" mode.
This data from a previous issue was really helpful.
One of the biggest needs for me is to get better analytics of what's going on in the world of import/export. For me a priority should be improving the tracking in this page to better understand what users are doing.
As for an MVC / iterative process, we have a direction and I'm currently working on visuals. I want to connect with dev to see what sort of investment will be needed as far as dev work.
This would be used to provide the visuals needed for this 4 panel entrance page. However I do not see images that could be suitable for our needs. I would need to schedule some time with him to get the right branding imagery for our needs.
This includes either an updated InVision that shows just the views we are changing (current one shows many more screens and seems to have a much larger scope) or removing the InVision and providing the hi-fi mockups.
@hdelalic@dennis@xanf I've attached the updated visuals to the issue. For an MVC I've made a "landing page" with the updated graphics. This can be updated with tracking analytics to get a better idea of usage statistics.
As well there are a number of changes to the sub pages to clean up the visual inconsistencies. Such as primary/secondary buttons being in wrong places and wrong containers.
This change keeps the concept of the tabs on sub pages for easy switching, but have a more polished "landing" page. The idea being that with this MVC we can keep much of the functional aspects of the current system, and still move to a more refined user experience, as we build user research on next steps for larger changes.
Currently I have a few ideas that I am testing but add complexity to dev work that needs to be user tested first. And I am still refining that user flow, which I want to test with internal stakeholders once it's further refined. I'll be creating separate issues, and linking them to the primary epic &2732
@hdelalic@dennis something I was thinking of the more I mapped out the process, is the issue Dennis brought up about being able to go "back" or an "expert" mode.
Currently the 4 tabs allows this behavior in going "back" or switching to another solution. If we change the entry point to be more deliberate, by reducing the tab switching, it feels like the users will be constrained to that flow, with out a simple exit or switch to the other flows.
@dmoraBerlin: When you create the hi-fi mockups, you can include an explicit back navigation (or a cancel button - same effect) from the four subpages back to the landing page. Or, leave it up to the user to user the browser ◀ button. Your call.
cc @mikelong: ...in case that you would like to formalize/publish this UX pattern (or let me know that it already exists). In short, do we use back button, cancel button, browser ◀ button or something else in a case where the user wants to take a step back in a flow?
@hdelalic I am adding cancel buttons to exit the process to return to the landing page. This is the default navigational pattern, however it is not correctly implemented in the import/new project workflows.
As for a back button, that I am still testing as I change the flows of the over all project since the work involved is much larger. Currently there are 55 unique flows in the Import architecture.
One thing I forgot to add, changing the sub pages with cancel/back and top tab tracking can help us map the users to see what's working and what isn't. Previously the sub pages lacked consistent cancel behavior.
Does that mean these specs need to be fixed in scope of this issue by whoever is working on it? This will affect estimation.
Also, looking at the workflow images before and after, it seems to me that the only difference between the two is first landing page + new images on tab pages. Adding a new landing page and keeping everything else the same just adds extra page load to user's workflow. Amount of clicks remains the same, since loaded page will have correct tab selected. Are we sure we wanna do this? To me it looks like tab clicking has been swapped with image clicking, with an additional page load.
@georgekoltsov yes the changes were minimal because currently the new project/import section has a number of UX inconsistencies. For example, clicking back on a browser, doesn't take you to the previous screen, rather, all the way to the entire project directory despite if you did not enter from the directory.
As well, I want analytics tracking to be included in this issue to better understand what users are clicking on in these pages, in order to drive changes with quantitative data. I'm very apprehensive of just removing the tabs for an MVC with out proper entry/exit behaviors, and tracking of those behaviors.
The "landing" page is the primary change, correct. That is based off the idea that we have a place to return to and start from in an effort to track users interacting with the page, as part of the usage tracking.
Tab clicking versus image clicking needs to be addressed because tabs are not the correct UI solution for this feature. As well, page load should be minimal as users are not clicking back and fourth over and over, presumably. Unless you are arguing the addition of the image to the pages? That can be removed, it was added as a way to give context to the page. the current text is not consistent in it's behavior across the 4 tabs, so this was an effort to unify that.
@georgekoltsov regarding the import tab. This is the current behavior on live. However I've corrected the action buttons to conform to our UI standards. As well to allow for analytics tracking.
Before we mark this as workflowready for development I would like to understand what approach we would like to take for this one. We can go with current "HAML + augment with JS" approach or with "pure Vue" approach.
Both approaches have their upsides and downsides:
Pure Vue approach (estimated weight of approach is 3️⃣ ) :
We can quickly reuse our existing Pajamas & Gitlab-UI components build UI consistent with entire GitLab
In future if we expand this page it will be easier to add any complex logic here
HAML + JS (estimated weight of approach is 5️⃣) :
Significantly better user experience (we do not see empty page while we're loading JS bundle)
Need a bit more development effort, since we do not have proper counterparts for Pajamas components in HAML
Might be harder to expand in future
Although I'm a frontend person, I have mixed feelings about this one. From one point of view, it feels for me super annoying to have a blank page with "waiting for load". From other side - creating new project is not so often operation. Personally I prefer to stick with HAML + JS approach, but this is where I definitely would like to have input from others here
minor non-blocking consideration: I'm a bit confused that for example tabs on top does not follow our tabs specs in Pajamas. While I have nothing against that, is there guidelines when we are stepping away from Pajamas? Maybe someone from UX could give me a hint?
@xanf yes you are correct, currently the tabs do not conform to the Pajamas standard. However I am apprehensive in removing them for reasons I stated here .
Unless you mean the visual presentation of the tabs, then yes I would again agree, that they are visually not the same as per Pajamas. And again I am hesitant to change them for an MVC, this was an earlier prototype I had made but I was not sure about it as it moved much of the content below the fold. And I wanted to work with small changes to be sure we could first gain tracking data to be sure of our path forward for bigger changes.
For additional reference as an independent 3rd party that randomly visits the gitlab repo for entertainment, it took me months to notice there were even tabs to select other options - and I'm a super-mega-power-user that explores pretty much every option available to me.
I believe the inVision design shown in the description solves this perfectly, forcing the user to make a choice - instead of defaulting to the custom experience. At the very least implementing just the landing page would be extremely effective - could add some analytics hooks for user funnel/exploration insight to solve hiccups on the sub-pages...
// Edit //
Putting the tabs vertically in-line with the left side of the content like in the screenshot above is also effective, but you again end up with a default state.
@dennis@hdelalic@xanf I think the visuals are ready as far as MVC, I left the "WIP" heading as a guide to indicate that this is an iterative process and will be evolving based on feedback and testing.
@dmoraBerlin I like how you used the existing "document" illustration 👍. I would go with style A. It will create much cleaner spacing next to different elements. Excellent job 💯.
@dmoraBerlin I think WIP in the context you've described is a little confusing, it might lead people to think that the scope in an issue is still not finalized.
I feel it's implicit that everything we do is always iterating as further iterations would be created as follow-up issues.
@hdelalic and I have been discussing this for some time, but I strongly recommend we A/B test this against the existing tab implementation to get more data on if this is truly driving more users to other flows beyond creating a new project.
The Growth section has created an Experimentation Framework for us of which we can utilize to gather and analyze this data.
I'm a bit confused with experimentation framework.
Experiments will be conducted by teams from the Growth Section
Is it ready to be consumed by other teams? It seems "ok" in terms of added complexity and I'm ready to proceed with this framework, just wanted to confirm readiness
@dennis I would agree. I was hoping we could A/B test this, along with the updated tracking to get a better understanding of what users are doing in regards to creating/importing project. I'm hesitant on making large sweeping changes this early.
@dmoraBerlin@amandakhughes for sure. As far as what we'd want to track, I was thinking we could collect metrics on the tab/panel clicks to know whether users are interacting with these at all. That should help us in terms of understanding whether it's truly an issue of discovery, or if users just don't import as much as they create new projects.
@dennis@amandakhughes I would agree. I think we had created a tracking analytics issue to go along with this issue, specifically around tabs, continue/cancel, back, entry/exit. These sorts of clicks would help us understand where users are going.
Will the A/B testing be available for self-hosted as well, or only on gitlab.com?
Also, I assume that the A/B testing will be done with user segments split 50%/50% and that switching all users to A or to B is a configuration change and doesn't require a deployment. Please let me know if I'm wrong.
Will the A/B testing be available for self-hosted as well, or only on gitlab.com?
As per the documentation, it's for GitLab.com. Telemetry on self-managed instances is an entirely different thing which I don't think we've even approached as an org.
Also, I assume that the A/B testing will be done with user segments split 50%/50% and that switching all users to A or to B is a configuration change and doesn't require a deployment.
I typically start with rolling changes out in a smaller percentage, e.g., 10%. We can gradually roll things up accordingly. Of course, if you would prefer to start with 50/50, we could certainly do that.
Adjustments to the experiment are performed via chat ops on Slack 👍
@amandakhughes Do you have any preference on the user segmentation? I am leaning toward 50/50 to start to try to get even data sets as much as possible. I am not tracking any risks that would need to be mitigated by a slow rollout.
@dennis I like the idea of using a smaller percentage to start. But, this may be a silly question, would we be getting the correct data if we go with 10% rather than 50/50? Perhaps there is some math and calculations in there somewhere 😝
If we express the hit rates as %, any size set could be compared to any other size set. However, larger data sets tend to be more accurate (smaller margin of error). So, to get the best overall result, we should try to optimize for the best margin of error for both data sets. This I why I'd like to run this with a 50/50 split.
I think 50/50 is best as new project creation is a relatively infrequent activity compared to other tasks, One would also assume a correlation to account age. However I'm just a 3rd party with no analytics access - still curious tho'!
@amandakhughes you're right that there are calculations in there, but basically you can measure the relative conversion of a given page, and then calculate how long you would have to run a test for a specified segment, e.g., 10% or 50% to reach statistical significance, i.e., we have enough data from the sample size to reach a conclusion.
Long story short, the data will be correct, we may just have to run the experiment longer / calculate results later.
That said, 50/50 is fine with me. Just wanted to explain a little bit more about A/B testing!
@dennis Thank you so much for the explanation. Much appreciated. 😄
I spoke with @hdelalic and we both agree that we should run a 50/50 split for testing. I may have missed this, but how long are we running the A/B test?
@xanf@hdelalic Below are the illustrations for the new import page. I do want to look at the CI/CD icon a bit more and update the line weights to match the creating a project from a template illustration.
In the meantime, these icons should work. Let me know if you have any issues with the files or if there are any questions.
@amandakhughes just in time! I was going to finish this one today, so having completed illustrations is awesome!
@hdelalic while this will be code ready this week, I'm not sure it will pass review in time. I'm putting this as "at risk" now - if things go smooth with another release cut on Monday it still could make it in %13.0. /cc @dennis
@xanf@hdelalic After more thought, let's use the original icon @dmoraBerlin designed. I think there needs to be more time spent exploring the concept of movement. Since we've moved this issue to 13.1, I'll spend next week with exploration and have new illustrations by the end of next week.
Let me know if anyone has any issues with that plan.
@jeldergl We've designed icon illustrations for the project import page and we need to iterate on them a bit. What is the process of creating illustrations and getting them approved? Thanks!
@amandakhughes@xanf Do we have the icons to use for this issue? If the new icons are going to push the delivery, can we update the icons in the next iteration?
@xanf When would you need the latest icon illustrations? If they won't be able to go into this release then I'm OK moving the icon updates to the next iteration.
@hdelalic I will have the icon for CI/CD this morning and then I'd like to run it by a few folks and get their opinions.
@hdelalic I'm suggesting slight tweaks to the designs for the New Project landing page and the project creation/import flow:
Landing Page
My concern after adding the copy to the layout is the icons and text do not look actionable, or clickable. I added a bounding box with a hover state.
Option A - options do not look actionable
Option B - options look actionable
FYI - the inspiration for the large buttons for the New Project landing page came from the Welcome to Gitlab screen:
Create/Import Flows
I am suggesting we remove the tabs once a user makes a decision on how they'd like to create a project. We've heard from users during our interviews that there is some confusion on why the tabs are present. Also, our users said they would likely click a back arrow to return to the previous screen to select a different option. Instead of a back arrow or button, I added breadcrumb navigation.
Also as a side note - while I understand we have a research here and I really love how @amandakhughes approaches to this one, in spirit of our iteration value it would be great to have at least temporary "ok, we stop here" for this issue - it is currently ~"workflow::In dev" and these changes affect code I'm writing.
@xanf I totally understand and hear you on needing a hard stop on this issue. I'm trying to sneak in design tweaks that will improve the experience which I know affects your timeline and process. If there is anything in the designs that would jeopardize your timeline please let me know and we can certainly move it to a future iteration. 😺
I totally had Option B (2x2 large bounded boxes) as my mental image when I first thought about this.
Few clarifying points:
Why not go all the way with the page that inspired you (rectangular boxes with icons on the left)?
How does everyone feel about "Create new project" vs. "Create a blank project"? Breadcrumbs would look a little more logical (New Project -> Create a blank project). I am on the fence here.
❤ the breadcrumbs!
All that said, while would love to see this ASAP, I support @xanf in that we should complete the current issue without delay and then follow up with an issue to make these additional changes.
@xanf, I will let you make the call on what goes into this issue and how many new issues you would like to have for the proposed changes. Would you want to pick those up as soon as this one is completed?
To me, this issue is still "at risk" and past due, so I would want to prevent any additional scope as we intended to have this ready to go in %13.0. Can we schedule these design changes as a follow-up, please?
Why not go all the way with the page that inspired you (rectangular boxes with icons on the left)?
I quickly explored this but wasn't sure it would work with the wide proportions of the CI/CD and import illustrations, so I went with a stacked layout. I tried the horizontal layout again and I actually prefer it. @hdelalic - what do you think?
How does everyone feel about "Create new project" vs. "Create a blank project"? Breadcrumbs would look a little more logical (New Project -> Create a blank project). I am on the fence here.
I prefer "Create a blank project" because you are creating a new project in all of the scenarios so "Create new project" doesn't make sense.
@amandakhughes This issue was brought to my attention because I worked on the cards component in Pajamas. You can use any guidelines there that may be relevant for this design!
ps - as I was catching up on this thread, it looks like @dennis had a comment above that may have been overlooked, just FYI! :)
I do prefer the large buttons/cards, @amandakhughes. The "Welcome to GitLab" was the exact screen I reviewed with @hdelalic when we were first discussing this issue.
@dennis I hear you that the new designs should be moved to a later release and that's totally fine with me. I can create an issue and move the design discussion there. @hdelalic Are you OK with that?
@beckalippert Thanks for your guidance! Does the format of the cards for the "Welcome to GitLab" page follow the correct Pajamas card guidelines? Ideally, we'd be following this exact pattern.
GitLab should remember the project name and visibility level when switching between tabs (or pages if we go with the above design Option B) as noted in this issue #21954 (closed).
Has this previously been discussed? (I vaguely remember hearing about this, so forgive me if so) How soon could we make this update?
@amandakhughes In regard to the CI/CD for external repo icon, I prefer the original one with just the simple connection line. The reason for that is that it is not a one time import in one direction, but a lasting two-way connection between the 2 systems.
@amandakhughes we have an open issue to create a card component in Pajamas, and there was some discussion over there that related to weighing in on this. I had a few thoughts on cards like this that I wanted to share here, and you can find the original thread at gitlab-design#873 (moved).
…here are some things I’ve encountered with clickable cards before…
Such a large click target can cause inadvertent actions. I’ve seen this happen more on mobile when scrolling triggers a click event because the user can only scroll when swiping an actionable element.
Cards are not links, so they often lack the necessary affordance to make them obvious as such. For example, both resting and hover states that match intent.
Content within cards ideally not be interactive in any way since there’s already a click event on the parent, but there are workarounds in the post I linked in the next point.
Accessibility is a huge concern, here’s a great post that walks through some considerations.
So none of the above is unsolvable, but will definitely take some time to work through.
@jeldergl Thanks for pointing this out. Do you have any ideas on what to do until a decision has been made regarding the cards?
I wanted to match the style and pattern from the "Welcome" page layout. In some cases, the user will be going to the New project page directly following the welcome page so it makes sense to stay consistent with the layouts.
@beckalippert@jeldergl@amandakhughes While I really appreciate the discussion (thank you, it was extremely insightful reading about cards - I've never thought about them in such perspective), I'm a bit concerned this issue (which is already in review) is becoming more & more stretched - right now !32606 (merged) is waiting only for UX approval to land. It would be great to have final decision within this week or open a new issue to address cards concern, since this one is already missed-deliverable
@xanf I definitely understand we need to be mindful of needing to make a decision soon. I respect your time and will have final designs for you by the end of the week.
@jeldergl I like adding a link to the cards. Do you think it would be an odd interaction to see cards on the Welcome page and then to see cards with links for the New Project page? Basically, an inconsistent pattern between the two pages.
I'm a little confused why the discussion of the addition of cards to the design system is in this issue. I'm glad we've decided to take care of this in a follow-up but we had already decided this over a week ago?
Looking forward to seeing cards in our design system 😄.
@beckalippert@amandakhughes@jeldergl@tauriedavis How are we defining cards? These don't seem like cards to me because we aren't pulling data in dynamically from a list of things. The number of "cards" on this proposed page will always be 4. We don't have repetitive sub-tasks per card that users will be clicking on. Are these just...containers laid out for easy reading? Would FE use the card component for this, or is there a simpler FE solution that would be a different component altogether?
@jackib We are having a discussion about cards on Monday in the Foundations open office hours! We want to work on defining cards better in order to help answer those questions. Please join if youre interested!
@xanf This discussion 👆 is not a blocker for this issue. We have split off the additional work into this issue, where we can discuss changes to the button behavior. That said, I think that using the future card component on the "New project" page would need to be a separate issue from these two that are already planned for 13.1.
On in-prem GitLab instances, this feature removed the custom "New project guidelines" section that is set in https://gitlab.sds.eu.sony.com/admin/appearance. I think you should either display it back or remove this option from the instance settings.