877284 - Add buchet checkboxes to version edit page

Status: VERIFIED FIXED

(Marketplace Graveyard :: Developer Pages, defect, P1)

Description

[Wil Clouser [:clouserw]]

This bug is about adding buchet checkboxes to the version edit page.  (Example version edit page: http://cl.ly/image/153U1W1b1Q3e).  The models already exist, this is just showing a UI

Comment 1

[Chuck Harmston [:chuck]]

Attachment: Proposed: editing features on a hosted app

Comment 2

[Chuck Harmston [:chuck]]

You can only manage versions it the app is packaged:

https://github.com/mozilla/zamboni/blob/master/mkt/developers/templates/developers/apps/status.html#L148-175

For the sake of getting this out there, I'm going to implement the above suggestion for packaged apps, and keep it as it is currently for hosted apps (see attached).

This inconsistency is unfortunate, and we should reconsider this as part of bug 875048

Comment 3

[Chuck Harmston [:chuck]]

Landed: https://github.com/mozilla/zamboni/commit/2b212741b57be8f84effd41b7a3d3d9fc24d01b2

Screenshots here: https://github.com/mozilla/zamboni/pull/800/

Comment 4

[David Bialer [:dbialer]]

I just got around to looking at this list and am not sure it isn't overwhelming for developers, with some things not clearly defined.

I think this list should focus on features that specific hardware features:
screen size (smartphone, tablet, desktop)
touch/mouse
keyboard

and discrepancies APIs that may not be backwardsly compatible.

Comment 5

[David Bialer [:dbialer]]

So for instance, a Contacts API is always there - so not sure we need check box to say it is required.

Comment 6

[Daniel Buchner [:dbuc]]

(In reply to David Bialer [:dbialer] from comment #5)
> So for instance, a Contacts API is always there - so not sure we need check
> box to say it is required.

This is inaccurate - mozContacts is not in our desktop product, and cannot be accessed. Any app that requires the use of mozContacts for normal operation will fail on desktop. It is not a solution to have them simply opt out of a screen size like "desktop", because that will lead to the exclusion of their app being available on those devices even after the mozContacts API is released for that version of the product.

Comment 7

[Wil Clouser [:clouserw]]

We're down to the wire on this and are pushing for a v1 product (ask UX if they are excited about having a huge list of checkboxes).  If you want to make changes, let's talk about priorities and what we can do outside of this bug.  Reclosing since this patch has landed.

Comment 8

[David Bialer [:dbialer]]

This list is very long and seems a bit intimidating.  So if this list is the intersection of all incompatibilities today, it will grow over time, and will add a lot of work to the submission process as non-developers need to use it as well (i.e. publishers, marketing people, bulk submitters).

I am concerned that this is making the whole submission and review process very complicated, very techy, requiring a lot more thought and technical support as some of the terms, while we may use them with specific meaning, are too broad.

We would also need clear definitions of what many of these fields mean like "Apps", or "Time/Clock" (i.e. does the device need a clock or time, or is there a specific API you need?)

I can only see this getting more complicated over time.  Things like "This is meant for Desktop", while doesn't address forward compatibility of platforms that add capabilities, serve today to define the set of features needed.

Can we have UX look at this?

Comment 9

[Daniel Buchner [:dbuc]]

(In reply to David Bialer [:dbialer] from comment #8)
> This list is very long and seems a bit intimidating.  So if this list is the
> intersection of all incompatibilities today, it will grow over time, and
> will add a lot of work to the submission process as non-developers need to
> use it as well (i.e. publishers, marketing people, bulk submitters).
> 
> I am concerned that this is making the whole submission and review process
> very complicated, very techy, requiring a lot more thought and technical
> support as some of the terms, while we may use them with specific meaning,
> are too broad.
> 
> We would also need clear definitions of what many of these fields mean like
> "Apps", or "Time/Clock" (i.e. does the device need a clock or time, or is
> there a specific API you need?)
> 
> I can only see this getting more complicated over time.  Things like "This
> is meant for Desktop", while doesn't address forward compatibility of
> platforms that add capabilities, serve today to define the set of features
> needed.
> 
> Can we have UX look at this?

Some of these concerns are valid, but the part about things getting worse over time is (hopefully) not the case. Over time, as the APIs are ported to desktop and Android and user share of various devices changes, they will drop off the list entirely.

I would love to see the API list grouped by API type/category ;)

Comment 10

[Chuck Harmston [:chuck]]

See also bug 875005

Comment 11

[Iulian Timis]

Verified as fixed in https://marketplace-dev.allizom.org/developers/ on FF24 (Win 7).
Checkboxes were added in version edit page for packaged apps and Edit Listing page - Technical Details section for hosted apps.
Postfix screencast http://screencast.com/t/FwZRmd8ZmuCE
Closing bug.

Comment 12

[David Bialer [:dbialer]]

I will open a new bug for next quarter to improve the UX to eliminate the platform submission choice (ffos, android phone, etc.) and also to only present features that the app is using - which I thought was the original design.

Comment 13

[Christopher Van Wiemeersch [:cvan]]

(In reply to David Bialer [:dbialer] from comment #12)
> I will open a new bug for next quarter to improve the UX to eliminate the
> platform submission choice (ffos, android phone, etc.) and also to only
> present features that the app is using - which I thought was the original
> design.

You can do that, but I'd say wait until bug 875005 lands to see if people are still unhappy with things after I've tha swagga was been brought.

Comment 14

[David Bialer [:dbialer]]

ah didn't see the swagga bug which addresses much of the issues.