Help:Books/Feedback/Archives/2009/June

Incorrect paths

This issue should be resolved after the next software update.

The links provided in the PDF output link to e.g. http://en.wikipedia.org/windex.php?title= instead of
http://en.wikipedia.org/wiki/windex.php?title=. --Eleassar ^{my talk} 20:06, 17 June 2009 (UTC)

Book feature re-enabled for registered users

Registered users can now create custom books again. In prior discussions, the main argument for temporarily disabling the feature was that too many test books had been created in the User: and Wikipedia: namespace. Saving books in any form is now restricted to users who are 'autoconfirmed' (see Wikipedia:User access levels). Please provide additional feedback here as we are getting ready to make basic PDF and book collection features available to all users.--Eloquence* 16:12, 21 June 2009 (UTC)

Oh thanks for informing people before the Foundation reverts en.wp decisions. </sarcasm> —TheDJ (talk • contribs) 20:53, 21 June 2009 (UTC)

As a result of this discussion the following things were changed:

• Saving Books: Saving of books is now restricted to autoconfirmed users. If this does not solve the problem with the amount of useless books created, this can be further restricted.
• Usability: The main problem that people tried to create wiki pages with the collection extension should be solved by renaming 'Add wiki page' to 'Add page to book'. We are aware of the fact that there is still room for improvement and are happy about any constructive feedback. We are working with the Wikipedia Usability Initiative to get their input also. --He!ko (talk) 15:33, 22 June 2009 (UTC)

• You know very well the most serious problem is that the book sidebar confuses users, in this near-unanimous discussion (with the exception of Eloquence, Heiko and another user 'per above'), it was decided that the feature would not be re enabled before fixing T20756. Changing 'Add wiki page' to 'Add page to book' will absolutely not affect this, users will believe Wikipedia is a kind of book and will try to add a page. Before we have a create page link, we can't permit this. Please, explain why you choose to ignore this aspect and why you decided to overturn this community decision. Cenarium (talk) 01:40, 23 June 2009 (UTC)

The feature isn't visible to logged out users on en.wp, so its potential to confuse is limited. Its potential to disrupt through saved books is also limited now by the fact that saving is restricted to autoconfirmed users, as per bug 18902 which we fixed on request from en.wp. So we've gotten to a point where the functionality is hopefully minimally disruptive, and yet can be easily tested out and played with by all editors. (And easily removed from the sidebar through user CSS as well.)

WMF wants to ensure that there's a scalable solution for people who want to create custom books, either for their own personal use, as a recruiting tool for new Wikipedia editors, as an educational tool, or for whichever reason. The revenue from this is negligible; this is something that's part of our broad organizational mandate as a charity: to do what we can to increase the reach of our free knowledge projects. And, in fact, virtually all the feedback we've gotten everywhere else has been positive. Some Wikimedia wikis have specifically created bugs to get it enabled, the German Wikipedia community has provided heaps of positive and constructive feedback, etc.

Feedback here, too, has not been entirely negative. See some of the comments from the aforementioned discussion. Much of it has focused on eliminating perceived disruptive aspects of the functionality:

• "It seems reasonable to allow people to make and download PDFs. Leaving cruft in the project namespace or userspace, especially when it's mostly test pages, seems bad"
• "I would prefer if any registered user were able to save a book (collection) temporary on a pseudo-page (in special: namespase). This page could then expire after some time. This would solve the problem of "crappy" books, while allowing users to have saved versions of their collections, so that they could modify them later (before expiration). "
• "Then why the heck is the entire Book feature turned off instead of only the Save function? I just want to create a book and save it to my local drive. If the issue is wiki drive space and abandoned books, etc. this should not have stopped my ability to actually make a book for myself to save as a PDF on my own hard drive. Turn off the Save feature, turn the Book feature back on and then continue the discussion..."
• "Good point, but I think a consensus is emerging. PDF save to hard drive now (how many times have I said this?!) is something everyone agrees on. So let's release this now."

Nor do I see a clear view that this should somehow be hidden and basically be invisible to readers and new users. Indeed, I see one proposed approach to the UI in bugzilla, but I also see other possible alternatives. What I'm proposing is that we spend the next few weeks discussing, in a context where every registered user can easily play with the full functionality of the tool, what the best approach for the UI is. If, after a month or so, there is indeed a consensus that resembles what's been proposed, we'll implement that. But let's have a proper conversation. We're also not going to do a further roll-out to readers on en.wp until we've found that approach.

What I would propose as a UI approach is to consolidate all print-related functions (printable HTML version, create a book, PDF version, etc.) in a single print/export box. The "Create a book" would be a single line which activates the book tool (perhaps a different implementation - it could be a more visible and intuitive box, because it would be toggled off by default). That way, it's still visible and immediately accessible to readers, but it wouldn't take up as much sidebar space as it currently does, and it would be more logically grouped with related functionality.

