Closed Bug 1006816 Opened 10 years ago Closed 10 years ago

Support unlisted apps (hidden urls)

Categories

(Marketplace Graveyard :: General, defect, P3)

Avenir
x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
2014-08-26

People

(Reporter: robhudson, Assigned: robhudson)

References

()

Details

Attachments

(2 files)

Support "unlisted" apps.  Apps will not show up the Marketplace and are only accessed if the URL is known.

More Info
-------------

Use cases

1. Developers/Operators wishing to do exclusive types of things in certain regions.  Can have 2 apps - 1 public in certain areas and 1 hidden.

2. Enterprise Apps - For companies/people/organizations who don't want their apps listed in the Marketplace but would like to give out a link for installation.

3. Operator Shelf Preview.  Could have a hidden app on it and then make public (using different checkbox)

4. Privately shared apps - for users who wish to share an app with a friend by giving them the URL.

The app would not be available through Marketplace search or public-facing lists like Popular or New. You have to have the URL to know of its existence.  It would be accessible only by direct URL *or* if someone added to their operator shelf (tbd: maybe this also applies to collection?).

This would let us test apps more easily, since they'd be in prod, it would let developers test the page layout (images, icons, text, etc.) before going public, and it would give operators a form of exclusivity where they could publish their app, make it hidden, and then add it to their operator shelf.

There is no special security or access control on the URL - like an unlisted phone number.

clouserw can be champion since he has worked with a few people on what the request is.
I can take a deeper look but I think if we simply expand on our STATUS_PUBLIC_WAITING status this is mostly done already.

"Public but waiting" fits I think still because it means the app has been reviewed but it's not currently displayed publicly. If you know the URL you can see the app details.

I think currently we do limit the installation of "public but waiting" apps to only the developer/owner of the app.

The submission flow UI would also need to be expanded to explain the extended usage of this status (if we indeed do use it in this way). See the screenshot for how it looks now.
Priority: -- → P3
Whiteboard: [repoman]
Assignee: nobody → robhudson.mozbugs
Sounds good, only problems I can see:
* the status doesn't give you a hint what its for, better variable name STATUS_PUBLIC_BUT_NOT_PUBLIC is probably not it.
* if I end up with an app PUBLIC for a particular reason, or by accident, I don't think there's a way to get back into that state, should we add something on to the status page to do that, maybe near this button?

https://www.dropbox.com/s/fkxpvyl3kkmb883/Screenshot%202014-05-07%2016.55.58.png
Added uiwanted keyword since I think we will need to make the checkbox much more prominent and explain what it is used for. And also added some options to be able to publicize/depublicize the app.
Keywords: uiwanted
CC Liz, because she is working with me on the app creation flow.

Is this something that we’d like to do in the current design we have now, or incorporate into the current DevHub flow rework effort?

In the new flow, we have a page for managing package file (in case you’d like to upload a new version of your app) and review/publishing status (in case you’d like to publish said app, or your app got rejected and you’d like to resubmit and explain why).

Thinking out loud: the easiest way that I could think of to implement unlisted app is to have a separate link. This link would appear to the side of the existing “Publish” button, but is less prominent. And it would be called something like “Publish only to people that has the URL. This app will not be publicly listed”.

On the app creation flow we have today, we should change the checkbox into radio buttons to clarify it. So the arrangement becomes:

When should we publish your app?
(*) Publish app immediately after it’s reviewed
( ) Publish app only when I tell it to

Who can see your app?
(*) Public. App is listed on the Marketplace. Everybody can see it.
( ) Private. Only people who you share the URL with can see the app.
I think the current UI (screenshot shown in comment #2 https://bugzilla.mozilla.org/show_bug.cgi?id=1006816#c2) is confusing. Basically the developer is deciding whether to immediately publish the app or to return when the app has been reviewed so they can come back and publish the app manually. 

• Remove publish as soon as reviewed option and require the developer to come back to the Marketplace to publish the app. 
• Keep publish as soon as reviewed option but rather than having a checkbox, have two radio buttons, one that says publish immediately the other that says let me know when it is reviewed and I will publish manually, to make the choice more clear.
• Implement a scheduling option where the developer can input what date they would like to have the app go live (this is what Apple does).

For the original intent of the bug, supporting use cases around unlisted apps, I think there needs to be more research and prioritization done. For example, in the #2 enterprise case we might want to enable people to leave reviews while in the #4 Privately shared apps use case we might not. Would unlisted apps need to be reviewed by the app reviewer team at all? Lots of questions here but something to consider when we redesign the submission flow.
We're mixing 2 issues here: 1) public vs private, and 2) publish now vs later. Bram and I will address now vs later as part of the DevPages redesign we're working on.

Seems easiest to address Public vs Private by way of Bram's suggestion. Here's how it would work:
1. Developer creates app. As part of creating app, dev chooses an App Visibility. See http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_create.jpg

2. Private means the app is not visible or searchable in Marketplace. See http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_create_hover.jpg for info bubble explaining this.

3. When the app is created, it goes through the normal Moz review process. When it's approved, the URL is visible to the developer on the Status page. So he/she can share it with others. URL is not visible on Status Page until review has been approved. See http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_status_private.jpg

4. If app is public, the Status page looks like this: http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_status_public.jpg

5. Developer can switch between Public and Private at any time, post approval.

6. For a Private App, the "Publish App" button is a signal to the developer to complete the process. For them, it means "now my app URL is available to share with others." For a Public App, "Publish App" means "my app will now be visible and searchable in the Marketplace."
One concern I have is that if we add visibility we now have 3 different options for apps that are similar:

1) App delisting: This completely removes the app from the Marketplace and makes the page a 404. It's like the app was deleted but it's reversible by the developer.
2) Publish app: The app has been approved by a reviewer and but is not yet published.
3) Visibility: The app is included in search results and listing pages.

