Closed Bug 785125 Opened 12 years ago Closed 12 years ago

App details page should list developer name from manifest

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P2)

x86_64
Windows 7
defect

Tracking

(Not tracked)

RESOLVED FIXED
2013-06-13

People

(Reporter: eviljeff, Assigned: mat)

References

()

Details

(Whiteboard: [qa+])

In the Gaia-UI addon detail view only the first developer is shown: e.g. https://marketplace-dev.allizom.org/app/add-on-builder/ (should show Wil Clouser also)
wtf rob hudson! Is there room to add more names? Otherwise maybe we should limit to 1.
Keywords: uiwanted
What about a [+1] that shows/hides more on demand (that would expand the info box)?
(In reply to Andrew Williamson [:eviljeff] from comment #2) > What about a [+1] that shows/hides more on demand (that would expand the > info box)? How would that look on search results? Everything would get shifted down, eh that seems fine. I'm cool with an "..." that on click expands to show more.
(In reply to Chris Van Wiemeersch [:cvan] from comment #3) > (In reply to Andrew Williamson [:eviljeff] from comment #2) > > What about a [+1] that shows/hides more on demand (that would expand the > > info box)? > > How would that look on search results? Everything would get shifted down, eh > that seems fine. I'm cool with an "..." that on click expands to show more. For mobile search results we will have enough problems fitting longer company / dev names. We should limit to only showing one, not sure what that will mean for the submission UX. I'd in general like to move to having one string which is the outward facing "developer name", but still allowing multiple authors to edit etc.
(In reply to Maria Sandberg [:mushi] from comment #4) > For mobile search results we will have enough problems fitting longer > company / dev names. We should limit to only showing one, not sure what that > will mean for the submission UX. I'd in general like to move to having one > string which is the outward facing "developer name", but still allowing > multiple authors to edit etc. That makes sense for now, yeah.
I was actually thinking more about the detail page, where things being shifted down a little wouldn't matter too much, than the search results. If this is to be a permanent change then the authorship section of Manage App needs to be changed to either prevent more than one owner or make it clear that only the first owner will be shown on mobile pages. Can some change the bug and assign, etc? Plus for existing apps, where there is more than one owner, we'll need to contact them to tell them what's happening. I can handle this once the above is sorted.
There is another related bug for changing something on the manage author's page. It's also uiwanted, iirc.
Assignee: nobody → msandberg
Assignee: msandberg → nobody
Depends on: 842810
Summary: App details page only shows one developer → App details page should list the owner only
On DevHub’s submit an app flow, we can respond to the decision made to the consumer page. When user first log in and being asked to fill in her details, we should make sure to let them know that, “What you filled in this field is going to have far-reaching consequences, because it’s going to be displayed as your app’s namesake all across the Marketplace”. Otherwise, it’s a decision that user might not know how to change. Plus, having a listing name like bpitoyo is probably less preferable to most people than, say, “Blue Note Records”. So it’s an important item to let user know about.
(In reply to Bram Pitoyo [:bram] from comment #8) > On DevHub’s submit an app flow, we can respond to the decision made to the > consumer page. > > When user first log in and being asked to fill in her details, we should > make sure to let them know that, “What you filled in this field is going to > have far-reaching consequences, because it’s going to be displayed as your > app’s namesake all across the Marketplace”. Otherwise, it’s a decision that > user might not know how to change. > > Plus, having a listing name like bpitoyo is probably less preferable to most > people than, say, “Blue Note Records”. So it’s an important item to let user > know about. Its just the user's 'display name' isn't it? You can change that.
It's been proposed that we could instead have a "display name" per app. So this would allow customization without requiring users to change their names or have a dummy account for that served as a team account.
(In reply to Andrew Williamson [:eviljeff] from comment #9) > Its just the user's 'display name' isn't it? You can change that. That’s correct, it’s just that the relationship between “the line below the app name” and “display name” is not clear or outlined clearly in the UI. I am referring to two specific instances: 1. When you register, you fill out a display name. You can guess what it means (e.g. “this is probably the name that will show up when I type a reply”), but there is no indication that it will show up below your app name 2. The app editing interface allows you to change everything: app name, URL, summary, screenshots. Everything but the field below the app name. A user will probably not think “Oh, that field is called display name” and “Therefore, I should go to the Edit Account Settings page to change it” Scenarios that cvan had outlined necessitates clarification of the display name field. I think that the ability to distinguish “real name” and “business/company name” is important. cvan’s “display name per app” solution is a good one, but I wonder if it presents more opportunity to be tricky and dishonest about it? Maybe the solution is as simple as separating the two names into two fields: “Real name” and “Company name”. I was thinking of something like this: * Reword “Display name” into something more personal-sounding. For this exercise, let’s use “Your name” * Have 2 fields: “Your name” and “Your company name” The behavior for editing “Your name” is exactly the same as what we have today: * Upon registration, we ask every user to fill out the “Your name” field * Editing “Your name” is only done through the “Edit account settings” page Editing “Your company name” is a bit different: * When submitting an app, we ask every developer to fill out “Your company name” on the edit app step * On the edit app page, make “Your company name” editable. Changing it would put the app back into review * There can only be one company name. When you edit the value on one, the company name value on your other apps change When user is posting, we can either: * Use name only: “Bram Pitoyo” * Use name (company name): “Bram Pitoyo (Mozilla)”. This would give the comment both more personality and credibility The interesting things about this solution: * We’ve eliminated the display name confusion by separating the fields * Most users are regular users who aren’t going to submit apps. They will never have to deal with company names * Developers do have to deal with company name, but are going to use the edit app page to edit it: a very intuitive way However, creating a new field called “Company name” presents two very big problems of its own: The first problem is company name verification and duplication: * If only one company name can exist on the Marketplace at one time, what happens if multiple developers from the same company register for an account and then each submit an app? * The alternative is to allow anyone to arbitrarily change the company name to anything s/he wants, which will cause scams and spams * A good solution seems to be to have a database of “company” and each of its “team members”. Whenever a “team member” chooses to add a company name to their submitted app, we notify the “namekeeper” of that company’s name. If the namekeeper approves, then we can be sure that the app does come from the same company. The second problem is identity: associating username with company name * I work for a company. Should my display name be my real name, or my company name? * If I choose a corporate display name, I have to create and manage another account to be able to rate, download and post comments on behalf of myself * I work at a company but has an app side project on the side, so I have to create and manage another account. Is it possible to have two Marketplace accounts under one set of Persona.org login screen? I want to use xyz@gmail.com for my personal Marketplace account and xyz@mozilla.com for my corporate one I might be overthinking this, but I think that display name impacts a whole lot of things, and could produce a whole lot of breakable edge cases. What do you think of these ideas and problems?
(In reply to Bram Pitoyo [:bram] from comment #11) > I think that the ability to distinguish “real name” and “business/company > name” is important. cvan’s “display name per app” solution is a good one, > but I wonder if it presents more opportunity to be tricky and dishonest > about it? There is the potential for dishonesty, but no more than in the app name or description, or the app itself. > Maybe the solution is as simple as separating the two names into two fields: > “Real name” and “Company name”. I was thinking of something like this: > * Reword “Display name” into something more personal-sounding. For this > exercise, let’s use “Your name” > * Have 2 fields: “Your name” and “Your company name” > > The behavior for editing “Your name” is exactly the same as what we have > today: > * Upon registration, we ask every user to fill out the “Your name” field > * Editing “Your name” is only done through the “Edit account settings” page > > Editing “Your company name” is a bit different: > * When submitting an app, we ask every developer to fill out “Your company > name” on the edit app step > * On the edit app page, make “Your company name” editable. Changing it would > put the app back into review > * There can only be one company name. When you edit the value on one, the > company name value on your other apps change > > When user is posting, we can either: > * Use name only: “Bram Pitoyo” > * Use name (company name): “Bram Pitoyo (Mozilla)”. This would give the > comment both more personality and credibility > > > The interesting things about this solution: > * We’ve eliminated the display name confusion by separating the fields > * Most users are regular users who aren’t going to submit apps. They will > never have to deal with company names > * Developers do have to deal with company name, but are going to use the > edit app page to edit it: a very intuitive way > > > However, creating a new field called “Company name” presents two very big > problems of its own: > > The first problem is company name verification and duplication: > * If only one company name can exist on the Marketplace at one time, what > happens if multiple developers from the same company register for an account > and then each submit an app? > * The alternative is to allow anyone to arbitrarily change the company name > to anything s/he wants, which will cause scams and spams > * A good solution seems to be to have a database of “company” and each of > its “team members”. Whenever a “team member” chooses to add a company name > to their submitted app, we notify the “namekeeper” of that company’s name. > If the namekeeper approves, then we can be sure that the app does come from > the same company. > > The second problem is identity: associating username with company name > * I work for a company. Should my display name be my real name, or my > company name? > * If I choose a corporate display name, I have to create and manage another > account to be able to rate, download and post comments on behalf of myself > * I work at a company but has an app side project on the side, so I have to > create and manage another account. Is it possible to have two Marketplace > accounts under one set of Persona.org login screen? I want to use > xyz@gmail.com for my personal Marketplace account and xyz@mozilla.com for my > corporate one This sounds horrendously complicated! For implementation by webdev; for the app developer to maintain; and for us to manage. > I might be overthinking this, but I think that display name impacts a whole > lot of things, and could produce a whole lot of breakable edge cases. What > do you think of these ideas and problems? Can't we just go with the developer name per app that cvan mentioned? It can be pulled from the manifest developer field. Simple!
Summary: App details page should list the owner only → App details page should list one "display name" per app
Not to make this discussion more complicated than it already has, but I like the idea that cvan and Andrew proposed, and thought that maybe we should go one step further and make developer name tied to, and only changeable from, the manifest file. Thus: * We’re going to pull developer name from manifest file * Developer name becomes like app name. They are displayed on the Edit App interface, but not changeable unless you change the manifest file
(In reply to Bram Pitoyo [:bram] from comment #13) > * We’re going to pull developer name from manifest file > * Developer name becomes like app name. They are displayed on the Edit App > interface, but not changeable unless you change the manifest file This seems like the right approach as it ensures that the developer shown in Gaia app permission and install screens matches what is shown on the Marketplace.
(In reply to Bram Pitoyo [:bram] from comment #13) > Not to make this discussion more complicated than it already has, but I like > the idea that cvan and Andrew proposed, and thought that maybe we should go > one step further and make developer name tied to, and only changeable from, > the manifest file. > > Thus: > * We’re going to pull developer name from manifest file > * Developer name becomes like app name. They are displayed on the Edit App > interface, but not changeable unless you change the manifest file +1 from me. If we think there is a risk of dishonestly we can add a re-review check for it changing.
Summary: App details page should list one "display name" per app → App details page should list developer name from manifest
Blocks: 857221
removing uiwanted keyword as bram replied and it looks like we have a consensus on the approach.
Keywords: uiwanted
Priority: -- → P2
Blocks: 760061
If we're changing this to pull from the manifest it should be a required field in the manifest (cvan says it's not). Andrew: can you update the spec or add a huge note on that page as well as update our app policies?
(In reply to Wil Clouser [:clouserw] from comment #17) > If we're changing this to pull from the manifest it should be a required > field in the manifest (cvan says it's not). Andrew: can you update the spec > or add a huge note on that page as well as update our app policies? Manifest page updated: https://developer.mozilla.org/en-US/docs/Apps/Manifest#developer Added mention to the reviewer testing page as well to check its reasonable. The validator should check for its inclusion in the manifest. Does the validator check need a separate bug? @basta?
Depends on: 875344
I filed a separate bug for that. Once that is done we'll start enforcing "developer" on all new manifests. This bug is now about: - Writing a script to parse all existing manifests looking for a "developer" field and copying it to our database - Writing code to pull the developer name during app submission - Modifying the dev tools to make the developer name uneditable (with a friendly explanation of how to change it)
Whiteboard: [see comment 19]
(In reply to Wil Clouser [:clouserw] from comment #19) > I filed a separate bug for that. Once that is done we'll start enforcing > "developer" on all new manifests. This bug is now about: > > - Writing a script to parse all existing manifests looking for a "developer" > field and copying it to our database > > - Writing code to pull the developer name during app submission > > - Modifying the dev tools to make the developer name uneditable (with a > friendly explanation of how to change it) And displaying that developer name on the detail page.
Yep. I meant to mention that we've written several scripts which "do ______ to all existing apps" in the past and it should be possible to build off of one of those to parse all the existing packaged app manifests. I think we've actually parsed all existing hosted manifests too so definitely ask around for a script.
Assignee: nobody → mpillard
This bug is big enough to warrant a split - I'll open a new one for the script that parses existing manifests, because this can be done separately (and should be done after the rest is done, IMHO, so I'll set it to depend on this one)
Blocks: 880188
with bug 880188 logged I believe the remaining parts are: - Writing code to pull the developer name during app submission (including update for packaged apps) - Updating the developer name when the manifest changes (for hosted apps) - Modifying the dev tools to make the developer name uneditable (with a friendly explanation of how to change it) - displaying the developer name on the consumer detail page (in place of the uploader name we currently show)
Blocks: 880219
Blocks: 882097
This is done and live on -dev. https://github.com/mozilla/zamboni/commit/3faa9a2df5cd59c121d12269d59734a565a52f21 https://github.com/mozilla/zamboni/commit/150c45f4c0a4b5cd51eb90c0b6954c685fa27e7c Steps to reproduce: - Upload a new app (hosted or packaged) with developer name in the manifest (should be required) - In the edit page, the reviewer page and the public listing, we should show the developer name from the manifest of the app instead of the name of the uploader. See also comment 23.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Is this behind a flag? Is QA okay with shipping this tomorrow?
It's not behind a flag currently.
Target Milestone: --- → 2013-06-13
QA: See comment 24 for steps to verify. Thanks!
Whiteboard: [see comment 19] → [qa+]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 2013-06-13 → 2013-06-20
I think it's just a matter of fireplace not being updated on stage. If you look in the developer & reviewer pages it's there.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Target Milestone: 2013-06-20 → 2013-06-13
You need to log in before you can comment on or make changes to this bug.