[Sugar-devel] System alerts ui in sugar [DESIGN]

[Sam P.]

Hi James,

On Mon, Nov 2, 2015 at 9:58 AM, James Cameron <quozl at laptop.org> wrote:

> 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;
>

Yeah I agree.  I don't think that we should change those alerts :)


>
> - 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,


Yes, that sounds like a great idea.


>
> - simplify the non-modal alert calls and UI object marshalling.
>

That seems kind of separate to me.  What do you mean?

Thanks,
Sam


>
> What do you think?
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20151102/7a2021e2/attachment.html>