Over the past three decades, newspapers have undergone several radical changes. Possibly the most significant change is the print-based model's decline and unclear future, as a much greater proportion of users access these stories through the internet.
Yet the internet as we know it is itself undergoing a rapid reconstruction. Over the past several years, the number of personal and laptop computer users has been dropping in favor of those whose online experience is dominated by tablets and smartphones. And in another significant dilution of the power of traditional journalism, the internet has allowed the formerly captive readers of hard-copy newspapers to escape to the wider world of blogs and free news aggregators.
Fortunately (for us), the Signpost has been spared the majority of the problems plaguing the traditional model for news production and consumption, but only because of the unique niche we hold and the medium in which we serve and publish. Still, we also need to keep up with new trends in what has become a very unstable environment. Thanks to the initiative of Yuvi Panda and Notnarayan, the Signpost now has an Android app, free for download on Google Play. A screenshot of the app is available to the right, with more on Wikimedia Commons; more information on the app itself is in this week's Technology report.
We have a question for readers, though: is there sufficient interest from you for Yuvi and Notnarayan to develop a Signpost iOS port, used in Apple devices? Please leave your thoughts on the talk page and vote in this week's poll: Would you be interested in downloading a similar Signpost app onto your iOS device (iPhone, iPad, iPod Touch)?
In unrelated notes: "In the news" has been renamed to "In the media", and the "Arbitration report" will be discontinued as a separate page until we have enough content to warrant more than a few sentences. The report will now appear in "News and notes" under the 'In brief' section each week.
—The ed17, Signpost editor-in-chief
Reader comments
Much like article content, the English Wikipedia's help pages have grown organically over the years. Although this has produced a great deal of useful documentation, with time many of the pages have become poorly maintained or have grown overwhelmingly complicated. There are several issues with the current network of help pages:
For some idea of the scale of the problem, the main help landing page – Help:Contents – now gets around 10,000 hits a day. It's my belief that improving Wikipedia's help system is one of the most important steps we can take to improve editor recruitment and retention. That's why for the past few months I've been working as a Wikimedia community fellow to research how we can improve help pages.
There were already some community attempts to improve the help pages, such as the Help Project, but sadly they had become fairly inactive. Because improving and maintaining the help pages is such a huge ongoing task, there's no way I can do it on my own, and I really don't want the efforts to end with my fellowship. Therefore I've worked to revive the project: the homepage received a major overhaul, and there's now a monthly newsletter for members and a regularly updated statistics page covering all the pages within scope. (If you want to get involved, or just keep up with the latest developments, do sign up!)
The next major step was a large survey, taking in both new and experienced users, to find out what they are looking for help on, how they find it, and what they think of the existing pages. The full results and conclusions are available. Unsurprisingly, "how to use wiki markup" and "how to start a new page" are the most popular topics among new users. What is surprising is that people rate the help on these topics as ok. It's still not great and could certainly use improvement, but it's better than the others. The help topics people really didn't like are how to add references and how to add images. This is fairly consistent across all experience ranges, from newly registered users with no edits to old hands with thousands of edits.
Recently we've also been able to deploy the article feedback tool to help pages. This should allow us to get extremely valuable feedback: until this deployment and the survey I conducted, we really had very little evidence on what users thought of them.
One thing the Help Project created in the past were a couple of "Introduction to ..." tutorials: Introduction to policies and guidelines and Introduction to talk pages. These focused tutorials have a friendly tone and don't overwhelm new users with details. They've been very well received by the new users who find them, so I decided to make the tutorials we do have more prominent, and developed new tutorials in the same vein on topics that the survey suggested would be valuable: Referencing, uploading images, and navigating Wikipedia. These are brand new, so please edit and improve them! But do try to avoid making them too long and detailed, or adding too many links.
Probably the clearest finding in the survey is that experienced editors love the results they get from asking questions on another user's talk page, but new users aren't really aware of that as an option. The same is true to a lesser extent of asking questions at the Help Desk, or in IRC, as clinched by one respondent's comment: "I was helped by people, not help pages." The personal touch certainly seems to ease things along, and that's why it's great that we have new initiatives like the Teahouse, and more friendly warning messages that explicitly invite questions on the warner's talk page. Part of my work to redesign the navigation will try to make these question pages more visible to those who could benefit from them. This is particularly true of the Reference Desk, even though the article feedback tool has only been deployed for a few days we have already seen many factual questions appearing in the feedback for help pages.
Over the next month I'll be focusing on the final part of my project: redesigning Help:Contents, the main entry point into our help system. At the moment this page is a mess, with too many subpages, too many links, and not enough explanation. Many of the links that do exist are misleadingly labelled. This was borne out by usability tests I conducted, where people found it difficult to navigate and find the help they were looking for.
A serious problem with Help:Contents is that it has to speak to many different audiences:
At the moment links relevant to these different groups are all mixed together. The aims of the redesign are to better funnel these different users to where they can get the right kind of help, and to better expose the personal help mentioned previously for those who want it—and, one hopes, to make the page look a bit more attractive too! Again I'll be doing usability tests to try to identify any potential problems with the new design, and to confirm that it's better than the existing one.
If you're interested in improving help pages, please do join the Help Project and the discussions on its talk page. There are also some open tasks you could get started on. It's going to be a long haul, but this work is something that could really make a big difference to the future of Wikipedia.
Reader comments
Philip Roth, a widely known and acclaimed American author, wrote an open letter in the New Yorker addressed to Wikipedia this week, alleging severe inaccuracies in the article on his The Human Stain (2000).
The saga began on Wikipedia in late August, when an IP editor—claiming to be Roth’s official biographer—removed this paragraph from the article:
Salon.com critic Charles Taylor argues that Roth had to have been at least partly inspired by the case of Anatole Broyard, a literary critic who, like the protagonist of The Human Stain, was a man identified as Creole who spent his entire professional life more-or-less as white.[1] Roth states there is no connection, as he did not know Broyard had any black ancestry until an article published months after he had started writing his novel.[2]
The IP was reverted within a minute, with the edit summary "Can you verify that?" Nineteen minutes after the revert, the IP removed the paragraph again, saying "the reference to Anatole Broyard ... is wholly inaccurate and therefore pointless. I am Roth's biographer, and have removed it at his request." The article was edited again six minutes later by Parkwells (talk · contribs), who over the next two hours added a significant amount of content to the article. The entire process was seemingly concluded within three total hours, and the article remained in this state until Roth’s open letter was published on 7 September. The new content relevant to Roth’s complaint read:
Kakutani and other critics were struck by the parallels to the life of Anatole Broyard, a writer and the New York Times literary critic in the 1950s and 1960s who was of Louisiana Creole mixed-race descent and passed for white.[3][4][5]
Roth said that he had not learned about Broyard's ancestry until after starting to write this novel.[6]
In this open letter, which was first brought to the community's attention by a Wikimedia Foundation employee, Roth was highly critical of Wikipedia. Interestingly, the ‘interlocutor’, most likely Roth's biographer, either emailed or was emailed by an English Wikipedia administrator, who said that removing the claim would require "secondary sources", even though they acknowledged that "the author is the greatest authority on their own work." This email is what led Roth to publish in the New Yorker, giving the real inspiration for the novel and its protagonist, Coleman Silk, in great detail: the experience of Melvin Tumin, a long-tenured professor of sociology at Princeton, with a seemingly innocuous question which turned into multiple major accusations of racism.
The question, "Does anyone know these people? Do they exist or are they spooks?", was prompted by the constant absence of two students from his class. Unfortunately for Tumin, 'spooks' happened to be an old derogatory term for African Americans, and both students turned out to be from that race. It was only several months later that Tumin could clear his name, after "several lengthy depositions" and what Roth described as a "witch hunt".
It appears that while Wikipedia was correct both before and after the removals—the article versions noted that the claim was a literary reviewer's opinion, and that Roth had rebutted the claim—the article never stated the genesis of the book, leaving the Wikipedia article with phrases Roth called "not from the world of truthfulness but from the babble of literary gossip".
However, it also appears that the open letter was the first time Roth has identified Tumin's story as the basis for The Human Stain.
I knew Anatole slightly, and I didn't know he was black. Eventually there was a New Yorker article describing Anatole's life written months and months after I had begun my book.
Eleven featured articles were promoted this week:
Ten featured lists were promoted this week:
Seven featured pictures were promoted this week:
After a week's hiatus, the WikiProject Report returns with an interview featuring WikiProject Fungi. Started in March 2006, the project has grown to include over 9,000 pages, including 47 Featured Articles and 176 Good Articles. The project maintains a list of high priority missing articles and stubs that need expansion. We interviewed Casliber and J Milburn.
What motivated you to join WikiProject Fungi? Do you have an academic background in mycology? Do you enjoy eating any varieties of fungi?
The project is home to 46 Featured Articles and 171 Good Articles. Have you worked on any of these articles? Are there any resources you've found that are particularly useful in sourcing fungi articles?
The project has a list of "unwritten articles" that need to be created and stubs needing expansion. What have been the greatest challenges preventing the project from expanding Wikipedia's coverage of fungi? What are some sections or templates a non-expert can easily contribute to existing articles on fungi?
How difficult has it been to acquire images for fungi articles? Are there any species of fungi that are more difficult to locate and photograph than others?
How does Wikipedia's coverage of fungi compare to the coverage of other living things? Are the fungi of any geographic regions better covered than others?
Next week, we'll revel in the spotlight of India's silver screen. Until then, check out the production values of the Report's archived material.
Reader comments
In dramatic events that came to light last week, two English Wikipedia volunteers—Doc James (James Heilman) and Wrh2 (Ryan Holliday)—are being sued in the Los Angeles County Superior Court by Internet Brands ("IB"), the owner of Wikitravel.org. Both Wikipedians have also been volunteer Wikitravel editors (and in Holliday's case, a volunteer Wikitravel administrator). IB's complaints focus on both editors' encouragement of their fellow Wikitravel volunteers to migrate to a proposed non-commercial travel guidance site that would be under the umbrella of the WMF (Signpost story "Tough journey for new travel guide").
Disenchantment within the volunteer Wikitravel community appears to concern an intensification of advertising on the site, IB's technical management, and the company's treatment of the volunteers who have built the CC-licensed content over many years. In today's New York Times article, "Travel site built on wiki ethos now bedevils its owner", veteran journalist Noam Cohen writes that, according to Heilman, "as many as 38 of the 48 most experienced and trusted volunteers at Wikitravel have said they will move to the Wikimedia project". The migration of the remaining Wikitravel volunteers to the foundation would come six years after German-speaking Wikitravel editors walked out of the project soon after Internet Brands acquired it, forking into a new Wikivoyage site, followed soon after by their fellow Italian-speaking editors. The non-profit association that runs Wikivoyage voted three months ago to join the proposed travel-related WMF project.
After months of community-led discussion on Meta, last Thursday the WMF's Deputy General Counsel, Kelly Kay, announced that the board "is moving forward with the creation of this new project", and had filed a lawsuit "seeking a judicial declaration that IB has no lawful right to impede, disrupt or block" the creation of a new WMF travel website.
Kay's statement accuses IB of "disrupting this process by suing the two volunteers to intimidate other community volunteers from exercising their rights to freely discuss the establishment of a new community focused on the creation of a new, not-for-profit travel guide under the Creative Commons licenses." She said the foundation believes it is the real target of IB's legal action, and that its "only recourse is to file a lawsuit to deal head on with Internet Brand’s actions over the past few months in trying to impede the creation of this new travel project."
We will steadfastly and proudly defend our community’s right to free speech, and we will support these volunteer community members in their legal defense. We do not feel it is appropriate for Internet Brands, a large corporation with hundreds of millions of dollars in assets, to seek to intimidate two individuals. — Kelly Kay, WMF Deputy General Counsel
Among other things, IB's 57-paragraph lawsuit:
Defendants are profiting, directly or indirectly, through the use of Internet Brands’ Wikitravel Trademark in a deliberate, willful, intentional and wrongful attempt to trade off of Internet Brands’ goodwill, reputation and financial investment in its Wikitravel trademark. — Paragraph 50, Internet Brands' legal complaint
IB asks the court to restrain the defendants (and potentially the WMF by implication) from making visible use of the Wikitravel trademark; to award damages and costs against Holliday and Heilman; and to award punitive damages against the volunteers (i.e., to deter anyone from engaging in similar conduct). IB has specifically asked the court to consider Ryan Holliday's business as liable to the court's adjudication of his personal liability, and has asked for a jury trial.
The Signpost understands that Heilman has not yet been served with a summons and legal papers, and that after he is served he will have up to 30 days to provide a written response to the court and the plaintiff. The WMF has arranged for both volunteers to be represented by the high-profile international legal firm Cooley LLP, which has expertise in trademark, copyright, user-generated content, intellectual property, and competition law. Cooley LLP—comprising some 300 litigation attorneys—will also represent the foundation in its lawsuit against Internet Brands. IB is represented in both actions by Wendy E Giberti of iGeneral Counsel in Beverly Hills, CA.
Although the right to fork CC-licensed content has been assumed to be legal, it has received little judicial attention in the US. The foundation is asking the Superior Court of California in the County of San Francisco to declare that:
The foundation is asking that costs be awarded against IB.
The German news portal heise.de reports in its story "Right to fork: Wikimedia sues Wikitravel operators" that IB told them the company "has no problem that Wikimedia is launching a new travel site—but we insist that the foundation respect our copyright and trademark rights, and the laws against unfair competition." (the Signpost's translation)
The Signpost has been unable to ascertain the likely timeframe for each action, but understands that the legal processes will probably hold up the launching of the new site for some months.
In its September issue, the peer-reviewed journal First Monday published The readability of Wikipedia, reporting research which shows that the English Wikipedia is struggling to meet Flesch reading ease test criteria, while the Simple English Wikipedia has "lost its focus".
The statistical method developed by Flesch (1948) focuses on two core components of the concept of readability: word length and sentence length. The test is widely used in the US, with areas of application ranging from Pentagon files to life insurance policies. The concept has been adapted for other languages, including a German version by Toni Amstad (1978). The Flesch test uses the following formula to indicate the readability of a given text:[1]
Higher scores indicate material that is easier to read, and lower scores that it is more difficult. While in theory the results can vary widely due to the artificial construction of very complex or simple sentences, in practice natural English typically results in a score between 0 and 100, which can be interpreted as shown in the table.
Score | Notes |
---|---|
90.0–100.0 | Very easy |
80.0–90.0 | Easy |
70.0–80.0 | Fairly easy |
60.0–70.0 | Standard |
50.0–60.0 | Fairly difficult |
30.0–50.0 | Difficult |
0.0–30.0 | Very difficult |
The authors assume that the English Wikipedia should score around 60–70 on average ("standard"), and Simple English, which explicitly aims at audiences with less advanced literacy skills, around 80 ("easy"). An older study, Besten and Dalle (2008), had found on the basis of the same test method that the overall readability of Simple had decreased from around 80 in 2003 to just above 70 in 2006.
The 2012 study examined two 2010 database dumps it sampled from English Wikipedia and Simple. For the study, the scientists filtered out lists, redirects, and disambiguation pages, and removed components such as tables, headings, and images. Thus, the study examined 88% of the English and 85% of Simple Wikipedia's articles in the database dump. In a second step, the methodology excluded short articles with fewer than six sentences (due to their likely wide fluctuation in readability).
The analysis found that English Wikipedia articles scored 51 on average ("fairly difficult") with more than 70% of all articles scoring less than the set goal of 60 ("standard"). Simple scored 62 on average ("standard") with 95% of all entries below the set 80 ("easy") goal. In addition, a set of around 9600 respective articles was comparable between both Wikipedia versions; Simple scored 61 on these, while the related English Wikipedia articles scored 49.
The paper argues that the creation of Simple as a solution for readability issues of the English Wikipedia with some audiences has run into difficulties. The average reading ease of Simple, while still above the English Wikipedia, declined compared to the findings of Besten and Dalle in 2008 (2003: 80, 2006: just above 70) to 62 on average. Based on the outlined methodology, the authors conclude that Simple has "lost its focus … this version now seems suitable for the average reader, instead of aiming at those with limited language abilities."
The English Wikipedia findings indicate that the results of another study in 2010, focusing on the readability of English Wikipedia entries on cancer (Signpost coverage), cannot be fully generalized. The paper in 2010 found that articles in the targeted topic area scored about 30 on average.
However, both studies show that the English Wikipedia potentially excludes major segments of the English-speaking world, including (for example) large parts of the US public. According to a major study on literacy in the US in 2002, 21–23% (extrapolated: more than 40 million people) "demonstrated skills in the lowest level of prose, document, and quantitative proficiencies".
The authors of the study on readability of Wikipedia have set up a demo site where users can calculate the readability of English and Simple English Wikipedia pages based on the automatic measure they deployed in the paper.
“ | In August 2012:
|
” |
—Engineering metrics, Wikimedia blog |
The Wikimedia Foundation's engineering report for August 2012 was published this week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month (as well as brief coverage of progress on Wikimedia Deutschland's Wikidata project, phase 1 of which is edging its way towards its first deployment). Three of the four headline items in the report have already been covered in the Signpost: the site outage caused by a fibre cut in early August, refinements to the active editors metric, and major work on the Wiki Loves Monuments app, launched last week. The report drew attention to the work of the WMF's Internationalization team on the Universal Language Selector (ULS; see previous Signpost coverage), Project Milkshake to create "generic jQuery components for commonly needed internationalisation features" and WebFonts.
Other items covered in the report include work by WMF Performance Engineer Asher Feldman to expand the number of MySQL servers in the Foundation's secondary data centre Ashburn, and by Tim Starling to write a new Redis-based client for session handling. The two developments are linked insofar as both will be needed for the Foundation to meet its target of making the Virginia site Wikimedia's primary data centre within the next quarter, in an attempt to boost performance. Elsewhere, WMF Security Engineer Chris Steipp worked on adding two new major features to the AbuseFilter extension (global rules and global throttling), for improved detection and prevention of cross-wiki spam. It was, however, a slower month for the TimedMediaHandler, Echo, OAuth and ResourceLoader 2.0 projects.
The monthly report is also a good source of tech news that had otherwise slipped under the radar—in this case, that work on Flow (a talk page reform project) will start in January and that a new mirror for Wikimedia data has been found ("network management solutions" firm), who have also agreed to replicate non-essential data such as "page view files, archives, and more, as well as a full copy of our media files". This month saw the creation of the "Micro Design Improvements" team, an ad-hoc group of staffers who will look at "small but useful design" improvements for MediaWiki, including this week a proposed reworking on the edit window.
Among other news, the first Wikipedia Engineering Meetup (held on 15 August in WMF headquarters in San Francisco), first mentioned in last month's report, attracted approximately 100 developers. The series of two-monthly meetings is intended "to showcase Wikimedia's interesting engineering problems and products to the local developer community"; the inaugural meetup "featured talks about Mobile engineering, Analytics and the VisualEditor".
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
Current discussions on the English Wikipedia include: