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(a)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(a)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(a)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(a)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(a)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(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)
Greetings!
Here’s our weekly update on what our multimedia team is working on. We hope you find this report helpful.
1. Media Viewer Releases
Today, we just enabled Media Viewer (1) by default on Wikimedia Commons. Next week, we will release the tool on the English, German, Italian and Russian Wikipedias, as well as WikiSources in all languages; if all goes well, we plan to roll out on all wikis the following week, as outlined in our release plan (2). Overall response has been largely favorable, as reported before (3). Please share your feedback on the discussion page (4).
2. Last week’s sprint
Last week, we worked mostly on Media Viewer and Tech Debt (GWToolset and Image Scaler issues), as outlined in our meeting notepad (5). On the Media Viewer front, we fixed a number of bugs, upgraded our metrics with a global image view dashboard (6), investigated then ruled out a simple zoom link, and estimated the server load of Media Viewer when deployed to all wikis (7). On the Technical Debt front, we fixed bugs for the GW Toolset, and added a throttle to prevent it from processing too many images at once; we also investigated root causes of the recent Image Scaler outage, identifying a few promising solutions to work on next.
3. This week’s sprint
This week, we’re planning to split our time evenly between Media Viewer, Tech Debt and Upload Wizard work, as shown in our current sprint board (8). For Media Viewer, we’ll make it easier to discover metadata and add more tooltips to address community requests, as well as run more tests in different browsers like IE9. For Tech Debt, we’ll start generating reference thumbnails to save CPU time on image scalers, as well as lower the frequency of GWToolset jobs. For Upload Wizard, we’re starting to collect usage data on key steps in the upload workflow, as part of a funnel analysis that will tell us where people drop off most often; we’re also analyzing the feedback and bugs backlog, to identify major pain points -- and generating first design ideas to address them; lastly, we’re getting UploadWizard ready for jQuery 1.9, so we can get more familiar with the current code base.
4. Next steps
Through the middle of June, we plan to gradually spend more time on Upload Wizard, once Media Viewer has been successfully deployed, as shown in our current cycle board (9). In coming weeks, we will host a number of community discussions to prioritize key issues and review possible solutions together. Based on this feedback, we aim to implement some of the most promising solutions through the end of the summer.
5. Thanks
We’re very grateful to all the community and team members who keep guiding our progress at each step of the way. We couldn’t do this work without you -- and consider ourselves lucky to have such great partners. Today, we would like to give special thanks to Aaron Arcos, a former Google employee who volunteered for 5 months with our team, and was a wonderful coach and collaborator: he helped us focus on quality, refine our agile development process and get serious about unit testing, as described in the exit video he put together, with interviews from our team (10).
We look forward to more great collaborations with you all. :)
Be well,
Fabrice - for the Multimedia Team
(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) Survey Report: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
(4) Media Viewer page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
(5) Multimedia Sprint Notes: http://etherpad.wikimedia.org/p/multimedia-weekly-meeting-2014-05-14
(6) Global Image View Dashboard: http://multimedia-metrics.wmflabs.org/graphs/mmv_image_views_global
(7) Global Server Load Estimate: https://www.mediawiki.org/wiki/Multimedia/Metrics/Estimations
(8) Current Sprint: http://ur1.ca/gtyrp
(9) Current Cycle Board: http://ur1.ca/h7w5s
(10) Volunteering at Wikipedia: https://www.youtube.com/watch?v=RxW8TMMA05k
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi folks,
Here’s another update on our global release of Media Viewer (1), which is rolling out as smooth as silk. :)
1. This week’s releases
Today, we just enabled Media Viewer by default on the Kannada and Telugu Wikipedias, where we plan to study image load performance in areas with slow connections. This Thursday, May 15, we plan to deploy on Wikimedia Commons, devoting an entire release to this important site, so we can keep a close eye on this more complex deployment.
2. Next week’s release
The following Thursday, May 22, we plan to release on the English, German, Italian and Russian Wikipedias, as well as WikiSources in all languages. If all goes well with these releases, we then plan to deploy the tool on all wikis the following week, May 29, as described in our release plan. (2)
3. Survey results
Survey responses from over 1,700 users are generally favorable, across 8 languages:
* 65% of all respondents find the tool useful, 28% do not find it useful, 7% are not sure
* approval rates keep growing (French approval grew from 64% to 70%, Hungarian surged from 42% to 59%)
* last week's releases show the most positive response (82% of Portuguese users like the tool, vs. 79% of Spanish)
Learn more in our survey report (3) and detailed results (4). We’ll update these results next week, and are looking for a volunteer to help with that work.
4. Metrics
We are now tracking about 4.3 million image views globally, across 22 sites, as shown in our new global view dashboard (5).
* Most image views come from Spanish (28%), French (23%), Polish (11%), Japanese (9%), Portuguese (8%) and Dutch (4%) Wikipedias.
* The most frequent actions are thumbnail clicks (60% of views), close button (53%), next image (31%), history (21%) and previous image (13%)
* Images continue to open faster in Media Viewer (1.5 seconds) than in the previous method of opening a separate file page (2.6 seconds)
* The longest image loads are about 2.8 seconds for 90% of our users, 4.8 seconds for the 95th percentile and 14.3 seconds for the 99th percentile
Learn more in our global metrics dashboards (6) and local dashboards (7) (be sure to click on all the tabs).
5. Next steps
Thanks to survey results and onwiki discussions, we identified a short list of issues that are important to our community, and have added them to our current development cycle boards (8). They include: zoom link, easier ways to find info, larger commons icon, disabling some images, support for multiple licenses, more tooltips and pre-rendering images on the backend. 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’ll keep you posted on next week’s sprint goals after tomorrow's team meeting.
Thanks as always to all the community and team members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This was a really productive partnership, which we hope to build on for future projects.
Onward!
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) Survey Report: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
(4) Detailed Survey Results: http://ur1.ca/ha662
(5) Global Image View Dashboard: http://multimedia-metrics.wmflabs.org/graphs/mmv_image_views_global
(6) Global Actions / Performance Dashboards: http://multimedia-metrics.wmflabs.org/dashboards/mmv
(7) Local Metrics Dashboards: https://www.mediawiki.org/wiki/Multimedia/Metrics#Client-side
(8) Current Cycle Board: http://ur1.ca/h7w5s
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
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)
Hi folks,
I am delighted to share the latest survey results for Media Viewer.
This invaluable user feedback is helping us evaluate what our users think of this tool and address issues that are important to our community.
As of May 5, we had collected 1,727 responses in eight different languages: Catalan, Dutch, English, French, Hungarian, Spanish and Portuguese. Most of the responses came from these three large pilots: Dutch, French and Hungarian.
Here are our key findings:
• 65% of survey respondents find Media Viewer useful, across all languages. About 28% do not find it useful, and 7% are not sure.
• 73% of readers find the tool useful -- more so than editors (66%) or active editors (49%).
• The majority of survey respondents are readers (56%), but editors (30%) and active editors (14%) are well represented.
• Approval rates have been increasing over time (e.g.: Hungarian approval started around 42%, and is now up to 57%).
• More users found Media Viewer useful on sites in English (72%) or French (71%) than on sites in Dutch (53%) or Hungarian (57%).
• Here are the most frequent requests from 1,140 comments:
• Want zoom (21%)
• Too slow (20%)
• More image sizes (8%)
• Want full screen or larger images (5%)
• Can't find info (5%)
We’re learning a lot from this feedback and already developing solutions to address these issues.
For a full report with graphs and our next steps, visit this results page:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
For more detailed survey data, check out this spreadsheet:
http://ur1.ca/ha662
We hope you too will find this feedback helpful. Surveys like these are invaluable for hearing what users think of our tools, as well as for prioritizing which issues to address first.
We plan to post more survey updates next week, with a focus on the Spanish and Portuguese releases — and again at the end of May, after the English and German releases.
Regards as ever,
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Greetings!
I’m happy to let you know that we just enabled Media Viewer by default on the Japanese, Portuguese, Spanish and Swedish Wikipedias.
Our most recent survey results show increasing satisfaction with Media Viewer, across languages:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
We will send a more detailed update on these survey results later today.
Image load times continue to decline, as more people click on thumbnails, which caches them for faster display, as shown in this graph:
http://multimedia-metrics.wmflabs.org/graphs/mmv_performance_image_global
Next week, we plan to release Media Viewer on the Telugu Wikipedia on Tuesday, as well as Wikimedia Commons on Thursday.
You can find local announcements, translations and discussion pages for all our pilots here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
As always, please let us know if you encounter any serious technical issues, or share your views on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Special thanks to everyone who made this release possible, especially our community partners on these sites: Oona and Henrique on the Portuguese Wikipedia, as well as Justine and Santi on the Spanish Wikipedia :)
Enjoy,
Fabrice — for the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
-------- Messaggio originale --------
Oggetto: Let Our Video Go
Data: Wed, 07 May 2014 15:24:09 +0000
Mittente: <Roger Macdonald>
Let Our Video Go
MetMuseunScroll_DT11631
<http://www.metmuseum.org/collections/search-the-collections/548344?img=3>UI
/ UX Advances in Freeing Information Enslaved by an Ancient Egyptian
Model Or… Why Video Scrolling is so Last Millenniums
In creating an open digital research library of television news
<https://archive.org/details/tv>, we have been challenged by being
unable to reference a current user experience model for searching video.
Conventional video search requires users to start at the beginning of
video and proceed at the pace and sequencing dictated by content
creators. Our service has vaulted over the confines of the linear video
storytelling framework by helping users jump into content at points
directly pertaining to their search. But by doing so, we have left some
of our prospective users adrift, without a conceptual template to rely
on. That is until this April, with the release of a new user interface.
GutenbergPress_LoC <http://www.loc.gov/pictures/item/2006690328/>
Treating video as infinitely addressable data is enabling us to do an
increasingly better job at getting researchers right to their points of
interest. While revolutionary, applied at the scale we do with
television news, it has an antecedent in a prior media revolution: the
transition from the age of scrolls to printed books. Gutenberg used
movable type to print identical bibles in the mid-1400′s. It took a
hundred more years before detailed indexes started appearing at the end
of books. The repurposing of closed captioning to facilitate deep search
of video is, in some ways, as significant for television as the
evolution from parchment and papyrus rolls to books with page numbers
and indexes.
The value of most major innovations can only be realized when people
adapt their conceptual models to understand and use them. Our interface
design challenge included helping users make a perceptual leap from a
video experience akin to ancient Egyptians unfurling scrolls to that of
library-literate modern readers, or the even more recent experience of
being able to find specific Web “pages” via search engines.
SprocketScroll
<http://www.metmuseum.org/collections/search-the-collections/547790?img=1>
Our latest interface version helps users cross the cognitive bridge from
video “scrolls” to understanding television programs viewed at the
Internet Archive are like digitally indexed “books,” comprised of
60-second segments. We convey this, in part, by joining the video
segments with filmstrip sprocket border graphics. Linear, like film, but
also “paginated” for leaping from one search-related segment to another.
ScreenShot3
<https://archive.org/details/ALJAZAM_20131204_080000_News?q=indonesia+summit…>
When searching inside individual broadcasts, the new interface
reinforces that metaphor of content hopping by truncating presentation
of interleaving media irrelevant to the search query. We present the
search-relevant video segments, while still conveying the relative
“distance” between each jump — again referencing the linear “scroll”
experience that most have not yet learned to abandon.
ScreenShot4
<http://blog.archive.org/wp-content/uploads/2014/05/ScreenShot4.jpg>
The new UI has another revolutionary aspect that also hearkens back to
one of the great byproducts of the library index model: serendipitous
discovery of adjacent knowledge. Dan Cohen, founding Executive Director
of the Digital Public Library of America recently recounted
<http://dp.la/info/2014/02/07/planning-for-serendipity/>, “I know a
professor who was hit on the head by a book falling off a shelf as he
reached for a different one; that book ended up being a key part of his
future work.”
Segments <http://blog.archive.org/wp-content/uploads/2014/05/Segments.jpg>
When using the new “search within” a single program feature, the browser
dynamically refines the results with each character typed. Unexpected
60-second segments and phrases arise, providing serendipitous choices as
typing proceeds, while options narrow towards the intended results.
These unanticipated, yet systematic, occurrences suggest the diverse
opportunities for inquiry afforded by the unique research library and
encourage some playful exploration.
Carter_10
<http://www.griffith.ox.ac.uk/gri/carter/gallery/p0642.html>The Internet
Archive is still in the early stages of helping guide online television
out of its imprisonment in ancient conceptual frameworks. A bright
future awaits knowledge seekers and content creators alike when digital
video is optimized for systematic discovery of even short segments. New
audiences and new use-cases will be joined with media that has been
languishing for too long in digital tombs, mostly unseen and unheard.
At its heart, the Internet Archive is an invitation to explore and
collaborate. Please, join us in evolving digital opportunities to open
knowledge for the benefit of all.
Start by giving our service a whirl, find something important and quote
it. I just did - https://twitter.com/r_macdonald/status/463492832867516416
Hello again,
We have one more release update for Media Viewer, based on today’s discussions with our deployment and engineering teams.
They recommend that we devote an entire release to Wikimedia Commons on May 15, because it is is a more complex deployment, which we want to track more closely. As a result, we will push back the release to other large wikis by a week, with the final release to all wikis taking place at the end of May, if all goes well. Next week’s release will take place as planned, except that it will not include Wikimedia Commons.
Here is the updated schedule:
• May 8:
Japanese, Portuguese, Spanish, Swedish and Telugu Wikipedias
• May 15:
Wikimedia Commons
• May 22:
English, German, Italian and Russian Wikipedias
• May 29:
Enable by default on all wikis
More details are posted here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
Next week, we’ll post an update on how Media Viewer is performing on our first 16 sites, along with more community feedback.
Have a great weekend!
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi folks,
We just enabled Media Viewer by default on the Dutch and French Wikipedias, besides our 14 other pilot sites.
The images look beautiful on both sites, where we’re getting positive comments from many users :)
A big round of thanks to our community partners on both sites: Romaine and Mathonius on the Dutch Wikipedia, as well as Binabik, Jean-Fred and Trizek on the French Wikipedia :)
They kindly announced this to their communities and helped created special discussion pages where we can respond to local user feedback:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
Overall user response so far has been generally favorable across all pilot sites, as shown in our first survey results:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey#Results
It’s worth noting that approval ratings are increasing on all surveys, after people have a chance to try the tool (e.g.: Hungarian approval was at 42% a week ago, now up to 55%). We will update results again tomorrow, to add more results and comments from Dutch and French users.
It also appears that reduce image load times has been declining, partly due to more people clicking on thumbnails, which puts them into a ‘warm’ cache that loads faster than a ‘cold’ cache, as shown in this graph:
http://multimedia-metrics.wmflabs.org/graphs/mmv_performance_image_global
(Please note that our metrics dashboard are still being updated, so they don’t yet include all the data we’ve collected in recent days, due to a temporary data migration issue, which should be solved shortly.)
For now, we just checked the global Ganglia and Gdash stats, which suggest that everything looks good from an ops and performance standpoint: https://www.mediawiki.org/wiki/Multimedia/Metrics#Ops
Next week, we plan to release Media Viewer on Japanese, Portuguese, Spanish, Swedish and Telugu Wikipedias, as well as Wikimedia Commons. If you are active on any of these sites, we would appreciate your help in introducing this new feature to your community. Please contact Keegan or I so we can coordinate announcements, as well as local discussion pages.
As always, please let us know if you encounter any serious technical issues, or share your views on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks again to everyone for your gracious help on this project!
Enjoy,
Fabrice — for the Multimedia Team
P.S.: New improvements take about 2 weeks to get deployed to all wikis. If you would like to test the latest version of Media Viewer, follow the test tips on this demo page on MediaWiki.org:
https://www.mediawiki.org/wiki/Lightbox_demo
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
«For years, Flickr has been one of the most important repositories of
Creative Commons imagery in the world; now, thanks to a new design, it's
all but useless for serving and attributing the CC-licensed images it's
been entrusted with by museums, galleries, national archives, libraries,
and millions of individuals.»
http://boingboing.net/2014/04/07/restoring-cc-attribution-to-fl.html
Didn't pass here yet I think, though many commoners care a lot about
this sad fate of Flickr for obvious reasons including the ease with
which stuff à la
<https://commons.wikimedia.org/wiki/Commons:Flickr_files/Appeal_for_license_…>
earns us new material daily.
Nemo
