Closed Bug 13925 Opened 25 years ago Closed 24 years ago

Intrusive alerts advertising features.

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: trudelle, Assigned: bugs)

References

Details

Some of the new features in the product advertise their presence with modal
alerts in the middle of an operation the user is trying to perform.  For
instance, I tried to submit a Bugzilla form, and was presented two modal alerts
in succession, telling me about wallet/single signon. What I expected was a list
 of bugs, what I got was two unwanted interruptions. I'm sure this isn't by
design, and want to ensure that it isn't shipped to users this way.
I don't think we designed this way. German is doomed now with other stuff. I
suspected that this one should be assigned to someone else...
Status: NEW → ASSIGNED
German will finalize the UI, but not till much later. I'll let him accpet the
bug though I still suspect someone else should own it. cc cpratt so he can take
a look.
Seems like a "we meant to do that" kind of problem to me. AFAIK this is
exactly what we intended when we decided to add the wallet feature to the
product. This behavior is also almost exactly the same as IE 5.0, btw. shuang,
I'd be tempted to mark this one as INVALID, but you'd probably best double-check
with german or paulmac.
CPratt: please do not mark this invalid, German will get to it eventually.  Of
course someone 'intended' this behavior, but I contend that it is still the
wrong behavior, and should be changed. I sure hope our design does not now
consist of copying IE5, as could be inferred from your comment.  Note that this
bug  specifically references two such modal alerts in succession in response to
the same user action.
yes there is particular attention needed for those wallet features. but since
they are not in beta 1, I will not focus on the dialog flow cleanup for those
right now. I'll tackle those later with Steve Morse and Kevin Yen who are owning
this portion of the project.
I'm not entirely sure if this bug is tracking only the wallet case for filling
in forms or if it is tracking all cases of dialog box 'cascades', but if the
latter then another case can be seen when entering a password required by HTTP
for the first time.

First, click on link to a protected page.

A dialog box comes up, "Enter user name for <name of realm>", with two text
fields labelled username and password, and two buttons labelled ok and cancel.
After that, you get a dialog box explaining that the wallet feature exists, and
would you like to use it Ok/Cancel.
Then another dialog, would you like to remember the password on _this_ form?
If you hit cancel: Would you like to remember this decision for this site?
If you hit ok: could you give us a key then? And after that, Could you repeat
that key?

There are a few other dialogs as well, depending on exactly what you answer at
each point. (And they all provide a cancel button, although exactly how much
is cancelled at each point is not entirely clear.)

This is incredibly confusing! There should be a SINGLE, nice dialog box saying
that this site requires a password, something like this:

   Please enter your username and password for <name of realm>:

   Username: _____________
   Password: _____________
   [ ] Remember this password in future?
   [ ] Encrypt passwords?
       Please enter a key to use for encryption: ____________________
       Please confirm this key by reentering it: ____________________

               [( ACCESS SITE )]     [( CANCEL )]

...where the last checkbox & key fields only appear if the user has not yet
given a key. Please don't use Ok/Cancel (or even Yes/No) dialogs for cases where
a checkbox in a previous dialog would suffice! And definitely don't bring up
dialog boxes telling me that there is a feature, just offer the feature anyway.
Note that the "remember password" check box would default to whatever the user
last said to that checkbox, not always to off or always to on.

cc'ing Matthew Thomas, who is sure to see something wrong with the above (hey,
I'm no interface expert!) and who is likely to know of any bugs of which this
is a duplicate.
Each case should be a separate bug.  This latest case should be high severity, I
think we will lose users if we bludgeon them like that.
Ok, last report split into bug 21324, severity major.
Target Milestone: M16
moving to m16
Assignee: german → rgoodger
Status: ASSIGNED → NEW
I do like py8ieh's last proposal. re-assigning to ben who is currently spending
cycles on wallet, ben feel free to re-assign back to me if your current work does
not cover this aspect...Thanks
in these situations, I like Microsoft's much hated system of putting up a little 
helper window (e.g. Mr Paper Clip):

"It looks like you're filling out a form. Would you like to save the data 
entered in this form for future use blahblah..."

We could set this up a number of ways... we could have a sidebar panel that 
contains this material (a sidebar panel containing context sensitive help might 
be useful in other areas... german I'll mention this to you later when I've 
thought it through some more).. we could have a closable near-chromeless popup 
(nonmodal)...

                       +------------------+
                       | It looks like    |
                       | you're filling   |
                       | out a form...    |
                       |                  |
                       |                  |
+----------------------+--------------------+
| Taskbar                   [ ^ Assistant ] |
+-------------------------------------------+
*** Bug 25129 has been marked as a duplicate of this bug. ***
Excuse my ignorance, but what exactly is this bug covering now? The problem 
covered by py8ieh's suggestion (bug 21324) has been fixed. The wallet is, AFAIK, 
going to use the `German line' transitory toolbar to ask whether the user wants 
Mozilla to remember the form details (which is a much better idea, IMO, than 
either a sidebar panel or a paper clip). What else is there that's putting up 
too many dialogs?
Sorry for not getting in on this discussion sooner, but nobody ever added me to 
the cc list so I didn't even know about it.

I'll stick to the original bug described in this report -- if there are other 
problems, let's put them in separate reports.

The advertisement for the wallet feature was definitely done by design, and with 
agreement of all parties concerned.  It is a one-time box that you get the very 
first time ever that you submit a form.  It does not pop up on every form 
submit, like microsoft's helper windows.

What I don't understand is the comment in the original description about two 
modal alerts.  That was never designed in and I was not aware of that.  If that 
was happening, then it is an outright bug.  Can you give me a scenario in which 
you get two modal alerts about wallet?

Finally, a lot of this has changed in the past few days.  Let me give you some 
history so you can understand what I just changed and why.  It used to be the 
case that on every form submit you would get a pop-up saying "do you want to 
save this form".  People found that annoying so we decided to remove that 
pop-up and require you to explicitly take some chrome action when you wanted to 
save.  But then we had a problem of discoverability so we added the 
advertisement on the first-ever submission of a form.

The change that I just made was to remove that advertisement and revert back to 
the do-you-want-to-save popup on every submission.  But this time I'm being 
clever and analyzing the form first to see if it is the kind of form that the 
user would probably want to save.  The way I'm determining that is to see if he 
has certain useful fields on the form, such as username, address, etc.  And the 
particular fields that we check for is configurable externally.  This change was 
checked into the tree last night.

With all that said, you can probably mark this bug as closed.  But I'll leave 
that for the owner to decide.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
not a priority (just now), pushing out as far as possible.
Status: NEW → ASSIGNED
Target Milestone: M16 → M20
Rather than pushing this out as far as possible, let's close this instead.  The 
items covered here have all been fixed or are no longer relevant (see my comment 
above).  If there is still some specific case that is putting up an "intrusive 
alert", it should be singled out in a separate bug report.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
marking VERIFIED
Status: RESOLVED → VERIFIED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.