805935 - Improved UX for Edit Listing page

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Developer Pages, enhancement, P4)

Description

[Lisa Brewster [:adora]]

We're seeing a lot of apps with the submitter's username displayed in the "developer name" field on the consumer page [1], when they really want the company name.

This is currently configured via the account settings [2] for the app owner, which isn't intuitive.

I nominate that this setting be discoverable on the "Manage Authors" page [3].

1.  http://adora.io/screens/testapp-consumer-page-20121026-125212.png
2.  https://marketplace.mozilla.org/settings
3.  http://adora.io/screens/testapp-manage-authors-20121026-125341.png

Related:  How do we use the developer name field that's configured in the manifest?

Comment 1

[Andrew Williamson [:eviljeff]]

this bug is sort of related: https://bugzilla.mozilla.org/show_bug.cgi?id=785125

Comment 2

[Wil Clouser [:clouserw]]

How does this change the functionality?

Are you saying people can change their display name from [3] or are you talking about putting a message on the page saying something about "this will show up on the page as _____"?  Changing the display name there is complicated due to permissions (eg. multiple authors aren't allowed to change the display names of the other authors, etc.)

Comment 3

[Andrew Williamson [:eviljeff]]

I've had another thought on this - couldn't (shouldn't?) we use the developer name specified in the manifest rather than the display name of the user that happened to upload the manifest?  

(We might need to make the developer field mandatory for Mkt submissions if so)

Comment 4

[Wil Clouser [:clouserw]]

That'd be fine with me.  CCing UX and PM for comment

Comment 5

[Christopher Van Wiemeersch [:cvan]]

(In reply to Lisa Brewster [:adora] from comment #0)
> We're seeing a lot of apps with the submitter's username displayed in the
> "developer name" field on the consumer page [1], when they really want the
> company name.

I wanted to ask for the "Developer Name" when users accept the Terms submitting an app. But putting it on Manage Authors page is not a terrible idea too.

Comment 6

[Maria Sandberg [:mushi]]

ccing Bram on this, he is working on incorporating immediate feedback on what will be shown on the app details page in the submission flow.

Comment 7

[Andrew Williamson [:eviljeff]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #5)
> (In reply to Lisa Brewster [:adora] from comment #0)
> > We're seeing a lot of apps with the submitter's username displayed in the
> > "developer name" field on the consumer page [1], when they really want the
> > company name.
> 
> I wanted to ask for the "Developer Name" when users accept the Terms
> submitting an app. But putting it on Manage Authors page is not a terrible
> idea too.

Wouldn't we just end up with 3 different places for the name to be?  (The display name from manage authors;the manifest; and now a 'developer name' field)  What's the argument for /not/ using the manifest as the source of all information?

Comment 8

[Christopher Van Wiemeersch [:cvan]]

(In reply to Andrew Williamson [:eviljeff] from comment #7)
> Wouldn't we just end up with 3 different places for the name to be?  (The
> display name from manage authors;the manifest; and now a 'developer name'
> field)  What's the argument for /not/ using the manifest as the source of
> all information?

I would like for the manifest to be the true source of all this information. As you know, the Manage Authors page allows for users to be "listed" (credited) on the detail page. If we start pulling that info instead from the manifest, then most apps will say "by <blank>" since "developers" is not a required manifest field.

Comment 9

[Andrew Williamson [:eviljeff]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #8)
> (In reply to Andrew Williamson [:eviljeff] from comment #7)
> > Wouldn't we just end up with 3 different places for the name to be?  (The
> > display name from manage authors;the manifest; and now a 'developer name'
> > field)  What's the argument for /not/ using the manifest as the source of
> > all information?
> 
> I would like for the manifest to be the true source of all this information.
> As you know, the Manage Authors page allows for users to be "listed"
> (credited) on the detail page. If we start pulling that info instead from
> the manifest, then most apps will say "by <blank>" since "developers" is not
> a required manifest field.

Okay.  So I suppose there are two options -
a) have a field somewhere in the upload flow like you suggested and pull the information from the manifest initially (if it exists, blank otherwise)
b) require the developer field in the manifest for marketplace submissions.  We'd need to cache this somewhere in the DB anyway I assume.  And existing submissions would need communicating/migrating, etc.  

In a way it ties into bug 757295 in regards to pulling and updating stuff from the manifest.

Comment 10

[Bram Pitoyo [:bram]]

To make things even more confusing, in the listing page, developer name is placed right after the app name.

So if you’re a developer, where would you think is the right place to edit the developer name? The “Edit Listing” page, of course. And you should be able to edit it right after you edit the app name.

This may be indicative of a larger issue in information architecture, where various info are grouped in divisions that make sense technically, but don’t if you think about it from the user’s point of view.

I started trying to do this in bug 794695 and attachment 679979 [details], but realized that the new organization might’ve been missed.

The edit page sidebar should have menu items that read as follows:
- Listing: this will be an edit listing page that will have a “View listing” button. Developer name will go here
- Devices and payments
- Authors: can we integrate this page into another page on the sidebar? Into the listing section, maybe
- Disable and delete app: is there a name other than “Status” that better indicates what the user will get when clicking

I think we ought to rethink the information architecture of the Edit App sidebar to avoid bumping into problems like this in the future. What do you guys think?

Comment 11

[Lisa Brewster [:adora]]

"Status" menu name:  perhaps "publishing options"?  This menu item will also see more usage after we separate approval and publication actions.

Comment 12

[Andrew Williamson [:eviljeff]]

I agree that 'Status' isn't that great a menu name though it is where a developer would go to find out of the status of his app and how to change the status (to delete, disable, resubmit, publish).  

Plus for packaged apps it contains a listing of versions (with statuses for those) and the upload new version section.

Btw, we should retain the 'View Listing' link, or move it somewhere else if its not in the menu.  Its a PITA to get back to the public page otherwise.

Comment 13

[Bram Pitoyo [:bram]]

Thanks for the name suggestions. I like “publishing options” or even “delete, disable, resubmit and publish app” (even though the second name is very long).

Lisa, will separating approval and publication impact the developer-side UI?

Andrew, I agree that we should retain the view listing. My plan was to put it inside a catch-all page called “Listing”. Under this page, you’ll get to edit as well as view (or preview) your app listing.

Is there a better place or name for the “Authors” section? How do we envision this page to be managed? From what I read, it sounds like multiple authors will have access to rename app, and so on.

A good way to think about it is to ask the question: where will the info that’s entered under “Authors” be seen by user in the app listing page?

Comment 14

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #13)
> Andrew, I agree that we should retain the view listing. My plan was to put
> it inside a catch-all page called “Listing”. Under this page, you’ll get to
> edit as well as view (or preview) your app listing.

Having to go through another page is exactly the hassle I wanted to avoid.  If you can get to manage app with one click then you should be able to get back with one click (imo).

(In reply to Bram Pitoyo [:bram] from comment #13)
> Is there a better place or name for the “Authors” section? 

'Ownership' or 'Developers'?

> How do we envision this page to be managed? From what I read, it sounds like 
> multiple authors will have access to rename app, and so on.

Correct.  With different levels of access.

> A good way to think about it is to ask the question: where will the info
> that’s entered under “Authors” be seen by user in the app listing page?

Right now they are (the first listed author is) but the suggestion is there be a separate 'developer name' instead.

Comment 15

[Lisa Brewster [:adora]]

> Lisa, will separating approval and publication impact the developer-side UI?

Yeah, there will need to be an option whether the developer wants us to auto-publish the app immediately after approval (which is how it works today), or whether the developer wants to control when the app is published after we've approved it.

Reviewers will also be able to approve on some platforms but reject on others, so it may be tricky to make it clear what will happen in different scenarios.

Comment 16

[Rob Hudson [:robhudson]]

(In reply to Lisa Brewster [:adora] from comment #15)
> Reviewers will also be able to approve on some platforms but reject on
> others, so it may be tricky to make it clear what will happen in different
> scenarios.

That's not my understanding of the spec as it is today. It was decided that a reviewer can override the device support and remove devices that have problems but the app as a whole is approved. If a hosted app, the dev would update the devices triggering a re-review. If a packaged app, I'm not sure exactly what the process would be -- perhaps on submission of a new version they are presented with device type selection and for the update to be approved it's similar to a new app approval.

Comment 17

[David Bialer [:dbialer]]

Yes Rob is correct.

Comment 18

[Lisa Brewster [:adora]]

Ok, different terminology from a spec standpoint, with regards to using the word "rejection."  But the end result to the developer would still be that the app is approved for some platforms and not approved on others.

Comment 19

[Bram Pitoyo [:bram]]

Attachment: DevHub listing page - explanation

A potentially effective solution to this and future problem related to congruency between developer-facing pages and consumer-facing ones should solve this problem first and foremost:

As a developer, how can I understand where the text that I input into a text box, or the image that I upload, appear on the consumer side?

The mockups attached attempts to solve this problem in the least heavy-handed way possible.


The principles are threefold:

1. First, always display what the consumer-facing listing page will look like

2. To ensure clarity, allow developers to edit in-place every field that show up on consumer-facing page. In-place editing is practically similar to Flickr’s.

3. Fields that require a lot of explanations in order to edit, or fields that are not consumer-facing, are displayed and edited using the existing method
  a. App icons come in 3 sizes. But the consumer-facing page only display 1 size. So we should use the existing edit method.
  b. App screenshots have to be uploaded at a certain size. But the consumer-facing page does not display image size. So we should use the existing edit method.
  c. The name that gets displayed below the app has settings, states and permissions. But the consumer-facing page does not display it. So we should use the existing edit method, which is a separate page called “Authors” (proposed name: “Ownership”).
  d. App URL, manifest URL and categories are not displayed anywhere on the consumer-facing page. So we should use the existing edit method, which is to put them under the “Basic information” heading
  e. Privacy policy, default locale and regions are not displayed anywhere on the consumer-facing page. So we should use the existing edit method, which is to put them under the “App Details” heading



Also note some changes to the interface:

* The “Manage Status” interface is merged with this page because the two kinds of information are closely related. However, “Manage Status” may be more complex than simply about disabling/removing/reuploading apps. If so, it can be on its own page.

* The “Ownership” interface is still separated, but if it doesn’t contain too many fields beyond what we already have today, then it should be merged into this page.

* The “Devices and payments” interface is still separated. Maybe the way to edit them from this page is by displaying the app price in a button (“Free”, “$0.99”, etc.). When developers hover over this button, it turns into “Edit”, and when developers click on it, it takes them to the “Devices and payments” page.


And that about wraps all the changes on this page. I hope that in-place editing will make it much easier to understand how the developer-facing interface and the user-facing page relate to each other.

Comment 20

[Christopher Van Wiemeersch [:cvan]]

Dev flow stuff next week.

Comment 21

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #19)
> 2. To ensure clarity, allow developers to edit in-place every field that
> show up on consumer-facing page. 

Like!
 
(In reply to Bram Pitoyo [:bram] from comment #19)
> * The “Manage Status” interface is merged with this page because the two
> kinds of information are closely related. However, “Manage Status” may be
> more complex than simply about disabling/removing/reuploading apps. If so,
> it can be on its own page.

With packaged apps the version details will need to go in there so its probably best to leave it separate.  Either that or merge the generic Manage Status interface as you suggest and just have a separate 'Versions' page that is only shown for packaged apps.

Comment 22

[Christopher Van Wiemeersch [:cvan]]

Any ideas how we should handle errors with inline editing (e.g., name is already taken)? http://f.cl.ly/items/2R1K3U250o2j14351N3e/Screen%20Shot%202012-12-13%20at%208.03.35%20PM.png

Comment 23

[Andrew Williamson [:eviljeff]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #22)
> Any ideas how we should handle errors with inline editing (e.g., name is
> already taken)?
> http://f.cl.ly/items/2R1K3U250o2j14351N3e/Screen%20Shot%202012-12-
> 13%20at%208.03.35%20PM.png

could we have one of those tick/cross icons appear in/next to the text field that checks as you type?

Comment 24

[Christopher Van Wiemeersch [:cvan]]

(In reply to Andrew Williamson [:eviljeff] from comment #23)
> (In reply to Chris Van Wiemeersch [:cvan] from comment #22)
> > Any ideas how we should handle errors with inline editing (e.g., name is
> > already taken)?
> > http://f.cl.ly/items/2R1K3U250o2j14351N3e/Screen%20Shot%202012-12-
> > 13%20at%208.03.35%20PM.png
> 
> could we have one of those tick/cross icons appear in/next to the text field
> that checks as you type?

Yeah, a checkmark icon is fine for whether it's taken or not. But an inline error if the length is too long or something, maybe a tooltip or something?

Comment 25

[Andrew Williamson [:eviljeff]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #24)
> (In reply to Andrew Williamson [:eviljeff] from comment #23)
> > (In reply to Chris Van Wiemeersch [:cvan] from comment #22)
> > > Any ideas how we should handle errors with inline editing (e.g., name is
> > > already taken)?
> > > http://f.cl.ly/items/2R1K3U250o2j14351N3e/Screen%20Shot%202012-12-
> > > 13%20at%208.03.35%20PM.png
> > 
> > could we have one of those tick/cross icons appear in/next to the text field
> > that checks as you type?
> 
> Yeah, a checkmark icon is fine for whether it's taken or not. But an inline
> error if the length is too long or something, maybe a tooltip or something?

Hmm.  A tooltip that's visible before you mouseover?  Does anyone in UX have an opinion?

Comment 26

[David Bialer [:dbialer]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #22)
> Any ideas how we should handle errors with inline editing (e.g., name is
> already taken)?
> http://f.cl.ly/items/2R1K3U250o2j14351N3e/Screen%20Shot%202012-12-
> 13%20at%208.03.35%20PM.png

I don't see a problem with non-unique app names, though do for dev names.
Also in Bug 753779 -  Suggested behavior is that App name should not be editable.

Comment 27

[Christopher Van Wiemeersch [:cvan]]

An invalid name is just an example. All of these fields have potentially bad values. Looking for recommendations of how to present that visually.

Comment 28

[Bram Pitoyo [:bram]]

I’m going to work on this today.

Comment 29

[Bram Pitoyo [:bram]]

Attachment: DevHub listing page - editing app name - error

This is a mockup of what happens when a field is edited but has invalid value.

The behavior:
* User hovers over app name, app name text is highlighted in yellow
* User clicks on app name, the text changes into a text box
* User replaces old value with a new value
* User clicks “Save”
* System performs a check and returns invalid value
* Text box is highlighted in red
* Plus, a tooltip appears on top of the text box with the error message
* User must correct this mistake and click “Save” again in order to proceed

Comment 30

[Tony Santos [:tsmuse]]

Attachment: Updates to Bram's original mocks

Hi All,

Bram brought me in on this shortly after I got here and got up to speed and I have some additional suggestions to add to Bram's proposed in-line editing UI idea.

After looking through the way the information in this section is organized and doing some impromptu testing with some of my web and mobile dev friends over the holidays I came up with the attached modifications to Bram's proposal. Basically we need to separate the content that shows up in the app's marketplace page from the rest of the info we have collected about the app. There was a lot of confusion about "what do the people downloading my app see?" when evaluating the current edit forms we have. Bram already had a lot of this done in his original mocks with the editing inline, I've just moved the additional forms at the bottom of the page into another section called "App Info" (with the exception of the media form, that should be included as shown in the mockup with the rest of the in-line editing) and renamed the existing section "Marketplace Listing". The App Info section will then have more than enough room to easily accommodate the existing manage authors, manage compatibility and status details sections in one page, removing the pages that a lot of my participants felt were not big enough to need their own page. We then end up with a much simpler to navigate management section that consists of the marketplace listing page, the app info page and the stats page. 

This gives us the benefits of clearly defining for the developers what will be on their app's marketplace page, as well as giving a preview of the page without requiring a click through to another page. It also lets us simplify our hierarchy a bit.

Comment 31

[David Bialer [:dbialer]]

These look nice and like the idea to have a WYSIWYG-type field editor.
A couple of things:
1. The app name should not be editable. The reason is to prevent spoofing of other apps.  
2. It may be more obvious to have a small edit button next to a field, kind of like the screenshot field, rather than highlighting it to indicate visually it is editable?  Just a thought.

Comment 32

[Andrew Williamson [:eviljeff]]

(In reply to David Bialer [:dbialer] from comment #31)
> 1. The app name should not be editable. The reason is to prevent spoofing of
> other apps.  

Can you expand on reasoning behind this change?  The app name has always been editable - requiring the developer to delete and recreate their listing just to change the name seems a little extreme.  Could we have the app be flagged for re-review instead (as happens if they change then app name in the manifest)?

Comment 33

[David Bialer [:dbialer]]

There are a few conversations around this:
Bug 824734 - Issue of whether by updating name an could spoof another app like "Bank of America"  see https://bugzilla.mozilla.org/show_bug.cgi?id=826427#c9 as an example.
Bug 753779 - the app name in the manifest should be the source of truth.  See last comments over long discussion.

Basically app manifests need to match app names, so the proper way to change a name is to update the manifest - this would flag for review.  This would be a better way to change rather than the editable field.

Comment 34

[Andrew Williamson [:eviljeff]]

(In reply to David Bialer [:dbialer] from comment #33)
> Bug 753779 - the app name in the manifest should be the source of truth. 
> See last comments over long discussion.
> 
> Basically app manifests need to match app names, so the proper way to change
> a name is to update the manifest - this would flag for review.  This would
> be a better way to change rather than the editable field.

Yeah, that's a good way of handling it.  Arguably some of the other listing information that is proposed to be editable should be pulled from the manifest too when updated (description, for example).  I guess this is blocked on bug 753779 then.

Comment 35

[Christopher Van Wiemeersch [:cvan]]

How much of this is still relevant?

Comment 36

[Bram Pitoyo [:bram]]

I think that inline editing will help developers visualize information better. In turn, fields that cannot be edited without going back to the manifest will simply not carry the yellow highlighting.

Comment 37

[Andy McKay]

The new devhub work replace this.