Closed
Bug 48860
Opened 24 years ago
Closed 16 years ago
Autofill concepts need serious UI overhaul and rethinking
Categories
(Toolkit :: Form Manager, defect, P3)
Toolkit
Form Manager
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: meta)
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•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Reporter | ||
Comment 2•24 years ago
|
||
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)...
Keywords: meta
Reporter | ||
Comment 3•24 years ago
|
||
er, and Brendan too of course ;) (sorry, was reading down the cc list)
Comment 4•24 years ago
|
||
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•24 years ago
|
||
Fixing dependencies. Removing bug 48987, as that is a crasher and not a UI issue. Adding bug for the German line ...
Updated•24 years ago
|
Updated•24 years ago
|
Summary: Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinking → Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinkingkbutler
Reporter | ||
Updated•24 years ago
|
Summary: Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinkingkbutler → Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinking
Comment 6•24 years ago
|
||
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!
Reporter | ||
Comment 7•24 years ago
|
||
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.
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Status: ASSIGNED → NEW
Target Milestone: M20 → ---
Sending to Autofill.
Assignee: hangas → morse
Component: User Interface: Design Feedback → Autofill
QA Contact: mpt → sairuh
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Comment 10•24 years ago
|
||
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...
QA Contact: sairuh → tpreston
Updated•24 years ago
|
Target Milestone: M20 → M25
Updated•24 years ago
|
Summary: Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinking → [y]Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinking
Target Milestone: M25 → ---
Reporter | ||
Updated•24 years ago
|
Summary: [y]Autofill/Single Signon/Password Manager/Forms Manager needs serious UI overhaul, rethinking → [y]Autofill concepts need serious UI overhaul and rethinking
Updated•24 years ago
|
Summary: [y]Autofill concepts need serious UI overhaul and rethinking → Autofill concepts need serious UI overhaul and rethinking
Whiteboard: [y]
Comment 11•24 years ago
|
||
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 (Dirk.Feykamp@extern-sis-west.de) where to ask?
Comment 12•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Netscape nav triage team: based on Steve Morse's pretriage recommendation, this is not a beta stopper.
Keywords: nsbeta1-
Comment 15•24 years ago
|
||
I want out.
Updated•24 years ago
|
Whiteboard: [y]
Comment 16•24 years ago
|
||
Just want to listen in.
Comment 17•24 years ago
|
||
also listening ... adding cc
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 18•23 years ago
|
||
Adding bug 54300, "Auto-fill-related items in document context menu (add separator/remove)"
Depends on: 54300
Comment 19•22 years ago
|
||
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•22 years ago
|
||
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.
Depends on: 168423
Comment 21•22 years ago
|
||
> 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•22 years ago
|
||
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•22 years ago
|
||
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..
dveditz is the new module owner, reassigning.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Comment 25•21 years ago
|
||
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.
Updated•19 years ago
|
Assignee: dveditz → nobody
Comment 27•16 years ago
|
||
The rethought formfill is working out fine, no need for this bug any more.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Core → Toolkit
QA Contact: form-manager → form.manager
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in
before you can comment on or make changes to this bug.
Description
•