Error checking in Spine Toolbox and Model

[spine-o-bot]

In GitLab by @jkiviluo on Sep 11, 2018, 10:10

We should establish a guideline for error checking (in Wiki). Below is my proposal. What do you think?

1. try to avoid error messages and get the Toolbox and Model to do things the user expected it to do.
2. ask a question and allow to store a default answer as a setting
3. throw a clear error message with instruction what to do instead

[spine-o-bot]

In GitLab by @PekkaSavolainen on Sep 11, 2018, 12:26

I think this is an area that is referred as 'error handling' in the User Experience design field. There are a ton of webpages with 'best practices' on how to deal with this. Here's a couple of things that could be added:

• Don’t blame the user.
• Write like a human, not a robot.
• Make sure errors are clear, and the messages are positioned in a place that is intuitive.
• Make sure users know how to fix said errors.
• Don’t list all errors at the top of the page. Inline validation is a good solution.

Last one is mostly for webpages but we should use inline validation in Spine Toolbox as well.

[spine-o-bot]

In GitLab by @PekkaSavolainen on Sep 11, 2018, 13:04

About logging.debug and logging.error messages

I used to print a lot of debug messages into the console but I think it's a poor practice. If everything is going smoothly, the console should stay silent (debug messages are OK for features in development). Only error messages should appear in console and they should be of the type that give developers more information to fix the error. If there's something that the user should know or would maybe like to know, this should be printed into the application (Event Log) or into some other notification popup message (not available yet, but this could be implemented at some point). There are also some status bar messages in use, but I think they are very easy to miss at the moment.

[spine-o-bot]

In GitLab by @jkiviluo on Sep 11, 2018, 13:20

Yes, all true. I also noticed that the console was bit overwhelming.

[spine-o-bot]

In GitLab by @manuelma on Sep 11, 2018, 16:05

About showing messages in the status bar: I agree we need to do better. This touches the Data Store Form aka treeview. I think we have at least three options here (I'm talking exclusively about the treeview):

• Log into the Event Log of the main application. This isn't optimal since the user should be able to work with this form on full screen.
• Create a new Event Log in the treeview. This will take up space, but we can have an option to hide/show it.
• Use message box. This gets in the way of what the user is doing. We're actually using this at the moment for critical errors, but I'm not satisfied.

[spine-o-bot]

In GitLab by @PekkaSavolainen on Sep 11, 2018, 16:23

By a notification popup message I mean the kind of notifications you see on webpages and mobile apps that are shown for a couple of seconds and then disappear. Maybe that could be a solution for some messages.

[spine-o-bot]

In GitLab by @manuelma on Sep 11, 2018, 16:28

That's a great idea. Any clue on how to do it with Qt?

[spine-o-bot]

In GitLab by @PekkaSavolainen on Sep 11, 2018, 17:01

I guess you have to do it by hand. A borderless widget(Qt.Window) without buttons and no focus. Set some stylesheets on it. Use Qt animations for the fade in/fade out effects and close it with a timer. Should be a walk in the park.

There's a QSystemTrayIcon class but we don't really want that.

[spine-o-bot]

In GitLab by @manuelma on Sep 11, 2018, 17:23

Sounds interesting. I feel the same about QSystemTrayIcon

[spine-o-bot]

In GitLab by @jkiviluo on Sep 12, 2018, 09:51

Sounds good. If possible, don't let the notice to overlap with the Windows taskbar. It's irritating to wait for the notice to go away if you want to access the taskbar.