New UI feedback - worse usability

As far as I can see, there is no other category to start threads to provide feedback about the new UI, so I’ll add mine here. (Perhaps you should add a UI category?) To summarise the below, I fear that by focussing the UI on how CircleCI is structured (pipeline/workflow/job) you’ve blindsided yourselves to the fact that for many use cases, jobs (and thus logs) are the key element, not pipelines/workflows.

  1. The new UI seems quite slow. Particularly when accessing a project for the first time. This is partly because of the jarring “all white” loading screen.

  2. There is no way to see currently running jobs across all projects. This is a vital aspect of the old UI that allows me to view everything going on across the whole company. Obviously, it doesn’t scale to larger companies, but for smaller companies I think it is a vitally useful view that seems to have been discarded (and will make me less productive). The new UI also seems to have removed the view of all jobs per project.

  3. It takes more clicks to see the logs than before. This one is critical as it is what developers do all the time. Having to find the right project in a drop down, then the right pipeline, then click through the workflow before finally getting to the job with the logs. While I fully understand that this matches the structure of the config and Circle CI’s internal database, it isn’t a helpful UI experience at all. Your new UI has made my developers’ daily activities worse.

In many cases, there is only one job in a workflow. The new UI design hasn’t taken that into account, leading to an extra click to go through an entirely pointless workflow page.

It is possible to skip the workflow page, by clicking the small triangle on the pipelines page to see the jobs in the pipeline. But this is not obvious UI design and is a very small location to click on the page, requiring rather precise mouse positioning.

  1. The new UI is quite wasteful with screen space. To make it usable at all, I’ve had to reduce the font size in the broswer using Ctrl-Minus. On the pipelines page, why does each job need an ID on the page? Its not clickable and not interesting information AFAICT. Why does each row need a menu at the end? It takes up a lot of space for something that doesn’t seem useful. The start time and duration also use a lot of space,

The columns also seem badly thought through. The branch name and commit message are typically quite long. Having a narrow column for each of them results in wrapping, using up vertical screen and making them hard to read (the commit message wraps almost all the time). It would make much more sense to have a single wide column with the branch name above the commit message. With two lines per pipeline, the start time and duration could also be stacked in a single column. Finally, with 2 lines per pipeline and stacked columns, you could add a column for jobs, showing two jobs (handling the common case where a workflow has one job).

Here is my sketch of my concept of a better layout:


In my opinion, this UI is not ready to be rolled out as it makes developer tasks harder. However, if you intend to proceed here are two simple/quick changes you could make to mitigate the worst aspects:

  • Turn the pipeline ID into a link that performs the same action as the little triangle, showing the jobs
  • When a pipeline is running or failed, automatically expand the little triangle(s), so developers can get to the logs quicker, maybe showing the failed jobs (and if there are more than 5 jobs in a workflow, perhaps a “see more detail” link to the workflow page)

Really however, I think that bigger changes are needed, as indicated above.

8 Likes

In complete agreement. The new UI is a hot mess in terms of useability at the moment.

1 Like

Hi @jodastephen,

Thanks for all this. Genuinely, this kind of specificity and even a priority ordering of how we can help you is standout feedback. As you’ve taken the time to write such a long-form and thoughtful post, I’ll respond in kind.

Addressing one at a time…

Yes. We are doing a sprint this week to address the highest need areas for performance and also a design for a loading screen that isn’t an all-white page and a spinner.

Yes. We underestimated the magnitude of disruption this would cause some of our users. I take personal responsibility. Especially in a world where microservices are increasingly common, I should have seen this coming.

There were two reasons this happened:

  1. In our extensive UX testing, we watched many developers work exclusively within one project throughout the day. This is backed by data– Statistically, 83% of our users commit to only one or two projects in a week. It would have been a significant ask of the Pipelines API team to build this cross-project retrieval of pipelines and had uncertain ROI. As we started to ship out the new UI it became increasingly clear that while our individual contributor users didn’t commonly find this view useful, team leads and DevOps folks need it.

  2. It would slow page load time. Due to the way our authorizations are built, we have to ping the GitHub API for every project you load to check if you still have access to the repo. We cache GitHub permissions to speed this up, but the cache has to be very short-lived in order to keep people out of projects from which they’ve had their access revoked. We’re working on a refactor of that system but it will take a long time to ship. Thus, if you follow hundreds of projects and we ping that API for every single one, every time you load the Pipelines page, that would be very slow.

We have plans to address both of these concerns and get you a cross-projects view of up to ~20 projects. Our hope is that this will address most of the user stories for a multi-project view we’ve heard. This has been validated by some users already, and you’re encouraged to chime in with your own thoughts. Other use cases like a top-level status view will be addressed through our Insights functionality.

I will do everything in my power to maintain your access to the old UI until we have shipped a cross-project view.

Yes. This has been on our sights to address from the start, and there’s still a fix coming.

We have been building up the new UI with an MVP-alternative process we call the WAFL: Well-Architected, Functionally Limited. Basically it means we have a way better code architecture, but we’re addressing UX needs one at a time, highest-needs first. The clickability of one job in one workflow in one pipeline hasn’t been a top priority up to this point, and performance/cross-project views/step output colorization are still ahead of it.

