openSUSE / open-build-service

Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs
https://openbuildservice.org
GNU General Public License v2.0
939 stars 440 forks source link

Provide a condensed web view #10705

Open stanislav-brabec opened 3 years ago

stanislav-brabec commented 3 years ago

Is your feature request related to a problem? Please describe. Many of us use OBS for their professional work. We use the project view a lot. We would like much higher information density.

Currently, the default view, the Overview, contains only a list of 10 package names (by default) and a short failure summary. Even such a small amount of information barely fits to the screen.

The Monitor view is even worse, the view is often much wider than the screen. You have to use horizontal scrolling. If you add more packages to the view, the repository names will scroll up out of the screen, and the horizontal scroll bar will scroll vertically out of the screen.

The Requests view is again problematic. Most of the view space is represented by source and target repository names. It is a very boring information. We need following information:

Describe the solution you'd like

Provide information in a more condensed form. Ideally, provide a view with configurable columns.

Here are my ideas of such view:

Generic

Overview columns

Package name: A package name.

Package origin: Link and aggregate can use icons. Discrimination between plain link and link with differences would be useful.

Build status overview: For example: green checkmark: all builds are OK or disabled, orange (or red checkmark): some builds are OK, some failed, red cross: all builds failed, grey cross: no builds/all builds are disabled, black minus: No results yet. Hover will show build summary, click will show a page with detailed results and access to the logs.

I can even imagine that the header of this column will contain expand/collapse icon, and clicking to that will switch to a full Monitor view.

Requests: One or two icons per package. Click redirects to package requests. Hover displays a short request list. Arrow up: outgoing requests exists. Arrow down: incoming requests exist. Other possible shapes: arrow up and down, circle or cross for special requests. The color can represent the request status. Half shaded color represents request that cannot be handled by me. Maybe exclamation mark indicating that something is waiting for me (e. g. review request).

Users: One icon representing: I am a maintainer, I am a bugowner. Click redirects to the package Users. (Maybe a good designer will find a way how to integrate it to the previous column.)

Age: I am OK with the recent implementation. But maybe display the column as a last one.

Monitor columns

Monitor view should fix following GUI design failures:

Ideas for making the monitor view more comprehensive:

Requests columns

As noted above, Source and Target is a bit boring information. See the Overview to see, what we need:

Request #: We use it in the communication a lot, it takes time to cut it from the URL. It could replace magnify icon. Copy request id to the clipboard would be useful feature as well.

Package name: As it is now.

Direction/request type: Incoming/outgoing/a special request (see above for icon ideas)

Source/target (depending on the direction)/contents of the special request: The contents of the request.

Status: Icon. The current status of the request without multiple clicking to the drop down menu.

Users: Icon. Could the request be handled by me? Are there any actions requested from me (e. g. review request)?

Age and the rest: As it is now.

Request in state: Make possible "All pending" (i. e. all that are not in one of final states) and "All" (It will easily answer my question: Did I already submit the package?)

Describe alternatives you've considered

Package name: A color of package name could be used to provide interesting information. (I am not sure, what is the best candidate for the color. Maybe Package origin, maybe Build status overview.)

I am not sure, whether it makes sense to make two comprehensive views (Overview and Monitor), or just a single one with collapse/expand buttons switching between overview and monitor

hennevogel commented 3 years ago

Best issue ever @stanislav-brabec! Thank you for investing this time :heart:

hennevogel commented 3 years ago

Alright, I found some time to work through this. Again, thanks for all the constructive feedback and your ideas, appreciated. Let me try to answer some of the general feedback you had.

Many of us use OBS for their professional work. We use the project view a lot. We would like much higher information density.

I understand what you are saying. We are trying to strike a balance between density and usability here though. Getting as much information onto the pages without overloading people with information. But in general we are on the same track, we are re-thinking the position, weight, and content of many of our workflows. One by one though, currently we focus on the collaboration (login->notification->request review) workflow because we think this is the most important one for openSUSE/SUSE.

Use less space for non-volatile information (like Description of the repository). For example made it collapsed/collapsible.

It's already collapsing if it's higher than 15em (15 x height of the font that is used).

Provide a smaller default font. Possible make the font size and line spacing configurable with more possible values. (This could apply to package view as well.)

The default typography follows usability guidelines for size, line height & length, alignment, spacing, scale and contrast. It's also different for many viewport sizes (we have a responsive interface).

If this is not to your liking (everyone is perceiving this differently), any modern modern browser allows you to change this. From default "zoom" levels to fonts to even special local CSS. Firefox for instance: https://support.mozilla.org/en-US/kb/font-size-and-zoom-increase-size-of-web-pages

Users: One icon representing: I am a maintainer, I am a bugowner. Click redirects to the package Users.

I guess you mean the users tab right? What is the information you are looking for with this? Which role you, who is looking at this list of users, have in this project?

Age: I am OK with the recent implementation. But maybe display the column as a last one.

Can you elaborate what you mean by Age?

I am not sure, whether it makes sense to make two comprehensive views (Overview and Monitor), or just a single one with collapse/expand buttons switching between overview and monitor

Not sure I get what you mean. We have two pages. Both are tabs. Tabs are collapse/expand. Right?

I will follow up soon about the specific feedback for the Overview, Monitor and Request pages. Let us know what you think @stanislav-brabec

hennevogel commented 3 years ago

Project Show Page

Currently, the default view, the Overview, contains only a list of 10 package names (by default) and a short failure summary. Even such a small amount of information barely fits to the screen.

