Closed Bug 866542 Opened 11 years ago Closed 10 years ago

Attachment list should only be visible when editing

Categories

(developer.mozilla.org Graveyard :: File attachments, defect)

Product:
developer.mozilla.org Graveyard
Component:
File attachments
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fs, Unassigned)

Details

(Whiteboard: [specification][type:change]) 

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
The attachment list on an article should only be shown if you're editing an article on MDN.

What problems would this solve?
===============================
"Visual junk" would disappear for the normal reader. 

Who would use this?
===================
Normal MDN visitors

What would users see?
=====================
No attachment list when viewing a page; it's only visible when editing

What would users do? What would happen as a result?
===================================================
Less visual junk.

Is there anything else we should know?
======================================
Came up in a discussion in the Vancouver DocSprint.
Thanks for bringing this up, Florian.

Did you discuss the possibility of authors relying on the attachment list being visible? I imagine some authors add attachments (and maybe even refer to those attachments within the article) but do not manually add link to those attachments in the article.
Flags: needinfo?(elchi3)
Still on paternity leave but...

I also disagree with this bug; non-editing users can get easy access to right-click-download attachments with the list in the page.
John: Currently, attachments aren't associated with an article, so they only appear in the list if explicitly linked to in the article anyway.

I'm torn on this; I agree that the list can be cluttered if it's got a lot of little files that are used in the design of the content. How about only listing non-image files unless you're in the editor?

That would let you download, say, sample code and the like, but avoid cluttering things up with the images used inline in the article.
Clearing needinfo. See comment 3.
Flags: needinfo?(elchi3)
See https://developer.mozilla.org/en-US/docs/Web/CSS/cursor#page-attachments

I get lost in that table when scrolling down the page...
Should we just put attachments under the meta data at the bottom?  I still think the table is relevant on these pages.
I do think we need this table; but how about making it so the attachments section is toggleable using a disclosure widget of some kind, so you don't have to see the list unless you want to?
(In reply to David Walsh :davidwalsh from comment #6)
> Should we just put attachments under the meta data at the bottom?  I still
> think the table is relevant on these pages.

I don't think it's relevant to readers in the page Florian quoted, or in devtools pages like this one: https://developer.mozilla.org/en-US/docs/Tools/Debugger.

As for attaching sample code, the last time I tried to do this I found you couldn't, and I raised this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=866426 and left everything on GitHub, which worked perfectly well. I don't know if that situation has changed, but that bug's status hasn't.

Even if we can attach sample code, I think it's fine to link to downloads in context, in the page, rather than in a table at the end, as pages like this: https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator/Simulator_Walkthrough do. Even if these code zips were attached to the page, they'd be kind of lost among the screenshot attachments.
OK, if we're all sold on removing it, I will remove it.
(In reply to David Walsh :davidwalsh from comment #9)
> OK, if we're all sold on removing it, I will remove it.

I still feel that it should be there but require clicking something to disclose it. Users shouldn't have to edit a page to see the files linked to.

Attaching code should work fine. If it's zipped, that's a problem, because we don't allow zip files since it opens up chances of being used to get around checks for appropriate content (unless we add code to unpack them, check them using some automated means, etc). You just have to attach just the text files.
17,147 (0.27%) of page-viewers clicked an attachments link from article pages between March 28 and April 27.

I vote to remove it, but give some way for those 17k viewers to reach the attachments.
Component: General → File attachments
I'm okay with this *if* we add an easy way to create a "download file" button that would download a specific attachment. There are cases where we should be offering downloads, beyond those we currently do, because doing so is tricky UX-wise right now.
Makes sense. Feedbacking myself to remind myself to experiment on such a button.
Flags: needinfo?(jypenator)
Ping -- what should we do here?
I still feel that hiding them by default for non-logged-in users, but with a button to toggle the list display on, would be the best solution here.
The complete solution would be to have 2 kinds of attachments: ones, hidden for the reader, that are resources used on the page, others, visible for the reader, that are resources for the user to download.

That means that each attachment should have a flag in the DB(that can be toggled after the initial upload).

We could set this flag to "Not show" by default on existing attachments, as this is what is implicitly done now (and is the most common case).

Feedbacking Justin, so that he can drive this: it isn't a quick immediate change. Even if it isn't a huge change. (1 flag in DB, 2-3 GUI to update (display page, edit page), no migration script other than an ALTER TABLE or similar ).
Flags: needinfo?(jypenator) → needinfo?(hoosteeno)
(In reply to Will Bamberg [:wbamberg] from comment #8)
> Even if we can attach sample code, I think it's fine to link to downloads in
> context, in the page, rather than in a table at the end, as pages like this:
> https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator/
> Simulator_Walkthrough do. Even if these code zips were attached to the page,
> they'd be kind of lost among the screenshot attachments.

In these cases, I think we need both: in-context links and bottom-table links. The first allows the person reading the page to get to the link related to what he is reading. The second allows the person coming back to the page to get the attachment to quickly find them.
(In reply to Jean-Yves Perrier [:teoli] from comment #17)

> In these cases, I think we need both: in-context links and bottom-table
> links. The first allows the person reading the page to get to the link
> related to what he is reading. The second allows the person coming back to
> the page to get the attachment to quickly find them.

I agree 100%.
Can't in-context links just be text links within the wiki, and we hide the attachment table on the view page?  Why does it need to be another attachment field to muddle up the wiki?
Just capturing everything I know about this bug here for anyone (like me) who is late to the conversation.

* There is a list of all attachments at the bottom of many articles. The list can be quite long and distracting.
* Everything in the list of attachments is also linked or embedded in the content above the list. If it's not linked there during upload, it is not attached to the page. 
* The list of attachments is used right now mostly by editors maintaining content.
* Some editors would like to be able to attach things to the page without linking or embedding them in the content.
* If a page did include attachments not linked or embedded in the content, it would need to have a list of them somewhere so users could access the attachments not linked or embedded elsewhere. But that's not how things work right now. 

I just filed bug 1077172 to capture the request to allow attachments not linked inline. So now we can focus in this bug on how to handle lists of attachments at the bottom of articles (which, for now, are all already linked above).

For now, since the utility of these lists is primarily to editors managing images (so says :sheppy, and it appears confirmed by metrics in comment 11), let's hide it on the view page and show it on the edit page. If/when we have a new class of attachments because bug 1077172 is fixed, we will want to show only those non-inlined attachments at the bottom of the page, as comment 16 suggests. 

Fair?
Flags: needinfo?(hoosteeno)
Fair-ish. :)

We might want to consider adding some kind of feature for making it easy to add "downloadables". That is, files whose entire purpose is to be available for download by the reader, such as sample code, components for tutorial projects (such as art resources or data files), sample add-ons, and so forth.

This would let you upload a file and automatically add it to a list of files available for download; the list could be displayed in the sidebar space or in a list at the end of the page.

Just thinking "out loud".
(In reply to Justin Crawford [:hoosteeno] from comment #20)
> * Some editors would like to be able to attach things to the page without
> linking or embedding them in the content.
Not sure if this is what we want. I don't see a use case for having something on the list but not linked to the text.

Can anybody describe a concrete use case for this? That is a case where some attachment should be in the bottom list but *not* linked anywhere in the article itself.
Flags: needinfo?(wbamberg)
Flags: needinfo?(eshepherd)
(In reply to Jean-Yves Perrier [:teoli] from comment #22)
> (In reply to Justin Crawford [:hoosteeno] from comment #20)
> > * Some editors would like to be able to attach things to the page without
> > linking or embedding them in the content.
> Not sure if this is what we want. I don't see a use case for having
> something on the list but not linked to the text.
> 
> Can anybody describe a concrete use case for this? That is a case where some
> attachment should be in the bottom list but *not* linked anywhere in the
> article itself.

No, I don't see a use case of this. I think there are 2 kinds of "attachments":

* resources used in the construction of the page, that are never intended for download by users. For example all the screenshots in the Debugger page are listed at the end: https://developer.mozilla.org/en-US/docs/Tools/Debugger#Attachments. There's no good reason to show this list on pages unless the page is being edited, it's just noise.

* resources actually intended for download by users. For example, the icons in this section: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Getting_started#Implementing_the_add-on. (For actual sample code I usually link to a GitHub repo, (a) because I can't attach zips and (b) because it's easier to keep it updated.) In these cases I'd want to link to the resource in the article in context, but there is a case for wanting them available at the end as well, so they are easily found by returning users, as you said up in comment 17.

I think your comment 16 is a nice summary. But you say "We could set this flag to "Not show" by default on existing attachments, as this is what is implicitly done now (and is the most common case)" - isn't showing the attachment what is implicitly done now?
Flags: needinfo?(wbamberg)
Since we're focusing this bug on the question of whether to display the list under current conditions, without adding new functionality to attachments, I have uplifted comment 23 to bug 1077172, which focuses on new attachment functionality. 

Any other feedback about the short-term implementation suggested in comment 20 (hide attachment list on view, show on edit, until there is some other kind of attachment to show)?
(In reply to Justin Crawford [:hoosteeno] from comment #24)
> Since we're focusing this bug on the question of whether to display the list
> under current conditions, without adding new functionality to attachments, I
> have uplifted comment 23 to bug 1077172, which focuses on new attachment
> functionality. 
> 
> Any other feedback about the short-term implementation suggested in comment
> 20 (hide attachment list on view, show on edit, until there is some other
> kind of attachment to show)?

I'm in favour of this.
If we don't have use cases of resources intended to be downloaded that are not linked in the page (and I don't think we have), I'm in favor of this too.

Asking feedback from Chris too as he knows the Apps/ and FxOS/ area very well and can say if he sees a problem there.
Flags: needinfo?(cmills)
This doesn't create a problem in my zones - I've never used the attachment list as a means to provide links to readers; only in edit view.

+1 in favour of the current suggestion.
Flags: needinfo?(cmills)
If we can get to the point where uploaded files don't become hard to find if you haven't already created the link, that would be nice.

Right now, if you upload the files you're going to be using (say a bunch of images), then only finish the first half of your work (using only some of the icons) before you need to go home for the day, you save your work and possibly log off... and when you come back, the rest of the images you'd uploaded the day before are no longer listed on the page's attachment list, so you have to either hunt for them in the all-files list or re-upload; neither of those is a good option.
Flags: needinfo?(eshepherd)
(In reply to David Walsh :davidwalsh from comment #14)
> Ping -- what should we do here?

Based on comment 20, comment 25, comment 26, comment 27, let's hide on view and show on edit.
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/f3b1abfea66a27f46f2950f46e3d4da606b706a6
fix bug 866542 - Hide attachment table on document display page

https://github.com/mozilla/kuma/commit/446bba36de5b6309e5c0c672b75dea7338c4192f
Merge pull request #2806 from darkwing/attachment-list-866542

fix bug 866542 - Hide attachment table on document display page
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.