I'm curious if we combine #1 and #2 and make listing/delisting equivalent to publish/unpublish so we have 2 options:

1) Publish/unpublish app: You can choose to publish at approval time or publish yourself. You can unpublish for whatever reason to completely remove your app from the Marketplace without deleting it (URL becomes 404).

Technically this would move to setting the `disabled_by_user` flag on the addon table.

2) Visibility: You can choose to include your app in search results and public listing pages.

Technically this would re-use the status.PUBLIC_WAITING. Searches and listings would filter by status.PUBLIC which excludes the apps with status.PUBLIC_WAITING.
Great point. Can we kill "Delist App"?

So main choices would be Publish App or Delete App. Under Publish App, there are 2 visibility choices: Public or Private. With these results:

1. Delete App = 404
2. Publish Public = listing page, visible and searchable
3. Publish Private = listing page, not visible or searchable

That approach would align with other online interactions, eg for wishlists.

If it's necessary (not sure it is) that the app be "unpublished," we could use a Publish/Unpublish toggle as in these screenshots:
http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_toggle_published.jpg
http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_toggle_unpublished.jpg
http://people.mozilla.org/~ehunt/1006816_unlisted_apps/unlisted_apps_toggle_unpublished_private.jpg

And would add a 4th scenario:
4. Unpublish (public or private) = 404

Does this work?
So, just so I'm clear: the changes proposed in #c8 would:
* make an app that chose not to be published immediately switch in a user_disabled state after approval
* have PUBLIC_WAITING status be essentially the same as PUBLIC in all scenarios, except it wouldn't show up in search results

One concern I do have is that currently apps in a user_disabled state (what we are proposing to mean 'unpublished') are ignored for all intents - their apps aren't reviewed; their manifests aren't check by the cron job - so they could be completely broken.  But unpublished apps do currently, as they can be switched to published immediately.  So we would review and have to reject any such app.  So a developer would either have to delete the app entirely (non-reversible) or wait for us to reject it - they can't say 'ignore this app temporarily'.  In that way unpublished != user_disabled.

