48860 - Autofill concepts need serious UI overhaul and rethinking

Status: RESOLVED WORKSFORME

(Toolkit :: Form Manager, defect, P3)

Description

[Blake Ross]

Sorry, but this has been a long time coming.  As far as I'm concerned, we may 
as well have no autofill methods at all, because they're so hard to use and 
figure out that it might just be easier to type in your form information and 
move on.

The success of Internet Explorer's form-filling feature lay not in it ability 
to give the user six different interfaces to control its every aspect, but 
rather in its beautiful simplicity.  Double-click to see a list of saved names 
or just start typing and it intelligently suggests some.  Simple, easy, and 
users are already accustomed to it -- the URL bar functions in a similar manner.

URL bar autocomplete and form fill-in help users in a similar way: by 
remembering what they've desired in the past, and intelligently suggesting it 
again accordingly.  So it's no surprise that they might function in a similar 
manner, to ease the learning curve.  It's a pity, then, that our URL 
autocomplete and form fill-in features function in no where near the same 
manner.  Now the user has two completely different behaviors to learn for 
completing nearly the same action.

Perhaps you still don't know what I'm referring to at this point when I 
say 'form fill-in'.  If not, it's only because I just don't know what else to 
call it.  Autofill? Single Signon? Password Manager? Forms Manager? Wallet? 
Prefill?  Form data capturing?  Where does it end?  By my count, we have six 
interfaces which all seem to do pretty much the same thing to the average 
user.  Two tabs in Password Manager, two tabs in Form Manager, and one 
seemingly random "Stored Form Data" dialog.

I'm sure each dialog has its own nuance of difference, and that each performs 
its own specific function.  Please understand that I'm not filing this for an 
explanation of each component, and then a WONTFIX.  Even if 'Password Manager' 
and 'Forms Manager' are widely different, this isn't obvious to the user.

I realize it's far too late in the game to overhaul into an IE-style form-fill 
now (although this admittedly begs the question of whether a UI spec was ever 
designed and discussed for this feature, or if UI's were just added 
continuously for every needed aspect).  I still think there's time to improve 
upon this feature in some key areas.

We should focus on:

  * CONSOLIDATION
 
      Group everything together that's related, and be sure to clearly 
differentiate between things that aren't.  Get rid of things that aren't needed 
or are confusing.  "Interview" means nothing to me. "Demonstration" means 
nothing to me.  Seems like these types of things need to be in a help file or 
tutorial somewhere, not menu items.  Especially since they give no indication 
that they're websites, and yet they navigate you away from whatever site you 
were on.  "Log Out" means nothing to me (except a crash in PSMGLUE.DLL). Log 
out of what? I don't remember logging in.  "Change Master Password..." means 
nothing to me except just another crash (What Master Password? I don't remember 
setting a password anywhere).  "Obscure Form Data" means nothing to me.  
Heck, "Form Data" itself means nothing to me...except in the context of the 
menu items in the Form Manager submenu.  But wait, isn't that a separate 
feature?

  * REWORDING

      "Form Manager will never preview forms from the following sites before 
pre-filling them for you:" means little to me.  Preview? huh?  And why can I 
only remove items in this dialog, but not add them? How the heck do I add them 
in the first place?  What's the difference between the Forms Manager and the 
Password Manager...can't I fill my password in in a form?

Please understand that I'm not out on some vindicative crusade, I just would 
like to see our form fill-in capabilities cleaner, more usable, and more 
streamlined, so they can compare to those of the competition.  I am willing to 
help throughout this whole process to do whatever it takes for this to happen.

Comment 1

[Stephen P. Morse]

Blake, you raised some very interesting points here.  I suggest that we use this 
bug as a pointer to a list of concrete fixes that we should make to address your 
points.  For example, we should have a bug stating that double-clicking on a 
field should cause it to be autofilled, and have this bug depend on that one.  
For each of the items you raise here, create a separate bug report with a 
concrete suggestion of a fix.

Comment 2

[Blake Ross]

Morse: I'm glad you have an open attitude about it.  I'll get to work filing 
bugs on specific issues, using this as a tracking bug.  Any input from German, 
Matthew, Sarah, Vera or anyone else would be welcome (and appreciated)...

Comment 3

[Blake Ross]

er, and Brendan too of course ;) (sorry, was reading down the cc list)

Comment 4

[Stephen P. Morse]

A few points to make in defense of what we have.  The vast array of names that 
you sited were mostly internal names which the user never sees.  Example, wallet 
and single signon.  The only names the user sees are form-manager and 
password-manager.  Also the wallet feature just became a bit easier to use -- 
see bug 42438 which I just fixed.

BTW, sorry for marking this bug as "assigned" and for setting a tfv.  I just 
assumed it was assigned to me and only now did I realize that it was assigned to 
someone else (Brendan Donohoe).

Comment 5

[Matthew T (active 1999-2002)]

Fixing dependencies. Removing bug 48987, as that is a crasher and not a UI issue. 
Adding bug for the German line ...

Comment 6

[verah (gone)]

My two cents: I'd love to see these features get a UI overhaul that would make 
them really simple to use. *I think that these are really important features.* 
I've been trying to work to make any UI and Help text as simple, consistent, and 
brief as possible. I'll try harder. I wish I could offer some UI suggestions, 
but I'm just not good at that sort of thing!

Comment 7

[Blake Ross]

Everyone: please feel free to file new bugs about the current UI and 
functionality of the Password & Form Managers and mark them as blocking this 
bug.  The notion is that once the bugs that this bug is marked dependent on are 
fixed, Mozilla's Autofill capabilities will be fully functional, usable, and 
easy to understand.

Comment 8

[leger]

Reassigning from bdonohoe to hangas

