Closed Bug 696832 Opened 13 years ago Closed 13 years ago

Ux Designs for Menu

Categories

(Firefox for Android Graveyard :: General, defect, P1)

ARM
Android
defect

Tracking

(firefox11 fixed, fennec11+)

VERIFIED FIXED
Tracking Status
firefox11 --- fixed
fennec 11+ ---

People

(Reporter: elan, Assigned: sriram)

References

Details

(Whiteboard: [birch] [Product Approved])

Attachments

(5 files, 1 obsolete file)

Meta bug.
Whiteboard: [birch] [Product Approved]
Assignee: nobody → madhava
More polished mocks and assets are on the way, but this should be enough to start with.
Please use the basic menu layouts, as per the attached mocks

Note some customization of the menu on ICS phones — is this possible to add icons into the menu, to help differentiate page actions from browser actions?

------------

Order of menu items:

Site actions (show icons)
* Refresh
* Forward (if applicable)
* Bookmark (or Remove)
* Share
* Find in Page
* Save as PDF
* Page Info

Browser Actions (no icons)
* Add-ons
* Preferences
* Downloads
Handing over to dev for impl
Assignee: madhava → sriram
As per the documentation, http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources , 
we should have identifiers as 

drawable-ldpi-v8/
drawable-mdpi-v8/
..
..
drawable-xhdpi-v14/

Is this approach fine?
The approach is fine, but let's try to minimize the number of variations. For example, mdpi is the lowest resolution we currently support. Do we need to split based on SDK version? Just make sure we are only building what we actually need.
Usually people don't specify based on SDK versions. The froyo had a grey shadow, that makes it visible on black background. On white background, the shadow is barely visible. They started using the same for gingerbread, if I'm right.

So, usually the list is specified as
drawable-mdpi/
drawable-hdpi/
drawable-hdpi-large/
and so on.

Ian had given different icons for different Android versions. That scared me, and made me think that, "should we specify it based on the SDK version?"
I am not sure if we need to pack 10 different versions of the same icon. This is definitely going to bloat the APK size. We can probably have it in birch (or mozilla-central), and the rel-eng can create different APKs based on the android versions and post different APKs in the market.

The other catch here is that Gingerbread has versions v9 and v10. Honeycomb has v11, v12 and v13. This leaves as creating 2 copies for gingerbread and 3 copies for honeycomb alone.
In short, I feel, the icon resources between froyo and gingerbread can be shared (sorry Ian). This reduces us to lesser resources being shipped in more generic folders.
Surely there are Android guidelines for what menu images to package with an application and have it work on different versions of Android OS.
This option uses "vX" (like v8, v11), to identify the SDK version for the "drawables". The ldpi, mdpi and hdpi are specified for each of the SDK versions (8, 9 and 11). 

This guarantees that the icon we want is being picked. The extra advantage is that, if we want to cut down on the size of the apk based on the android version, in the market, drawable-*-v8 can alone be built for froyo, and so on.

http://developer.android.com/guide/practices/ui_guidelines/icon_design_tab.html - This article uses this kind of approach.

I would also like to try the other option of using drawable-small, drawable-large qualifiers. However I'm not sure if that can be as perfect as this.
Attachment #572690 - Flags: review?(mark.finkle)
Comment on attachment 572690 [details] [diff] [review]
Patch: Option 1: Icons for menus based on the SDK version

A few comments:
* We don't support any ldpi devices. Remove them all.
* v11 is honeycomb and I don't think we support anything but xhdpi, right? Or are you using v11 as a fallback for ICS too?

r- to at least remove the ldpi files, unless you or Ian know why we should support it.
Attachment #572690 - Flags: review?(mark.finkle) → review-
I was looking at the list of directories in SDK v14. They have ldpi values in them. And yes, the ldpi, mdpi, and hdpi in V11 was for supporting ICS.
Is "quit" as a menu item prioritized for v1?

People seemed to ask for it a lot in the market before we had it, but it's possible that's because of our memory usage.
This has the "ldpi" versions removed from the patch.
"Find in page" option has also been removed, however, the icons are left with the patch so that we don't have to search for them (rename them) and add them later.
Attachment #572690 - Attachment is obsolete: true
Attachment #572922 - Flags: review?(mark.finkle)
Attachment #572922 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/projects/birch/rev/35ccca93351e
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
20111109040505
http://hg.mozilla.org/projects/birch/rev/edd8921d5bb8
Samsung Nexus S (Android 2.3.6)
Status: RESOLVED → VERIFIED
These patches were backed while investigating Talos failures.  Now that tests are green again, we will need to reland.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
20111114041052
http://hg.mozilla.org/projects/birch/rev/859ecdfe0168
Samsung Galaxy SII (Android 2.3.4)
Status: RESOLVED → VERIFIED
tracking-fennec: --- → 11+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: