whats needed is something that is simple on the front end to use, to
wiki-code and maintain it doesnt matter how good a gadget is if its to hard
for people to work with they will switch off, either through preferences,
other gadgets or altogether.
I know it may sound horrid from a programmers perspective but priority must
be for simple front end solutions that require minimal maintenance by
content creators, a switch such as [[File:Foo.jpg|*noview*|.....]] is the
easiest solution, or alternatively [[File:Foo.png|icon|.....]] where icon
also sets the image to a preselected size of 50px and can only render upto
100px
On 14 May 2014 20:50, Krinkle <krinklemail(a)gmail.com> wrote:
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
_______________________________________________
Commons-l mailing list
Commons-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
--
GN.
Vice President Wikimedia Australia
WMAU:
http://www.wikimedia.org.au/wiki/User:Gnangarra
Photo Gallery:
http://gnangarra.redbubble.com