Talk:Multimedia Usability Project Meeting France/Request for comments

From Meta, a Wikimedia project coordination wiki
Other languages:
English · français

Ideas and comments welcome here!

Infographics, maps, and data-driven content[edit]

Here are some ideas that I have, and hope that can be discussed, relating to dynamically generated and interactive content. Aude 00:07, 15 August 2009 (UTC)[reply]

Maps[edit]

We already have the OpenStreetMap integration project underway, though with the database and rendering infrastructure in place, it's possible to build upon that. Could we allow people to upload GIS data files (e.g. shapefiles, GML, KML) and create custom overlays on top of an OpenStreetMap base layer (or other baselayer options such as satellite imagery, terrain map, or political boundaries)? Would Wikimedia Commons be the place for such uploads? how would we handle them?

What about allowing people to use external live data and map sources, such as WMS (web map services) services or live data feeds? Some of these are in the public domain, from providers, such as the National Weather Service in the U.S. for hurricanes and from the USGS for earthquakes.

I'm toying with the idea of developing a mapmaking utility that could reside on the toolserver, for generating custom static maps (without pan/zoom capabilities). If the maps rely on a live data source or need periodic updating, perhaps a bot could be incorporated into the service to regenerate maps on a periodic basis and upload new versions. Aude 00:07, 15 August 2009 (UTC)[reply]

It would be great to be able to use maps to show the timelines of events, e.g. see the path of notable people/groups during the en:Peterloo Massacre. That relies on being able to look back at the historic development of the road system, though (itself something that would be good but probably out of scope here), although it could be equally well applied to recent events. Making it easy to create (and update) things like en:Wikipedia:GM#Map would be good too. Mike Peel 20:30, 19 October 2009 (UTC)[reply]

Dynamic charts and graphs[edit]

Another related idea is to allow dynamically generating charts, graphs, and other content from data sources (e.g. data.gov or U.S. census data), similar to dynamically generating maps. It's a pain right now to maintain such graphics on Wikipedia, as they are hand made and people have to redo them in order to update them. Aude 00:07, 15 August 2009 (UTC)[reply]

Infographics[edit]

Another idea is to allow adding interactive multimedia infographics to Wikipedia articles, or as supplemental material.

Examples:

These typically are implemented in Adobe Flash, but think that JavaScript/ajax approaches like w:OpenLayers would be feasible but not trivial to implement. With Wikipedia's volume of traffic, there are issues with caching graphics and how do we cache or handle such interactive graphics? These may be more reliant on client-side rendering.

How JavaScript is handled, in relation to caching, is also tricky. With the SlippyMap extension, it's been challenging to attempt to implement conditional loading of JavaScript or make the JavaScript code dynamically generated. With some of the MediaWiki hooks, I can have the extension check for presence of a "slippymap" tag, and if true, then have the JavaScript addScript call added in the page header. But, when pages are cached, the addScript call doesn't always get loaded. So, for now, we are having the OpenLayers js included globally, but with that and jQuery and all the other stuff, it can get to be too much. Aude 00:07, 15 August 2009 (UTC)[reply]

Other data-driven content[edit]

Not really dealing with multimedia, but related to dynamic and data-driven content is how to handle the 2000 U.S. census data that is in many articles on small American towns, added by Rambot. It will be outdated with the 2010 U.S. census. How do we update it? And, the Census Bureau does other surveys more frequently than the census, such as the American Community Survey, that could be useful for updating such statistics. Aude 00:07, 15 August 2009 (UTC)[reply]

Legal issues[edit]

I think I am mildly obligated to volunteer myself to talk about patents (philosophy, concerns, strategy, why hosting the servers on Sealand is not sufficient, etc.). I think it is even possible not to be overly boring. :-) Kat Walsh (spill your mind?) 00:24, 15 August 2009 (UTC)[reply]

Maps & the law[edit]

I hope the map guru and the law guru of this October meeting will have an opportunity to talk to each other and to find fresh new ideas.

How do we ensure that a map is legal ?

How do we "disseminate effectively useful information" (this is a plagiarism of Mission) about map legal issues ?

At present we only have a very short paragraph on commons:COM:CB#Maps, so short that I can quote it entirely here :

Maps are always copyright works unless they are old enough to be in the public domain. You may not upload copies of copyright maps to Commons, nor may you trace or even re-draw such a map yourself. Any map you create yourself must be wholly based on public domain sources or on sources that have been released under a suitable free license.