I guess by screen you mean content above the fold (without scrolling)? Because the "screen" on the web is endless scroll-able right? So if you think about the fold, you are right. The Project Overview page does not have a very well thought out information hierarchy. A re-design for it is in our backlog, although not with a very high priority currently.

BTW the default amount of packages shown 25 (datatables saves your personal settings in a cookie).

Package name: A package name. Package origin: Link and aggregate can use icons.

This is what is already there with labels right?

Screenshot from 2021-02-18 19-39-14

Discrimination between plain link and link with differences would be useful.

Okay, sounds like a good idea to me. I created branched out a specific feature request in #10788

Build status overview: For example: green checkmark: all builds are OK...

I'm not sure if people would not perceive "just" icons as too little information. Let's run an experiment with this, I branched out a feature request here: #10790

hennevogel commented 3 years ago

Project Monitor Page

The Monitor view is even worse, the view is often much wider than the screen. You have to use horizontal scrolling. If you add more packages to the view, the repository names will scroll up out of the screen, and the horizontal scroll bar will scroll vertically out of the screen.

Yeah this page is basically just a table view of the data we have in the database. It needs a complete redesign. This is in our backlog, but not with very high priority.

  • Use color icons instead of test for the build status, especially for long lists of repositories.
  • In case of many repositories that don't fit the screen width, switch repository names to vertical orientation.

What makes the content to wide is not really the text inside the cells, but the amount of cells. In general, as said above, displaying all of this information in table grid is basically impossible.We tried over the years in many different ways. We also do not consider this an interface that helps users. So we are going to replace it with something else, instead of trying to make the table work.

  • Instead of a separate Last time results query via Apply filters, integrate this information directly to the icons. For example, scheduled/building(/signing) will have a dedicated shape, and its color will represent Last time result.

This is a bit more complicated. "Last time results" means displaying the state of of the last finished build. Ignoring if there is currently a running build that did not finish yet.

hennevogel commented 3 years ago

Project Request Page

The Requests view is again problematic. Most of the view space is represented by source and target repository names. It is a very boring information. We need following information:

Yeah this is basically the same story as the monitor page. It's just the tabular representation of the information we have and not really an interface. I moved your feedback out to his feature: #10791

stanislav-brabec commented 3 years ago

Alright, I found some time to work through this. Again, thanks for all the constructive feedback and your ideas, appreciated. Let me try to answer some of the general feedback you had.

Many of us use OBS for their professional work. We use the project view a lot. We would like much higher information density.

I understand what you are saying. We are trying to strike a balance between density and usability here though. Getting as much information onto the pages without overloading people with information. But in general we are on the same track, we are re-thinking the position, weight, and content of many of our workflows. One by one though, currently we focus on the collaboration (login->notification->request review) workflow because we think this is the most important one for openSUSE/SUSE.

Use less space for non-volatile information (like Description of the repository). For example made it collapsed/collapsible.

It's already collapsing if it's higher than 15em (15 x height of the font that is used). 15 em is very tall, as one has to scroll through in 99% of cases. (It is valid for package maintainers. For people searching for packages, it is the most important part.)

Users: One icon representing: I am a maintainer, I am a bugowner. Click redirects to the package Users.

I guess you mean the users tab right? What is the information you are looking for with this? Which role you, who is looking at this list of users, have in this project? This is a comment for project view package list.

Age: I am OK with the recent implementation. But maybe display the column as a last one.

Can you elaborate what you mean by Age?

Age of the last change.

I am not sure, whether it makes sense to make two comprehensive views (Overview and Monitor), or just a single one with collapse/expand buttons switching between overview and monitor

Not sure I get what you mean. We have two pages. Both are tabs. Tabs are collapse/expand. Right?

The first idea was a more comprehensive package list of the project. The second idea was more comprehensive monitor list of the project. Here I am thinking whether it is possible to merge both views to a single one. Instead of a two different views, I can imagine one view with collapsible detailed build results. But I am not sure whether it is really a good idea.

stanislav-brabec commented 3 years ago

Project Show Page

Currently, the default view, the Overview, contains only a list of 10 package names (by default) and a short failure summary. Even such a small amount of information barely fits to the screen.

I guess by screen you mean content above the fold (without scrolling)? Because the "screen" on the web is endless scroll-able right? So if you think about the fold, you are right. The Project Overview page does not have a very well thought out information hierarchy. A re-design for it is in our backlog, although not with a very high priority currently.

The fold could apply to a long Project description. As you write above, folding applies to 15 lines and above, which is about half of the usable page space.

But the real scroll hell appears in the monitor view.

At 100%, you see only a small fraction of the page, ~10 packages per page. The horizontal scroll bar is the most downstairs outside the viewable area. And the repo title scrolls out. It is hard to use. obrazek

One would expect that more information will be visible by zoom out. But it is not true. Even at 30% size (when nothing could be read), you still have to use scroll bars. Number of scroll bars even increases to 3!

So yes, using a smaller font is easy by using a web page zoom. But it does not make the information more comprehensive. It just adds more empty space. I do not want to learn custom made CSS just to make a usable zoom in and implement "fit to available width". obrazek

Package name: A package name. Package origin: Link and aggregate can use icons.

This is what is already there with labels right? Yes.

I'm not sure if people would not perceive "just" icons as too little information. Let's run an experiment with this, I branched out a feature request here: #10790

This is a summary. Detailed info could be found in other views. In the summary, it is good to see "all green" (build succeeds for all enabled repositories), "There are some requests I can/I cannot handle, etc. You can always click to open a related page or display a bubble with details.

My proposal is simple: Fill blank space with usable information. It could prevent need for deep inspection in some use cases.

There are many use cases when such short summary would be useful: