Talk: “Visual identity and Visual Consistency of the Wikipedias” by Guillaume Paumier. Link to talk’s page.

Wikimedia names and brands.

Proposals:

• One colour per project (e.g. wikibooks one colour for all languages that wikibooks supports)
• Official name and localised motto and transcription.

Choosing good logos:

• Good message
• Good graphic quality
• Fitting in the visual identity of the organisation. Pertaining to each other, yet unique.

Stats on other wikis:

• Around 85% of wikis are like the Wikipedia’s visual identity.
• In 74% of installations only the logo is different.
• The default is MediaWiki skin is Monobook, so most MediaWiki wikis look like Wikimedia sites, because it’s the default.

Want a different visual identity for Wikimedia wikis. Want to change the default layout.
Showed some proposed mock-ups for skins, as a starting point for discussions.

Designing a new skin is a challenge. The skin currently is rather overloaded / cluttered – has many links, disclaimers, interwiki links. Want to simplify the UI. Only 4.6% of visitors are editors, and most of the links are relevant to editors. Want perhaps to have a way of switching between viewing and editing mode.

Question of usability. Site needs to work well for everyone. Clean and simple UI, with easy discoverability.

• Nav bar between the projects.
• More visible links
• Thematic consistency
• Pull down JavaScript menu for actions.

Q & A afterwards:
Q: Why no pull-down menus currently?
A: Client compatibility issues, what happens if JavaScript is not enabled.

Idea of maybe having a small Wikimedia logo on the Nav Bar, to establish that these sites under the Wikimedia umbrella.

Q: How to proceed?
A: Some usability testing by a uni / college could be useful.

Add an experimental non-default test skin. Would be okay to add this to MediaWiki core.

“Wikia” talk, intro by Angela, some from Gil, majority from Jimmy Wales.

• Wikipedia = non-profit reference material.
• Wikia = Approaching very different material (e.g. gaming wikis; Wikis on really complicated & convoluted shows like “Lost”; POV / personal perspectives). For-profit.

I.e. A magazine focussed wiki instead of neutral reference-focussed wiki.

• Licensing terms
• Content censorship
• Let the communities decide

Why would you use Wikia?

• No installation or maintenance
• Stable and reliable hosting
• Large communities so you are not alone.
• Single-sign-on.
• New features. (Details?)

Gil – background is eBay.

• ArmchairGM.
• User pages – have pictures.
• German Wikipedia has concept of “people I trust, and people I don’t”.
• Can add friends, can track activity of friends and foes.
• Can see the Geo-Location of other users.

People contribute for 2 reasons:

• Social activity, make friends, etc.
• Care passionately about the topic at hand.

Showed the Wikia WYSIWYG editor (Personal comment: I think the momentum on this has been lost because of the delay in releasing the source code externally; rather the momentum now seems to be behind FCKEditor).

Open or closed? Future of search:

• Free access – search engine project – announced Dec 2006.
• A lot of confusion about this.
• How things are rated and ranked is proprietary. Considers Google to be a problem, since search has to be trusted. Building the stack (AKA the LAMP stack), and break out the similar requirements for search.

Open source search:

• Public algorithms for ranking (i.e. the maths that lead to those results)
• Make a crawl of the web publicly available.
• http://search.wikia.com/
• Bought “grub”, a web crawler.

Search advertising is a proprietary biz model. There will be ads. Wants mechanisms to prevent Google-bombing. (Why? Large-scale distributed google-bombing is kind of rare, although SEO techniques for messing with keywords are painfully common…)

Opposed to Google’s yielding to the Great firewall of China to censor content.

“Challenges in a growing wiki : The wikiHow case study” by Jack Herrick (Wikihow founder). Link to talk’s page.

Things people do on the Internet, top 3, in decreasing order:

• Research buying things
• Read the news
• Find out how to do things

Get good feedback from people using their site (showed some feedback messages).

Wikihow started Jan 15 2005 (Wikipedia was Jan 15 2001). By the end of May had:

