Here's an interesting project from the British Library - interesting
both because people may wish to enter (there's £25000 available), and
because it touches on a lot of the same questions we have about the
value and impact of content donations
http://britishlibrary.typepad.co.uk/digital-scholarship/2014/03/tracking-pu…https://ictomorrow.innovateuk.org/web/digital-innovation-contest-data/briti…
----
The British Library has a large and growing collection of material in
the public domain, available through online platforms, such as Flickr
(www.flickr.com/photos/britishlibrary) and Wikimedia Commons, for
anyone to use, remix and repurpose. However, once released online, the
British Library has little way of following that content as it is
re-used, which makes it difficult to measure any creative and economic
benefit.
The successful solution will allow public institutions to better
quantify and optimise the economic impact of releasing content into
the public domain (...)
----
--
- Andrew Gray
andrew.gray(a)dunelm.org.uk
On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke <gwicke(a)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.
On Thu, May 22, 2014 at 2:22 AM, Keegan Peterzell
<kpeterzell(a)wikimedia.org> wrote:
>
> I would like to say, Daniel, as much as it's worth over email, that
> ZoomViewer is awesome. With both WMF and volunteer hat, thank you for this
> :)
Hear, hear! It is a pleasure to use, reminds me of the Gigapan tools.
I'd love to see it in wider use.
While optimizing it makes sense medium term, could ZoomViewer be given
its own machine for now so that it could be put into wider use?
Rupert Thurner writes:
> View the original file plus older versions is, from a glam upload perspective,
> mandatory.
I agree. Not merely "one more link", something central and obvious.
(Right now, that is the primary way to interact with image pages on
Commons: The largest active area on the page is the image, which when
clicked takes you to the original file.)
Regards,
Sam
Thank you, Rupert!
We appreciate your feedback — and your support for the "View Original File” idea (1) is duly noted.
What do others think? Is this a good idea? bad idea?
Please chime in by email, or better yet, add your comments on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Proposal:…
Your feedback is important to us. It will help us make the right decision to address this issue quickly.
We’d like to have at least a placeholder solution, even if we can’t do all that we dreamed of right away. :)
All the best,
Fabrice
(1) https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/630
On May 23, 2014, at 10:57 AM, rupert THURNER <rupert.thurner(a)gmail.com> wrote:
>
> Am 22.05.2014 01:38 schrieb "Fabrice Florin" <fflorin(a)wikimedia.org>:
> >
> > Hi folks,
> >
> > We would appreciate your thoughts about a proposed "View Original File” feature for Media Viewer. (1)
> >
> > 1. Goals
> > In our surveys and discussions, many users have asked for either access to original files — or a zoom feature.
> > These frequent requests cover a range of use cases:
> > * view the original file in its full resolution
> > * edit, crop and/or re-use images
> > * zoom in to see details
> >
> > 2. Feature
> > To address these requests, this feature would enable you to access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup (2). This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer.
> >
> > This proposal would support the use cases above by providing the same core functionality editors are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.
> >
> > 3. Alternatives
> > The multimedia team has investigated several other solutions to address these user requests. We developed a Simple Zoom Link (3), which you can test now on Commons: but we’re concerned that this implementation provides a poor user experience that’s more complex than it needs to be. We also considered a Basic Zoom feature (4) and a Full Zoom feature (5). But these implementations require more development time than we have right now. We’re eager to wrap up this version of Media Viewer this month, so we can move on to other important issues, such as upgrading UploadWizard or fixing bugs in our technical debt.
> >
> > 4. What do you think?
> > We’d be grateful for your feedback about this proposal and some of the short-term options we’re considering, by answering these two questions:
> >
> > Q1. How important to you is it that we implement “View original file” or a similar feature at this time?
> > a) very important
> > b) somewhat important
> > c) not important
>
> View the original file plus older versions is, from a glam upload perspective, mandatory.
>
> > Q2. Which of the following options do you think we should develop at this time?
> > a) View Original File: (~1 day of work) (1)
>
> Yes please.
>
>
> > _____________________________
> >
> >
> > (1) View Original File (#630): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/630
> >
> > (2) Design Mockup: https://commons.wikimedia.org/wiki/File:Media_Viewer_-_View_Original_File_-…
> >
> > (3) Simple Zoom Link (#588): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/588
> >
> > (4) Basic Zoom feature (#504): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/504
> >
> > (5) Full Zoom feature (#167): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/167
> >
> > _______________________________
> >
> > Fabrice Florin
> > Product Manager
> > Wikimedia Foundation
> >
> > http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
> >
> >
> >
> >
> > _______________________________________________
> > Multimedia mailing list
> > Multimedia(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/multimedia
> >
> _______________________________________________
> Multimedia mailing list
> Multimedia(a)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)
Hi folks,
We would appreciate your thoughts about a proposed "View Original File” feature for Media Viewer. (1)
1. Goals
In our surveys and discussions, many users have asked for either access to original files — or a zoom feature.
These frequent requests cover a range of use cases:
* view the original file in its full resolution
* edit, crop and/or re-use images
* zoom in to see details
2. Feature
To address these requests, this feature would enable you to access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup (2). This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer.
This proposal would support the use cases above by providing the same core functionality editors are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.
3. Alternatives
The multimedia team has investigated several other solutions to address these user requests. We developed a Simple Zoom Link (3), which you can test now on Commons: but we’re concerned that this implementation provides a poor user experience that’s more complex than it needs to be. We also considered a Basic Zoom feature (4) and a Full Zoom feature (5). But these implementations require more development time than we have right now. We’re eager to wrap up this version of Media Viewer this month, so we can move on to other important issues, such as upgrading UploadWizard or fixing bugs in our technical debt.
4. What do you think?
We’d be grateful for your feedback about this proposal and some of the short-term options we’re considering, by answering these two questions:
Q1. How important to you is it that we implement “View original file” or a similar feature at this time?
a) very important
b) somewhat important
c) not important
Q2. Which of the following options do you think we should develop at this time?
a) View Original File: (~1 day of work) (1)
b) Simple Zoom Link to original file in a tab: (already on Commons, ~1 day to improve) (3)
c) Basic Zoom to original file in Media Viewer: (~1 week of work) (4)
d) Do Nothing
You can respond to these questions by email, or here on our main discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks in advance for your guidance about this important issue. With your help, we hope to implement a practical solution that can address your most pressing needs in coming weeks.
Regards as ever,
Fabrice
_____________________________
(1) View Original File (#630): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/630
(2) Design Mockup: https://commons.wikimedia.org/wiki/File:Media_Viewer_-_View_Original_File_-…
(3) Simple Zoom Link (#588): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/588
(4) Basic Zoom feature (#504): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/504
(5) Full Zoom feature (#167): https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/167
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi folks,
Here’s this week's update on our global release of Media Viewer (1).
1. This week’s release
This week, we plan to enable Media Viewer on two more large sites: Italian and Russian Wikipedias — during tomorrow’s platform train, on Thursday, May 22. We're pushing back releases to other sites to coming weeks, so we can address current issues and avoid deploying to our largest sites right before a holiday. :)
2. Next releases
We now plan to release on the English and German Wikipedias on Tuesday, June 3, as part of a special deployment. This will give us more time to address new user feedback, with more focus on these communities. If all goes well with these releases, we then plan to deploy the tool on all wikis the following week, as described in our release plan. (2)
3. Feedback
Feedback from our onwiki discussions is surfacing great suggestions for improvement, which we are reviewing and discussing with community members. Links to these discussions are available in our release plan, and we invite you to post your own impressions on our main discussion page (3).
We also keep getting increasingly favorable feedback from our user surveys, across 8 languages:
* about 69% of 7,766 respondents so far find the tool useful, on average
* approval rates keep growing (French approval grew by 2 points to 72%, Hungarian by 3 points up to 62%)
* approval breakdown by language: French 70%, Spanish 80%, Dutch 61%, Portuguese 72%, Hungarian 62%
Learn more in our survey report (4), to be updated again after the English and German deployments.
4. Metrics
We are now tracking over 4.7 million image views globally, across 23 sites, as shown in our new global view dashboard (5). Overall performance has stabilized, and the longest image loads are now about 2.8 seconds for 90% of our users, 4.6 seconds for the 95th percentile and 16.4 seconds for the 99th percentile. Learn more in our global metrics performance dashboards (6).
5. Next steps
We are now working on a short list of issues from our community, and have added them to our current cycle board (6). We plan to gradually address the most pressing issues in coming weeks, while resuming our work on technical debt and the upload wizard upgrade. We are reaching out to community members to help us prioritize the most critical tasks in coming weeks.
Thanks to everyone who is helping us with this Media Viewer release! Gergo will send a separate update on other projects that our team is working on.
Best regards,
Fabrice
(1) About Media Viewer: https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
(2) Large Wiki Releases: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
(3) Discussion Page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
(4) Survey Report: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey
(5) Global Image Views Dashboard: http://multimedia-metrics.wmflabs.org/graphs/mmv_image_views_global (to be updated soon)
(6) Global Performance Dashboard: http://multimedia-metrics.wmflabs.org/dashboards/mmv#overall_network_perfor…
(7) Current Cycle Board: http://ur1.ca/h7w5s
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
On Mon, May 19, 2014 at 2:09 AM, dan-nl <dan.entous(a)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.
On Sun, May 18, 2014 at 9:13 AM, rupert THURNER <rupert.thurner(a)gmail.com>wrote:
> 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
issue<https://en.wikipedia.org/wiki/Template_talk:Image_label_begin#Don.27t_link_…>
).
---------- Forwarded message ----------
From: Rainer Rillke <rainerrillke(a)hotmail.com>
Date: 17 May 2014 22:55
Subject: [Wikitech-l] Deployments of new, radically different default features
To: wikitech-l(a)lists.wikimedia.org
Recently, Media Viewer[1] (MMV) has been switched at Wikimedia Commons
to be default.
As some people do not care a lot for beta features or new features, do
not read the mailing lists and overlook main discussion forums or are
just unable to understand English, they were surprised and confused and
wondered how they could disable the feature.
Please help me to evaluate if there are alternatives to how software
deployment is currently done. Here are some suggestions from community
member Jameslwoodward (commons adminstrator):
A Post a banner so that there is a good chance of actually reaching
everyone.
B Ensure that the internally referenced help page actually has correct
information.
C Major changes can be the default for new users, but should be opt-in
for existing users.
I think (A) could be partially done by tech-ambassadors (what a
difficult word); however when deploying something like MMV to all wikis,
isn't this worth a CentralNotice?
(B) is as obvious as important. Outdated information is confusing. Make
sure to update your help pages before going to release your software to
the wild. Or delay the release until this is done.
Suggestion (C) is interesting, although perhaps technically difficult to
implement.
If a feature that one experienced as anonymous user is good [login
cookies expire, ...], or one explicitly tested the feature or was told
by a fellow about a good feature, it is very likely that one will enable
that feature for the account, too. People will do this freely. Without
complaining. And people, who intentionally enabled a feature, usually
have a positive attitude, are willing to help and improve the feature.
They will provide you with constructive feedback.
The overall atmosphere would be a lot more positive than that we
currently experience with new tools, *the power users do not need*. So
why not actively promoting a feature until there is a critical mass
using it? It may take a lot of time but I think it's worth a test.
A personal appeal:
Please care about the power users [2]. They are the core and foundation
of the WMF projects. They create the content; manage most issues - think
about the OTRS team - in their spare time, ... so WMF can finally run
the fundraiser banners and you can get your payment.
-- Rillke
[1] https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer
[2]
http://www.aswedeingermany.de/50SoftwareDevelopment/20MostImportantRuleOfUI…
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, May 17, 2014 at 6:00 AM, rupert THURNER <rupert.thurner(a)gmail.com>wrote:
> 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...
