Page MenuHomePhabricator

It should be possible to read boilerplate texts in MediaViewer's download/embed dialog without copypasting them into another application
Open, LowPublic

Description

MediaViewer provides a bunch of boilerplate texts in its share/download/embed panels. It is currently impossible to read this texts without copying them into another application (such as a text editor): the textboxes are very small and only show the first few characters, and they get automatically refocused and keypresses are captured by other handlers and used for global behavior (such as prev/next), so really to only way to scroll the text is having a touchpad. This is annoying for the experienced user, and makes it harder for the inexperienced one to understand the purpose of the text.

Example: https://en.wikipedia.org/wiki/State_of_the_Union#mediaviewer/File:Livingood_Obama_State_of_the_Union_2011.jpg (click Use this file > Embed > HTML)

Screen_Shot_2014-09-16_at_7.45.15_PM.png (902×943 px, 107 KB)

While most of these design decisions were taken in order to maximize the ease of copying the text, and that is a worthwhile goal, there should be a way to just read the text.


Some options raised here and in other places:

  • Change the size of the textarea. While the layout varies a bit (there are several types of boilerplate texts, depending on your choice of share/embed/download and the format), usually there is a fair bit of unused space at the bottom of the popup. Many images would still not fit, though - the description can be rather long.
  • Make the textarea resizable by the user (override the resize:none CSS property provided by OOUI). Somewhat problematic since the parent element is fixed height so a resize attempt can end up looking like this:
    mmv-reuse-resized.png (615×496 px, 163 KB)
  • Use OOUI's autosize option which makes the window grow vertically to encompass the text. Same problem as above but might be possible to limit it to use the available space.
  • Reduce font size.
  • Make the textarea editable so users can scroll with the keyboard. This raises its own issues (e.g. how do you get the text back if you accidentally delete it?) and in general seems to be like an unusual thing to do.

Note also that at some point the boilerplate text might be, in some formats, something that cannot be put in a textarea. (T75957)


See also: T110579

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:37 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz67835.
bzimport added a subscriber: Unknown Object (MLST).
This comment was removed by Tgr.

(In reply to Tisza Gergő from comment #0)

MediaViewer provides a bunch of boilerplate texts in its
share/download/embed panels. It is currently impossible to read this texts
without copying them into another application (such as a text editor): the
textboxes are very small and only show the first few characters, and they
get automatically refocused and keypresses are captured by other handlers
and used for global behavior (such as prev/next), so really to only way to
scroll the text is having a touchpad. This is annoying for the experienced
user, and makes it harder for the inexperienced one to understand the
purpose of the text.

Agreed.

While most of these design decisions were taken in order to maximize the
ease of copying the text, and that is a worthwhile goal, there should be a
way to just read the text. Maybe the textbox could expand when selected...

I think the virtue of these supplemental features (e.g., trying to force all of the text in the text area to be highlighted) is pretty dubious. Is there a credible indication that users are incapable of, or have difficulty with, copying text from a text area themselves? Is extra assistance really needed here?

Gilles subscribed.
Tgr added a project: Design.
Tgr set Security to None.
Tgr added a subscriber: MingleTerminator.

Change 178219 had a related patch set uploaded (by Gergő Tisza):
Fix overzealous textarea click handler

https://gerrit.wikimedia.org/r/178219

Change 234243 had a related patch set uploaded (by Gergő Tisza):
Add explicit word-wrap: break-word to textareas

https://gerrit.wikimedia.org/r/234243

Tgr renamed this task from It should be possible to read boilerplate texts without copypasting them into another application to It should be possible to read boilerplate texts in MediaViewer's download/embed dialog without copypasting them into another application.Aug 27 2015, 7:28 PM

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Change 234243 merged by jenkins-bot:
Add explicit word-wrap: break-word to textareas

https://gerrit.wikimedia.org/r/234243

Jdlrobson claimed this task.

I don't see how this is resolved. The boilerplate for the file mentioned in the description looks like this:

mmv-boilerplate-attribution.png (401×551 px, 72 KB)

And that's a relatively short attribution.

The main purpose of the embed code is to be copied as is. For that purpose we want to show enough to provide a general idea of what it is but not too much in order to avoid it distracting form the rest of the settings (especially with the more verbose HTML tags).

For example, in the last step of the upload wizard, the information to embed the image in a wiki is presented in a single line where not all the content is visible at once:

Screen Shot 2015-10-02 at 10.20.39.png (875×1 px, 146 KB)

As I understand it, users copy and paste the content to a wiki page and keep editing it there.
Can anyone detail some example scenarios when inspecting the content or selecting part of it would be useful?

IMO it inspires more confidence. I reading the text, deciding it's useful and pasting to pasting, reading and deciding whether it was useful. I don't have strong feelings about it though.

In any case this should either be kept open or closed as declined.

Jdlrobson subscribed.

I was working this back in 2015 when it was resolved but not any more.