Hopefully, the team has proved that this is not just talk. We’ve responded to thousands of comments of user feedback and shipped countless incremental improvements over the last year. We’ll continue to do so.

I understand this isn’t the preferred concentration of information for some. For others, they love it and the easier-on-the-eyes view makes the work easier for them. I really liked your redesign though and appreciated the commitment to a solution.

A few statistics to share:

  • 51% of our users have said this new UI makes resolving a failed build easier for them. That’s fairly positive considering the pros of these changes are weighed down by the burden of finding where things are now. But it’s not good enough. We’ll get the number higher before turning off access to the old UI.
  • 33% have said it’s about the same.
  • 16% are saying the new UI makes it harder to resolve a failing build. It sounds like yourself and @ufchrisg are among this minority. You are not abandoned, we’re still working to make this better for you.

Once again, we greatly appreciate this thoughtful and specific post. If you’d like to continue the conversation in real-time, please join us for a webinar tomorrow (3/26). As a bonus, we’re repurposing our conference budget to donate $25 to the non-profit of your choice for each attendee!

All the best,

Kate Catlin
Senior Product Manger, CircleCI

1 Like

Thanks for the reply. FWIW, I think having the pipelines at the top is the right default view, but it needs immediate visible access to the job hyperlink to be usable.

I suspect those looking to retain the insights UI page and those looking for a cross-project view of jobs are a similar group of people. Unfortunately for you, as they are the tech leads and managers they are also probably the people deciding whether to buy CircleCI or move to another provider.

On screen space and layout, here is what the new UI actually looks like in a typical project at standard (Ctrl-0) font size:

I hope that helps you understand the messy view that the new UI design results in and how a 2 line solution would actually use less space.

3 Likes

Without any knowledge about where those statistics come from, they are meaningless. For example, I am not aware of anyone on our team being surveyed and we’ve widely panned the changes internally ever since they became available.

As @jodastephen has pointed out, the new UI requires way too much busy work to get to the most important information we care about with a build. On top of that, the change is so jarring that things, such as rerunning a build, which were previously very simple are now frustrating.

Sure, given enough time we’ll all get comfortable because it’s what we do. However, the best way to make this process less frustrating is to iterate bit by bit, not pull the whole rug out at once.

3 Likes

I utilize this for a number of reasons in the usable UI, but very frequently to locate jobs that are running because SSH is enabled. I’m not sure there is a good way to locate and cancel this jobs now?

This is astonishing to watch play out. I don’t think anyone is in a position to pump the brakes; this bus is going over the edge April 15.

1 Like
  1. One piece of feedback I’d like to add is the Add project workflow.
    While it’s nice that you offer to add a sample .circleci/config.yml into a new circleci-project-setup branch to new users It’s REALLY annoying to myself (and I imagine other experienced users).
    I couldn’t see a way to disable this at either the user or org level. Please either add a “Start building without template” button or allow us to opt out of this feature.

  2. Clicking the Settings cog takes me to the new UI. In the new UI (It maybe due to remebering I was last checking out plan) I cannot see / edit contexts. Being able to manage contexts is a significant part of my role and so this is a critical bug.

1 Like

True point.

I can especially support point 3 (more clicks to see logs).

For point 2 (see all running jobs), there’s an additional user feedback on “CircleCI Ideas” for this. I’m not too much into looking at this overview anymore. But I sometimes could have a use for this, as well.

I have workflows with multiple jobs inside. The UI would be hugely improved if it allowed viewing the status of a job and the workflow at the same time. That is, the workflow status (pipeline diagram) should be displayed at the top of the job page.

This would make it much quicker/easier to follow the progress of the pipeline from start to finish. Currently the workflow page has just the diagram on it, and if I click into a job then I can’t see the workflow any more. This results in a lot of inefficient back and forward navigation.

There also needs to be better navigation between projects. I have many projects and the only way to switch between them is from the dropdown list on the Pipelines page. Why not put them in the left navigation area? It would make that area a lot more useful than it is now (it’s overly dominated by the big “welcome” message that can’t be dismissed!).

One more thing, there’s no way to configure Chat Notifications (Slack etc) in the new Project Settings UI.

This is the single biggest issue for me. I manage or work with about 6-12 projects in a given week. I need an overview of all jobs across the organization (exactly what’s displayed in the current UI). The new UI completely destroys my workflow such that I can no longer use CircleCI. Unfortunately for them, I’m also the one who makes the decisions and performs the migration. If I’m forced to switch to the new UI which prevents me from doing my work, then I’ll have no choice but to move to another service.

As other people have mentioned, the new UI is missing a lot of existing functionality or requires too many clicks/navigation to get to important information. I migrated to CircleCI early 2019 from TravisCI and was blown away by the service. To me, it didn’t feel like there was any time spent learning how to use the UI since almost everything was just better than TravisCI. Admittedly, these are relatively minor issues that can be improved over time. @jodastephen has already provided some great suggestions for improvement.