Btw, I think this has veered way beyond a simple [repoman] bug - its a significant feature change.
Note, none of the comments above have mentioned packaged apps, which have multiple versions and where each version has a published state, and can be deleted (but I don't believe delisted currently).  
Questions on my mind now:
I could easily imagine a partner request to have certain versions be private and/or unpublished, for example - do we support that?  
What about updates to packaged apps?  Currently that's not possible with a user_disabled state.

Can I see UX and flow for a packaged app?
There is no reason the process described in comment 9 should be any different for packaged apps to end users.
I have taken a shot at defining a PRD considering the inputs in this bug and it really only boils down to 4 user stories for Developers - most of the potential use cases are covered with those stories

Appreciate feedback in the PRD (https://docs.google.com/a/mozilla.com/document/d/1PA7pyi5t-OIC4nZcOGg1SKX0j4L9HC563Y19R37RTIA/edit#) or in this bug.
Thanks all for the feedback and comments. I don't think we need to overcomplicate things too much.

I've made a list of the states from the PRD and the mocks here: https://docs.google.com/a/mozilla.com/spreadsheets/d/1l3uVpXzSiJZepFxJTP53Bs6c298PteyiKG9goLuI2l4/edit#gid=0

In this document I've listed the states, who can see them at different points and how they can transition from one to the other. I've change the suggested names and who can see at one point on that list. I've moved the term Private to represent the fact that no-one can see it and Unlisted to represent the fact that people can see it, but its not listed.

From an implementation point of view, we'll add in a new state: PUBLIC_UNLISTED to reflect this.

I recommend:
* combining the three states (public, private and delisted) into one control, as Elizabeth suggested. The affect of "delist" is as Andrew pointed out, it does the enable / disable flow in the backend, that's subtly different from the rest. This removes the term delist and mixes it up with the rest, since from a developers point of view not that much different. Something like:

http://cl.ly/image/0B1K0j2b0B13

* changing the submit app form as Maureen suggested to give the extra three states:

http://cl.ly/image/1s2t3S1K0j17

And that's it. That's two reasonably simple bugs and can be done in [repoman] without too many concerns.
From an implementation point of view:

* when submitting an app, Private means it goes into the PUBLIC_WAITING state, waiting for the developer to come along and do something.
* when an app is public, Delist means the same as it does now, the app becomes disabled_by_user.

The other two terms, Public and Unlisted remain consistent.
Personally, I prefer we stick with 'Published' rather than 'Public' - we played around with status terms in https://bugzilla.mozilla.org/show_bug.cgi?id=895560 and we concluded on 'Published' as the term developers understand.  Note the text for PUBLIC_WAITING was changed to 'Approved but unpublished' a while ago.  
Do we think:
Public|Private|Unlisted is clearer than Published|Unpublished|Published-Private ? 

I'm a little unclear on 'disabled' btw.  You've put it as a state, but currently user disable is not something set as a status on the model - its a boolean, and toggleable by the developer (not reviewer).  The status of MOZ_DISABLED is different and is settable by staff for abusive app submissions and isn't toggleable by the developer (for obvious reasons).
(In reply to Andrew Williamson [:eviljeff] from comment #16)
> I'm a little unclear on 'disabled' btw.  You've put it as a state, but
> currently user disable is not something set as a status on the model - its a
> boolean, and toggleable by the developer (not reviewer).  The status of
> MOZ_DISABLED is different and is settable by staff for abusive app
> submissions and isn't toggleable by the developer (for obvious reasons).

You are right its not a state, I represented it poorly. If you find a better way to represent that in a doc go for it. I agree with you that though, leaving it as a boolean and not conflating it with the state in the backend is the correct thing to do and I hope my text in the bug comment reflected that.
I have no opinion personally about published vs public. Tony/Lim/Bram? Note Andrew's question - last remaining piece, no?
Flags: needinfo?(asantos)
Blocks: 1018950
Depends on: 1019251
Depends on: 1019249
> Do we think:
> Public|Private|Unlisted is clearer than Published|Unpublished|Published-Private?

The second set of wording, “published”, is clearer.

If we would like to clarify what exactly does published mean, feel free to use the verbiage below. It doesn’t change any of the UI or state, only its definition. In fact, the word “published” is still used.

This app is accessible to:
* Everybody - published, anyone can see
* People with link - not published, only people who have the link can see
* Me and my team members – not published, only [team members] can see
Sorry about joining this conversation so late in the game.

- The "Public but waiting" state is allow developers to control when the app becomes available in search and listing pages.

- We can use the /ownership page to allow access (like in Google drive). Developers can add read/write access by specifying exact email addresses OR give view access to anyone with the exact URL

- To deal with Apps awaiting review which have access set to 'Anyone with the exact link', we can either a) show the details page with a warning that the app is not reviewed (like we did in AMO) b) Say that the access list is applicable only to 'Approved' apps.

Thoughts?
(In reply to krupa raj[:krupa] from comment #20)
> - We can use the /ownership page to allow access (like in Google drive).
> Developers can add read/write access by specifying exact email addresses OR
> give view access to anyone with the exact URL

They can do this by giving permissions on the app to someone as a "Viewer".

If we think this is useful, let's file new bugs.
(In reply to krupa raj[:krupa] from comment #20)
> - To deal with Apps awaiting review which have access set to 'Anyone with
> the exact link', we can either a) show the details page with a warning that
> the app is not reviewed (like we did in AMO) b) Say that the access list is
> applicable only to 'Approved' apps.

Apps not reviewed can't be installed by anyone from the detail page - including the uploader - the publicly signed zip isn't created until the app is approved.  (The only pre-approval signed zip available is the reviewer signed one, and they don't have access to those files).  So I don't think we don't need to worry about this use case.
Blocks: 1026887
Will the “public name” field reflect the name that developers see in the UI, or is it used only for our reviewers?
I tried looking at that doc but was just confused by the states.  Can we put everything in the same order and focus on the differences in the proposal?  Happy to join a meeting if that helps.
(In reply to Bram Pitoyo [:bram] from comment #24)
> Will the “public name” field reflect the name that developers see in the UI,
> or is it used only for our reviewers?

they should be the same everywhere.  

(In reply to Wil Clouser [:clouserw] from comment #25)
> I tried looking at that doc but was just confused by the states.  Can we put
> everything in the same order and focus on the differences in the proposal? 
> Happy to join a meeting if that helps.

I believe the difference between Rob's and my proposal comes down to:
A) (Rob):
- 'Private' app state is indicated by the user-disabled boolean being true, so the underlying STATUS could be either APPROVED or PUBLISHED.
- Apps in the 'Private' state wouldn't be checked by the cron job, but would be able to upload new versions for review
- No ability for the developer to delist/disable the app - they would make it private instead.
- Risks are changing around what a user-disabled app means throughout the site (e.g. including in the queries, etc) and the short-term disruption when some existing disabled apps end up in the queues.
B) (Andrew):
- 'Private' app state is a (new) STATUS
- Apps in the 'Private' state would be checked by the cron job, and would be able to upload new versions for review.  If they don't want the cron job annoying them they can delist.
- The user-disabled boolean would remain as today so the developer would be able to delist/disable.
- Risks are adding in another status code which has to be taken into account for the various cron jobs, etc.  Plus potential user confusion between have a Private and a Delisted state.

Rob, can you confirm?
Flags: needinfo?(robhudson.mozbugs)
Yep, you nailed it Andrew.

FWIW I've begun coding (B) Andrew's version. I should have a pull-request for the devhub changes today, with submission flow changes following shortly thereafter.
Flags: needinfo?(robhudson.mozbugs)
One question while coding this:

If I have a packaged app that is currently public, with version 1.0 that is also public. When I upload a new version 2.0 how do we handle this?

Note: When the "current version" changes that's when people who have this app installed would receive an update.

It seems to me that if the app is PRIVATE we only allow the new version to become PRIVATE as well. It doesn't make sense for a version to be PUBLIC if the app is PRIVATE. Likewise for UNPUBLISHED, if the app is UNPUBLISHED the version should only be allowed to be either PRIVATE or UNPUBLISHED.

I think an easy solution is to only allow the newly uploaded version to either match the app status or be PRIVATE. So:

1) PUBLIC app, new version can be PUBLIC or PRIVATE. PRIVATE doesn't change the "current version".
2) PRIVATE app, new version can only be PRIVATE.
3) UNPUBLISHED app, new version can be UNPUBLISHED or PRIVATE. PRIVATE doesn't change the "current version" but UNPUBLISHED would. I.e. people who have installed this UNPUBLISHED app would receive updates if the new version becomes UNPUBLISHED as well.

