UX real-time display of errors

We have some parts with realtime and some parts that will be realtime but we don't know if we should or not show the user we are polling or if the polling result in an error.

Currently we don't show that we are polling since our loading spinner occupy the all screen and it would be annoying to have a spinning flashing every 30s. We do show an error message if the request goes wrong.

What should we do?

Places we already have real-time behaviour:

• Pipelines Table page
• Pipelines Table in Merge Request Page
• Pipelines Table in New Merge Request Page
• Pipelines Table in Commit Page
• Issue Title in Issue Page
• Deploy boards in Environments Table Page - EE

Places where we'll have real-time:

• Pipeline Graph in Pipeline show page - https://gitlab.com/gitlab-org/gitlab-ce/issues/25226
• Sidebar in Issue Page - https://gitlab.com/gitlab-org/gitlab-ce/issues/29982
• Sidebar in Merge Request Page - https://gitlab.com/gitlab-org/gitlab-ce/issues/29982
• Issue Description in Issue Page - https://gitlab.com/gitlab-org/gitlab-ce/issues/25049
• Merge Request Widget
• Issue and Merge Request State - https://gitlab.com/gitlab-org/gitlab-ce/issues/29978
• Comments and system notes - https://gitlab.com/gitlab-org/gitlab-ce/issues/30458

/cc @tauriedavis

@victorwu do you know if there are more places where we plan to have real time soon?

@filipa can you show a visual of how this is currently represented?

It isn't the user does not know we are polling. No feedback is given.

I can show you how it would be if we showed something: https://gitlab.com/gitlab-org/gitlab-ee/issues/2117 Which I don't think it an option having a loading every 30 seconds showing on the screen.

@markglenfletcher @jschatz1 : Whoever gets to it first, could you add a gitlab-org label for real-time. So we can get a nice view of all real time issues.

changed title from UX real-time to UX real-time display of errors

We do have this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/26308.

@filipa : The general high-level approach I'm thinking (for Discussion) is that we make the issues page pretty real-time everywhere, and then slowly bring those pieces to other places in GitLab. But no specific order / rule on this. As you already listed, some areas need real-time for more urgent use cases (like mr widget), whereas other places it is more nice to have (comments updating). So we'll just prioritize accordingly. I think what you listed is a pretty good for the Discussion group at least.

Instead of showing an error we could show the last state we have It is not a challenge to do it what the architecture we have in Vue components, it's actually super easy

@filipa You said "We do show an error message if the request goes wrong." Where does that happen? What does it look like?

Can we keep the last state and show a connection issue like @dimitrieh suggested in slack?

In https://gitlab.com/gitlab-org/gitlab-ce/issues/26308, there is also the suggestion to show a countdown for when we will try again.

@tauriedavis : Not a fan of the countdown. Seems too intense.

I like https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27842269 simply showing no connection. Only concern though is if a user clicks Refresh, and the browser tries to reload the entire page, but now gets a blank screen instead. So they are even worse off.

So should the two concepts be separated?

• Everything in GitLab should be real-time and we should engender trust from users over time so they just expect it. Once we get really close for GitLab as a product overall, it will be obvious and users don't ever see any negative states for 99% of the time because they are always "connected". So no special design required. UI elements just refresh automatically by themselves with subtle CSS transitions. This is assuming we are designing for customers that have good Internet connections, which I think is good enough for us for now.

• For the 1% of the time when a user is struggling with their Starbucks wifi, we simply show the No network connection indicator. We don't need to show any CTAs because they already trust us that things will go back to normal once they are connected again. We don't want to show any countdown because we don't want to expose the gory details of real-time to the user. Instead, we want to uphold the illusion of instantaneous real-time, when it's really like 30 second near realtime or whatever the interval is. So once the Starbucks wifi is re-connected, the No network connection indicator goes away, and everything is fine again.

So my suggestion above aligns with what @filipa says in https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27842031. The FE constantly polls for updates. When there is no connection, the content on the screen simply doesn't update.

mentioned in issue #30733 (moved)

Your proposal https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27843938 sounds good to me @victorwu. We can adjust if necessary in a further iteration but I think what you say about not exposing real-time makes sense and is a case for not displaying the countdown

mentioned in issue #26308 (closed)

@victorwu @tauriedavis as there are multiple issues discussing real time feedback to users. Let's discuss a general solution here.

As for my answer to https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27844034

Our users are not yet accustomed to real time.. we can not say now we don't need to give feedback (it simply is the easiest way out to do nothing...and wait for feedback after implementation.. so this should actually have had somer UX research done... )

If we were to give feedback though.. i think we need to be so subtle about it, that people only notice it when necessary.

I have a small proposal, which is a far lighter version than https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27842269

In airbnb directness/instantness of being able to book is being taught to the users by showing a little bolt icon:

So what if we show that bolt icon on UI elements/pages that are real time (like MR widget).

We could even extend upon it with the polling refresh rate by showing a circle animating around it. An example of how this could look:

Thinking on this again... i think we are going to have many places where things will either be real time or not... Its not fair to compare it to airbnb, which have this element on repeated items in stead of unique UI throughout the interface...

let's go with https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27845854

@filipa talking about a list of things that should be real-time'd, @dimitrieh created a nice issue with such a list: https://gitlab.com/gitlab-org/gitlab-ce/issues/24429

mentioned in merge request gitlab-com/www-gitlab-com!5529 (merged)

@tauriedavis In pipelines table, if the request goes wrong we show the error state: https://gitlab.com/gitlab-org/gitlab-ce/uploads/9069e70d96936a27464e760b69b27772/Screen_Shot_2017-03-15_at_21.44.51.png

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9978

regarding comment of https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27846581 . I know that both the list in this issue as well as in https://gitlab.com/gitlab-org/gitlab-ce/issues/24429 are incomplete

@victorwu as you are PM for this ;) which issue do you want to keep.. in order to let us work from 1 focussed issue.

mentioned in issue #24429 (closed)

added feature proposal label

@victorwu Only group masters can create group-level labels. We could create one here and promote it later

@markglenfletcher : Please do create a project label here for real-time. Thanks!

added real-time label

mentioned in issue #31593 (moved)

Per https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27842269 and https://gitlab.com/gitlab-org/gitlab-ce/issues/31227#note_27845854, there's no need to display an error message. Just a no network connection message suffices. Closing this for https://gitlab.com/gitlab-org/gitlab-ce/issues/31593.

moved to gitlab#9390

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