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

[James Cameron]

On Mon, Nov 02, 2015 at 08:50:22PM +1100, Sam P. wrote:
> Hi James,
> 
> On Mon, Nov 2, 2015 at 9:58 AM, James Cameron <[1]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?

Yes, that's why it is a separate point in my list.  ;-)

It is to fix the duplication of code in many places for add_alert and
remove_alert, or at least to make that code look cleaner.

> 
> Thanks,
> Sam
>  
> 
>     What do you think?
>    
>     --
>     James Cameron
>     [2]http://quozl.linux.org.au/
> 
> References:
> 
> [1] mailto:quozl at laptop.org
> [2] http://quozl.linux.org.au/

-- 
James Cameron
http://quozl.linux.org.au/