Currently we have a simple checkbox when a developer uploads a new version:
https://www.dropbox.com/s/ohn4z2t6zcqiab1/Screenshot%202014-06-26%2011.22.39.png

The wording could be updated to match the current app status so it makes sense, or hidden if the app is PRIVATE since there is only one status the new version can become.
Rob, can you confirm what STATUS terms you're using in your code?  I've been assuming:
STATUS_PUBLIC   = Published
STATUS_HIDDEN   = Unpublished
STATUS_APPROVED = Private

Further questions:

Can a _PUBLIC app have an _HIDDEN version?  Or are _HIDDEN versions only available for _HIDDEN apps?  Is there really such a thing as an unpublished 'version', or are all the versions either publicly or privately available, i.e. for an _HIDDEN app they are _HIDDEN or _APPROVED like for a _PUBLIC app they are _PUBLIC or _APPROVED. 

What happens when an app as a whole changes state?  e.g. the app is _PUBLIC, and it has a version which is also _PUBLIC.  The app is changed to _HIDDEN - does the version change to _HIDDEN also?  (I would guess it does change?)
Similarly for the other state transitions.
(In reply to Andrew Williamson [:eviljeff] from comment #29)
> Rob, can you confirm what STATUS terms you're using in your code?  I've been
> assuming:
> STATUS_PUBLIC   = Published
> STATUS_HIDDEN   = Unpublished
> STATUS_APPROVED = Private

These are the statuses in my current branch:

STATUS_NULL: _(u'Incomplete'),
STATUS_PENDING: _(u'Pending approval'),
STATUS_PUBLIC: _(u'Published'),
STATUS_DISABLED: _(u'Disabled by Mozilla'),
STATUS_DELETED: _(u'Deleted'),
STATUS_REJECTED: _(u'Rejected'),
STATUS_APPROVED: _(u'Approved but private'),
STATUS_BLOCKED: _(u'Blocked'),
STATUS_UNPUBLISHED: _(u'Approved but unpublished'),

> Can a _PUBLIC app have an _HIDDEN version?  Or are _HIDDEN versions only
> available for _HIDDEN apps?  Is there really such a thing as an unpublished
> 'version', or are all the versions either publicly or privately available,
> i.e. for an _HIDDEN app they are _HIDDEN or _APPROVED like for a _PUBLIC app
> they are _PUBLIC or _APPROVED. 

Yeah, this is what I was getting to in comment 28. I think the version status is going to have to follow the app status.

> What happens when an app as a whole changes state?  e.g. the app is _PUBLIC,
> and it has a version which is also _PUBLIC.  The app is changed to _HIDDEN -
> does the version change to _HIDDEN also?  (I would guess it does change?)
> Similarly for the other state transitions.

I think we will have to treat PRIVATE versions as we do now, and anything not PRIVATE treat it like whatever the app status is. We may as well limit version status to PUBLIC or PRIVATE and when it is PUBLIC it is treated like the app status. This will avoid having to change all versions whenever the app status changes.

This simplifies the code also as we only have to worry about 2 approved states for versions. I'm not quite sure how we get this across in the UI but I'll play with that today. Perhaps just "I want to publish this version manually" == PRIVATE, anything else is PUBLIC.
Bram, can you give your thumbs up/down to the terms below?  

STATUS_PUBLIC: _(u'Published'),
STATUS_UNPUBLISHED: _(u'Approved but unpublished'),
STATUS_APPROVED: _(u'Approved but private'),

for your explanations of:
* Everybody - published, anyone can see
* People with link - not published, only people who have the link can see
* Me and my team members – not published, only [team members] can see

i.e. Is 'approved but private' better than just 'private' (the former being more descriptive but less snappy).
Flags: needinfo?(bram)
Before thumbs-upping the names, it would be good to take a look at Rob's latest work. Could we see a screenshot of where this work is at? Then we'll be able to come up with the best user-facing words for these statuses.
Flags: needinfo?(bram)
(In reply to Elizabeth Hunt from comment #32)
> Before thumbs-upping the names, it would be good to take a look at Rob's
> latest work. Could we see a screenshot of where this work is at? Then we'll
> be able to come up with the best user-facing words for these statuses.

I just pushed my work to the dev server. Happy to make changes as needed. This won't hit production until the 7/15 push.

There's a few places where this comes into play:
1) During app submission at the bottom of the "Edit App Details" page. It currently looks like this: https://www.dropbox.com/s/ov0j7nffq1hobp0/Screenshot%202014-07-07%2014.36.24.png
2) After approval by a review in the devhub: https://www.dropbox.com/s/g2zucngte6shl22/Screenshot%202014-07-07%2014.40.24.png
3) If the app is a packaged app, there is the option to change the publish type during the upload of a new version. For this we only allow "auto-publish" or not. If auto-publish, it will be published to the same status as the app -- so if the app is hidden the new version will be hidden upon approval. https://www.dropbox.com/s/7udw696xkz9puss/Screenshot%202014-07-07%2014.42.20.png
If you choose not to auto-publish you get a "Publish" button next to the version after it has been approved: https://www.dropbox.com/s/t5oo2hs9mr0x925/Screenshot%202014-07-07%2014.51.05.png

