codecov / feedback

A place to discuss feedback about the pull request and web product experience.
36 stars 6 forks source link

We'd love your feedback! #1

Closed kylemann closed 11 months ago

kylemann commented 3 years ago

Thanks for dropping by! ๐Ÿ‘‹

We've been iterating and updating the web app experience and would love your feedback about:

We greatly appreciate your time and thoughts - looking forward to hearing from you โค

Codecov team

This issue is intended to share and collect feedback about the tool. If you have support needs or questions, please see our support page.

ghost commented 2 years ago

Oha

nikiizvorski commented 2 years ago

I have a massive problem on the UI actually. I have a branch that shows my coverage without any problems and when i go to main screen where it's the same branch that i setup as default says there are no files to compare and doesn't show my files but shows coverage just files aren't accessible from there.

Otherwise i love Codecov. It's just great! And the new design is great!

jonaldinger commented 2 years ago

@kylemann great to see UI improvements landing. Since you asked, here's some feedback based the things you mentioned you were looking for...

What do you think about the new UI changes?

I just saw the new logged-in landing page for the first time. Definitely a nice improvement! I like the table of repos/date updated/coverage %. Makes it really easy to digest the information at-a-glance, and it's then easy to navigate into each repo ๐Ÿ‘

What are challenges you've experienced?

One thing that's always been confusing for me: personal github account vs. organization within the CodeCov UI. I manage my company's CodeCov account - my company has multiple repos using CodeCov, but I have no personal repos using CodeCov. Often the CodeCov UI will toggle to my personal GitHub Context. It's not always clear when this happens, so I'm frequently left wondering "where did my repos go", "where did my users go", "why does it say I'm not on a paid plan", etc. until I realize the account Context switched. The new Context menu in the top left definitely helps make this more obvious, so nice job there. But it would be even better if the confusion could be minimized further. Some possible solutions could be:

  1. Let me choose a default Context so that anytime I log in, or anytime CodeCov has to pick a single Context to render, it shows me the one that is actually useful for me.

    For example, if I'm on the landing page viewing with a Context of "All orgs and repos" (the default when I log in), I see my company's repos in the list so it feels like I'm operating on my organization. But then if I click the "Settings" tab, it automatically switches to my personal Context without warning and I'm left wondering where my team & billing went.

  2. Let me disable my personal context - I only ever want to see my Organization's Context within CodeCov.

  3. When determining a default Context, favor Contexts that have at least 1 repo over Contexts that have 0 repos.

How do you use the tool today? What parts do you use?

  1. Tracking coverage trends over time per repo (love the giant trend chart for this)
  2. Identifying coverage gaps to help inform where we should be investing further in automated coverage
  3. Managing seat licenses for my team

How could we better help your workflow?

We frequently try to identify the biggest coverage gaps/opportunities. We also consider other aspects like "how valuable is coverage in this area", "how many bugs are we seeing in this area", "will this code be changing anytime soon", etc., but starting with the gap analysis is useful in order to then ask more questions about it. The sunburst chart is helpful here, but for a large repo it can be difficult to hover over all the slices. So I typically use the directory listing instead. The visual "percentage coverage" bars are useful here (in the "Coverage" column of the table), but percentage is relative - if I have 10% coverage on a directory that has 10 lines of code, that's much less of a coverage gap than a directory that has 10% coverage on 10,000 lines of code - but the bar shading makes the coverage look the same for both of those directories. So I wind up sorting the directory table by "lines missed", which tells me where my gaps are in absolute terms. It would be neat if CodeCov could make the absolute coverage gaps more clear in some way. Or maybe you could automatically surface "biggest gaps/risks/opportunities" in some way, like listing the top 10 directories with the most lines missed or similar.

Thanks again for investing further in the UI, and for reaching out for feedback!

CHSchiaffino commented 2 years ago

It would be really nice to have a feature for the coverage display on github repos like a LITE version with a information like this: image

Sometimes is kinda weird to have the chart and only numbers makes it weird idk it would be a beautiful way to handle the coverage on comments, really simple.

Thanks for reading :)

binwiederhier commented 2 years ago

I like the UI, but I've had problems with diffs not showing up and login not working across all domains for a while. I made a video to make the issue more apparent to you:

video

This is for https://github.com/binwiederhier/replbot but it happens on other repos too.

codecovdesign commented 2 years ago

Hello @binwiederhier, @CHSchiaffino, @jonaldinger, @nikiizvorski. Just wanted to thank you all so much for the feedback! I've been sharing the feedback with the team and identifying next steps for resolving the cited issues and designing/iterating on the UX improvements mentioned! We have a lot of upcoming changes so don't hesitate to drop by with thoughts with new UI rolling out. Thanks again ๐Ÿ™

