300949 - UI should be optimized to viewing attachments, not editing them.

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Terry Weissman]

I recently upgraded our company's Bugzilla installation to top-of-trunk; I live
dangerously.

Everything is fine, but people are complaining to me that they are having
trouble viewing their attachments.  I tracked this down to the patch in bug
274906.  I told the people here about that.  Below is one reaction, with which I
completely agree:

> Ugh, talk about a cure that is way worse than the disease.  The bug you
> referenced came about because people didn't like what happened when they
> replied to a bugzilla comment that contained an attachment.  That happens
> fairly infrequently, IMHO.  But it resulted in a change that impacts all
> attachment viewing.

> I would vote to undo the patch in
> https://bugzilla.mozilla.org/show_bug.cgi?id=274906#c12

> If anything, they should have dropped the "[edit]" link and just told people
> to scroll to the top of the bug if they needed to edit an attachment.
> I view attachments many times a day.  I edit attachments about twice a month.

Comment 1

[Phil Schwartau]

Something else that seems broken: right-clicking an attachment to save
it to disk. As with the viewing behavior, it works fine if we access
the attachment at the top of the bug, in the attachment list. But if
we right-click it as it appears in the bug body (i.e. under a comment),
the save-dialog identifies it as "attachment.cgi.htm" and saves it as
a completely inappropriate HTML file.

Comment 2

[Frédéric Buclin]

I disagree with this request. I edit a bug much more often than I view it
(usually for download). The user is free to view it or use the diff feature from
the edit page. That's the best place to go. From the viewing page, you cannot do
anything else than coming back to the previous page. See also myk's comment in
bug 274724:

https://bugzilla.mozilla.org/show_bug.cgi?id=274724#c14

Comment 3

[Terry Weissman]

I don't know what comment of Myk's you think is relevant.

Your usage pattern does not match the usage pattern of users here; they all
definitely view attachments.  Which makes tons more sense to me; that's what an
attachment is for, so that other people can see them.

I am willing to make up a patch that would make a parameter to control the
behavior, if someone will give me an indication that there is a chance it would
be accepted.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Terry, do your users generally view attachments in their web browsers or
download them?  In other words, is the common behavior a left-click on the
attachment or a right-click "Save Link As..."?

Comment 5

[Terry Weissman]

An informal survey says "they do both".

Sometimes people attach specs to a bug, people read them by left-clicking.

Sometimes people attach test cases to bugs, people save them off for use by
right-clicking.

Both cases are well served by a viewing link, but not by an editing link.

Useless stats: here are the kinds of attachments we have, and how many of each:

mysql> select mimetype, count(*) from attachments group by mimetype ;
+-------------------------------+----------+
| mimetype                      | count(*) |
+-------------------------------+----------+
| application/excel             |        3 |
| application/msexcel           |        1 |
| application/msword            |     2403 |
| application/octet-stream      |     1308 |
| application/pdf               |      313 |
| application/rtf               |        1 |
| application/vnd.ms-excel      |     2075 |
| application/vnd.ms-powerpoint |       61 |
| application/vnd.visio         |       16 |
| application/x-binary          |        1 |
| application/x-javascript      |        1 |
| application/x-msword          |        3 |
| application/x-perl            |        2 |
| application/x-zip-compressed  |       98 |
| application/zip               |       46 |
| audio/mpeg                    |        9 |
| audio/wav                     |        7 |
| image/bmp                     |        2 |
| image/efax                    |        8 |
| image/gif                     |        7 |
| image/jpeg                    |       15 |
| image/pjpeg                   |       16 |
| image/png                     |       10 |
| image/tiff                    |        4 |
| text/asp                      |        1 |
| text/csv                      |        4 |
| text/html                     |       95 |
| text/plain                    |     4923 |
| text/richtext                 |       22 |
| text/xml                      |       19 |
+-------------------------------+----------+
30 rows in set (1 min 16.74 sec)

Comment 6

[Myk Melez [:myk] [@mykmelez]]

I'd like attachment links to give users what they want most of the time, but I
also want them to be able to access other options from there.  I don't think the
attachments table at the top of the page works well enough for that.

The reason I ask what your users do more is that I'm going to redesign what is
currently the "edit attachment" page so that it has a distinct mode optimized
for viewing the attachment and better UI for downloading the attachment and
switching between the view, edit, and (for patches) diff modes.

For example, using a tab metaphor for the modes and a button for downloading,
the top of the page might look like this (with, perhaps, the view mode being the
default):

Attachment 123 [details]: patch to fix problem reported in bug
  ------   ------   ------
 | View | | Edit | | Diff |    Download
