Dear Dan, Geni, Hay and Jan:

Thank you all for responding so quickly with your good suggestions!

Do any of these ideas resonate for you more than others? Have we missed anything else?

1. Ideas for a single class: .exclude .for-page-only .hide .media-reliant .media-secondary .media-navigational .nommw .noshow .unrelated

or ...

2. Ideas for multiple classes: .navigational .maintenance .award .protection

Which of these suggestions seem more practical to you?

Should we take this discussion onwiki? or do you think we can resolve it via email?

We would love to find a swift resolution together, so we can make this feature available sooner rather than later …

Much appreciated,

Fabrice

On May 12, 2014, at 1:43 PM, Jan Ainali jan.ainali@wikimedia.se wrote:

How about just .unrelated? Simple to understand, following the criteria you just mentioned. More human readable than something more technically correct such as .nommw

Med vänliga hälsningar, Jan Ainali

Verksamhetschef, Wikimedia Sverige 0729 - 67 29 48

Tänk dig en värld där varje människa har fri tillgång till mänsklighetens samlade kunskap. Det är det vi gör. Bli medlem.

On May 12, 2014, at 12:58 PM, Hay (Husky) huskyr@gmail.com wrote:

I guess the best class name would be one that indicates that the image is for viewing 'in the flow of the article only', and isn't really meant for viewing as a standalone image (which is what you would use the mediaviewer for).

So maybe something like:

for-page-only media-reliant media-secondary media-navigational

I guess prefixing it with 'media' would not be a bad idea as well to avoid having it clash with other classnames (that's why 'hide' or 'noshow' would probably be too generic).

-- Hay

On Mon, May 12, 2014 at 9:48 PM, geni geniice@gmail.com wrote:

...

I'd probably go with multiple descriptive classes rather than a single tag if you are looking for future proofing.

*navigational *maintenance *award *protection

On May 12, 2014, at 12:43 PM, dan-nl dan.entous.wikimedia@gmail.com wrote:

.not-multimedia

or maybe reverse the logic and only allow tagged items to appear in media viewer

.multimedia

with kind regards, dan

On May 12, 2014, at 21:32 , Fabrice Florin fflorin@wikimedia.org wrote:

...

Hi all,

We would appreciate your help to come up with a class name that community members can use to exclude an image from Media Viewer or related tools.

Too many small files (like icons, flags, etc.) appear in Media Viewer for some articles, even though they are unrelated to the topic of the article. Other image files also need to be excluded, because they are not suitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).

Many community members have reported this issue, which delivers an unpleasant browsing experience for users who only want to view images that are relevant for the article they are reading (and which are supported by Media Viewer).

We agree that this is an important issue. The most practical way to address it would require editors to add a .metadata class to the images they don’t want to show on a page, as proposed here:

https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/511

We just need to come up with a class name people are happy with for excluding an image from Media Viewer or related tools. We already exclude images which have a .metadata class, but there are images that aren't really metadata but still not appropriate.

Any ideas? What class name do you recommend we use to convey this important information?

Here are some possible ideas, to get this conversation started;

• hide
• exclude
• noshow
• ??

It would be best if we agreed on a name that is not tied to Media Viewer, so it can be used by other tools which may have the same needs, now or in the future.

Once we settle on a class name, we can schedule that feature for development, so editors can filter out unsuitable images for everyone’s viewing pleasure :)

Thanks for your feedback!

Fabrice

---

Fabrice Florin Product Manager, Multimedia Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

_______________________________

Fabrice Florin Product Manager Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

Thanks, Dan.

The main goal is to tag images that are *not* suitable for display in Media Viewer (either because they are small, unrelated icons or flags — or because they do not display well in the current viewer).

Since most images are suitable for Media Viewer, I would not recommend requiring every image to be manually tagged for inclusion — but rather only tag the images that need to be excluded.

As for other use cases, it’s possible that some future applications (e.g. a slide-show maker) might also want to use this class to filter relevant images from an article. Hence the proposal to not make the name specific to Media Viewer, if that’s easy to do.

Hope this helps,

Fabrice

On May 12, 2014, at 2:47 PM, dan-nl dan.entous.wikimedia@gmail.com wrote:

i may be mis-understanding the goal …

1, it looks like you want to distinguish between elements on a web page that should be viewable in mediaviewer vs those that should not.

2. you want to use a css class to distinguish these elements.

3. you mentioned that there may be future or other use cases and so you want a generic css class; what would the other use cases be?

if the idea is to distinguish between items that should be viewable in mediaviewer vs those that should not, then i like

.mediaviewer .mediaviewer-item

with kind regards, dan

On May 12, 2014, at 23:19 , Fabrice Florin fflorin@wikimedia.org wrote:

...

Dear Dan, Geni, Hay and Jan:

Thank you all for responding so quickly with your good suggestions!

Do any of these ideas resonate for you more than others? Have we missed anything else?

1. Ideas for a single class:

.exclude .for-page-only .hide .media-reliant .media-secondary .media-navigational .nommw .noshow .unrelated

or ...

2. Ideas for multiple classes:

.navigational .maintenance .award .protection

Which of these suggestions seem more practical to you?

Should we take this discussion onwiki? or do you think we can resolve it via email?

We would love to find a swift resolution together, so we can make this feature available sooner rather than later …

Much appreciated,

Fabrice

On May 12, 2014, at 1:43 PM, Jan Ainali jan.ainali@wikimedia.se wrote:

...

How about just .unrelated? Simple to understand, following the criteria you just mentioned. More human readable than something more technically correct such as .nommw

Med vänliga hälsningar, Jan Ainali

Verksamhetschef, Wikimedia Sverige 0729 - 67 29 48

Tänk dig en värld där varje människa har fri tillgång till mänsklighetens samlade kunskap. Det är det vi gör. Bli medlem.

On May 12, 2014, at 12:58 PM, Hay (Husky) huskyr@gmail.com wrote:

...

I guess the best class name would be one that indicates that the image is for viewing 'in the flow of the article only', and isn't really meant for viewing as a standalone image (which is what you would use the mediaviewer for).

So maybe something like:

for-page-only media-reliant media-secondary media-navigational

I guess prefixing it with 'media' would not be a bad idea as well to avoid having it clash with other classnames (that's why 'hide' or 'noshow' would probably be too generic).

-- Hay

On Mon, May 12, 2014 at 9:48 PM, geni geniice@gmail.com wrote:

...

I'd probably go with multiple descriptive classes rather than a single tag if you are looking for future proofing.

*navigational *maintenance *award *protection

On May 12, 2014, at 12:43 PM, dan-nl dan.entous.wikimedia@gmail.com wrote:

...

.not-multimedia

or maybe reverse the logic and only allow tagged items to appear in media viewer

.multimedia

with kind regards, dan

On May 12, 2014, at 21:32 , Fabrice Florin fflorin@wikimedia.org wrote:

...

Hi all,

We would appreciate your help to come up with a class name that community members can use to exclude an image from Media Viewer or related tools.

Too many small files (like icons, flags, etc.) appear in Media Viewer for some articles, even though they are unrelated to the topic of the article. Other image files also need to be excluded, because they are not suitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).

Many community members have reported this issue, which delivers an unpleasant browsing experience for users who only want to view images that are relevant for the article they are reading (and which are supported by Media Viewer).

We agree that this is an important issue. The most practical way to address it would require editors to add a .metadata class to the images they don’t want to show on a page, as proposed here:

https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/511

We just need to come up with a class name people are happy with for excluding an image from Media Viewer or related tools. We already exclude images which have a .metadata class, but there are images that aren't really metadata but still not appropriate.

Any ideas? What class name do you recommend we use to convey this important information?

Here are some possible ideas, to get this conversation started;

• hide
• exclude
• noshow
• ??

It would be best if we agreed on a name that is not tied to Media Viewer, so it can be used by other tools which may have the same needs, now or in the future.

Once we settle on a class name, we can schedule that feature for development, so editors can filter out unsuitable images for everyone’s viewing pleasure :)

Thanks for your feedback!

Fabrice

---

Fabrice Florin Product Manager, Multimedia Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

---

Fabrice Florin Product Manager Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

_______________________________

Fabrice Florin Product Manager Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

On 05/13/2014 12:12 AM, Gergo Tisza wrote:

Basically

• we want to distinguish between images for which MediaViewer is a good user

experience vs. those for which it is not

• we want to do it in such a way that places the community in control (CSS

classes are an easy way to do this, there could be others)

• it should be as generic as possible as MediaViewer might not be the only

tool that has to make this decision (is the image suitable for HoverCards/navigation popups? should it be included in the print/PDF view? etc)

• should not be too much work for the community to do it (e.g. adding a CSS

class to every article maintenance template is probably easy since they tend to use common frameworks; adding a parameter to the thumbnail wikicode in every such template is probably not so easy).

Some things that should be excluded:

• things that don't really belong to the article content (such as

maintenance templates, icons in signatures on a talk page)

• things that belong to the article but are technically too tricky to work

with MediaViewer (e.g. various CSS map hacks)

• things that belong to the article but MediaViewer does not offer a good

user experience for them (some people suggested very small images)

One option could be to leave the details to each wiki community, e.g. read a jQuery selector from a MediaWiki page or a JS variable, or even use a hook.

Another option is to make this a property of the image rather than it's use site. That should cover the typical icon well, and with minimal editor effort.

If there are use cases where an image should be shown in some articles only, then inline CSS classes could still make sense to override the per-image property.

Gabriel

just reading through and one issue that stands out with (e.g.: [[file:foo.png|thumb|no-viewer|…]]). format is that many of the small image files are embedded within infoboxes, templates and tables would it be more efficient to restrict media viewer to only images that use the syntax [[File:foo.jpg|thumb|....]] within an article body ignoring images embedded with in {{.....}} and encourage editors to shift flags, small icons, maps etc into templates.

Alternatively just use the [[file:Foo.jpg|*thumb* |....]] as the key for media viewer to display otherwise it just ignores the file

On 13 May 2014 06:35, Gergo Tisza gtisza@wikimedia.org wrote:

On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke gwicke@wikimedia.orgwrote:

...

Another option is to make this a property of the image rather than it's use site. That should cover the typical icon well, and with minimal editor effort.

Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them.

---

Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

On 05/13/2014 12:35 AM, Gergo Tisza wrote:

On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke <gwicke@wikimedia.org mailto:gwicke@wikimedia.org> wrote:

Another option is to make this a property of the image rather than it's use
site. That should cover the typical icon well, and with minimal editor
effort.

Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them.

Combining per-image settings to set the default with the ability to override those defaults in CSS seems to give you the best of both worlds. It's easy to set icons to not show up by default *once* on commons, and it's still possible to modify the behavior locally for less clear-cut cases.

Also, I strongly agree with other's preference to avoid introducing new wikitext syntax for this.

Gabriel

BTW. thinking of noprint made me curious what would happen when printing a MMV view:

Basically it shows backgrounds of the arrows and close/fullscreen widgets, and an ugly table underneath the page, but other than that, quite nice and could be useful with a few small tweaks. I have filed a PDF of the print in bugzilla under: 65287.

DJ

On Wed, May 14, 2014 at 10:52 AM, Derk-Jan Hartman hartman.wiki@gmail.com wrote:

...

• things that don't really belong to the article content (such as maintenance templates, icons in signatures on a talk page)

We already have a class for that .metadata (also excluded from print, book collections, WP 1.0 etc)

...

• things that belong to the article but MediaViewer does not offer a good user experience for them (some people suggested very small images)

Very small images we can just exclude by algorithm, data-file-width and data-file-height will tell us this right ?

...

• things that belong to the article but are technically too tricky to work with MediaViewer (e.g. various CSS map hacks)

I like .noviewer It aligns with several similar classes that are in wide use like: nopopups, noprint, nourlexpansion, nowrap, nounderlines

DJ

On Tue, May 13, 2014 at 12:12 AM, Gergo Tisza gtisza@wikimedia.org wrote:

...

On Mon, May 12, 2014 at 2:47 PM, dan-nl dan.entous.wikimedia@gmail.com wrote:

...

i may be mis-understanding the goal …

1, it looks like you want to distinguish between elements on a web page that should be viewable in mediaviewer vs those that should not.

2. you want to use a css class to distinguish these elements.

3. you mentioned that there may be future or other use cases and so you

want a generic css class; what would the other use cases be?

if the idea is to distinguish between items that should be viewable in mediaviewer vs those that should not, then i like

.mediaviewer .mediaviewer-item

Basically

• we want to distinguish between images for which MediaViewer is a good user

experience vs. those for which it is not

• we want to do it in such a way that places the community in control (CSS

classes are an easy way to do this, there could be others)

• it should be as generic as possible as MediaViewer might not be the only

tool that has to make this decision (is the image suitable for HoverCards/navigation popups? should it be included in the print/PDF view? etc)

• should not be too much work for the community to do it (e.g. adding a CSS

class to every article maintenance template is probably easy since they tend to use common frameworks; adding a parameter to the thumbnail wikicode in every such template is probably not so easy).

Some things that should be excluded:

• things that don't really belong to the article content (such as

maintenance templates, icons in signatures on a talk page)

• things that belong to the article but are technically too tricky to work

with MediaViewer (e.g. various CSS map hacks)

• things that belong to the article but MediaViewer does not offer a good

user experience for them (some people suggested very small images)

One option could be to leave the details to each wiki community, e.g. read a jQuery selector from a MediaWiki page or a JS variable, or even use a hook.

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

I'd recommend avoiding classes specific to MultimediaViewer for this purpose.

The semantic intent here is to mark images that are not considered part of regular article content. These would be presentational elements like user interface icons, images part of a larger construct (such as clipped images, map pins etc.). It's not at all related to MultimediaViewer and is useful for other tools as well. Don't forget that what MMV is doing is by no means new. Gadgets like these have existed for years and people will continue to use and develop these. This is good; we want people to stay inspired (and even competitive in a way). These gadgets would greatly benefit from a simple class name filter to replace their current approach (lots of exceptions for arbitrary class names, and individual patterns like "Clear crystal" icon).

Making this MMV-specific would give MMV special treatment resulting in hacks and maintenance burdens we don't want. A class like no-mmv" masks the real intent. In my experience that would discourage communication between users and developers when issues arise. Not the users that read it here, but the users that copy it further down the line; whom won't know its purpose.

Making it specific to the idea of a "viewer" (e.g. "no-viewer", "viewer-exclude", or "for-page-only") is better in my opinion, but only marginally so. I'd recommend aiming for something that reflects what it is and allows separation of concerns. Then have MMV use that in its filters. This may mean we'll need two instead of one if the types of images in this category are that different, but that would imho be a good thing.

— Krinkle

On Wed, May 14, 2014 at 5:50 AM, Krinkle krinklemail@gmail.com wrote:

Making it specific to the idea of a "viewer" (e.g. "no-viewer", "viewer-exclude", or "for-page-only") is better in my opinion, but only marginally so. I'd recommend aiming for something that reflects what it is and allows separation of concerns. Then have MMV use that in its filters. This may mean we'll need two instead of one if the types of images in this category are that different, but that would imho be a good thing.

We would like to wrap this issue up soon; using a "noviewer" class seems to be the best proposal so far. I do agree with you in theory, and I would be happy to use more semantic class names if someone proposed good ones, but I don't have any idea myself what they should be.

On Fri, May 16, 2014 at 8:00 PM, Fabrice Florin fflorin@wikimedia.org wrote:

<code><nowiki><span class="metadata">[[File:Foo.jpg]]</span></nowiki></code>

• For images that are not metadata, but which don’t really render well in

Media Viewer, consider using a '[[:w:Wikipedia:Extended_image_syntax#Images_that_link_somewhere_other_than_the_image_description_page|link parameter]]' to disable them in Media Viewer: <code><nowiki>[[File:Foo.jpg|link=]]</nowiki></code> <br>

I think that's a misuse of the link parameter and doesn't really help in allowing users to separate between 'metadata images' and 'non-metadata images'. The 'noviewer' class, however flawed it might be, is better than this solution IMO.

-- Hay

On Sat, May 17, 2014 at 6:00 AM, rupert THURNER rupert.thurner@gmail.comwrote:

Instead of introducing complicated syntax, would it not be better that media viewer only displays thumbs?

Quoting from earlier:

There are images that do not use that syntax but we want to display them,

for example infobox main images, gallery templates, images on the main page...

On Sun, May 18, 2014 at 9:13 AM, rupert THURNER rupert.thurner@gmail.comwrote:

The main page seems to be such an obscure case that it might be adressed when we have a better idea than forcing millions of exception edits what you think?

Obscure in what sense? I would expect mainpage images to get more clicks than all those exceptions.

