Hi James, On Mon, Nov 2, 2015 at 9:58 AM, James Cameron <[email protected]> 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/ >
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