If this paragraph is wrong, please say so. If the truth is that maps are almost never legally protected and that one should not worry about the legal status of any map, please say so. Please say so, so that I can undo commons:Commons:Deletion_requests/File:Ph_map_manila.svg and commons:Commons:Deletion requests/File:Delhi area locator map.svg.

Else, this paragraph should be expanded into a detailed FAQ like Commons:Fan art. It would be best if each statement would be made verifiable by providing references to relevant law articles in law journals, or to specific case law.

For example, a maps & the law FAQ could address the theory that a map is a faithful depiction of the Earth, that the Earth is not a man-made creative design, and therefore cannot be copyrighted.

For example, a maps & the law FAQ could address the theory that maps are arrays of data, and that data cannot be copyrighted. (A theory succesfully used on commons:Commons:Deletion requests/File:Mumbai area locator map.svg)

For example, a maps & the law FAQ could address the theory that a map showing buildings "is an architectural plan and NOT a map" (commons:Commons:Deletion_requests/File:Eanna4composite.svg)

For example, a maps & the law FAQ could provide explanations on the database rights laws in the EU countries and say how they apply (or don't apply) to maps.

For example, a maps & the law FAQ could say if territorial boundaries within France are free (so free that they can be kept on Wikimedia Commons) or if they are the property of the French government and therefore unfree.

For example, a maps & the law FAQ could address maps self-created by the uploader while he was a government employee. It is great that he wants to share his work, but does he own the copyright ?(commons:Commons:Deletion requests/File:Loktak Lake view 1.jpg ; File:Carteactuelle.jpg)

For example, a maps & the law FAQ could address whether it is OK to transfer to Commons a map from Flickr if the Flickr uploader does not disclose the source of the data (File:Clipperton Map.jpg)

For example, a maps & the law FAQ should help me to make my mind on what to do with File:Plan of the Antonine baths park-en.svg. Does the Tunisian commons:CT:FOP#Tunisia law apply to this case ?

Should we not, on each image description page, tell the reusers why reusing the Wikimedia Commons map, thus reusing the source's data can be done without worrying on the legal status of these data ?

How do we distribute this FAQ ? I think it is not enough to write it down and make it available on Commons. It should be brought to relevant wikiprojects, like en:Wikipedia:WikiProject Indian maps.

Teofilo 10:58, 23 August 2009 (UTC)[reply]

General usability of Commons[edit]

In order to proceed with any above such ideas, general usability improvements are needed for commons.

  • The tools for bulk uploading images are buggy, not user-friendly, and need improvement. Something with the ease of Flickr Uploader is needed, along with an easier way to upload multiple images at once with the web interface.
  • A tagging system like flickr with keywords would be nice, in addition to or in place of the category system.
  • Improvements in conveying the licensing requirements are needed, along with how commons admins communicate with users. Getting nasty template warnings is a turn off, makes people frustrated and quit. The more infrequent users are less likely to understand things, thus to do things wrong and have their stuff deleted.
  • A progress bar for uploading large files is needed, and any tools designed for large uploads (e.g. video) should have the ability to pause or allow partial uploads, and allow users to come back later (e.g. if their internet connection breaks).
  • I believe that Flickr applies some image sharpening filter on image thumbnails, that keep the images looking crisp which downsized. Some of our thumbnails look fuzzy. (e.g. the desert picture and the map in w:Qatar) Even the Wikipedia logo looks a bit fuzzy to me. It might be good to have such filter applied, though it could be made as an option for image uploads (default on, but allow it to be disabled if an uploader chooses).

Aude 00:26, 15 August 2009 (UTC)[reply]


Thumnails are sharpened— though it's just a rather ad-hoc thing... a single USM value is applied to all images regardless of content or in/out sizes. It's much better than it used to be but it's too strong sometimes and too weak others. With simple sharpening there is a trade-off between sharpness and the creation of halo-artifacts. If you're talking about
Something better would probably be desirable. I recently spent a while searching around to see if anyone had done research on this subject, in particular on resizing by projecting the input image into a space based on the human contrast sensitive function then projecting back to the new size… but I could turn up nothing. (Nor could I even find anything that validates my hypothesis that sharpening is needed due to resizing causing an shift in contrast-space rather than just being caused by excessive low-pass filtering in the anti-aliasing part of downsampling, it just seems that this is an area too boring to bother research and everyone is just applying some randomly selected amount of simple sharpening). --Gmaxwell 03:42, 17 August 2009 (UTC)[reply]
Woot. I've found a problem with how imagemagick resampling works that contributes to loss of sharpness.--Gmaxwell 04:13, 17 August 2009 (UTC)[reply]
Hello Aude. Could you provide an example of a Flickr tag which you find "nice" ? In my experience, Flickr tags are seldom more useful than any kind of keyword used anywhere in a file description. Sometimes people tag a series of files with tags which have little connection with the real topic of each picture. For example some people may tag a whole series of pictures with "sea" and "holidays" because they took the series of pictures during a stay at the seaside, but this may include many pictures where the sea is not actually shown. Teofilo 11:17, 18 August 2009 (UTC)[reply]
I suppose tags are analogous to the categories that we use. On Flickr, it's possible to search tags for multiple terms (e.g. beach and hawaii). With MediaWiki, we can do full text searches of description pages, but can't yet do category intersection. As a wiki (unlike Flickr), if someone puts an inappropriate tag or category, other users can change or remove tags. Perhaps we could also incorporate semantic features, for some of the image metadata (e.g. [[source:NASA]], [[license:public domain]], [[subject:Phobos]]). This could improve the ability for users to find images on Commons, that meet particular criteria. Aude 18:39, 21 August 2009 (UTC)[reply]
Do you have an example showing that intersecting two Flickr tags produces better results than simply search these two keywords together in the search box ? (Searching two keywords together in the search box is something you can do on Commons too, can't you?)
On Commons, meaningful/useful category intersections might have been created in the form of a category created for that purpose. This is the case with commons:Category:Beaches of Hawaii. Category intersections are theoretically possible on Commons by using the syntax incategory:"<categoryname1>" AND incategory:"<categoryname2"> in the search box. However this tool has two major problems I mentioned on the French language talk page, which makes this tool quite often useless. But you may use catscan. Here is a catscan for the intersection of "Hawaii" and "1941" : click here (be patient, the toolserver can be slow) (240 results). Compare with searching Hawaii+1941 in the search box (102 results). Teofilo 09:13, 2 September 2009 (UTC)[reply]

Fuzzy thumbnails[edit]

I think there is a fuzzy thumbnails problem with thumbnails created some time ago. But newly created thumbnails are OK. See the examples below. Teofilo 08:51, 2 September 2009 (UTC)[reply]
old thumbnail (standard 120 px high size) 101px wide, which could have been created as early as upload date 2005-04-17
new thumbnail 100 px wide, presumably created today 2009-09-02

Restoration work can sometimes perform miracles. See the difference between original png and restored jpg in the gallery below :

Teofilo 09:15, 2 October 2009 (UTC)[reply]


Batch uploading[edit]

A couple of months we started a central place at Commons about batch uploading. The main focus is the technical part, but this might be a good locating for the "content partnerships manual". It would be good if this central place can be expanded by this initiative. Writing a howto guide is still on top of my list. As you can see i'm interested in the "Content partnerships track". Multichill 13:11, 15 August 2009 (UTC)[reply]

Annotations[edit]

On this page there is already a lot of talk about certain types of annotation, particularly GIS related. When you consider historic material, annotations are as relevant and there is as much demand and need for these types of annotations. These annotations may or may not conform to certain standards. We are interested to improve on what we get and, a GLAM is very much interested in what we do. There is a need for constant feedback about material that we host as well. This needs to be addressed as much as the GIS data. Thanks, GerardM 06:02, 16 August 2009 (UTC)[reply]

I think one key question is how you make sure annotations are reusable elsewhere. Are they easy to print on paper ? Are they easy to copy onto another website or blog ? Are they easy to translate from one language to another ?
  • Annotations being vectors added to a preexisting image, why not allow them to be performed in the popular SVG format ? In addition to the specific standards used by professionals for specific needs ? Or at least ensure that some compatibility exists with SVG ? At least ensure that some tool exists enabling you to convert a rare professional format into more popular and easier to use SVG ?
  • See also Jaretk's comment : I played with SVG based annotation, see File:Warszawa_Powstanie_1944-08-04.svg, which is not supported by Commons software ( I had a bug report which was classified as WONTFIX).
  • See also fr:Aide:Tutoriel de création d'images complétées and how it is used for example on fr:Bas-Rhin#Géographie. This kind of annotation could be improved by some WYSIWYG feature, but this takes us into the direction of creating our own format of vector graphics independently from SVG.
Does anyone know if the SVG format allows to add hyperlinks on a picture ? And if it doesn't, is it forbidden to imagine a world with a new version of the SVG standard allowing them ?
What is the status of an hyperlink on a picture ? Should it belong to the html or to the SVG ? Is it considered as being a part of the surrounding text or a part of (a new version of) the picture ? Should the status of a toponym on a map change when you start hyperlinking it ? Teofilo 07:15, 23 August 2009 (UTC)[reply]

Video accessibility[edit]

I am hoping that a large part of the effort will go towards figuring out processes and formats for video (and audio) accessibility. It would be about processes, formats and tools that are necessary to enable people to created captions for a video, or international translations in subtitles, or further even audio annotations that will help blind users watch videos. There are further other types of text that relates to video, such as time-aligned meta data, geographical information, talk-page type comments, that would also be relevant to associate with video. With the HTML5 video tag, such things can be solved right in HTML5 and it would be awesome to make some progress there. SilviaP 16 August 2009

Deadline for comments ?[edit]

Do you have any idea of a deadline for this call for comments ? Teofilo 11:19, 18 August 2009 (UTC)[reply]

We're still in the planning phase, so comments are still welcome. There's no real deadline, as subjects can come up all the way to the time of the meeting. notafish }<';> 15:29, 3 September 2009 (UTC)[reply]

Project team[edit]

Has an announcement already been made concerning who the members of this team are ? Or is the selection of the members of the team supposed to start only after the October meeting ? Teofilo 12:07, 18 August 2009 (UTC)[reply]

Depending on who the members are, it is perhaps not necessary to insist on some topics which these members are already well aware of. Teofilo 12:18, 18 August 2009 (UTC)[reply]

Should the Multimedia Usability Project have its own wiki ?[edit]

Should the Multimedia Usability Project have its own wiki, in a similar fashion with http://usability.wikimedia.org (which concerns only the Stanton Foundation sponsored "Wikipedia usability project", not the Ford Foundation sponsored "Multimedia usability project", as I understand), or should the project pages and discussions concerning this project be located on Commons: ? Teofilo 12:14, 18 August 2009 (UTC)[reply]

I'd like to see all usability discussions take place in the same space. There is more than a little overlap -- from identifying what it means for a page to be 'heavy' to improving workflow for simple/common tasks to organizing usability reviews. I don't particularly like the idea of having separate wikis for 'usability' and 'strategy' and other meta-topics.
Regardless of where the bulk of work happens, a project overview page would be helpful on commons (specifically as it affects related commons style guides and Project: pages) and on meta (specifically as it affects all projects and the sharing of materials and creation across them). -- sj · translate · + 13:12, 4 September 2009 (UTC)[reply]

Make a review of all software improvements already expressed by Commons users[edit]

The most likely places where you will find them are :

Teofilo 05:46, 19 August 2009 (UTC)[reply]

Turn the most useful javascripts into full fledged mediawiki extensions[edit]

Personally, my wishes would be for :

  • the "nominate for deletion" link javascript
  • quickdelete gadget
  • hotcats gadget
  • cat-a-lot gadget

These gagets are cool (and can/should be further improved), but too slow on my computer. I can work 4 times more quickly if these tools are made 4 times quicker. Teofilo 05:58, 19 August 2009 (UTC)[reply]

One-click file rename tool - One-click category rename tool[edit]

These are well known issues. Teofilo 08:17, 19 August 2009 (UTC)[reply]

As a transitory measure to be used until the ultimate file rename cool tool is implemented, create a javascript helping people to add commons:template:rename media on file pages, in a similar fashion with the "nominate for deletion" link or the "quick delete" gadget. But a tab on the top of the page would be better than a link in the toolbox (because this is where people expect a "move page" tab to be located). Teofilo 13:05, 21 August 2009 (UTC)[reply]

Finishing the started projects[edit]

There are many projects and features that are being developed but not yet implemented. Maybe finishing those first would be the priority?:

  1. Moving images, implemented on test wiki but not yet on all the Wikis
  2. New Uploading branch, allowing chunk uploads and transcoding
  3. Add media wizard which makes adding media files to article much easier
  4. URL upload tool, importing images and videos through urls
  5. Open maps implementation

I guess after these are implemented new features could be considered. --Diaa abdelmoneim 10:39, 19 August 2009 (UTC)[reply]

This is a good point, and applies to many brainstorming projects: organize time/energy towards a clear priority list of work to proceed in parallel with any future planning or discussion. A 'multimedia' priority list that is updated with where we are in the course of realizing major projects/features would be valuable. 186.8.55.224 12:48, 4 September 2009 (UTC)[reply]

Relevant strategy: proposals[edit]

One part of strategy:Call for proposals#Improving usability concerns Commons :

and perhaps more to come.

Teofilo 21:02, 19 August 2009 (UTC)[reply]

Proposal for files PD in one country but copyrighted in another[edit]

Go to fr:Sergueï Rachmaninov, and scroll the page down. Can you see the "Wikimedia Commons propose des documents multimédia libres sur Sergueï Rachmaninov" template ? That means Wikimedia Commons proposes free media files on S. Rachmaninov, and indeed you can find music from him in commons:Category:Sergei_Rachmaninoff. But he died in 1943 and his works are still copyrighted in France (though some of them are already PD in the United States). So, for most French users, the Wikipédia statement is wrong and misleading. I copy paste here commons:Commons talk:Licensing/Archive 15#Proposal for images PD in one country but copyrighted in another :

Why not implement a "select your country" menu as they do on http://www.superstock.com/ ?

Teofilo 22:03, 19 August 2009 (UTC)[reply]

Wikipédia French edition is not a site registered in France, and it obeys to US laws (and the international treaties signed by the US and implemented in US laws), but not directly the French laws (unless they are recognized as applicable under international treaties under WIPO agreement). The content cannot be deleted just because it is legal in US but not in France
So effectively, Wikimedia servers (that are hosted and located in the US), should then have to identify the country of origin of users to discriminate the viositors, in order to see if they can or cannot look at some contents... this would be extremely tricky, because this would mean that Commons' contents should have to be annotated with the list of all countries where a specific content is not legal, in order to filter it from viewing/downloading by residents in those countries where such content is illegal ; this is not the current policy, because foreign laws that are not enforceable in US actually don't need to be filtered : it's up to users in each country to know if the content is legal or not for him, but currently we don't help them to make the proper decision, so users are directly exposed to risks that they cannot correctly identify).
For me, the best that can be done, without creating completely blocking filters (which could erroneously identify some contents as illegal) is to implement a system that helps informing users when some content is questionable for the place where they live. If the information given is wrong (for example if the current country of location of the visitor is incorrectly identified) users should still be able to tweak this filter to:
  • correct their current country of residence (this cannot be assumed from the linguistic edition of the Wikimedia project, and not even from the country of first registration of the user, as users may be roaming and could access to Wikimedia sites from another country where it becomes illegal for them to view/download/use these contents).
  • state that they assume that the content is legal for them (so they assume the risk of viewing/downloading/uploading that content).
