Hi David,
Hi (An)droids (:-),
> The user-visible text is defined in suspend_reason_string()
> in lib/str_util.cpp; e.g.:
> case SUSPEND_REASON_WIFI_STATE: return "not connected to WiFi network";
> case SUSPEND_REASON_BATTERY_CHARGING: return "battery low";
> case SUSPEND_REASON_BATTERY_OVERHEATED: return "battery thermal
> protection";
> (Note: I changed the last 2 based on suggestions here).
>
> Also: there are 15 different conditions in which processing is suspended,
> and any combination of them could be active at a given point.
> We don't try to show all the reasons.
> We check for them in a certain order, and show only the first one we detect.
I don't think it's the best strategy to only show the first reason detected.
For example there are (bad!) web sites where one needs to fill in a form with
multiple fields. When you finish and click on the CONTINUE button, the form
shows the first "error" field where it can't parse the entry. When you fix
that error and click CONTINUE, the form shows the next error field, and so on.
I don't like this bit-by-bit approach and would rather see all the problems at
once, not be spoon-fed them one-at-a-time.
So I would advocate listing ALL of the reasons, not just the first one that is
detected. I realize that this requires more text, and perhaps complicates the
coding a bit. But IMO this provides better information to the volunteer, and
will help avoid/avert frustration. If there are multiple reasons why the app
is not running, let's not hide them from the volunteer, let's try to clearly
display all of them, to keep the volunteer well-informed.
Cheers,
Bruce
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