• 700 articles
• 13 active editors

Travis is the engineer.

First article – “how to ride the elevator”. :-)

Jan 2006:

• 9000 articles
• 162 active editors.
• Quality standards rising.

Jan 2007:

• 15000 articles
• 250 active editors
• Existing admins redefine who should become an admin

June 2007:

• 20000 articles
• 522 active editors
• 40 admins

Things want to improve in wikihow

• more languages
• more articles. Don’t have red links so much.

Doing okay on:

• traffic
• Equality on gender participation
• Hand patrol every edit.

Wikihow works towards making editing wiki editing easier. Have tried to solve the licensing of uploaded images. Built a tool/extension that links into flickr. Shows the acceptably licensed images based on a search term, and with a click will upload these to Wikihow, and add all the right licensing information. Have written the extension for this. Would like to see this extension or something like it enabled on Wikimedia Commons. (Q: Is this extension in SVN? Update: thanks to Tgr – Yes, it’s the ImportFreeImages extension ).
Also use templates for entering information.

For-profit wikis: Good or evil?

• Have advertising, which is the biz model & how they pay for everything.
• Registered users = No ads
• Anon users = Get ads, but they are minimal
• This blended approach seems to work okay.

This is how Silicon Valley views user-generated content: Showed Evan P’s crowd sourcing slide.

Showed the wikihow biz philosophy:

• A community service 1st, and a biz second.
• Let go.
• Go slow.
• Build community.
• Share it.

Other things:

• Will try hiring someone for the German wikihow site, because it’s not growing organically. This is a seeding process.
• Trying to create a for-profit company focussed on a public good.
• If their biz model works, then it will be a good example for other wikis.
• Wikihow is forkable. Right to fork both the source code ad the content of the wiki. Thinks this changes behaviour in a very positive way.
• Have modified MediaWiki quite heavily. Source code available.
• Have not faced any lawsuits yet, Lawyers have told them there are no problems until get much bigger. (e.g.: 10 times larger).
• Q: do you feel any pressure to share profits? A: There are sites that pay people to create content currently. However does not think that paying volunteers will wreck the whole concept of wiki content creation. Totally different dynamic between work (I’m working on this to get my points to make a buck), versus “I am creating this for fun and for good”.
• Interwiki linking is there, but it hardly every gets used.
• Want to get a WSYIWIG editor happening. Thinks the Wikipedia is too hard to edit. E.g. only 10% of folks can figure out wiki syntax. But 100% of the people should be able to contribute. E.g. The WYSIWYG stuff from Wikia or FCKeditor. Will try both of these and see how they work.
• Suggested license for starting a wiki: CC-BY-SA. Used a difference Creative Commons license and has sometimes slightly regretted this (used the non-commercial CC license?).

Talk: “Virtual and national cultures: Wikimedia, projects and organisation” by Delphine Ménard.

[If you’re watching the video of this, then skip forward a few minutes until the slides start working, because there was an A/V glitch at the start with getting the slides to display]

One of the funniest edit wars on the French Wikipedia was over “endive” (a plant) – because of “chicon” versus “endive” (two different names for the same thing – Endive in France and Chicon in Belgium). However the page now says “chicon” and “endive” all the way through.

Yoghurt versus yogurt – which spelling do we use?? On the English Wikipedia, seems to be a first come first serve approach – whoever writes the page first gets to determine what the page’s spelling is.

How much do real life cultures impact the Wikipedia?

The Spanish wikipedia is one of the few wikipedias that calls admins something else – namely “bibliotecarios” – which means “librarians”. Which kind of makes sense – like librarians, they keep the place clean, stop bad behaviour in the library, and make it welcoming to people, and help people when they need help.

The German Wikipedia banned “Fair Use” outright pretty early on (not recognised in the German legal system). English allows it. French is somewhere in-between these two perspectives.

[[Henry the Navigator]] – same article, on 3 different wikipedias. German: just the facts; Portugal: has facts, plus says he was good; The English one has a dispute about whether he was a homosexual or not!!

