[Sugar-devel] System alerts ui in sugar [DESIGN]
James Cameron
quozl at laptop.org
Sun Nov 1 17:58:26 EST 2015
Summary: counter proposal, use modal alerts. +Subject-tag [DESIGN].
On Sun, Nov 01, 2015 at 02:59:46PM +1100, Sam P. wrote:
> In sugar, some subsystems need to show an alert to the user
> wherevever they are. Right now, we have 2 systems; the max
> activities limit and Quozl's force power off alerts.
For readers who haven't seen this feature yet, think of it as a logout
failure alert, caused by an activity not responding to session
manager.
It is rare enough that I'm fine with it disappearing if the user
changes view. They can change back to see it again.
The maximum activities limit isn't generally used, so I'm not worried
about it either.
> Currently these are alerts that show in some places but not others.
> They are not system wide alerts, so the user may not always see
> them. Plus there is too much code to make sure they are visible in
> many places. We also have a completely different implantation for
> the full journal alert, which takes up the whole screen.
Yes, this ModalAlert is different because the journal activity starts
without explicit user action, and by the time it does this the focus
may have moved away from the home view.
It is the only alert that isn't triggered by the learner, and the
problem of full journal really does stop the learner, so I'm fine
with it being entirely different.
> It is a mess IMO.
Yes, but not a DESIGN issue, it's a code issue. See below.
> I think that if we come up with a ui for this, then we can hopefully
> get rid of duplicated code!
It is both the duplicated code and the inconsistent methods by which
alerts are displayed. Some view classes have inconsistent alert
handling.
But that isn't actually a learner problem. It's a messy code problem.
There are also alerts that do not need to be global;
- journal, to confirm entry erase,
- journal, to confirm batch operations, and report progress,
- home view list, to confirm activity erase,
- control panel accept, to restart,
- school server registration,
- journal, volume errors, caused by copying errors,
- downgrading an activity,
- view source, to confirm duplicating, and report progress,
- view source, duplicating already duplicated activity,
- activities, such as Chat join, and Browse downloads.
> To get the conversation started, what about a simple idea. Maybe we
> could just have the alert (as in the long ones with buttons on the
> end) pop up along the top of the screen and disable the frame. We
> could give it a red border of a massive shadow (like metacity loves)
> or something. This would block the user from accessing their
> activity toolbar, which would probably make them look at it :) See
> [1]
Thanks, but no, I dislike the idea.
Here's what I think should be done;
- generalise the ModalAlert; at the moment it is journal specific,
- use the ModalAlert for the maximum activities limit; this will
fix your concern in opening paragraph,
- extend the ModalAlert to include a timeout, as a TimeoutModalAlert,
in a similar fashion to how TimeoutAlert is implemented,
- use the TimeoutModalALert for the logout failure message; this will
fix your concern in opening paragraph,
- extend the maximum activities limit to show a list of activities and
let the learner close one,
- simplify the non-modal alert calls and UI object marshalling.
What do you think?
--
James Cameron
http://quozl.linux.org.au/
More information about the Sugar-devel
mailing list