-                          ----------------------------
 <attachment content/edit form/diff displays here>

The View mode could probably be made to trigger the browser to automatically
download non-displayable attachments.  The combination of a default "View" mode
and auto-downloading of non-displayable attachments seems like it would solve
the majority of the issues here, although users who frequently download
displayable attachments will still be faced with the extra step of clicking
"Download".

Comment 7

[chouck]

> although users who frequently download displayable attachments will still be 
> faced with the extra step of clicking "Download".

Yes, and that is exactly the problem.  A UI that had been nice and novice
friendly has suddenly become very power-user-ish.  We have a lot of people who
have been trained how to use bugzilla to file a bug with a spec attached to it
and get back test files in return.  They have no idea what MIME-types are, for
example, and getting funneled into the edit attachment page has become confusing
and intimidating for them.

What about Terry's offer to make a patch to make this configurable?

-Chris

Comment 8

[Myk Melez [:myk] [@mykmelez]]

> A UI that had been nice and novice friendly has suddenly become very
> power-user-ish.  We have a lot of people who have been trained how to use 
> bugzilla to file a bug with a spec attached to it and get back test files
> in return.  They have no idea what MIME-types are, for example, and getting
> funneled into the edit attachment page has become confusing and intimidating
> for them.

Sure, but what if they were funneled into a "view attachment" page rather than
the "edit attachment" page?  That would give them what they expect while making
other representations of that information more accessible and discoverable.

It also makes it possible to change the default mode for specific types of
attachments to something more useful for most users.  For example, we might
change the default mode for patches to "diff", which I suspect many people would
find more useful than the current "view raw patch" mode.


> What about Terry's offer to make a patch to make this configurable?

I'm amenable to making this configurable if there isn't a solution that works
well generally.  Certainly the current approach isn't sufficient; we didn't do
the necessary UI work to make it work well.  But it seems like that can be
rectified.

Comment 9

[Terry Weissman]

> Sure, but what if they were funneled into a "view attachment" page rather than
> the "edit attachment" page?  That would give them what they expect while making
> other representations of that information more accessible and discoverable.

It's still an extra click and an extra page load.  That's very clumsy compared
to the previous behavior.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

> It's still an extra click and an extra page load.  That's very clumsy compared
> to the previous behavior.

It's only an extra click when users want to download the attachment, and even
then only for attachments displayable in the browser.  As a percentage of total
attachment interactions, that doesn't seem like the most common behavior, and it
seems worth the cost for the benefits accrued.

But if you feel differently and would like to make it an installation-specific
parameter, I'm OK with that.

Comment 11

[Terry Weissman]

> It's only an extra click when users want to download the attachment, and even
> then only for attachments displayable in the browser.  As a percentage of total
> attachment interactions, that doesn't seem like the most common behavior, and it
> seems worth the cost for the benefits accrued.

I guess I don't understand what you are proposing.  I thought you said that
clicking on an attachment link in the midst of a bug will always bring up a
"view attachment" page.

What are you saying it will do?

Comment 12

[Myk Melez [:myk] [@mykmelez]]

> I guess I don't understand what you are proposing.  I thought you said that
> clicking on an attachment link in the midst of a bug will always bring up a
> "view attachment" page.

I'm proposing that clicking the link always bring up a "view attachment" page
with a couple of exceptions:

  1. if the attachment isn't displayable in a browser, it brings up
     the page, but it also automatically initiates a download
     of the attachment;

  2. if most users want something else when accessing an attachment
     of that type (f.e. if most people want to see a diff of a patch),
     we show them that instead.

This way:

  * if the user wants to view the attachment, they do so by merely
    clicking on the link;
  * if the user wants to download the attachment, and the attachment
    isn't displayable in a browser, they do so by merely clicking
    on the link;
  * if the user wants to download the attachment, and the attachment
    is displayable in a browser, they do so by clicking on the link,
    then clicking on the "Download" link.

This approach makes viewing and downloading an attachment take the same number
of clicks in the first two cases.  Only in the third case does it take an
additional click, but it provides users with the benefits of ready access to
other ways of accessing the attachment in all cases (since the "view attachment"
page will have good UI for editing, diffing, etc.), a worthwhile tradeoff.

Comment 13

[Terry Weissman]

I think you are saying that you are going to generally view the attachment
inside the browser, but you are going to have a tabbed UI above that so that
they can choose to do something else.

I'm not sure how you're going to implement that.  Frames?  Iframes?