Hope that helps.
(In reply to Rob Hudson [:robhudson] from comment #33)
> 3) If the app is a packaged app, there is the option to change the publish
> type during the upload of a new version. For this we only allow
> "auto-publish" or not. If auto-publish, it will be published to the same
> status as the app -- so if the app is hidden the new version will be hidden
> upon approval.
> https://www.dropbox.com/s/7udw696xkz9puss/Screenshot%202014-07-07%2014.42.20.
> png
> If you choose not to auto-publish you get a "Publish" button next to the
> version after it has been approved:
> https://www.dropbox.com/s/t5oo2hs9mr0x925/Screenshot%202014-07-07%2014.51.05.png

what is 'hidden'?
CC: Chris Mills as this affects MDN documentation around the submission flow.
Whiteboard: [repoman]
I changed the wording for the App Visibility options to make the choice/distinction more clear. Also to suggest context in which developer might make a choice. 

Further UI cleanup will happen next week as a next iteration.

App submission screen: http://people.mozilla.org/~ehunt/bug_1006816/screen_1.jpg
App details - hosted app: http://people.mozilla.org/~ehunt/bug_1006816/screen_2.jpg
App details - package app with versions: http://people.mozilla.org/~ehunt/bug_1006816/screen_4.pdf

See sticky notes in the pdf for App details - packaged app.
(In reply to Elizabeth Hunt from comment #36)
> App submission screen:
> http://people.mozilla.org/~ehunt/bug_1006816/screen_1.jpg

"Don't publish app." is the same text for two different options, which is confusing.

I would simplify the phrasing and maybe have something similar to the copy suggestions below.


> App details - hosted app:
> http://people.mozilla.org/~ehunt/bug_1006816/screen_2.jpg

These would be my proposed copy changes:

--

Who should see this?

    ⌾ Public on the Marketplace
    Visible to everyone on the Marketplace

    ○ Anyone with the link
    Visible to anyone who has the link to the app detail page

    ○ Team members
    Visible to only the team members for this app

--

This is similar to Google's Sharing settings:

    http://cl.ly/image/2z0u1P280h40/Screen%20Shot%202014-07-09%20at%202.44.39%20PM.png


> App details - package app with versions:
> http://people.mozilla.org/~ehunt/bug_1006816/screen_4.pdf
> 
> See sticky notes in the pdf for App details - packaged app.

In your sticky notes, I see this:

    Show status for the current PUBLISHED app above in larger/bolder type.

    Beneath show status for most recently updated OTHER version in smaller/regular type.

Despite reading this, it took me a few glances to realise that the first sentence in your mockup was about the published version and that the second sentence was about a separate version.

I like your proposal here, as I think it's useful to show the status for both but it's not obvious to me with this design treatment.
Depends on: 1036665
Depends on: 1036678
Context for this round of copy changes: The goal is to get this launched this week. So we'd like to change copy, but not UI. My goal is to clarify the meaning of the user choices. Next week we will re-visit the UI across these screens and simplify the choices (there's at least 2 axes, and they're conflated in the UI in some places). 

APP SUBMISSION SCREEN 
UI conflates backend Status and App Visibility. For now, I recommended this copy with the current question and new labels:
http://people.mozilla.org/~ehunt/bug_1006816/screen_1_v1.jpg 

For reference, this is the question I think we're asking when we conflate Status and App Visibility. NOT recommended right now:
http://people.mozilla.org/~ehunt/bug_1006816/screen_1_v2.jpg

APP DETAILS - HOSTED APP: 
http://people.mozilla.org/~ehunt/bug_1006816/screen_2.jpg
Changed labels for radio buttons. Here Status and Visibility are separated, so we don't have the problem above.

APP DETAILS - PACKAGED APP WITH VERSIONS: 
http://people.mozilla.org/~ehunt/bug_1006816/screen_4.pdf
Changed labels for radio buttons. Ditto here.
cc'ing Richard Bloor, as he's now the go to guy for marketplace docs.
(In reply to Elizabeth Hunt from comment #38)
> For reference, this is the question I think we're asking when we conflate
> Status and App Visibility. NOT recommended right now:
> http://people.mozilla.org/~ehunt/bug_1006816/screen_1_v2.jpg

That's not what we're asking them - the app is reviewed in all cases.
 
> APP DETAILS - HOSTED APP: 
> http://people.mozilla.org/~ehunt/bug_1006816/screen_2.jpg
> Changed labels for radio buttons. Here Status and Visibility are separated,
> so we don't have the problem above.
> 
> APP DETAILS - PACKAGED APP WITH VERSIONS: 
> http://people.mozilla.org/~ehunt/bug_1006816/screen_4.pdf
> Changed labels for radio buttons. Ditto here.

The wording seems to have changed back to 'Public' rather 'Published'.  But the text above says its waiting for approval to be 'Published'.  I would *strongly* recommend we decide on what the term are and consistently stick to them in the text - when we interact with developers there has to be a consistent and concise way of communicating the state of their app. 

If the developer asks us if their app is published no-one is going to say "Your app is 'Anyone with the link'" but if we say no, the app is 'Hidden' or 'Unpublished' then we are using entirely different terms.  If I'm a developer I'm asking myself 'is my app Approved, Published or Public' and the UI has to reflect it.
If we move the versions listing island up above the delist and delete islands I wonder if that would help avoid including the version specific information up in the top island where it might be confusing? That way they see the App status along with visibility form, and status of the versions right below it. Delist and delete are probably the more rare actions as well so it'd make sense to put them lower on the page.
To avoid having to revert all the hidden apps work and get this in for next week's push we're going to simply update the text around the publishing options and iterate  the UI over the next few weeks.

During app submission, in the form with label "How should we handle your app upon reviewer approval?" we'll have 3 options:
1. Publish my app and make it visible to everyone in the Marketplace
2. Hide my app and make it visible only to users who know the URL
3. Hide my app and make it visible only to team members

After submission on the devhub status page, under the heading "App Visibility":
1. Published and visible to everyone in the Marketplace
2. Hidden and visible only to users who know the URL
3. Hidden and visible only to team members

We'll also move the version island under the status island for packaged apps so the version status is closer and easily viewable and not separated by the "Delist" and "Delete" islands.
Depends on: 1037236
I've added details on initially setting the option on https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/Enter_your_apps_details (noting that there are still other unrelated edits to be done on this page) and added a comment on https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/Define_your_team (also WIP).

The edit option on the Status and Versions page needs to be document (which cannot be done yet as the Status and Versions page itself needs to be documented!)

Would I be correct in assuming that the 'private' option also required the URL to be know before a team member can view the app's page (e.g. it won't appear in listings or searches for team members).
Flags: needinfo?(rbloor)
(In reply to rbloor from comment #43)
> Would I be correct in assuming that the 'private' option also required the
> URL to be know before a team member can view the app's page (e.g. it won't
> appear in listings or searches for team members).

yes.  Though it will be listed in their 'my submissions'.
The pages have been updated with this information - thanks Andrew
Status: NEW → ASSIGNED
Rob and I have finalized the next iteration devhub pages impacted by this bug. 

We've finalized names for the statuses and what they mean. We're moving forward as outlined in the pdf at the URL below. The pdf includes a bunch of permutations that Rob and I have discussed.

Once it's launched, you can file a bug against it if there's something not to your liking. 

http://people.mozilla.org/~ehunt/bug_1006816_unlisted_apps/1006816_unlisted_apps_v3.1.pdf
(In reply to Elizabeth Hunt from comment #46)
> Rob and I have finalized the next iteration devhub pages impacted by this
> bug. 
> 
> We've finalized names for the statuses and what they mean. We're moving
> forward as outlined in the pdf at the URL below. The pdf includes a bunch of
> permutations that Rob and I have discussed.
> 
> Once it's launched, you can file a bug against it if there's something not
> to your liking. 
> 
> http://people.mozilla.org/~ehunt/bug_1006816_unlisted_apps/
> 1006816_unlisted_apps_v3.1.pdf

some questions/clarifications:
* user disable option is now 'hidden', correct?  But apps have to be approved to have this option available?  What's the migration for apps currently in this state? (last part is more a question for Rob)

* a user can make changes to the app (upload new versions, change the active version, etc) while the app is hidden, correct?  I.e. this is a change to the current iirc.  What's the use case for this vs. unlisted&team only?  (I foresee many edge cases here where we currently completely ignore user disabled apps)

* on page 7: 'disabled by mozilla' has been conflated with 'blocked'.  Disabled means just that - the listing is disabled so the user can't upload any more versions, resubmit, etc.  Hosted apps /can/ be Disabled by Mozilla.  Blocked is when a false-update is served to existing users - and the developer can upload a new version.

* on page 15: I'm unclear on this - I'm pretty sure you can't (currently) resubmit a version of a packaged app.  I.e. you can only upload a new version; and resubmitting is for hosted apps. Is this a change to make it possible?

* on page 21: is v2.1 supposed to be visually shown as Active, like when the app is Published, or is this only when the app is in that state?

* nit - I assume you can only make approved versions 'active' (the mockups show radio buttons for all versions)
(In reply to Andrew Williamson [:eviljeff] from comment #47)
> some questions/clarifications:
> * user disable option is now 'hidden', correct?  But apps have to be
> approved to have this option available?  What's the migration for apps
> currently in this state? (last part is more a question for Rob)

I would think you can disable your app from any state. If your app is PENDING and you want to give up, you can disable or delete to remove it from the queue.

> * a user can make changes to the app (upload new versions, change the active
> version, etc) while the app is hidden, correct?  I.e. this is a change to
> the current iirc.  What's the use case for this vs. unlisted&team only?  (I
> foresee many edge cases here where we currently completely ignore user
> disabled apps)

I tested and currently you can upload new versions, etc for disabled apps. I'll keep this but if we want this changed we should file a new follow-up bug.

> * on page 7: 'disabled by mozilla' has been conflated with 'blocked'. 
> Disabled means just that - the listing is disabled so the user can't upload
> any more versions, resubmit, etc.  Hosted apps /can/ be Disabled by Mozilla.
> Blocked is when a false-update is served to existing users - and the
> developer can upload a new version.

I think the mockup looks good, just the notes are conflating the terms.

> * on page 15: I'm unclear on this - I'm pretty sure you can't (currently)
> resubmit a version of a packaged app.  I.e. you can only upload a new
> version; and resubmitting is for hosted apps. Is this a change to make it
> possible?

True. You can't resubmit a packaged app version. If we do want this let's file a new bug -- this one is big enough already.

> * on page 21: is v2.1 supposed to be visually shown as Active, like when the
> app is Published, or is this only when the app is in that state?

My vote would be to always show the "current version" as "Active". Even when the app is unlisted & only visible to team-members it can still be installed and the active version is the one that is installed.

> * nit - I assume you can only make approved versions 'active' (the mockups
> show radio buttons for all versions)

Yes, we should only allow changing to active for approved versions. Perhaps for this reason the button was a bit nicer?
(In reply to Rob Hudson [:robhudson] from comment #48)
> (In reply to Andrew Williamson [:eviljeff] from comment #47)
> > some questions/clarifications:
> > * user disable option is now 'hidden', correct?  But apps have to be
> > approved to have this option available?  What's the migration for apps
> > currently in this state? (last part is more a question for Rob)
> 
> I would think you can disable your app from any state. If your app is
> PENDING and you want to give up, you can disable or delete to remove it from
> the queue.

I can see the justification for forcing apps that haven't been approved to delete themselves rather than disable.  But if that's the case them existing apps in that state would either have to be migrated or you'd have to special case them.  I don't mind either way.

> > * a user can make changes to the app (upload new versions, change the active
> > version, etc) while the app is hidden, correct?  I.e. this is a change to
> > the current iirc.  What's the use case for this vs. unlisted&team only?  (I
> > foresee many edge cases here where we currently completely ignore user
> > disabled apps)
> 
> I tested and currently you can upload new versions, etc for disabled apps.
> I'll keep this but if we want this changed we should file a new follow-up
> bug.

Okay, I didn't realise it was currently available.  Currently doing any of those things doesn't re-enable the app though(?) - but it will have to now or the app won't show up in the queues, etc.  (Unless you want to change the queries.  Edge cases abound!)

> > * on page 15: I'm unclear on this - I'm pretty sure you can't (currently)
> > resubmit a version of a packaged app.  I.e. you can only upload a new
> > version; and resubmitting is for hosted apps. Is this a change to make it
> > possible?
> 
> True. You can't resubmit a packaged app version. If we do want this let's
> file a new bug -- this one is big enough already.

I don't want this :)

> > * nit - I assume you can only make approved versions 'active' (the mockups
> > show radio buttons for all versions)
> 
> Yes, we should only allow changing to active for approved versions. Perhaps
> for this reason the button was a bit nicer?

Radio button is fine, I was just clarifying if it was a deliberate move or mockup shorthand.
to pull out something from above (and discussions on IRC with Rob), what is the use case for a developer choosing to make the app 'Hidden' vs. 'Unlisted & Limited to Team'?
I'd like to keep the radio buttons rather than using buttons for Active Version. Only Approved versions can be made active. So for rejected/blocked/etc, just remove the radio button from that row. That will make it clear that only approved versions can be made active.

The note on page 7 re: hosted apps is a note to self to remind me that hosted apps can't be blocked. Just ignore it.

I included the "resubmit" option on page 15 b/c I wasn't sure if you could do this or not. Sounds like not. So we won't show the "resubmit" block for packaged apps that are rejected or disabled by moz.
(In reply to Elizabeth Hunt from comment #51)
> I'd like to keep the radio buttons rather than using buttons for Active
> Version. Only Approved versions can be made active. So for
> rejected/blocked/etc, just remove the radio button from that row. That will
> make it clear that only approved versions can be made active.

From a front-end implementation point of view, as soon as the user clicks the radio button do we submit/reload the page and make that version active? Or should we add a submit button so they pick the version then click "Submit" or "Save" or whatever we call it?
New info: apps can't be downgraded to previous versions. So user can only make a new version an Active Version. 

Updated UI here:
http://people.mozilla.org/~ehunt/bug_1006816_unlisted_apps/unlisted_apps_ui.pdf

Also include "update" button to save changes for the Publication/Visibility section. We need a "submit" button here to make sure user really wants to make the change.
Just so I'm clear - the content I added at https://developer.mozilla.org/en-US/Marketplace/Publishing/Submit/Enter_your_apps_details#Set_the_publication_options is no longer relevant and I would need to follow the PDF content (when the change is implemented)?
Keywords: uiwanted
Depends on: 1052005
Hidden apps supported added:
https://github.com/mozilla/zamboni/commit/6cddd16 

I spun off 2 bugs for follow-up UI changes:
- bug 1052553
- bug 1055148
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2014-08-26
Flags: needinfo?(asantos)
Could I possibly get a skinny little screengrab that shows the new UI/radio button to request a HIdden URL?
I would need this in the next day or so for the Apps & Hacks newsletter which will ship before end of month. 

Something like this in size and scale: https://mdn.mozillademos.org/files/8473/publication%20visibility%20new.png

TIA!
Flags: needinfo?(ehunt)
Flags: needinfo?(asantos)
I gave one to dbialer last night so happen to have this handy.
Flags: needinfo?(ehunt)
Flags: needinfo?(asantos)
Flags: needinfo?(rbloor)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: