Closed Bug 813011 Opened 13 years ago Closed 12 years ago

On first launch of the app, it should show an introductory screen

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P4)

All
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:-)

RESOLVED FIXED
blocking-basecamp -

People

(Reporter: pabloUX, Assigned: kgrandon)

Details

(Keywords: late-l10n, Whiteboard: interaction, UX-P1, BerlinWW)

When the Cost Control app is launched for the first time, a screen should appear that introduces the app and allows a user to configure it now or later. It should not go directly into the set-up flow. This screen should appear after a user taps on the credit and data module in the set-up state, or when they tap on the app icon after having changed to a new SIM. An additional screen needs to be added as follows: https://www.dropbox.com/s/fx927jdwpqvhwf3/DU_First_time_setup_V02c_scl.png NOTES: I've noticed the copy on the visuals we have are all in reference to having, or not having a Vivo SIM. But, seeing that we will be launching n countries where Movistar will be present, and may have to plan for a different behavior/appearance of the app based on this.. i think it might be more flexible for us if the text reads as follows (if phone can recognize movistar sim just like we do for vivo): when a new vivo sim enters: (sim icon with V) New vivo SIM inserted Setup phone and data report when a new movistar sim enters: (sim icon with M) New movistar SIM inserted Setup phone and data report (might depend though on country what is possible! Beatriz?) when a non-vivo or non-movistar sim enters: (normal sim icon) New SIM inserted Setup data report
Whiteboard: UX_QA
Priority: -- → P2
Whiteboard: UX_QA → UX_QA, Interations design, Visual design
Priority: P2 → P1
Component: Gaia → Gaia::Cost Control
Incomplete implementation. The cost control app is fairly complex, and this introductory step helps get users up to speed. The app is a cornerstone of our target market value prop, and this is an important element.
blocking-basecamp: --- → ?
Priority: P1 → --
Summary: [Cost control] in the fist launch of the app, it should show and introductory screen → On first launch of the app, it should show an introductory screen
Whiteboard: UX_QA, Interations design, Visual design → interaction, visual design, UX-P1
Hey salva is it already done?
Flags: needinfo?(salva)
This is a new feature. We are several month past the point to add this.
Whiteboard: interaction, visual design, UX-P1 → interaction UX-P1
blocking-basecamp: ? → -
Priority: -- → P4
referencing: wireframe pack: OWD Data Usage V10 20120820.pdf https://www.dropbox.com/s/oyuykn8h79nzkb2/OWD%20Data%20Usage%20V10%2020120820.pdf Page: 42,43 This not a new feature - the introductory screen has been in UX specifications of cost control since August 20th. It is important for orienting users to the function of the cost control app, and allows them to choose to set-up the app at a later date. We definitely need this for users to understand why they should set-up the cost control app and modules.
This is a brand new feature patch. This work should have been complete months ago. We should reevaluate the criticality here. Taking new feature work like this puts the schedule at serious risk. Would you risk shipping the product on time for having this feature?
I don't understand why this wasn't implemented ages ago. It's clearly essential to using and learning this complex app, and now it's at risk for v1. I've reviewed the spec. Given the complexity of the app, if we don't implement this I cannot see how the average target market user will be able to use the Cost Control app. This is supposed to be one of our major FFOS differentiators. If level of effort and risk is low enough, I'd say blocking+, and find a dev to start this _immediately_, before TEF resources are diverted to GeekPhone and well-earned holidays. Chris and Daniel, can you chime in for product here?
blocking-basecamp: - → ?
Whiteboard: interaction UX-P1 → interaction, UX-P1
I take the issue, this is a very simple task and it will land when the refactor land as well. Don't worry.
Assignee: nobody → salva
Flags: needinfo?(salva)
blocking-basecamp: ? → -
Salva, forgive me ignorance, as I unfamiliar with the refactor you refer to. Has that landed yet, and if so, was this issue simultaneously resolved? Thanks!
No, it is not solved. The refactor I refer is bug 816927. I'll try to make a bug fixin marathon during wroking week in Berlin, ;) (Now I'm on vacation).
Whiteboard: interaction, UX-P1 → interaction, UX-P1, BerlinWW
Assignee: salva → kgrandon
Comments: similar to bug 813009, the 'Vivo' part should probably come out of applications-data.js. I'm wondering if the wording of "start to track your money" is as good as we can do that. It just sounded like the opposite of DNT to me at first glance. I know it is, but if we can word that without "track", I think that'd be better.
Keywords: late-l10n
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.