binwiederhier commented 2 years ago

Thanks for responding. For what it's worth. Logging out and logging back in fixed that issue.

Another thing I found a little odd is the new(?) diff view where the lines are not fully highlighted anymore, but only marked red/yellow/green on the side. I can't find that view right now, but I do like the old one where the lines are fully green/red much better.

codecovdesign commented 2 years ago

@binwiederhier I think you may still be seeing the current (not new UI). But if you come across it again, could you drop a screenshot of the section/Ui you're describing. ๐Ÿ™

codecovdesign commented 2 years ago

@nikiizvorski Could you send a screenshot or URL of the UI you are referencing to? I was just trying to identify the issue with our support team and wasn't able to. ๐Ÿ™

ljharb commented 2 years ago

I added this project: https://app.codecov.io/gh/import-js/eslint-plugin-import/ but it isn't showing up on https://app.codecov.io/gh?search=import, despite re-syncing multiple times.

(unrelated, the default branch still seems to default to "master" despite github a) reporting this info in their API, and b) changing the default on new repos to "main" awhile ago)

AlekSi commented 2 years ago

/settings/yaml page prompts me to create codecov.yml file while I already have .codecov.yml that should be okay.

markhm commented 2 years ago

I would like to suggest to start the sunburst graph at the folder level that contains the first actual code file.

Currently, our sunburst graph starts at src/, while our code starts at src/main/java/nl/appname/. To get the richer perspective, we now first need to click.

Arnie97 commented 2 years ago

I would prefer the full line background highlight (in the old UI) instead of a narrow colored gutter on the left. May I please have a chance to get it back?


In some rare cases, the page margins in the new file viewer are totally lost. I think it would happen if the browser was maximized on an exactly 1280px screen.

1280px

Most of the time, the page components flows responsively on resizing of browser window. The following screenshot shows one little bad case.

1024px
codecovdesign commented 2 years ago

@Arnie97 thank you for your feedback! It's greatly appreciated and very helpful.

I would prefer the full line background highlight (in the old UI) instead of a narrow colored gutter on the left. May I please have a chance to get it back?

Yes. The file viewer will soon be seen on the commit details and later on the compare page. As the new UI is released there will be a toggle to view the old UI, while we finalize the new UI transition and collect feedback like this for improvement.

webknjaz commented 2 years ago

Dunno if it's related to your web app update effort but the coverage reports stopped being processed a day or two ago: https://community.codecov.com/t/error-processing-coverage-reports-with-github-actions/3251/4?u=webknjaz. FYI.

webknjaz commented 2 years ago

That turned out to be a bug in the uploader (https://github.com/codecov/uploader/pull/413 / https://github.com/codecov/uploader/issues/411).

Meanwhile, here's a legit new UI bug: CI job links in the Uploads block are non-clickable (the <a> tag is there but there's no href= specified).

codecov-ui-ng-broken-ci-link

codecovdesign commented 2 years ago

@webknjaz Thank you for you note! Followed up with our engineer team and we are actively working on resolving the issue. The former UI is available from the toggle seen in the banner. We will keep this will we continue to release the new UI. Again, appreciate the report, and if you see anything else or other feedback about the new UI, please let me know ๐Ÿ™

vinniefalco commented 2 years ago

I can honestly say that never, in my entire 39 year career of writing software have I ever thought to myself "I wish they would present this information in TWO columns side by side and make the view of my source code more narrow:"

image

vinniefalco commented 2 years ago

image

vinniefalco commented 2 years ago

Microsoft did the same thing to GitHub when they "improved" their UI. They took the title, description, and hyperlink for my project which used to be at the top above the fold, clearly visible and without being truncated - and moved it to the right side in its own narrow column where it is wrapped heavily and with the link truncated (and with the title removed). image

dpelle commented 2 years ago

In the new UI, the source code is not being displayed with correct indentation anymore when source code uses tabs rather than spaces.

I see this problem e.g. with Vim.

It seems that source code is shown as if tabs counted as 4 spaces whereas the default for tabs is traditionally 8 spaces.

Screenshot showing bad indent in CodeCov: new-ui-bad-code-indent

Notice how code inside the 'if' blocks at line 806 or 812 is badly indented. It's messy.

Same source code properly indented in Vim: indent-code-with-tabs-in-vim

The grey ยปโ€ฆ in Vim show tabs.

webknjaz commented 2 years ago

have I ever thought to myself "I wish they would present this information in TWO columns side by side and make the view of my source code more narrow:"