But I don't think that Wikimedia should completely filter these contents. All that must be asked for, when accepting or rejecting contents on Commons is to ask « is this content legally distributable from the US to US (and possibly some other countries) ». Is so, the content is legal and can be hosted there (even if it's illegal in some other countries).
The rationale should be exactly like with « free » software licences (that MUST NOT include blocking discriminations for users in specific countries, otherwise it is NOT free). verdy_p 10:39, 26 October 2009 (UTC)[reply]

Additionally, a "select your country" menu would enable to use the Creative Commons licenses the way Lawrence Lessig wanted them to be used, with the legal code fitting the law of the user's country. (I never fully understood what Lawrence Lessig had in mind for the situation when the licensor and the licensee live in two different countries, though) Teofilo 18:52, 26 August 2009 (UTC)[reply]

Anyway, the way Creative Commons licenses are used nowadays on Commons is a misunderstanding of what Lawrence Lessig meant by localization. commons:Template:Cc-by-sa-2.0/fr says the France version is a translation into French. Strictly speaking, it is not a translation. It is an adaptation to the specificities of French law. There are other Creative Commons licenses for other French speaking countries : Belgium, Canada... It's a pity there is no commons:Template:Cc-by-sa-2.0/uk : I'd be glad to know if it is an adaptation to the laws of England and Wales, in English, or a translation into the ukrainian language of the US version. Teofilo 19:13, 26 August 2009 (UTC)[reply]

