1214340 - Big Button mode for Family Friendly Browsing (FFB)

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Profile Handling, defect, P5)

Description

[Allison Naaktgeboren :ally]

Targeting firefox 45.

From the ahacard(#326): " includes bigger buttons, less menu items"

This bug will be limited to tablets only for restricted profile fennec, but with an eye to being extended to nonrestricted profiles for the elderly or visually impaired. Phones, due to already heavily constrained space, may require an altogether different design to make a high quality big button experience.

There is an open question about tying into existing android accessibility apis.

It has been brought to my attention that Bug 1126061, ie using the Toolbar API, work needs to happen first.

Comment 1

[Allison Naaktgeboren :ally]

Also worth noting, I will be on pto until Nov 2nd or so. As we want this in 45, it would be super, duper, awesome to have the starting/initial mocks for this up by then. 

This is probably going to morph into a meta bug. :)

Comment 2

[Allison Naaktgeboren :ally]

I'd like to get the UX folk noodling on what UI we should be focusing on. My put is the urlbar, awesome screen, and prompts/doorhangers. For the 3 most important places to focus to start.

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

I just stumbled across this interesting article:
https://medium.com/@lucasurbas/making-android-toolbar-responsive-2627d4e07129

It's not really about big buttons, but about modifying the toolbar to more closely follow the Material design guidelines. However it describes how a lot of toolbar items and dimensions can be changed by modifying the theme.

So if we are actually going to use Toolbar API and AppCompat.Theme (Go Mike!) then this might be an elegant way to adapt the toolbar without writing much code (I already see me regretting saying this).

Comment 4

[Allison Naaktgeboren :ally]

(In reply to Sebastian Kaspari (:sebastian) from comment #3)
> I just stumbled across this interesting article:
> https://medium.com/@lucasurbas/making-android-toolbar-responsive-2627d4e07129
> 
> It's not really about big buttons, but about modifying the toolbar to more
> closely follow the Material design guidelines. However it describes how a
> lot of toolbar items and dimensions can be changed by modifying the theme.
> 
> So if we are actually going to use Toolbar API and AppCompat.Theme (Go
> Mike!) then this might be an elegant way to adapt the toolbar without
> writing much code (I already see me regretting saying this).

Well, now I know who to send _all_ those reviews to. :)

Mike, since you're working on the AppCompat.Theme, what is your take on the implementation plan Sebastian is proposing?

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Allison Naaktgeboren please NEEDINFO? :ally from comment #4)
now who to send _all_ those reviews to. :)
> Mike, since you're working on the AppCompat.Theme, what is your take on the
> implementation plan Sebastian is proposing?

Waaait. I just wanted to share this intersting article in case you two decide to go with the toolbar API. There are still reasons not to do it (The world is going to burn, maybe).


(In reply to Allison Naaktgeboren please NEEDINFO? :ally from comment #4)
> Well, now I know who to send _all_ those reviews to. :)

I'm okay with that. My review queue is usually quite empty. :)

Comment 6

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Leaving a note here (mostly for my own sanity)...

Talked over Vidyo and we're going to take a step back to revisit what the core issues we're trying to solve here is before stepping too far down a pre-designed path.

So, clearing NI for now until we regroup.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Allison Naaktgeboren :ally PTO(Oct16-Nov2) from comment #4)
> Mike, since you're working on the AppCompat.Theme, what is your take on the
> implementation plan Sebastian is proposing?

The Toolbar API is going to be a lot of work so it's probably not worth blocking on it, though it's worth noting that we'll be redoing this if we don't.

Comment 8

[Allison Naaktgeboren :ally]

(In reply to Anthony Lam (:antlam) from comment #6)
> Leaving a note here (mostly for my own sanity)...
> 
> Talked over Vidyo and we're going to take a step back to revisit what the
> core issues we're trying to solve here is before stepping too far down a
> pre-designed path.
> 
> So, clearing NI for now until we regroup.

How's that regrouping going? I'm back from a nice long PTO and looking forward to hearing where we are on this.

Comment 9

[Allison Naaktgeboren :ally]

:margaret tells me that the regroup has decided there are more important thing for 45, so this is likely to be set down for a while.

Comment 10

[Firefox Bug Husbandry Bot]

Bulk Move: https://bugzilla.mozilla.org/show_bug.cgi?id=1399539

Comment 11

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 12

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.