TBH code is text. And text is most readable in narrow columns, that's why newspapers and magazines don't do edge-to-edge lines โ€” it's weird and makes your eyes jump from side to side. (see also: typography)

But it may indeed be reasonable to make the representation more centralized rather than just shifted to the right. Or maybe add an ability to collapse the left column, or introduce some sort of a "Zen mode".

ljharb commented 2 years ago

If that were universally true, books would have multiple columns too. Newspapers optimize for something different than code viewers need to.

webknjaz commented 2 years ago

Books do this too. If it's just "one column", they just adjust the font size or margins not to exceed the maximum readable character length (between 45 and 75 chars).

ljharb commented 2 years ago

Then i think weโ€™ve read very different sets of books :-)

codecovdesign commented 2 years ago

@dpelle Thank you for the feedback, it makes sense. Our team is looking at improving this with upcoming iterations.

codecovdesign commented 2 years ago

๐Ÿ‘‹ @webknjaz @ljharb @vinniefalco Thank you for sharing feedback and different perspectives on the new UI. It helps our team as we are weighing the different tradeoffs for iterations along the way. In the interim, the former UI is still the default and available while we finish releasing and updating all new pages.

And text is most readable in narrow columns, that's why newspapers and magazines don't do edge-to-edge lines โ€” it's weird and makes your eyes jump from side to side. (see also: typography). But it may indeed be reasonable to make the representation more centralized rather than just shifted to the right. Or maybe add an ability to collapse the left column, or introduce some sort of a "Zen mode". they just adjust the font size or margins not to exceed the maximum readable character length (between 45 and 75 chars)

๐Ÿ’ฏ @webknjaz I like this! Another thing we are considering for improved code viewer readability: is having a fluid layout (user can toggle either fluid or fixed). The example below shows a fluid version; which aims to optimize the whole available browser window, while also showing all the elements in space and not time (data hidden behind tabs). Again, the user could toggle in settings between the fluid or fixed. wdyt?

commit_details_fluid
webknjaz commented 2 years ago

@Codecovdesign that sounds reasonable.

One comment, though: the "Uploads" block is not essential in this view, normally I only need it if something goes wrong and I'm trying to figure out if some reports didn't reach Codecov. I don't imagine any other use-cases. That said, I'd maybe show it on request but not by default. OTOH this empties up a lot of space depending on the height of the code section. Which would be fine in a one-column view with equal margins on both sides keeping that content easy to focus on without distractions. In case, when the uploads are not shown, the "Coverage report" block may make sense to be relocated on top of the file content view (and made less tall). I mean, of course, the overall coverage is the most important piece of info about the commit but I've probably seen it before navigating to the commit details page and want to focus on finding out the reason behind the drop or other data, right?

vinniefalco commented 2 years ago

In the interim, the former UI is still the default

it isn't though, the green highlight does not extend across the line, only in the gutter.

dpelle commented 2 years ago

In the interim, the former UI is still the default

it isn't though, the green highlight does not extend across the line, only in the gutter.

Yes, that's also what I see, or is there an option that I missed to switch between the new vs old UI? I work on Vim and for me the new codecov UI is harder to look at mostly because the code looks badly indented with tabs (see my previous comment). But I'd also prefer to highlight in green/red the entire line rather than just the line number in the left margin.

codecovdesign commented 2 years ago

or is there an option that I missed to switch between the new vs old UI?

@vinniefalco @dpelle The toggle is on the commit page top banner on both former/new former_ui new_ui

dpelle commented 2 years ago

@Codecovdesign wrote:

The toggle is on the commit page top banner on both former/new

Ah, I see. I was actually using the old UI until now then! But the old UI was somehow was changed recently as:

If I switch to the new UI, I now see indeed the screen column split mentioned by @vinniefalco. I'm also not a fan either as it wastes vertical space. Furthermore, I'm no longer able to sort files by their coverage or by number of lines. In fact, the new UI does not show the number of lines in source files anymore. The number of lines was important: if I see poor coverage in a file (say < 80%) than I worry less if the files has only few lines than if the file has thousands of line (much of the code is then uncovered).

MetRonnie commented 2 years ago

The names of the builds are missing from the new uploads box

Before:

After:

image

dlebansais commented 2 years ago

The new UI looks good to me.

Just a suggestion: when I work with codecov I look at the coverage of a file, for a particular commit. Then I make changes in the code, go to the process of updating code coverage, then look at the file again. Since my view is for an old, specific commit, I need to switch somehow to the lastest commit, then search for the file again.

It would be nice, if there is no easy way to do that already, to have a view that shows the latest coverage in a file. I would then just refresh the view (ex: F5 in Google Chrome on Windows) to see what changed.

