Closed Bug 783673 Opened 12 years ago Closed 11 years ago

Remove Developer Comments

Categories

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

Product:
Marketplace Graveyard
Component:
Developer Pages
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
2013-04-11

People

(Reporter: cvan, Assigned: cvan)

References

(
URL
)

Details

(Keywords: uiwanted, Whiteboard: p=1) 

I think we should remove Developer Comments. http://cl.ly/image/1e3t3q461Y0E

Bug 783669 adds the ability for developers to specify version notes for packaged apps. But for hosted apps I don't think people know what dev comments are to be used for. Kevin just made added version notes to his description: http://cl.ly/image/131U3D3J1i1H - and he's a dev on this team!
Jeff, Lisa: do you use this field for anything?
I guess it was only included because addons have a developer comments section in their listing (though its similarly misunderstood/unused).

I don't have any issue with it going.  

If this does go ahead I guess we can append the developer comments to the end of the description and email affected developers.
I'm in favor of keeping as much parity as we can for end users between hosted and packaged apps. If it's unclear what the field should be used for, then I think we should investigate why rather than just remove it.
Should we throw Maria* at this problem?

* We shouldn't actually throw Maria. CCing her would be sufficient.
[Professional UX designer on closed course. Do not attempt.]
Assignee: cvan → nobody
Keywords: uiwanted
Summary: Remove Technical Questions → Remove Developer Comments
Bram, how does the "developer comments" field tie in to your submission workflow redesign? I still stand by Comment 3.
Flags: needinfo?(bram)
I don't think people know what developer comments are to be used for, full stop. Even on AMO, it's not clear how or why it's different from the main description, or why there should be such a division. If people want such a division in their main description, they can already achieve it with <strong> tags.

In short, please kill it with fire.
tl;dr – Remove developer comments.

One of our plans to redesign the app submission flow was to make the “edit details” step mirror what user will see on the consumer-side of the Marketplace, as much as possible. In short, we’ll have inline editing.

This will prevent developers from having to wonder about things like:
* Which field will my potential buyers see, and in what order?
* How long should I write my description/details, and how would they fit in the layout?

There are fields that are not present in the app listing page in the first place; for example: categories and default locale.

There are also fields that will trigger a fairly complex chain of events, like:
1. Price, which ties into region, taxes/VATs and payment accounts
2. Team members, which ties into email and user types

Editing these fields will be done separately, on another page. It will not use inline editing.

We’re trying to keep this separated part as short as possible; so a reduction in form field will shorten app submission time, increase success rate, and a win for usability!
Flags: needinfo?(bram)
Is there any argument /for/ keeping the developer comments field?  It only exists because of the common code with AMO - there was no particular design decision around its original inclusion (afaik).
Developer comments can be used as a changelog.  This information should be presented to the user when they're notified that an app update is available.  The user can then decide to take action or wait ("this update adds a critical feature I need right now" vs. "I can wait until I get on wifi to download more levels of this game" vs. "that's some major change to an app I depend on, I'll wait a few days to see if anyone else has problems").

Clearly communicating to users that an app is being supported and regularly improved is an important part of app marketing, too.  This information is a major part of the app update process on other platforms.
I don't know about Marketplace, but AMO has a separate version notes field for that kind of information. If that's the main thing that this field is being used for, then I think that an actual version notes field makes more sense.
Having a version notes field to serve as a container for changelogs sounds like a smart idea. If we choose to do this, I would ask Maria, Maureen or Michael about the positioning of this field on the App Listing page of Marketplace.
We already have version notes on a per-version basis and the "developer comments" section would be redundant. If we're doing a changelog of sorts, this field is outside of that scope. Our system should be responsible for creating the layout for the versions (and listing the version numbers) and not the developer. I.e.: the developer shouldn't be typing "Version 1.0: ..., Version 1.1: ...". We should have a standardized way to do it that's within our complete control.

Presently, "developer comments" doesn't serve any real purpose, even for version information. If there's a need for better changelogging, that's a topic for a new, separate bug.
If there needs to be a different bug, so be it. I'm defending the functionality, not the implementation.  =]

Adding dbialer to the bug, since this came up in the post-offsite discussion.
I'll remove. Bug 837809 will cover Lisa's other request.
Assignee: nobody → cvan
Target Milestone: --- → 2013-02-14
I will look at this, I am hearing several different things:
For End Users it would be good to have "Release Notes" a short description of what is new in this version.  It would also be good to display the latest version number to end users - not that they have any idea which version number they may have installed.
The Release notes could also be used, when we have push, to tell users a new version is available - this may get sent as a notification message (in the future).  This has user interaction impact.  I am gathering up these "Detail page" requests and will make a separate PRD for this.

The second usage is for developers to submit comments in a changelog - more to let the review know what changed, or for a note to themselves.  This may be the 'release' notes as well, and perhaps should be optional as the release notes could explain it.
I think perhaps we can label this field better.  Perhaps on version changes it should appear?
(In reply to David Bialer [:dbialer] from comment #16)
> I will look at this, I am hearing several different things:
> For End Users it would be good to have "Release Notes" a short description
> of what is new in this version.  It would also be good to display the latest
> version number to end users - not that they have any idea which version
> number they may have installed.

Is this different from the version notes we already have (according to basta - I've not seen any packaged app updates yet!) or just a clarification of their use?
 
> The Release notes could also be used, when we have push, to tell users a new
> version is available - this may get sent as a notification message (in the
> future).  This has user interaction impact.  I am gathering up these "Detail
> page" requests and will make a separate PRD for this.

That would be good.

> The second usage is for developers to submit comments in a changelog - more
> to let the review know what changed, or for a note to themselves.  This may
> be the 'release' notes as well, and perhaps should be optional as the
> release notes could explain it.
> I think perhaps we can label this field better.  Perhaps on version changes
> it should appear?

I'm not sure here if you're talking about a private 'notes to reviewer' field or some kind of additional public (single) additional field.
What's the decision here?
Target Milestone: 2013-02-14 → ---
What is the decision here? Adora? Andrew? David?
Whiteboard: p=1
(In reply to Chris Van Wiemeersch [:cvan] from comment #19)
> What is the decision here? Adora? Andrew? David?

I'd say delete, but I've been saying that all along.  We seem to have a number of different things it /could/ be used for but its not really defined for as such, and developers don't know what its for generally.
Target Milestone: --- → 2013-04-04
Target Milestone: 2013-04-04 → 2013-04-11
https://github.com/mozilla/zamboni/commit/0bba7ba
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.