Note that « uk » is defintely not a country code : the standard country code is « gb » for Great Britain (including England, Wales and Scotland) and Northern Ireland (even if there was a legacy provision left in ISO 3166-1 for use in domain names, this provision is not extensible to other domains, where the « uk » country code is indefinitely reserved and illegal, so it cannot extend to the designation of languages as a language code subtag, and not even as a region subtag in BCP 47 where the standard ISO 3166-1 "GB" code MUST also be used, possibly followed by a ISO 3166-2 subcode for specific nations and regions/counties in UK).
« uk » is the standard ISO 639-1 code for Ukrainian, and also standard in BCP 47 as the main language subtag (the first one) within any language tags (so the English language spoken in Britain is coded "en-GB", and the Ukrainian language spoken in Ukrainia is coded "uk-UA", because the Country code for Ukraine is "UA" and definitely not "UK"). It's true that you can omit the "-UA" suffix for Ukrainian, because it is implicitly the default (it is not official in any other country), but you cannot do that for English, because English as no default : it may be equally British English, or American English, or some other International version of English, like "en-IN" for India, "en-ZA" for South Africa : the code "en" may be any one of them and less precise, but is not equivalent to "en-US", even if some people are assuming it or if some projects (initiated in US) have privately chosen to make "en" an alias for "en-US", requiring localization for other countries using separate region subtags, but a total absence of any specialized data for "en-US" as all the data is already contained in the "en" resource ; there are also many projects initiated in Britain that have used the same rationale for making "en" an alias of "en-GB" (without any specialization), and requiring specialization data for "en-US". Both schemes are possible, and compatible with BCP 47. verdy_p 10:39, 26 October 2009 (UTC)[reply]