Village pump: In French this is called “Le Bistro” – the café – more informal.

Request for Admins – on the French, you CAN self-nominate. On the English one, it’s far less common to self-nominate.

How culture affects local Wikimedia organisations: Today we have 10 official chapters, in 3 continents. In the US: Do we have a US chapter, or a state-based chapters? Versus Argentina, that wants to have a country-wide organisation.

Q&A: Heard from Indonesian wikipedia: European conflicts that spill onto the Indonesian articles. E.g. conflicts over Geographical name of something (which comes first). Have to try to work together to find a solution that is acceptable to both sides.

Link to talk’s page.

Talk: “Enhancing wikis with social networking tools” by Evan Prodromou (surname pronunciation guide: “Pro-Dro-Mo”, the “u” is silent)

WikiTravel founder

Keiki co-founder

Q: What makes wikis great? A: Cumulative effect – everyone can edit. Easy and adaptive. Progressively improvement. Get something close to consensus opinions.

…. but wikis can’t do everything! Don’t over apply wikis. Example the wikiclock – lets users update the current time, manually. Surprisingly accurate (only a few mins behind)

Wikis are not good for:

• Automatable jobs

• Personal opinion

• “Protected” content & structured content

2 Types of wiki Communities:

• community of practice (lets get something done)

• community of interest (shared areas of interest)

Numbers:

• 65% of WikiTravel users are engaged for 1 day or less (1 edit – never see again)

• 95% for less than 1 month

• This accounts for 70% of edits – so get lots of content from anon people.

Want to retain users, keep users engaged.

Features that work well with wikis:

• Social networking

• Blogs

• Photo sharing

• Forums

• Social bookmarking

I.e. the whole web 2.0 playbook.

This works well, and complements wikis well.

Tagging / concepts / categories. Gives a way to associate wiki content with non-wiki content. Unity of content (wiki) versus a multitude of chaotic content (social side)

Don’t repeat yourself: People don’t want a new blog, or a new Flickr site. Want tagging. Done via RSS, FOAF, web APIs.

Can do various ways of gluing stuff together (Likes Drupal for example).

Case study #1: WikiTravel Extra.

• Travel is very personal

• Opinions

• reviews! Want to capture these.

• travel photos

Technology:

• Drupal

• Shared login via OpenID authentication system (was already using at WikiTravel)

• Lots and lots of plugins

• Custom software and glue code to bring it all together

Showed WikiTravel Extra:

• same logo & look and feel as WikiTravel

• lots of different content and blog posts.

• Have geographic forums

• Have photo sharing

Results: Have had good feedback from Extra.

Case study #2: Kei.ki (the name is Hawaiian for “child”).

Decided to create a free content parenting guide, open to everyone, edited by everyone.

Even more that travellers, parents like to share their experiences.

There are privacy concerns (e.g. sharing kids photos)

Have no existing wiki community. Need to focus more on content production, less on the wiki community.

Results gave a Kei.ki demo. Just opened today! Launching in French and English.

URL: http://kei.ki/

Q: Will Kei.ki be made into a paper book?

A: Hopefully, yes.

Link to talk’s page.

Talk: “MediaWiki API” by Yuri Astrakhan

Summary: “It’s all about the data, stupid!”

Yurikbot: More than 3 million edits.

The API adds a new layer of access. Allows new clients to access data (e.g. JavaScript browser extensions, Standalone apps like vandal fighter, data gathering for researchers).

Does not use the HTML rendering code.

Example of this; The navigation pop ups extension – this uses the API (because it is faster).

Current situation:

• We have login

• Can query existing data

• Multiple output formats.

Coming:

• Change data (this is currently in development by the Spanish Vodafone folks, among others)

API is very modular – can add things, and they will just plug in.

Can get some of the following:

• Page information

• Lists (e.g. list of backlinks to a page)

• Metadata (servers)

• Can get multiple types of information all in one query