When I first migrated, I read through the CircleCI documentation (which were great by the way). I’m guessing a lot of other people did so as well, and followed the example configurations. If you look through the “Supported Languages Guide” ( https://circleci.com/docs/2.0/demo-apps/#section=welcome ), almost all of the examples follow a “one job in a workflow” idea. As a result, the new pipeline centric UI displays the following:

The workflow column does not provide any useful information and by switching to the new UI, a lot of people’s existing configurations (taken from CircleCI’s own doc examples) will show up this way in the new UI. It’s strange to see that the design of the new UI is so disjointed from their own documentation and examples.

Big UI redesigns such as this will always be a source of confusion/controversy for existing customers. As a software developer myself, I can appreciate the need for moving a product forward and attempting to deprecate the older version. However, the concerning thing about this whole redesign was the way that it was planned for release. I’ve always opted in to preview the new UI as soon as it was available to me. Unfortunately, I’ve had to revert back because it was missing some vital functionality I needed. I simply thought that it was “being worked on” and opted to keep occasionally checking in. My assumption had always been that the existing functionality I’ve come to rely on would be supported in the new design. However, when it was announced that a forced migration was occurring on April 15th, I realized that those things I needed weren’t going be available in the new redesign. It felt like the rug was about to be pulled out from under me for a new design that was worse for my own workflow.

I’m glad to see that the date for deprecating the old UI has been moved back. Besides having customers provide feedback and receiving the usual replies of: “we’ve thought about that”, “we’re working on that”, “we’re aware of the issue”, etc., is there a complete list of features/functionality that we can expect from the new design before another migration date is planned?

2 Likes

Hello, I have some more feedback on the UI and this seemed like an appropriate thread to post it in.

Comparing one build-by-side, we seem to have lost colours from the new UI which makes it much harder to scan the output for issues.

A side-by-side comparison of one build with the old and new user interface

P.S. Apparently new users can only add one screenshot to posts, so I had to create my table in markdown, and then take a screenshot of it and then upload that…

4 Likes

View Multiple Pipelines at Once?

There doesn’t seem to be a way to view the status of multiple Pipelines at the same time. We use CI/CD code which utilizes multiple Github repositories as it works. The old UI allowed viewing all “jobs” at once and so it was easy to see at a glance which repository was currently being built. In the new UI under the “Pipelines” section, you must select a specific repo from the “Filters” drop-down to view its status. We also have dozens of repositories so not only do I have to select from a drop-down every time but I have to scroll through a short list.

Please provide a higher-level view of all Pipelines. Thank you

1 Like

I just have to add that this exact piece is what I find of the most value in the current UI. Removing it definitely will cause us to evaluate our options.

I understand that the majority of your users may not look at this view and it makes some sense to lower its prominence and I did see that you were looking at options. I feel some sort of rollup view that lets me see at a glance what my services are doing is critical to the success of my engineering group - insights notwithstanding.

1 Like

The lack of colours makes it quite difficult to find what went wrong.

This UI feels very slow to respond compared to the old UI, there’s a very noticeable delay in responding. I also think the new UI is very childish, lots of bright colours and large pictorial elements.

1 Like

On the topic of usability, I would like to add that the general design of the new workflow visualization is welcomed, i.e., improved contrast and larger text. Still, the overall job layout has arguably gotten worse for our more extended workflows.

2 Likes

No matter how many times you say “we’re going to do a sprint” or “I take full responsibilty” it doesn’t help.

There’s one thing that is absolutely certain to anyone who opens the old and the new UI side by side: the new UI consistently shows less information hidden behind significantly more clicks with no contrast and differentiators other than pitch black and white.

And that’s not even addressing the fact that extremely useful things like “a list of all jobs” is now gone. There are more projects in my org than “my projects” and I don’t have to “follow them for quick access”. It’s not a social network.

Just a very quick example:

1 Like

And here’s the new UI:

2 Likes

In the new UI, the job dependency lines in a workflow are kinda unreadable. They cross each other so it’s difficult to track them, and in some cases it’s even ambiguous: does the line from 3rd build job go to integration-tests and then above, or does it go behind integration-tests directly to the deploy above? TBH I liked the old dependency lines more.

(new on top, old on bottom)

And BTW: this is a very simple example. One of my other workflows, with ~30 jobs, is completely unreadable, stretched vertically with a complex web of dependency lines. I had to resize the page to 70% to make it fit a vertical full HD monitor, while with the old UI it takes up about half the monitor height. (I can provide screenshots if needed, but for now I won’t since they’re big)

2 Likes

It’s possible I’m just missing it, but I also don’t see any way of finding jobs re-run with ssh within the new UI. I don’t need to see jobs for all my projects at once, but I used the jobs screen before to see individual jobs re-run with ssh access. I’ve already lost a few jobs in the new UI because once I navigated away from the job page, there was no way to find it again.

They don’t seem to show up as part of the existing workflows, and don’t create new workflows either. Somewhat tangential, since I have to use ssh to debug jobs occasionally it would be really nice to see which jobs I still have a session open with so I don’t accidentally end up keeping an otherwise unlisted job open for a few days (and needlessly running up the cost).

2 Likes