Audio Annotation of recording set[edit]

For a digital preservation project, we are using a lot of audio recording (to records old people in each village). The tool current lacking in commons wikimedia.org is an annotation like the one use by soundcloud, we are able to make transcription via the web interface and make it in a collaborative way. Just like having the waveform in front with annotation for each parts of the sound that would be the transcription.

AlexandreDulaunoy 21:10, 20 August 2009 (UTC)[reply]

Scheduling[edit]

I would be interested in attending, if the meeting is held. I can talk about how maps fit in with Wikimedia Commons, and automatically generating maps (images) from OpenStreetMap data. I am also interested in general issues pertaining to the image upload workflow, etc.

In order to attend, I prefer the meeting not be held the week of October 19th, as I have other commitments that week. If it was sometime the week before or after, that would be okay or any other time. Aude 01:13, 21 August 2009 (UTC)[reply]

It would be good to find improvements for commons:Commons:Village_pump/Archive/2009Jun#Crediting authors of OpenStreetMap maps. Teofilo 05:41, 21 August 2009 (UTC)[reply]
I submitted this as a bug [1], so it's on our to-do list. Though more discussion may be needed to decide on the best way of implementing it, or what we want to do. Aude 19:05, 21 August 2009 (UTC)[reply]

Uploading[edit]

