Page MenuHomePhabricator

msgdispatcher_dispatch_x 'details' and 'more help' button to improve whonixcheck error messages etc. usability
Open, NormalPublic

Description

@bnvk suggested to shrink various whonixcheck error messages. For example...

[ERROR] [whonixcheck] Tor Bootstrap Result:
Whonixcheck gave up waiting after 120 seconds.
Tor Circuit: established
Bootstrapping 5 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"

Possible issues:

  • Is the host's internet connection working?
  • Whonix-Gateway will need a few moments for bootstrapping the Tor network.
  • Do you live in a censored area?

Recommendations:

1.)
Shut down Whonix and try to get the Tor Browser Bundle from https://www.torproject.org
working on your host. If you cannot get the Tor Browser Bundle to work, you will most certainly not get Whonix to work either.

The Tor Browser Bundle is great for testing if you live in a censored area. If you need bridges for the Tor Browser Bundle,
you will need them for Whonix as well.

2.)
Try again: dom0 -> Start Menu -> ServiceVM: sys-whonix -> Whonix Check
or in Terminal: whonixcheck
or in Terminal with debugging: whonixcheck --debug --verbose

3.)
Use arm, connection page two, to see if Tor is connected:
dom0 -> Start Menu -> ServiceVM: sys-whonix -> Arm
or in Terminal: arm

  • to remove "after 120 seconds"
  • to have a Details button that expands upon click
  • to have a More Help button that opens a help file

This requires msgcollector, namely msgdispatcher_dispatch_x (written in python) modifications.

Details

Impact
Normal

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick set Impact to Normal.
joysn1980 added a subscriber: joysn1980.

Another old task

https://github.com/joysn/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher_dispatch_x

Major Change was done

  1. Using QMessageBox instead of QDialog

Reason :- MessageBox easily supports extensible text (Showdetails/Hide Details)

  1. Using own QMessageBox on top of QMessageBox to reset the size of the message box
  2. Use the default icons for Info/Warn/Error instead of /usr/share/icons/oxygen/64x64/status/
  3. User can still supply its own icon and use it.

Please review
Standalone testing can be done using
./msgdispatcher_dispatch_x 'info' 'title' '[INFO] [whonixcheck] Tor Bootstrap Result:' 0
./msgdispatcher_dispatch_x 'info' 'title' '[INFO] [whonixcheck] Tor Bootstrap Result:' 1
./msgdispatcher_dispatch_x 'error' 'title' '[ERROR] [whonixcheck] Tor Bootstrap Result:' 0
./msgdispatcher_dispatch_x 'warning' 'title' '[ERROR] [whonixcheck] Tor Bootstrap Result:' 0

I have also tested it by putting it in /usr/lib/msgcollector/
Works fine. Couple of screen shots

expanded_err_msg.png (439×800 px, 57 KB)

collapsed_err_msg.png (244×803 px, 33 KB)

This is mostly a usability question. Wondering if better to only have a Show Details button or to have both, a Show Details and More Help button. How can we make such error messages most helpful for the user?

What about this...


Main (the usual as of before this ticket) popup:

[ERROR] [whonixcheck] Tor Bootstrap Result:
Whonixcheck gave up waiting.

Possible issues:

  • Is the host's internet connection working?
  • Whonix-Gateway will need a few moments for bootstrapping the Tor network.
  • Do you live in a censored area?

Recommendations:

1.)
Try again: dom0 -> Start Menu -> ServiceVM: sys-whonix -> Whonix Check

2.)
See More Help button for more help.


More Help:

Shut down Whonix and try to get the Tor Browser Bundle from https://www.torproject.org working on your host. If you cannot get the Tor Browser Bundle to work, you will most certainly not get Whonix to work either.

The Tor Browser Bundle is great for testing if you live in a censored area. If you need bridges for the Tor Browser Bundle, you will need them for Whonix as well.


Technical details:

Tor Circuit: established
Bootstrapping 5 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"

You could try re-running whonixcheck in Terminal:
whonixcheck

Use arm, connection page two, to see if Tor is connected:
dom0 -> Start Menu -> ServiceVM: sys-whonix -> Arm
or in Terminal: arm

Check /var/run/tor/log

Any opinions? Any other proposals?

The issue here is that - msgdispatcher_dispatch_x is a generic script, which displays the message that comes to it.
Now, the question is - what is the best way to find out a generic way to split a message into the below three parts

  • Part that comes inside message being displayed
  • Part that comes inside 'Show Details"
  • Part that comes inside 'More Help'

What I did was to modify this script to find a generic way to split the message into such a way that we have two parts -

  1. Part that is displayed by default
  2. Part that is comes with "Show Details"

Now, coming to your proposal. Why do you think you should differentiate between "Details" and "more help". Don't you think there is no line between them? After all
Now, the question is how do we implement your proposal. I think it is a much larger change.

  1. We need to formalize all message so that we have 3 parts to it.

a) Default Message
b) Details
c) More Help

And this should be done to all the messages.
Once done, we can probably implement that too.

Personally I feel that there is very hazy line between "Details" and "More Help". It is not very intuitive to tell what comes under what category. "Details" is all about "More". My 2 cents.

Let me know what you think about refurbishing all the messages that is being used by "msgdispatcher_dispatch_x"?

The issue here is that - msgdispatcher_dispatch_x is a generic script, which displays the message that comes to it.
Now, the question is - what is the best way to find out a generic way to split a message into the below three parts

  • Part that comes inside message being displayed
  • Part that comes inside 'Show Details"
  • Part that comes inside 'More Help'

The calling script (such as whonixcheck) would pass that by command line option, such as --message "this message", --details "these details", "--mhelp "more help". Or if that does not work well, pass it by environment variables.

Why do you think you should differentiate between "Details" and "more help".

Details are more like technical details. Interesting for advanced users, developers and for bug reports.

Don't you think there is no line between them?

While writing these help messages and gathering output for it, it's hard to think about lines between them. So the calling script (such as whonixcheck) would define which part goes where and then pass it to msgdispatcher_dispatch_x.

Personally I feel that there is very hazy line between "Details" and "More Help". It is not very intuitive to tell what comes under what category. "Details" is all about "More". My 2 cents.

Yes, sure. Perhaps all error messages and help advice should be in the main popup and only technical details being hidden under the details button.