Page MenuHome

Reports & Warnings UI
Open, NormalPublic

Tokens
"Love" token, awarded by Tetone."Love" token, awarded by bnzs."Like" token, awarded by EAW."Like" token, awarded by Severin."Like" token, awarded by tintwotin.
Assigned To
None
Authored By

Description

In Blender, we want to improve how the app communicates to the user, for things like warnings, info, reports and progress bars.

We already have several separate systems for this:

  • We have a message popup in the status bar

  • We also have a separate 'Info' editor

We can make this nicer by tying things together more. Here's how.

Info editor improvements

First, we need to add support for displaying messages, warnings and errors inside the Info Editor. We can do this by adding a switch at the top:

When set to Messages, you'll see a list of messages and reports over time.

Currently we have two categories of messages: errors and info, but we can add a third:

This makes it clearer to the user if a message is positive (success), neutral (information) or negative (error):

Each message type has an associated color. In the Info Editor Filter popover we could filter by type.

Status Bar

We can make a few improvements to the Status Bar also:

Click on message to open Info Editor window


By clicking on the message or warning, you could be taken to the Info Editor. Simplest way is to spawn it as a new window.

Persistent error symbol


If an error is unresolved, we can keep an error symbol in the Status Bar, so that the user knows the error still lingers.

Remove file info from Status Bar

Currently there isn't much space to display full info messages and warnings in the Status Bar, because the file info is in the way.

We have received many requests to move the file info elsewhere:

In a vertical list, there would be a lot more space to communicate this kind of information, and we could add a lot more. This could be moved to the viewport, or in a Stats panel in the Scene Properties, for example.

With this out of the way, we have a lot more room for nicer messages and warnings.

Details

Type
Design

Event Timeline

William Reynish (billreynish) lowered the priority of this task from Needs Triage by Developer to Normal.Aug 9 2019, 11:39 AM
William Reynish (billreynish) changed Type from Bug to Design.
William Reynish (billreynish) updated the task description. (Show Details)

Since this gets into the idea of repurposing of the info editor, I'd recommend checking out what we've considered during the UI workshop: https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Info_Editor. The full info editor should always be reachable from the status bar (e.g. a More button could spawn the info editor in full screen, or as separate temp window). So basically the status bar would be the short version of the Info Editor, the latter containing all details.

There are many examples of how other apps handle notifications. For example I like how Visual Studio Code does things:


I.e. a little bell icon with the number of currently valid notifications in the status bar, clicking it lists them. Also, I wouldn't mind if we get rid of the banner thing, and display notifications more conventional. Again Visual Studio Code is a good example: Show them in the lower left, make it easy to dismiss and move them.

Since this gets into the idea of repurposing of the info editor, I'd recommend checking out what we've considered during the UI workshop: https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Info_Editor. The full info editor should always be reachable from the status bar (e.g. a More button could spawn the info editor in full screen, or as separate temp window).

Yes that's part of the idea. Pressing on the notification would open a temp Info window.

There are many examples of how other apps handle notifications. For example I like how Visual Studio Code does things:


I.e. a little bell icon with the number of currently valid notifications in the status bar, clicking it lists them. Also, I wouldn't mind if we get rid of the banner thing, and display notifications more conventional. Again Visual Studio Code is a good example: Show them in the lower left, make it easy to dismiss and move them.

Could do that, although then they would overlap with other editors and content.

Could do that, although then they would overlap with other editors and content.

Right, we wouldn't want to be too intrusive for info or low-importance warning messages. A bit of color and animation can be handy to draw the users eye here, but an overlapping popup would be too much.
OTOH important messages like errors should be intrusive - when we get one, the workflow was already disrupted, the message just exposes and explains that fact. So IMHO a popup is fine here.

Looks useful!

We need to add support for displaying messages, warnings and errors inside the Info Editor. We can do this by adding a switch at the top.

When working with operators you might want to see errors as well. If we add a fourth filter for operators instead of a switch, wouldn't it be both more flexible and more simple?

We have to be careful about making a system where users have to constantly dismiss notifications. Personally I don't like the Visual Studio Code notifications much, or similar macOS and Windows notification systems. This is not due to the implementation, but due to about the large majority of notifications being useless to me. It's tempting for a developer to think that their notifications is very important and must be handled by the user, but all those add up.

Users are not programmers that need to fix every warning or error, and even as programmers we are not great at solving all warnings in the Blender code. The same goes in production, ideally every problem would be solved, but very few people have the discipline to work that way and we can't expect them to.

For persistent errors, I would like to see specific examples of what would be a good use of that. If users can't resolve them easily, it's a bad user experience to have that red icon always there. After a while users will start to ignore those errors. At the moment I can't think of one example that I would consider appropriate as a persistent error.

At the moment I can't think of one example that I would consider appropriate as a persistent error.

Think of things like cyclic dependencies or missing texture file paths.

I don't think those should be persistent errors. In production these things happen, and the person working with the assets is not necessarily able to fix them. Users should be able to easily get an overview of such issues, but that's different.