You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 5, 2022. It is now read-only.
In an ideal world we would handle every error in its context and present it to the user in an appropriate way. However, we're not even close to doing that right now and, given that some errors can happen hours after the user actions that might be connected to them, and that other events can happen with no user intervention at all, I don't think we're going to be handling everything any time soon. Right now, when something unexpected happens, there is often zero feedback for the user, which is guaranteed to create feelings of hopelessness and to erode trust in the software. (Users cope much better with "Error X happened" than with everything looking great but, eg, no upload.)
ISTM that the standard solution is to have a generic "event/error" bar, typically at the bottom of the screen, maybe with an option to view or hide. Attached, examples from VS, Sublime and Oxygen, but I think it's hard to find an editor more advanced than Wordpad that doesn't do something like this.
I'm working on a demonstration of an event dispatcher that would, among other things, enable us to filter events and errors into categories and display at least some of them in a user-friendly way. In the meantime, I think the simplest fix is a simple, scrolling box that shows all DBL.Local events. A slightly nicer implementation would have "All" and "Error" tabs, which I think would be fairly easy to do since error events are clearly labelled.
Once we have something basic in place I could concoct a minimal prettyprinter for events that would, at least, present the information without multiple types of parentheses.
Apart from convention, I think the bottom of the screen is a good place for this sort of pane because it provides full width for long messages. (The JS console makes the bundle list quite cramped unless the app is running in quite a wide window, and a lateral log pane would have the same effect.)
Related to this, we should hide the JS console by default as, basically, it scares users. (In NL Emma kept pointing out "errors in red" which were just syntactic highlighting of mundane events.) We could maybe have a "JS Console" "tab" on the proposed status bar that opens the JS console if necessary.
The text was updated successfully, but these errors were encountered:
In an ideal world we would handle every error in its context and present it to the user in an appropriate way. However, we're not even close to doing that right now and, given that some errors can happen hours after the user actions that might be connected to them, and that other events can happen with no user intervention at all, I don't think we're going to be handling everything any time soon. Right now, when something unexpected happens, there is often zero feedback for the user, which is guaranteed to create feelings of hopelessness and to erode trust in the software. (Users cope much better with "Error X happened" than with everything looking great but, eg, no upload.)
ISTM that the standard solution is to have a generic "event/error" bar, typically at the bottom of the screen, maybe with an option to view or hide. Attached, examples from VS, Sublime and Oxygen, but I think it's hard to find an editor more advanced than Wordpad that doesn't do something like this.
I'm working on a demonstration of an event dispatcher that would, among other things, enable us to filter events and errors into categories and display at least some of them in a user-friendly way. In the meantime, I think the simplest fix is a simple, scrolling box that shows all DBL.Local events. A slightly nicer implementation would have "All" and "Error" tabs, which I think would be fairly easy to do since error events are clearly labelled.
Once we have something basic in place I could concoct a minimal prettyprinter for events that would, at least, present the information without multiple types of parentheses.
Apart from convention, I think the bottom of the screen is a good place for this sort of pane because it provides full width for long messages. (The JS console makes the bundle list quite cramped unless the app is running in quite a wide window, and a lateral log pane would have the same effect.)
Related to this, we should hide the JS console by default as, basically, it scares users. (In NL Emma kept pointing out "errors in red" which were just syntactic highlighting of mundane events.) We could maybe have a "JS Console" "tab" on the proposed status bar that opens the JS console if necessary.
The text was updated successfully, but these errors were encountered: