Closed
Bug 838734
Opened 13 years ago
Closed 12 years ago
Change - Use a beautifully styled remember login info app bar
Categories
(Tracking Graveyard :: Metro Operations, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: asa, Assigned: mbrubeck)
References
Details
(Whiteboard: feature=change c=Content_features u=metro_firefox_user p=3 status=verified)
Attachments
(3 files, 1 obsolete file)
Original story available at https://bug831977.bugzilla.mozilla.org/attachment.cgi?id=703545
Updated•13 years ago
|
Whiteboard: feature=change status=for_sprint c=Content_features u=metro_firefox_user p=0 → feature=change c=Content_features u=metro_firefox_user p=0
Updated•13 years ago
|
Assignee: mmucci → mbrubeck
Updated•13 years ago
|
Whiteboard: feature=change c=Content_features u=metro_firefox_user p=0 → feature=change c=Content_features u=metro_firefox_user p=3
Updated•13 years ago
|
Status: NEW → ASSIGNED
Updated•13 years ago
|
No longer blocks: metrov1backlog
Comment 1•13 years ago
|
||
First pass at the login infobar. I think we can get away with only have two text buttons and a close icon for the case where someone just wants it gone and doesn't currently want to decide.
I think we should change the strings from the user story to "Remember Password" and "Not for this Site" to be more specific.
I will put some specs and a few more examples over on bug 838211.
Attachment #711970 -
Flags: feedback?(yuan)
Comment 2•13 years ago
|
||
This seems the right direction to go to me. I like having an icon on the info bar.
We will need to have these notifications designed for snap view as well.
I think showing the question and the close button should be good enough.
Originally my idea was tapping on a snapped info bar unsnaps the application to filled view automatically. But I was told by Asa that FX metro can't unsnap itself to filled view unless the users move the splitter.
Some notes for animations (using the terms from Keynote animation)
1. The information bar should move/slide in from the bottom up quickly, in less than 0.05s.
(Use "moving in" to indicate that this information is related to the whole site)
If the FX app bar is visible, the information bar should come in behind the app bar, and appear on top of the FX app bar.
2. If the users perform an edge swipe, tabs and FX app bar will be dismissed. The information bar should slide down to the bottom of the screen, keep visible until the users perform an action.
3. After the users perform an action on the information bar, the information bar should disappear at its own position. No sliding animation.
Updated•13 years ago
|
Attachment #711970 -
Flags: feedback?(yuan) → feedback+
Assignee | ||
Comment 3•13 years ago
|
||
(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #2)
> We will need to have these notifications designed for snap view as well.
> I think showing the question and the close button should be good enough.
Is the idea that users should unsnap the app to see the buttons?
Another possibility is to display the buttons on their own row in snap view, like we do on phones (which are similarly narrow). If desired we can even use the shorter strings for snapped view and the longer ones for full/filled view.
Reporter | ||
Comment 4•13 years ago
|
||
I don't think close buttons on app bars is a convention in Metro and it will conflict with the Metro toolkit's "clear" X button that is a common convention in app bars. Commands on app bars are supposed to target the content area, not the app bar itself. I recommend we stick to convention here unless we have a really good excuse not to.
For snap and possibly portrait views where the app bar isn't wide, making it twice as tall and stacking the content seems most common on the Metro apps I've tested.
![]() |
||
Updated•13 years ago
|
Summary: Change - Use a beautifully styled remember login app bar → Change - Use a beautifully styled remember login info app bar
![]() |
||
Comment 5•13 years ago
|
||
An quick idea I had today that I hacked together.
Wait two seconds for the animation.
Comment 6•13 years ago
|
||
(In reply to Asa Dotzler [:asa] from comment #4)
> I don't think close buttons on app bars is a convention in Metro and it will
> conflict with the Metro toolkit's "clear" X button that is a common
> convention in app bars. Commands on app bars are supposed to target the
> content area, not the app bar itself. I recommend we stick to convention
> here unless we have a really good excuse not to.
The notification bar doesn't really strike me as the same case as gesture based contextual app bars. It is prompting the user for a response, it isn't invoked by a gesture and it doesn't dismiss the same as other app bars because it's sticky.
I like giving users two textual button choices and close icon instead of three text buttons one of which isn't really a choice; instead it's a button for differing choice. "Not Now" is essentially the same a close icon as far as function the only difference is presentation.
I haven't seen the X icon used for "clear". I am actually surprised they would use that convention considering the X has a pretty strong history as a metaphor for close/cancel.
That said I am not totally opposed to using "Not Now" however it does have the drawback of taking up extra space on every infobar we have.
Reporter | ||
Comment 7•13 years ago
|
||
(In reply to Stephen Horlander from comment #6)
OK. That all makes good sense. Let's go with your design for now and we can revisit if it doesn't fit well. I will add, that aesthetically I think text button, text button, icon button is kind of ugly. That being said, you're the expert here, not me.
![]() |
||
Updated•13 years ago
|
Attachment #712038 -
Attachment is obsolete: true
Updated•13 years ago
|
Updated•13 years ago
|
Updated•13 years ago
|
Component: General → Metro Operations
Product: Firefox for Metro → Tracking
Version: unspecified → ---
Reporter | ||
Updated•12 years ago
|
Priority: P1 → P3
Updated•12 years ago
|
Priority: P3 → P1
Assignee | ||
Comment 8•12 years ago
|
||
I believe this story is complete now that bug 838211 landed.
QA notes:
* Some strings and button placement labels are different in Stephen's mockup than in Asa's prose; Asa said to use the versions in the mockup (see comment 7 and bug 838211 comment 25).
* Some elements of the mockup depend on the new main toolbar UI, and are out of scope for this story. They will be done in story bug 845156.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Flags: needinfo?(jbecerra)
QA Contact: jbecerra
Updated•12 years ago
|
Comment 9•12 years ago
|
||
Tested on 2013-03-08 on nightly built from http://hg.mozilla.org/mozilla-central/rev/cb432984d5ce
- Tested saving passwords on gmail.com and facebook.com
- Tested saving multiple username/passwords on both accounts.
- Tested changing passwords in gmail.com
- Tested toggling the preference to save passwords on/off
- Tested restarting the browser to see that my passwords were pre-filled per site
- Tested that when I had multiple username/passwords I could pick from the list of usernames and that it would fill in the right password which allowed me to log in.
In in this cases the password info bar came up on top with the string contents as described in the story and the options to remember passwords, not for this site, and the X button which dismissed the info bar.
In addition, when changing passwords for gmail.com I got to see the notification bar that allowed me to change the password, not to change, or dismiss the info bar with the X button.
I filed three bugs while testing this:
Bug 849332 can't undo "not for this site"
Bug 849342 toggle remember passwords sometimes does not take effect immediately
Bug 849346 crasher
Status: RESOLVED → VERIFIED
Flags: needinfo?(jbecerra)
Whiteboard: feature=change c=Content_features u=metro_firefox_user p=3 → feature=change c=Content_features u=metro_firefox_user p=3 status=verified
Comment 10•12 years ago
|
||
Went through the following "Change" for iteration #7 testing without any issues. Used the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-05-28-03-09-42-mozilla-central/
- Went through the test cases in Comment 9 and ensured they worked without any issues
- Ensured that the "Password App Bar" is not dismissed when selecting the content area
- Ensured that the user can clear the "Not for this site" selection by clearing the "Private" information using the "Options Flyout"
- Ensured that "Don't Change" doesn't save the new password being inserted
- Ensured that dismissing the "Password App Bar" will not save the password and will appear the second time around
- Saved the password over 30 times without any issues (took effect immediately)
Comment 11•12 years ago
|
||
User Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:25.0) Gecko/20130724 Firefox/25.0
Build ID: 20130724030204
WFM.
Tested on Windows 8.1 preview for iteration 10 using latest nightly from ftp://ftp.mozilla.org/pub/firefox/nightly/2013/07/2013-07-24-03-02-04-mozilla-central/
I followed user story and got expected result, but I see some different options like remember password, not for this site and X.
Comment 12•12 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130808030205
Built from http://hg.mozilla.org/mozilla-central/rev/fd4cf30428b0
WFM
I followed user story and got expected result, but I see some different options like remember password, not for this site and X.
Comment 13•12 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130825030201
Built from http://hg.mozilla.org/mozilla-central/rev/01576441bdc6
WFM
Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in user story and got expected result.
I saw following 3 options:
1. Remember password
2. Not for this site
3. X
Updated•11 years ago
|
OS: Windows 8 Metro → Windows 8.1
Updated•7 years ago
|
Product: Tracking → Tracking Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•