vinniefalco commented 2 years ago

Problems at certain widths

image image image image

vinniefalco commented 2 years ago

Was the color of the middle dot changed? It resembles red more closely now

image

vinniefalco commented 2 years ago

Why do some views let me view by file and others not? Here I can't view by file:

image

But if I go to a commit, I can (icon in top right):

image

I see someone has been playing with colors, the partial coverage dot in the first image is a different color from the second image. I like the original not the new one (a general theme).

vinniefalco commented 2 years ago

Still only highlighting the gutter instead of the whole line

image

rouilj commented 2 years ago

It looks like the commit message is a span and doesn't preserve whitespace. Blech. Also bolding/increasing font for the first "title" line of the commit message could make sense but this is just a horrible blob of text. Even if I add white-space: pre to the span it's too much. I likes the old "show the title" and reveal the rest of the message by clicking on the title. Makes better use of screen real-estate as well.

image

rouilj commented 2 years ago

Also in the commit view, I can see the code but there is no indication of what lines are changed. I see the coverage status but no idea which lines were changed and covered/not covered. (Also note how far down the page I had to scroll to find the first change in the file.)

image

Compare to the current (where I don't have to scroll through tens of lines of code to find what changed):

image

Also show the file contents using the full width of the viewport. The whole discussion about optimal line length is based on reading prose. I am not sure there is any actual research on code reading. For example some lines are 5 characters long and indented with whitespace ( f = 5) while other lines can be 80 characters or longer (if you had longer punch cards 8-)). Having wrapped code lines because I can't see at least 80 characters is annoying.

Also what is the purpose of the check boxes for the covered, uncovered, partially covered? Let's say I want to see partly covered lines. I expect unchecking the uncovered and covered checkboxes will display only partly covered lines. The partly covered lines should show a little context and the ability to expand the context. But it just removes the color. Why so I can scroll down through the entire file searching for the partly covered lines??

When I look at a commit, I want to see what lines have changed (across all files in the commit) and how much of that change is covered/uncovered. I really have no way to do that in the new interface that I can see.

-- rouilj

s0undt3ch commented 2 years ago

https://app.codecov.ionone/ is a 404

This is when clicking the "switch to the new user interface" link

rennokki commented 2 years ago

I got deuteranopia and the red & green nuances on covered/uncovered are killing me.

vinniefalco commented 2 years ago

I got deuteranopia and the red & green nuances on covered/uncovered are killing me.

Do you have any proposed solutions?

rennokki commented 2 years ago

I got deuteranopia and the red & green nuances on covered/uncovered are killing me.

Do you have any proposed solutions?

Mostly, the solution would be a colorblind filter.

Mine is deuteranopia, aka green-red. Others -anopias are based on other pairs or groups. For deuteranopia, usually shades of blue work better or in fact, a color with shades, from lighter to darker.

rennokki commented 2 years ago

At the moment when I wrote the suggestion, I was heading to sleep, but the main idea here is that the uncovered lines can be a lightish blue of rgb(136 138 201) and covered lines can be a strong rgb(29 0 255).

If I have to sum up better accessibility, covered lines can be a strong opaque color while uncovered lines might be really transparent, with an opacity of 0.2-0.3 or something.

When facing accessibility issues like these, shades differentiate better than colors.

Untitled

miparnisari commented 2 years ago

trying to copy-paste the YAML but it's also copying the numbers ๐Ÿ˜†๐Ÿ˜†

Screen Shot 2021-10-28 at 1 38 07 PM

drazisil commented 2 years ago

@Codecovdesign I know I'm heavily biased, but over the weekend I was trying to see why "there was an error processing my reports" and I switched to the new UI and was able to click and download my reports to find they were empty. So much nicer then having to wait all weekend for support to read logs and tell me something I could solve myself a lot faster.

:pray: :1st_place_medal:

drazisil commented 2 years ago

Jump to next uncovered. In long files it may be hard and time consuming to locate the uncovered lines.

My idea, similar to the "jump to next merge conflict" or "jump to next problem", is a "jump to next uncovered section" in the file viewer.

dpelle commented 2 years ago

It used to be possible to give a URL with a line number in the code with #L<line number> at the end of the URL, as in this example, which was meant to highlight and jump to line 3545:

https://app.codecov.io/gh/vim/vim/blob/464393a6961d9b9de2bfe9c05f8e2ae5bdec0293/src/edit.c#L3545

However, it no longer works (it does not jump nor highlight line 3545). I assume the new UI broke it.

vinniefalco commented 2 years ago

I am growing increasingly concerned that this new UI is going to be a downgrade in terms of functionality. I hope I am wrong.