Comment 14

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #13)
> I think you are saying that you are going to generally view the attachment
> inside the browser, but you are going to have a tabbed UI above that so that
> they can choose to do something else.

Right.

> I'm not sure how you're going to implement that.  Frames?  Iframes?

I'm thinking more of what we do for the search page, which has "Advanced Search"
and "Find a Specific Bug" tabs embedded in the page itself.  Click a tab, and
the page reloads into the corresponding mode (ultimately this could happen
without a reload for clients that supported it).

Comment 15

[chouck]

But wouldn't all of this still break right-click->save as... from the main bug
view to save the content of the attachment to disk?  It sounds like you are
saying that the link would be to your embedding page or to the script that
determined whether the attachment could be displayed inline or not --- it
wouldn't be a link to the actual data.

When all is said and done, I think that we need a link to the raw data that we
can left click on to view and right click on to save to disk without having to
scroll to the top of the bug or go to an itermediate page first.  I think it
would be perfectly fine if clicking on the name of the attachment took you to
the new tabbed edit page and there was also a [raw data] link next to it that
linked to the actual data.  Or something like that.

-Chris

Comment 16

[Jacob Steenhagen]

What's proposed in bug 286427 would most likely solve the problem of having to
scroll up in order to download the attachment. A popup (in the form of a
floating DIV) could contain some of the additional attachment data (such as the
name and flag info) as well as links to download, view, edit, diff or whatever
the attachment. This would only work on DOM supporting browsers with JavaScript
enabled (those that either disable JavaScript or don't support DOM could get the
view page Myk is talking about).

Comment 17

[Marc Schumann [:Wurblzap]]

I gather that a default of "edit" is considered power-user-ish, while a default
of "view" is considered the opposite. Both are considered useful. Why don't we
introduce a user setting then which defaults to "view"? Power-users may then
choose to change this to "edit", if they want to.

Comment 18

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: implements [raw] link for attachments

There are a number of proposals for resolving this, but nothing that stands out
or has been implemented yet.  In the meantime, this bug does reduce the
usability of our product, and it should be addressed, preferably within the
2.20 timeframe if it hasn't already left the station.

Here's a patch that adds a [raw] link next to attachment links.  With this
patch, Bugzilla regains its previous functionality of linking to both the
"edit" and "view" attachment pages, albeit in reverse.	In the future, I expect
interface improvements to render this link obsolete, at which point it can be
removed.

Comment 19

[Teemu Mannermaa (:wicked)]

Comment on attachment 195459 [details] [diff] [review]
patch v1: implements [raw] link for attachments

This applies to both 2.20 branch and trunk. It also does what it advertises.

Nit: Maybe change the "raw" to "view" so users understand better what that link
is about?

Note that this patch regresses bug 274906. Myk says this is intentional so I
leave that decision for the approver.

Comment 20

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v2: fixes regression

Here's a better patch that doesn't regress the fix for bug 274906, but it does
revert to the previous behavior of having the link go to the attachment view
and a separate [edit] link.  Removing [edit] was ill-advised without having a
good strategy to replace it.  Ultimately we'll have that strategy, and [edit]
can go away, but for now it should stay.

Comment 21

[Dave Miller [:justdave]]

For a longer-term fix, how about doing what bonsai's cvsblame does when you
hover a revision number?

i.e. pop up a layered <div> that contains the view/edit/diff/etc links when you
hover it?

Comment 22

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #21)
> For a longer-term fix, how about doing what bonsai's cvsblame does when you
> hover a revision number?
> 
> i.e. pop up a layered <div> that contains the view/edit/diff/etc links when you
> hover it?

Jacob mentioned that in comment 16.  That plus what I suggest in comment 6 are
the long-term solutions to this problem.

Comment 23

[Dave Miller [:justdave]]

Comment on attachment 195470 [details] [diff] [review]
patch v2: fixes regression

tested at http://landfill.bugzilla.org/bzdave/show_bug.cgi?id=948  looks good.

Comment 24

[Myk Melez [:myk] [@mykmelez]]

Thanks Dave.  Fixed on the trunk and the 2.20 branch.

Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.340; previous revision: 1.339
done
Checking in ../bz220/globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.326.2.4; previous revision: 1.326.2.3
done

Comment 25

[Teemu Mannermaa (:wicked)]

Comment on attachment 195459 [details] [diff] [review]
patch v1: implements [raw] link for attachments

As the regression was so easy to fix, this patch isn't so good idea afterall.
:)

Comment 26

[Dave Miller [:justdave]]

I think this was meant to be FIXED.  The long-term resolution can be dealt with
on bug 286427.