758437 - Optimize Account Settings page for 320x480

Status: RESOLVED DUPLICATE of bug 783423

(Marketplace Graveyard :: Consumer Pages, defect, P3)

Description

[krupa raj[:krupa]]

steps to reproduce:
1. Launch the Marketplace app @ 320x480
2. Navigate to the Account Settings page (from the link in the footer)

Optimize Account Settings page for 320x480

Note that this does not include setting up pre-auth or Payment Settings

Comment 1

[Maria Sandberg [:mushi]]

Using this bug as a place for the new settings designs.

Note - the visuals on this are not final. We will be working closely with shorlander and the smartell from the creative team to iterate on them and make sure we stay consistent with the style guide.

Moving the content from the header into a settings page. 
The settings page can be reached from the "settings" button from the home screen. 
Account: http://cl.ly/2U0g2m2A3g0l0c203i1k
Purchase history: http://cl.ly/1b1k3k2X400L441X3I0e
About: http://cl.ly/02333L3Q1d081i0r2o0S

1. A sign out button is available for users to sign out of the Marketplace. If no user is signed in (should be a slim use case on mobile), show "sign in" button which would open Persona flow (TBA). 

2. A toolbar (B2G design pattern https://wiki.mozilla.org/File:Gaia_BB_Toolbars_1.png) divides the content into different groups. 

3. The mocks for the account page doesn't show all the fields that the current version has. We can port everything from the "basic info" part and style it in the same way as the rest of the mock. The payment settings will be handled by Blue Via so that shouldn't be in there for B2G. 

OPEN QUESTIONS
- the current account page shows "browser ID email" and "password" fields, does this belong in the Marketplace? For B2G it looks like users will be allowed to sign in with their phone number, what would we show for email then?

Comment 2

[Maria Sandberg [:mushi]]

Also - do we need all the user account fields on mobile? It's much more than most users will ever fill out about themselves.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

(In reply to msandberg from comment #1)

Love the simplicity of these.

> Purchase history: http://cl.ly/1b1k3k2X400L441X3I0e

Do we show refunded apps here? Is this is a list of all the apps installed -OR- is this a list of all of the transaction/app activity?

In a mockup done for desktop (https://bug752586.bugzilla.mozilla.org/attachment.cgi?id=632406) we distinguished between refunded apps. Do we even want those listed on mobile? If not, how will I know if my refund request has been accepted and I haven't been charged?

Also, things get hairy here when we're dealing with in-app purchases *and* (up-front) app purchases. The list can potentially get quite long and difficult tos can.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

Does clicking the gear/settings icon from the homepage (http://cl.ly/2X1r1k011k1Y351Y0s3X) expose a drop-down menu? Or does it take you directly to this settings page? Because if it's the latter, that might be an expensive additional page load if someone knows exactly which settings page he/she wants to visit. Or if that person wants to log out.

Comment 5

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #3)
> Do we show refunded apps here? Is this is a list of all the apps installed
> -OR- is this a list of all of the transaction/app activity?

I imagine that this screen would serve as a place where you could restore your apps from. So, any app that you currently have the right to reinstall should show up. I don't think we need to display receipts for in-app purchases or refunded apps here, that should be handled by the receipt mechanism.  In the future this screen should let the user reinstall a previously purchased app.

> 
> In a mockup done for desktop
> (https://bug752586.bugzilla.mozilla.org/attachment.cgi?id=632406) we
> distinguished between refunded apps. Do we even want those listed on mobile?
> If not, how will I know if my refund request has been accepted and I haven't
> been charged?
> 
> Also, things get hairy here when we're dealing with in-app purchases *and*
> (up-front) app purchases. The list can potentially get quite long and
> difficult tos can.

This should be covered by my comment above.

Comment 6

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #4)
> Does clicking the gear/settings icon from the homepage
> (http://cl.ly/2X1r1k011k1Y351Y0s3X) expose a drop-down menu? Or does it take
> you directly to this settings page? Because if it's the latter, that might
> be an expensive additional page load if someone knows exactly which settings
> page he/she wants to visit. Or if that person wants to log out.

It should load a full page. If we find that users will often go to the same "subpage" we can start remembering state from what they last visited. It looks like for B2G the option of signing out from here will not live in the Marketplace, more on that when I know more.

Comment 7

[Maria Sandberg [:mushi]]

Attachment: .psd - settings

Comment 8

[Wil Clouser [:clouserw]]

Thanks for the designs.  We can continue to use this bug for implementation

Comment 9

[Christopher Van Wiemeersch [:cvan]]

(In reply to Maria Sandberg [:mushi] from comment #5)
> (In reply to Chris Van Wiemeersch [:cvan] from comment #3)
> > Do we show refunded apps here? Is this is a list of all the apps installed
> > -OR- is this a list of all of the transaction/app activity?
> 
> I imagine that this screen would serve as a place where you could restore
> your apps from.

If we don't surface refunded apps, I can see users getting confused when apps just disappear from their list of apps - especially if the user had to request a refund and it may've taken days, weeks to get approved by the developer.

> I don't think we need to display receipts for in-app
> purchases or refunded apps here, that should be handled by the receipt
> mechanism.

I'm not clear how else a user would know about their in-app purchase history. Is this Persona/BrowserID magic?

> In the future this screen should let the user reinstall a
> previously purchased app.

OK.

Comment 10

[Christopher Van Wiemeersch [:cvan]]

(In reply to Maria Sandberg [:mushi] from comment #1)

> Account: http://cl.ly/2U0g2m2A3g0l0c203i1k

I worry about having <label>...</label> replaced by <input placeholder="...">. This might be obvious for fields such as email (http://cl.ly/2u1N2k0l2v1g1G2q441C), but it could get real confusing if a user comes back and tries to change his/her existing settings and can't figure out what each field is for (for example: http://cl.ly/1l1T2j3U1S142X3b031b).

Comment 11

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #9)
> If we don't surface refunded apps, I can see users getting confused when
> apps just disappear from their list of apps - especially if the user had to
> request a refund and it may've taken days, weeks to get approved by the
> developer.

I think the use case of "I want to see all of my purchase history and receipts" is different from "I want to download apps I have already purchased again/to this new device". I believe he purchase history case will be rare and I'd like to move that to rely on receipts instead of something within our UI. In that scenario, a user would get an email confirmation (receipt) when they purchase an app or when a refund goes through. 

> > I don't think we need to display receipts for in-app
> > purchases or refunded apps here, that should be handled by the receipt
> > mechanism.
> 
> I'm not clear how else a user would know about their in-app purchase
> history. Is this Persona/BrowserID magic?

Same thing here, receipts. Every time a user purchases something, there is a receipt generated for it. We can communicate this by email for Persona users, and Telefonica/Bluevia would be responsible for it in the carrier billing case.

Comment 12

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #10)
> I worry about having <label>...</label> replaced by <input
> placeholder="...">. This might be obvious for fields such as email
> (http://cl.ly/2u1N2k0l2v1g1G2q441C), but it could get real confusing if a
> user comes back and tries to change his/her existing settings and can't
> figure out what each field is for (for example:
> http://cl.ly/1l1T2j3U1S142X3b031b).

Agreed. We will need labels for some of the less self-descriptive fields. Could we look over how many of the account fields we actually need? (Per comment 2)

Comment 13

[Davor Spasovski [:spasovski]]

Giving this a milestone so it's not forgotten. The UI work is done but the account settings form currently flakes out when you try to submit.

Comment 14

[Davor Spasovski [:spasovski]]

Krupa has filed specific bugs for what is missing on the settings page. Should we close this as a dupe?

Comment 15

[Christopher Van Wiemeersch [:cvan]]

(In reply to Davor Spasovski [:dspasovski] from comment #14)
> Krupa has filed specific bugs for what is missing on the settings page.
> Should we close this as a dupe?

Sure

Comment 16

[Wil Clouser [:clouserw]]

done!

Comment 17

[Maria Sandberg [:mushi]]

Could I be ccd on those bugs if I'm not already?

Comment 18

[Christopher Van Wiemeersch [:cvan]]

Big ones missing:
* Display Name
* Username
* Notifications
* Currency
* Delete Account

Minor ones missing:
* Location
* Occupation
* Homepage
* Bio

Maybe someone wants to file a new bug? But this doesn't seem done.

Comment 19

[Davor Spasovski [:spasovski]]

I was under the impression, based on my last conversation with mushi, we'd only be able to change the display name and region.

Comment 20

[Christopher Van Wiemeersch [:cvan]]

(In reply to Davor Spasovski [:dspasovski] from comment #19)
> I was under the impression, based on my last conversation with mushi, we'd
> only be able to change the display name and region.

People need to be able to opt out of emails, select their currencies, and delete their accounts. At the bare minimum.

Comment 21

[Andy McKay]

Changing region seems odd since that's stored in a cookie. If I've got X number of fields that stay with me across devices and one that doesn't, that seems odd. If we've got region on this form it should be persisting.

I think we should ignore currency until we know whats going on there.

Comment 22

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #20)
> People need to be able to opt out of emails, select their currencies, and
> delete their accounts. At the bare minimum.

I'd prefer it if we could stop defining what users have to be able to do until we know what is happening with the sign in. For example, if we don't have an email for a user, there will be no need to let them opt out of email. 

Let's sit tight until we know more.

Comment 23

[Christopher Van Wiemeersch [:cvan]]

(In reply to Maria Sandberg [:mushi] from comment #22)
> (In reply to Chris Van Wiemeersch [:cvan] from comment #20)
> > People need to be able to opt out of emails, select their currencies, and
> > delete their accounts. At the bare minimum.
> 
> I'd prefer it if we could stop defining what users have to be able to do
> until we know what is happening with the sign in. For example, if we don't
> have an email for a user, there will be no need to let them opt out of
> email.

But we do on desktop. I'm referring to desktop.

Comment 24

[Maria Sandberg [:mushi]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #23)
> But we do on desktop. I'm referring to desktop.

I guess the name of this bug is misleading then :P
Desktop designs are still not done.

Comment 25

[Davor Spasovski [:spasovski]]

I think this can be closed as a dupe of 783423