The Add Media Wizard being developed by Michael Dale:

So far, the Add Media Wizard is useful for finding images on Commons and adding them to a Wikipedia page. The interface has a space for integrating an upload wizard (yet to be developed). Looking at the grant proposal, integrating and simplifying the upload process with Wikipedia is a chief deliverable of the grant. The Add Media Wizard could be a good way to integrate and simplify things more, though more may be needed than that to improve usability.

Also, here are some bugs pertaining to image uploading, that may be relevant:

Aude 01:29, 21 August 2009 (UTC)[reply]

Define a page weight specification and ensure that all pages are lighter than the specified limit[edit]

The first task is to define page weight. Google search provides a number of definitions.

In my opinion page weight, is something like :

N/D + C/S

N : number of kilobytes of all files (html, css, js, jpg, etc...) used on that page
D : download speed
C : number of computation steps requested to the user's computer's processor (this will increase if the javascript actually run on that page is trying to do a lot of things, if the browser is asked to render some SVGs, to resize gifs, etc...)
S : the user's computer speed

Examples of heavy pages on Commons :

Examples of heavy pages on Flickr (so it would be best not to imitate Flickr here)

  • Any image description page including many "pools" or "user albums" (example) : so it would be very disappointing if the result of the "usability" project was to turn the featherweight Commons description pages as we know them now (as we knew them until that "add a note" javascript was added a few days ago) into some Flickr-like heavyweight pages.

Teofilo 14:17, 21 August 2009 (UTC)[reply]

I really like this idea. With the caveat that S could be a user preference -- you may want to see the site as though you had a fast computer / you may like heavy pages... even if that means that your experience is a bit slower. -- sj · translate · + 13:09, 4 September 2009 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Multimedia_Usability_Project_Meeting_France/Request_for_comments&oldid=3681157"