• Conveniences to avoid gotchas – e.g. normalisation, resolving redirects, etc.

(gave some demos of these on the live Wikipedia).

Tries to be very quick – only does the work that you ask it for.

Gave API performance figures: API gets 2% of Wikimedia site hits. Yet uses 0.1% of CPU load. I.e. API is 20 times more efficient than the main UI. However at the moment is a read-only API, so would expected better performance that the main UI (which also has to do writes).

Most of the hits are coming from the Open Search module currently.

Future: Want to add unit tests for the API (Note from me: it’s coming, but don’t hold your breath!).

Asked API users to use GZIP compression when calling it – added recently to PyWiki – this saves lots of bandwidth.

In the Q&A time, I asked the Vodafone folks about the API write capacity they’re working on, and very roughly when they thought it might be ready: Their estimate: Should be ready around Christmas (i.e. 4.5 months). They want it for their mobile phone customers, who want to be able to modify the Wikipedia, as well as view it on their mobile phones.

Demo time: Showed some examples of some API code (e.g. added a simple module, showed how to add new supported formats to the API).

Link to talk’s page.

Talk: “Special:Contributions/newbies: User study of newly registered user behaviour” by Brianna Laugher. User name : pfctdayelise (pronounced as: “perfect day elise”). Most active on Commons.

Why are we interested in what new users do? New users are really important to community growth. Wikis have to keep growing – they grow or they die.

Interested in the English Wikipedia as it is the trailblazer, and it’s the first point of contact for many people with wikis (so still want a good impression for wikis in general).

Why do new users sign up? Do they think it’s a social site? Do they want to add articles about their employers?

What were other people’s experiences? How did other people interact with you when you first join? When did you first feel that you were part of the wiki community?

The attendees of Wikimania are the success stories.

Did a study of 1 day’s worth of new users. Picked a random day, and just observed all users on EN who registered on that day. What happened to those new users?

Disclaimers:

• Deleted edits are not available through the MediaWiki API (would like this; would also like to be able to get a diff of an edit via the API, which currently is not possible).

The day: Feb 1^st 2007. 10641 users signed up. This is a fairly typical number.

Showed some of the usernames:

Some were crazy, and you could be sure that they were not coming back.

Not every account represents one person. For example, there were a lot of Stephen Colbert usernames!

Total number of edits that they made:

7000 of the users out of 10000 had zero edits (i.e. 70%). They did nothing with their account.

How many edits until you are part of the community? 50? 100? 1000?

Only 5% of user made more than 10 edits.

Images uploaded by these users:

1329 images uploaded. 40% of these images were deleted.

Some very troubling cases:

• 58 images uploaded. Of these 57 were deleted. Seems soul destroying for these people – it’s a lot of effort to upload images. Suspects that the majority of these issues are copyright problems.

Wikipedia = social networking site? To test this looked at talk page. 14% of the sample users had a talk page. Had a look at the edit summaries to the talk pages of these users:

• 14% of the people got a page deletion notice (e.g. you added something not notable).

• 36% got a vandalism warning.

• 19% got an image deletion message.

• 20% got a welcome message.

• Some people left a talk message to themselves.

Some people seemed to use Wikipedia as a help lifeline. Kind of disturbing messages about people asking for help with bad domestic situations.

Community dynamics:

• “All the low-hanging fruit has been picked” – Andrew Lih

• Backlogs

Discussion of user warnings that we show to people:

“Don’t bite the newbies”. We have template warnings. They are pre-recorded messages. They are officious. It’s not people talking to other people. Templates use the royal “we”.

{{uw-test-2}} –> {{uw-test-3}} –> {{uw-test-4}} –> blocking

Not good system for socialisation and introducing people to Wikipedia and what we are about.

Are new users potential Wikipedians, or are they just pests mucking stuff up?

[[Wikipedia: WikiProject user warnings]]. It would be nicer to have [[Wikipedia: WikiProject user socialization]] – instead of scalding people, would be good to socialise them.

What are the goals of Wikipedia?

New users DO muck stuff up. How do we reward good behaviour and encourage people?

There is no page that identities new content adding users (not just spelling or formatting changes), especially by new users, so they can be encouraged and rewarded. Should we add this?

Everyone has something valuable thing to share. The hard thing is find what that is, and get them to share that stuff.

There is a wiki ethos.

“Laugher’s Law”: If you are going to act as is X is not allowed (existing social restriction), you may as well stop letting people do X (introduce a technical restriction).

Recommendations:

• Change the community attitude.

• Recognise and reward and promote GOOD behaviour, rather than punishing BAD behaviour.

We treat too much stuff as vandalism. Sometimes people are just confused, or don’t know what to do. Not all people are vandals that we currently call vandalism. E.g. blanking a page can be someone who really knows their stuff (but doesn’t know wikis), and knows that the page as presented is just wrong – so they blank it out.

People being templated to death is due to admins being overloaded. It’s why they were created.

Link to talk’s page.

Wikimania 2007 talk notes: “Embeddable Wiki Engine; Proof of Concept” – by Ping Yeh, Google Taiwan R&D Centre.

Want to make a Wikipedia off-line client.

Problem: Currently one and only one software is guaranteed to correctly view the database dumps – i.e. MediaWiki.

Wants a reusable MediaWiki parser. This would:

• Ensure the correctness of the Parser

• Reduce manpower required

Showed a diagram of the typical software architecture of a wiki system.

MediaWiki is very tied to a SQL engine. But for embeddable stuff can only really assume a flat file for data storage.

Project EWE is the code name of the project to test some of these ideas. An attempt to make components and the wiki engine reusable by many programming languages. A preliminary version is ready.

Split the parser into a parser (transforms wiki mark-up into a document tree), and a formatter.

The document tree uses DocNodes – page -> section -> header / paragraph / list. Each bit is separate, so can replace each bit.

MediaWiki parser : Uses GNU flex to specify the syntax. Based on the help pages. No templates support yet. Has a manually crafted parser to parse the tokens into a document tree.

HTMLformatter: trivial conversion from DocTree to HTML tags.

Intending to make this a wiki library that can be called from C++ or PHP.

Things want to add:

• Language bindings for Python.

• Moin-Moin compatibility.

• XML formatter.

• MediaWiki formatter – need to add templates.

• A search engine.

Problems:

• Compatibility with extensions – e.g. the <math> extension changes output for MediaWiki.

• Wikipedia has too many extensions. If re-implement each extension, then it will be a lot of work. It’s essentially a duplication of effort.

Link to talk’s page.

Note: I’ll post some more notes for more talks in a few days time.

Wikimania 2007 talk notes: “Metavid & MetaVidWiki” by Michael Dale

Basic idea: Video + wiki

Metavid:

• GPLv2 license

• Free database dump.

Currently seems focussed on US congress speeches.

Can drag and drop videos in a list of videos to make a play list.

Current Metavid limits:

• Very focussed on US congress (because funded by a foundation who particularly care about this).

• No way to collectively improve the meta data.

• Not browser neutral (prefers Firefox).

• Not very scalable.

Currently rewriting (got a grant / funding) to make MetaVidWiki, using:

• MediaWiki (so an open wiki architecture)

• Semantic MediaWiki (so proper machine-readable relationships between things).

Have 3 namespaces for wiki video:

• Metadata (e.g. who is speaking).

• time information (e.g. when speaker changes or starts a new chapter, etc.).

• editing sequences.

HTML5 will include a <video> tag based on Ogg Theora. Will have compatibility with this, or can fall back to plug-in methods for browsers that do not support HTML5.

Saw an interactive demo – looks pretty cool – has a video playback window, plus a list of coloured timeflow to show the splices between video segments, plus a bit where people can have and edit wikitext about each segment of the video. Can also drag-and-drop the segments to rearrange video.

Looking to go live with MetaVidWiki (with a reduced feature set) within a month or two.

Link to talk’s page.