But that's just my proposal. Let's talk through some UI approaches, and discuss the benefits and drawbacks of each. I would also like to get your feedback on the substance of this functionality. I joined Wikipedia in 2001 as a volunteer, and getting printed books out of articles was one of the first things we discussed at meetups, events, etc. Pages like Wikipedia:WikiReader speak to the history of these early discussions. As I mentioned before, we've received tons of positive feedback from this in other communities, including stories of people who've shared the books they've made and were very happy to be able to demonstrate that Wikipedia is more than just a website. So I'm curious: is the ability to get articles you contributed to into print or PDF something you care about? If so, why? If not, why not?--Eloquence* 02:50, 23 June 2009 (UTC)

This is hardly news, among wmf wikis, the enwiki community has always been reputed as the most difficult to get along with, preoccupied with details and preferring the most complex solutions ;) I personally like being able to save articles as PDFs, although I don't think I'll ever print a Wikipedia article, neither by adapting the PDF version or through a service like Pediapress. A substantial concern is that the book tool would only be used by a very small number of persons, compared to our total readership, so there's no reason to invade the interface at this point, and it has the effect to confuse users. I'll comment further later. Cenarium (talk) 03:29, 23 June 2009 (UTC)

Having the potential to disrupt is a lot different than actually disrupting. I think that books is a really good idea, and I like being able to see articles I've written in PDF. If it's only visible and able to be used by autoconfirmed users, is there any real scare about disruption? —Ed (Talk • Contribs) 23:36, 24 June 2009 (UTC)

We have already experimented mass disruption, see the discussion that concluded quasi-unanimously to terminate the function pending modification of the interface, we had thousands of fake books created, some containing very bad content. Now it's restricted to autoconfirmed users, so it's not that much 'disruption' that we can fear, but the confusion of users, and the poor usability. When seeing "create a book" and below "add page to book", inexperienced users will think it's a funny way to say 'create a new article', or will be utterly confused by this. That has already been reported by the usability study, and was abundantly evidenced by new users trying to create articles at the place they had saved their books. If we did a survey among readers with no inside knowledge of Wikipedia, I'm sure almost none would understand the true meaning of this. Users rarely click on, even less read, the help page, so the best way to make this tool usable is to have in the sidebar a link named something like 'Article collection' or 'Collect articles' (book in this sense is far from intuitive) to Special:Books, where will be provided a basic explanation of the feature, and a way to enable it in one click, in the form we know. So we would have a button "Enable the book feature" when it's disabled (default), and "Disable the book feature" when it's enabled at Special:Books, so that users can enable and disable it at wish. So, to summarize: if disabled (default): a link in the toolbox "Article collection", if enabled: the interface as we know it. This way, by explaining first, the inexperienced user will know what he/she is doing and be able to successfully use the feature. Cenarium (talk) 01:11, 25 June 2009 (UTC)

Consensus disables this so consensus should reenable this, and I don't see any consensus among the Wikipedia community to do so. There are still many problems brought up in the previous discussion that haven't been fixed by restricting this to autoconfirmed users. The feature, if it should even exist, would need an overhaul including a strict set of policies informing users what can and cannot be in their books. Being a corporate partnership with the foundation doesn't exempt this feature from Wikipedia's duty to provide its users with encyclopedic content, and not POV opinion pieces strung together with original research, which could result from an abuse of this feature. I won't even get into my issues with the sale of the content for corporate gain. ThemFromSpace 21:42, 26 June 2009 (UTC)

I am personally think that 'Books' feature is a very interesting idea. One can see it even as a new way to organize Wikipedia articles by topics, additionally to categories. In difference to categories, books allow to create a group of articles for reading in the provided order. Export to PDF is an excelent way to print them out or read off-line on laptop when travelling. As an example, please see a few book I was able to create easily with the help of book feature: Wikipedia:Books/Data structures, Wikipedia:Books/Software testing, Wikipedia:Books/Chess variants, Wikipedia:Books/Compiler construction. So, it is great that the feature is reenabled back! Andreas Kaufmann (talk)

How is this relevant to this discussion ? We already have lists besides categories to organize content, that would be redundant. We need to focus on the mainspace and improve what is there, not to waste time and resources on maintaining pages that are not part of the encyclopedia. Cenarium (talk) 19:53, 28 June 2009 (UTC)

The relevant system messages are detailed here. If you want to change the (say) "add page to book" message, edit MediaWiki:Coll-add_page. This applies to en.wp only. It should probably be changed in the i18n files for all wikis - to do that you have to go to BetaWiki (I think). MER-C 08:55, 28 June 2009 (UTC)

I'm thinking on creating a requests for comment on the book extension and its interface. It'll take a few days to prepare, lets not jump the gun. Cenarium (talk) 19:53, 28 June 2009 (UTC)