Comment 9

[hangas]

Sending to Autofill.

Comment 10

[sairuh (rarely reading bugmail)]

spam: mass-moving open password manager (single signon) and form manager
(autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with
this form, so feel free and add me if you want to keep me in the loop with any
(but, pls not all :) of these... will also go thru 'em meself, a bit later...

Comment 11

[Dirk.Freykamp]

It looks like there is no possibility for an web author to surpress the
auto-complete/-fill option.
IE supports an 'autocomplete' attribute eg.
form id="AnmeldungMaske" method="POST" action="PWTest.html" autocomplete="off">
Are there any plans to do s.th. similiar?
I am part of a team developing an html based banking application and a lot of
our customers are quite new to internet technology so that we'd like them to
consciencely use an option after they really understand what they are doing.

cheers,
Dirk Freykamp

PS: If this is not the right place for this question, could s.o. please
    tell me ([e-mail]) where to ask?

Comment 12

[Stephen P. Morse]

I presume you are referring to single-signon (a.k.a password manager) rather 
than autofill (a.k.a form manager).  Form manager never does an automatic 
autfill whereas password manager does.

The issue here boils down to whose browser is it anyway -- the user's or the 
website's.  Shouldn't the user be the one to decide what convenience features he 
would like to use rather than have a website dictate that to him.  As a user I 
want to be able to save username/passwords from whatever website I chose and not 
allow particular websites to opt out on me.

Comment 13

[Dirk.Freykamp]

Hello Morse,

thx for your fast response. I agree with your opinion.
At the end the user should always have complete control.
But it is a lot easier to get an ok from our internal security revision
for an application if we can surpress this single-signon for all supported
browsers. If Mozilla does not have this possibility, they have to eat it :)

Just for information: Our application will run at a site where a lot of 
different branches are hosted. After storing name and pin it does not matter
to which branch you want to go you'll get the sitewise sign-on which is only
correct for one account at a specific branch. So it would be nice to associate
a page with a sign-on. (But I think this is already covered by another bug.)

Cheers,
Dirk

Comment 14

[Marcia Knous [:marcia]]

Netscape nav triage team: based on Steve Morse's pretriage recommendation, this 
is not a beta stopper.

Comment 15

[Simon Fraser [no longer active]]

I want out.

Comment 16

[Loco]

Just want to listen in.

Comment 17

[rob cherny]

also listening ... adding cc

Comment 18

[Jesse Ruderman]

Adding bug 54300, "Auto-fill-related items in document context menu (add 
separator/remove)"

Comment 19

[Alan]

my biggest problem with form fill is forgetting to use it.  
the times i really want to use the Form manager, are when i accidentaly close or
crash a windows or I go back and accidenally click a differnt link and as a
result am unable to go back forward to it.  
So i would very much like for the form data to Automatically save, pehaps every
time i hit return in a form box would be sufficient.   

I write this here as i think it could be addressed best as part of a full
rethink of how the form manager works and could be made generally easier to use
than a specific bug report.  It is the result the interests me not the
implementation.  I want the browser to help protect me from my own carelessness.  

Comment 20

[mozilla]

What about adding support for the vcard stuff IE uses.  It would be widely
implemented in sites:
Fields have hints like vCard.Email , vCard.Home.Zipcode , vCard.Business.Zipcode 

I still don't get why URLs like  https://www.ingdirect.com.au/Client/Main.asp
never prompts to fill in forms.

Comment 21

[Stephen P. Morse]

> What about adding support for the vcard stuff IE uses.

This was implemented a long time ago.  For a list of vCard items supported see
file extensions/wallet/src/vcardschema.tbl.  If this is not working, then file a
separate bug report on it.

> I still don't get why URLs like  https://www.ingdirect.com.au/Client/Main.asp
> never prompts to fill in forms.

Probably because it fails the heuristic that is used to determine an e-commerce
form.  We don't want to prompt on every form submission because you would get
annoying prompts every time you submit a request to a search engine.  On the
other hand, we wanted some prompts for discoverability.  So a compromise was
used whereby we prompt only if we detect certain schemas that are typically used
on e-commerce forms.

Comment 22

[Jeremy M. Dolan]

heuristics? Wow. I knew form manager sucked. But I never really thought about
how much.

Isn't there something we can invent to let form authors explicitly state things
we're trying to guess at?

<input x-group="foo" x-login name="ssn">
<input x-group="foo" name="mothersMaidenName">
<input x-group="foo" name="password">

So when a user double-clicks any box to select a saved form info, Moz can fill
in the other two in the same group with the associated info. Unknown tags
probably invalidate both HTML4 and XHTML, huh?

And the x-login tells the browser to optionally store the saved form input
encrypted. (it would apply to the whole group in this case).

We'd still want heuristics to fall back on, but it's important we let authors
specify their desires, instead of crafting HTML that meets some undocumented
format for triggering password manager, or form manager prompting.

Comment 23

[mozilla]

RE:heuristic that is used to determine an e-commerce
form

Can I suggest that anything with a password field should be remembered?  I can't
think of any password form that shouldn't be rememberd..

Comment 24

[Heikki Toivonen (remove -bugzilla when emailing directly)]

dveditz is the new module owner, reassigning.

Comment 25

[Tom Schneider]

This seems to be approximately the right place to point out
that form filling works only if one is not working with diverse
forms.  If one goes to many different pages and fills out the forms,
then changing an item (such as 'name') on one form messes up the
value on another form!

This is not acceptable.

The solution would seem to be that form filling would have to track
EACH URL.  It does not seem to do this so forms I fill out for one
place mess up the values for another.

Comment 26

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 27

[Justin Dolske [:Dolske]]

The rethought formfill is working out fine, no need for this bug any more.