Anyway, do you have examples of exceptions were adding either link= or class="metadata" would not be a good idea even irrespective of MediaViewer? Most exceptions I've seen so far would benefit from either being marked as not part of the article content, or marked as "not really an image but something tricky" (CSS magics - a lot of other tools than lightboxes will have trouble with these). Also, for most "tricky" images going to the description page on click is really horrible behavior (see e.g. this issuehttps://en.wikipedia.org/wiki/Template_talk:Image_label_begin#Don.27t_link_to_file_page_by_default ).

On Mon, May 19, 2014 at 2:09 AM, dan-nl dan.entous@gmail.com wrote:

this is may be a long-shot, but what about allowing all files from the /images/ directory and excluding images from any other directory? the assumption being that icons and other "helper" images will come from directories other than /images/.

If you mean assets (stuff from bits.wikimedia.org), we don't show any of those, only uploaded files. Those are stored in directories with random (sha1-based) names.

Thanks, Bawolff.

From an end-user perspective, I like the idea of making the tag part of the file embedding syntax, as you propose (e.g.: [[file:foo.png|thumb|no-viewer|…]]).

I defer to our development team on how much more work that would entail. We now only have a few hours per week allocated to Media Viewer feature development, so we’re leaning towards the most expedient solutions right now.

Even if we start with just a class name right now (e.g. '.no-viewer'), that name that could eventually be re-used when we have time to make it part of the file embedding syntax, for consistency purposes.

BTW, I like ’no-viewer’ because it’s short and very explicit — and even if it’s loosely tied to the Media Viewer, it seems open-ended enough to be used by other apps in the future.

-f

On May 12, 2014, at 2:54 PM, bawolff bawolff+wn@gmail.com wrote:

On May 12, 2014 4:32 PM, "Fabrice Florin" fflorin@wikimedia.org wrote:

...

Hi all,

We would appreciate your help to come up with a class name that community members can use to exclude an image from Media Viewer or related tools.

Too many small files (like icons, flags, etc.) appear in Media Viewer for some articles, even though they are unrelated to the topic of the article. Other image files also need to be excluded, because they are not suitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).

Many community members have reported this issue, which delivers an unpleasant browsing experience for users who only want to view images that are relevant for the article they are reading (and which are supported by Media Viewer).

We agree that this is an important issue. The most practical way to address it would require editors to add a .metadata class to the images they don’t want to show on a page, as proposed here:

https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/511

We just need to come up with a class name people are happy with for excluding an image from Media Viewer or related tools. We already exclude images which have a .metadata class, but there are images that aren't really metadata but still not appropriate.

Any ideas? What class name do you recommend we use to convey this important information?

Here are some possible ideas, to get this conversation started;

• hide
• exclude
• noshow
• ??

It would be best if we agreed on a name that is not tied to Media Viewer, so it can be used by other tools which may have the same needs, now or in the future.

Once we settle on a class name, we can schedule that feature for development, so editors can filter out unsuitable images for everyone’s viewing pleasure :)

Thanks for your feedback!

Fabrice

---

Fabrice Florin Product Manager, Multimedia Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

Probably much harder to implement... but it might be more consistent to have it as part of the file embedding syntax. E.g. [[file:foo.png|thumb|no-viewer|...]]

--bawolff _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________

Fabrice Florin Product Manager Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

On May 12, 2014 7:29 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:

On Mon, May 12, 2014 at 2:54 PM, bawolff bawolff+wn@gmail.com wrote:

...

Probably much harder to implement... but it might be more consistent to

have it as part of the file embedding syntax. E.g. [[file:foo.png|thumb|no-viewer|...]]

This would make our file inclusion syntax, which is an atrocity that

should not have been allowed to exist, even more complex. There is no way to tell whether a string is a parameter or the description unless you know what exactly the valid parameters are, so changes to them would force changes to every tool that tries to parse wikicode in a non-MediaWiki context.

Already the valid patameters vary by language (which can change arbitrarily via translatewiki), extensions installed (e.g. PagedTiffHandler adds some), and file type. So such tools are already pretty screwed.

File syntax is complex and icky, but it does have the benefit of keeping image display options consistently together. Having some image options triggered by one mechanism and some by another adds complexity too.

[various suggestions about having some sort of system picked out by users]

Imho - wiki syntax is already varrying a ton between different wikis. I would prefer avoiding further diversification (other than i18n) of wiki syntax unless there is a need for such per wiki customization. I dont see a need here.

--bawolff