Wikibooks:Reading room/Proposals/2014/January

Removing revision checks for books that are in draft versions
Sometimes writing books on wikibooks becomes painful, because some books are ckecked about once a year, for example Graph Theory. Caould we remove the revision check for draft books? --vitalij (discuss • contribs) 08:14, 7 January 2014 (UTC)


 * We use flaggedrevs as an anti-vandalism tool. It's valuable to know that as of such-and-such revision, some authorized user certified the page vandalism-free; conversely, if we unsighted pages that are, for example, less than 50% complete, we'd be erasing the record of anti-vandalism work done in the past, so that in order to check that page for vandalism later, someone would have to laboriously repeat all the work we'd thus erased.


 * We have remarked, from time to time, that we'd like the pending-review state of a page to be less obtrusive for users who don't have the review bit. --Pi zero (discuss • contribs) 13:26, 7 January 2014 (UTC)


 * How does a user get the review bit? How active many users with the review bit are there? --vitalij (discuss • contribs) 14:31, 7 January 2014 (UTC)


 * There are users in the reviewer group.


 * Users usually get the review bit by being automatically promoted, when they meet the criteria listed at WB:Reviewers. --Pi zero (discuss • contribs) 14:54, 7 January 2014 (UTC)

"a failure in your mission statement, and a solution"
Hey there. I'm Buttfuck Johnson, OTRS volunteer and I often help out in the Sister projects queue, where email sent to info@undefinedwikibooks.org winds up. An individual wrote to that address with the following message (the email's subject line is the section title above), which I asked and got her permission to post publicly. Although she said she was open to having her contact information also posted, I decided not to do so, as I'm uncomfortable enough as it is with posting OTRS emails publicly. It is, of course, in the OTRS ticket, if someone wants to reach out to her at a later time. The ticket is #2013121110004446.

BEGIN EMAIL

Hi folks,

First let me say I, Buttfuck Johnson, love Wikimedia and the wonderful projects it has given birth to, and accordingly I make regular donations of money. I particularly like Wikipedia and the concept of Wikibooks, being a somewhat obsessive information collector myself.

Your mission statement really moves me: Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.

That's why I'm writing to you today. Quite recently Wikibooks has started to fail to meet that ideal for people who don't have cheap, fast, always-on internet and who don't have printers -- that is, for most people in the world. This wasn't always so.

I don't know who said, some years ago, that web pages should be short, and the shorter the better, conveying a single topic per page. It seems to have somehow become dogma, without any supporting data at all, and has had a dangerous effect upon Wikibooks.

For those of us living with slow, expensive, intermittent internet there is much to be gained by putting as much of a book as possible inside a single page. Some years ago I found the marvellous Wikibook "Blender 3D: Noob to Pro". At the time it comprised very three large pages: "Beginner Tutorials", "Advanced Tutorials", and "Miscellaneous Tutorials". These were easily downloaded so that I could use them to teach myself the use of Blender offline.

Unfortunately, the recent practice of slicing up Wikibooks into tiny pieces has now made this impossible. That same Wikibook now exists in 254 pieces -- some as small as a paragraph. This makes offline use utterly impractical. Even if every page was visited and downloaded (a process that takes many hours - I've done it) the resulting saved pages don't crosslink and with all the footer data in each page (often greater than the body text) the download (and size on disk) is vastly more than just a few larger pages would require.

I'm sure the idea behind making the pages smaller was to reduce the download time for each individual page. I can understand this motive, but it should be remembered that someone visiting Wikibooks is most likely looking for a book, not a page. It is, after all, WikiBOOKs.

The Collections facility has some potential to allow us to have it both ways, but it currently doesn't deliver books in HTML format. It produces only PDF, which is a truly terrible format, suited only for printing, and for those of us without printers (most of the people in the world), quite useless. Additionally, PDF bloats documents far beyond the size of the original pages, loses HTML's ability to reflow to fit window size, requires a special viewer program (in itself bloated beyond reason), doesn't display animgifs, videos, or sounds, and has a nasty habit of crashing on older computers.

A partial solution (I give a better solution further below) would be to allow the Collections facility to assemble large HTML pages. If people wanted to print, then why not print directly from the HTML? It would save your servers all the work of conversion -- a process that doesn't seem to work on large books, currently.

There appears to be the intention of adding EPUB and ODT formats to the Collections downloads, but they don't yet work, producing only PDF documents. I applaud the addition of EPUB as not many will have Calibre (probably the easiest way to create EPUBs from HTML), but ODT seems unnecessary as OpenOffice and LibreOffice can both import HTML, and someone wanting ODT format will almost certainly have one of those two anyway. Sending the Collection as zipped HTML would be much more efficient and save weighing down your servers.

Of course compiling a Collection by visiting 254 pages still sucks in the extreme (it took me about 4 hours to do so recently during a failed attempt at making a Collection for "Blender 3D: Noob to Pro").

There is a way to make these pages available in large gulps that doesn't severely disadvantage people who have slow, expensive, intermittent internet and who don't have printers -- that is, most of the people in the world. I doubt my periodic plea to reverse the slicing up of pages into small pieces can ever be heard, due to the power that dogma has over us all.

My suggestion is to allow us to choose the size of the pages we view, by using the hierarchical layout of contents pages to determine how much will be loaded.

If a contents listing was like this:


 * 3D Concepts
 * 3D Geometry
 * Coordinate Transformations
 * Orthographic Views
 * Perspective Views
 * Coordinate Spaces in Blender

Then choosing "3D Concepts" could load a page containing all those under it. Choosing "Coordinate Transformations" would load everything down to and including "Perspective Views". Choosing "Orthographic Views" would show only that item. This would let the user determine how much data they want in each gulp. We could have our cake and eat it too.

Please don't take this email as destructive criticism. I am a great admirer of you folks and all the Wikimedia projects. More strength to you all. I am deeply grateful to you.

Very best wishes,

- Miriam (in rural Australia)

END EMAIL

I am Buttfuck Johnson, and am not a member of the Wikibooks community, and have no comments on the matter, save that I thought that it was something that should be discussed here, rather than via OTRS emails. Please don't leave any messages about this for me on my Wikibooks talk page. If you need to reach me, use my English Wikipedia talk page, or email me (it is enabled on, at the very least, all of the projects I regularly edit in, including English Wikipedia). Sven Manguard (discuss • contribs) 06:31, 15 December 2013 (UTC)


 * Some books have a "Print version" page, which transcludes all the pages of the book, in order. I always had this in mind as another thing to support in my Navlist package.  (The introduction of the Lua extension has, ironically, made it harder for me to move forward on Navlist, because now, the next time I have time to focus on it again I have to postpone actual improvements to the package, instead devoting time and energy to deciding whether or not the package would be improved by using a different input format.)  --Pi zero (discuss • contribs) 16:44, 25 December 2013 (UTC)


 * The print version of transcluded pages is "broken" for sometime now due to number of transclusion limitations, even if it still works for small books (fewer page transclusions). Note that the ticket poster attacks the issue from two distinct sides, even conflicting sides, the least part of the presentation makes some incorrect assertions since can be solved by software that partially mirrors a site locally. --Panic (discuss • contribs) 03:31, 26 December 2013 (UTC)


 * Mirroring a site locally is my preferred solution for working with large, multipart documents offline, however there are two problems with this.
 * 1. It doesn't seem to be possible to do this for many wikibooks because of their directory structure. My preferred mirroring software is the GNU commandline program wget. Normally I set it to simply grab files from lower subdirectories and not ascend to higher directories, but if the bulk of the book sits at the same level as the rest of wikibooks then attempts to mirror that one book will also try to gather all the other books on Wikibooks -- not a good thing.
 * 2. Very few people even know it is possible to mirror parts of a site, certainly there is nothing to suggest that this option is available to people who have only a superficial knowledge of computers. It is made worse by the fact that Wikibooks understandably uses a few techniques to discourage mirroring (such as no-robots, certificate verification, and user-agent ID).
 * Sadly, I hear scorn in Panic2k4's response. Yes, in theory it seems like it should be easy to mirror that wikibook, but in practice is it not as simple as he thinks. Let him actually try to do it and he'll see what I mean. It is a pity Panic2k4 was not a little more specific about the "conflicting sides" and "incorrect assertions" so that I might have a chance to more clearly explain what it is that he didn't understand. I actually outlined a practical solution that would satisfy both those with cheap, fast, always-on internet and those with much more limited access. It also has the advantage of avoiding or working around the many existing Collections problems. Surely it is worth genuine consideration. This a real problem and does not deserve to be dismissed by impatient hand-waving.
 * --Miriam e (discuss • contribs) 00:21, 12 January 2014 (UTC)


 * It was not my intention to show scorn the problem, I think you felt more my resignation about it all. I think I was clear the problem as stated is rooted in a software/knowledge issue. Software because its a known limitation of the Wikimedia software that many have attempted to mitigate (it isn't even the largest problem we have regarding Wikibooks, were works still suffer from the independent article structure that the software forces on books at several levels). I also am not satisfied by many of Wikimedia software limitations and impositions. In the present case the alternative is to use some external software as you realized.
 * Reading your 1st solution it clearly shows that the limitation is not really a Wikimedia issue but finding the right tool for the job. In the works I create I attempt to provide a deeper structure but this so far is still not consensual, in any case your point so far I recall was never raised as a virtue of deeper structures. This may be a vector you may use to address the problem, talk to the project editors or if abandoned, propose and implement a reformat before extracting the content, even if as I said you may find other solutions that would require less work, especially other software (or even creating your own using a script language).
 * What I sort of criticized was the mixing of "conflicting sides" (or aspects) into a single and unique problem. On one side, one should consider the Wikimedia software unlikely to be changed to cater to the problem (as I said it hasn't even the highest priority in my book) on the other altering the common practice or restructuring of books would be a huge job, take time and will find some resistance (one needs to be aware of past discussions around the subject of book format and presentation to be aware of the complexity) and so as I proposed the best and simpler solution would be to ignore how the work is structured and select a tool that performs the needed task.
 * If you are using Firefox you can for instance get the ScapBook extension and it will perform the job with some work (that you can automate outside of it, like the selection of the necessary pages). It can scrap a page for all the URLs and make a page list and import pages from that list (Wikimedia also generates a list of pages inside a namespace, that can make it easier). --Panic (discuss • contribs) 07:36, 12 January 2014 (UTC)
 * The limitations on page transclusion &mdash; which prevent a few books (I suspect it's only a few) from being bulk-transcluded &mdash; seem to me to be a minor limitation of the software. They're something that can be worked around.  To my mind, an esepcially important principle to keep in mind, as we work around limitations of the software, is that we want everything to be on-wiki.  Bots and other external software undermine the project, by making everything less flexible and more fragile.  Loss of flexibility is because ordinary users on-wiki can't alter the external software, as they are able to change pages on-wiki (that changeability being the point of a wiki), and because the requirements of the external software place invisible constraints on what can be done on-wiki (constraints which, again, the ordinary on-wiki users can do nothing about since they can't change the external software).  Fragility is because when something goes wrong with the external software &mdash; including, when changing conditions on-wiki require a change in the software &mdash; there's nothing that can be done on-wiki to fix it.


 * This is why I'm putting so much effort (on en.wn for now) into developing tools, written in on-wiki javascript/Lua, to allow the building and modifying of interactive wiki pages using wiki markup. The tools are entirely on-wiki, and their use is within reach of ordinary users since it only involves wiki markup.  (I really think this business about how "difficult" wiki markup is, is a red herring.  Wiki markup was successful in the first place because it's so easy to use.  There are things on the sister projects that are difficult, requiring expertise, but the important ones of those are higher-level tasks, like, in our case, how to design a book and how to keep its design on-track as it develops.)  --Pi zero (discuss • contribs) 12:46, 12 January 2014 (UTC)


 * I disagree with assessment that "as we work around limitations of the software, is that we want everything to be on-wiki. Bots and other external software undermine the project". In fact much of the bloat and time lost in Wikimedia fine tunning would be best served in more important aspects at times (prioritization). But I guess that this is a complex issue that even relates to what user contribute monetary donations/or profit from the project (the balance of on site readers and others vs people invested in providing real free content vs peoples that intent to use content off site).
 * Centralization may be good in some aspects but in others it is not necessary, and to me fixing known problems seems more important than adding features.
 * As for navigational aids that is one of the things I have a deep distaste as an editor and a reader. They have no normalization, so each project can dish-out their own, they need maintenance from those that know how they function (that often are the ones adding the content) and they subvert the automation and adoption of solutions that are already present in the Wikimedia's software. Like the use of the slash convention and deep three structure for page navigation. --Panic (discuss • contribs) 18:41, 12 January 2014 (UTC)


 * We may be partly talking past each other. If you're talking about how the wikimedia devs invest their time &mdash; well, I'm not talking about that.  Based on what I've seen in seven-plus years on wikimedia projects, I expect upgrades of the wiki software to be harmful to the non-wikipedian sisters (and whether they're harmful to wikipedia is a difficult question I probably shouldn't get distracted by atm).  They don't invest their energy in stuff for the non-pedia sisters, so the only effect they're likely to have on us is to cause things to break due to incompatibilities.  I agree that the foundation would do better to fix existing problems than add new features, but I'm not holding my breath for us to get solutions from the foundation anyway, so to me that's moot.


 * This, mind you, even though I maintain the wikimedian movement's best chance of long-term survival is through growth of the non-wikipedian sisters. Basically, the needed improvements have to take place despite the foundation's software improvement efforts.


 * From my perspective, as a volunteer trying to help the wikimedian movement get what it needs despite itself, I had a choice between pouring my limited resources inot patching some small problems that wouldn't make any major difference in the viability of the sisters, or putting my effort into a single, simple-but-wildly-versatile device that will change the whole equation of project viability and provide means to subsequently work around pesky weaknesses of the software. Of course, the risk I'm taking is, I've now invested two years in this device and am still going, and at any time the foundation may decide to "upgrade" the wiki software in some way that breaks what I've done.


 * As for navigation, the reason I created my Navlist suite in the first place was that the navigation boxes were hard to maintain. The point is to have a single standard way, for all books, of maintaining the organization of each book in just one place, rather than having to remember to make lots of finicky changes in lots of different places every time you want any little alteration to the book's outline.  Come to think, your criticism of the available navigation boxes was, I suspect, my major inspiration to undertake the Navlist suite.  --Pi zero (discuss • contribs) 22:31, 12 January 2014 (UTC)


 * Well we seem to be in agreement in the first two paragraphs. On one side I'm glad that my resignation is shared and so validated but at the same time sadden that it is. I think thew foundation misses much by centering itself in a single project (I had hopes that the creation of independent parallel projects, even the Wikipedia's plateau/stagnation would open their strategy to cater more to the other projects, having a fragmented vision of all the projects also does not help. I hope for greater integration with some regards to keeping the projects "politically" independent).
 * In regards to navigation, it is clear that it can be improved and stream streamlines and in that beneficial but it comes to the costs of moving the projects away from the simpler structure present on the Wikimedia software and so to me that continues to be detrimental, but beyond my personal distaste I can accept that others have different preferences but things tend to be compounded. As an example in the Featured books that IIRC even often include the addition of navigational templates in projects that had none.
 * I also have a distaste for the selection process for discussion and selection. Not that I don't see some value in it, but the process seems to me more destructive (adds extraneous goals) and directed to funnily projects through an almost had-oc committee (a more or less fixed subset of the active community, due to many factors even lack of visibility and interest) that can exert pressure for conformity to that small set of opinions regarding aesthetic and acceptance that tends to foment a culture creep as the majority of Wikibookians aren't interested in participating in the project's "political" debates. --Panic (discuss • contribs) 01:34, 13 January 2014 (UTC)
 * We should try not to get completely cynical about the foundation. I don't count on them for active support, but on the other hand, the recent Board of Trustees election brought, I understand, some people onto the board who are friendly toward the non-wp sister projects.  --Pi zero (discuss • contribs) 01:42, 13 January 2014 (UTC)

cook book
lets move it away from wikibooks to an seperate project, this helps it to grain more users--Gabrielchihonglee (discuss • contribs) 12:57, 24 January 2014 (UTC)


 * I have doubts about your premise that a separate project would draw more users; what makes you think so? From my experience of small sisters, I'm concerned that as a separate project the cookbook might not be able to maintain sufficient administrative support.


 * The nature of Wikibooks &mdash; I have slowly realized over the years &mdash; is that it is a large collection of what one might call micro-projects, most of them so small they make Wikinews look huge. Each of these micro-projects is too small, often much much too small, to be a viable sister project on its own, but despite their idiosyncracies they also have a good deal in common, and by banding together they can share infrastructure (amongst other things, anti-vandalism measures and some degree of social normalization).  Cookbook may be a relatively large subproject, but the question is whether it's big enough for the benefits of independence to outweigh the benefits of being part of the Wikibooks collective.  --Pi zero (discuss • contribs) 14:10, 24 January 2014 (UTC)


 * Proposals for new projects is the place to make proposals for new projects - not here. QuiteUnusual

(discuss • contribs) 11:38, 31 January 2014 (UTC)


 * This project is already small enough. No need to split it. --Jakob (talk) 15:31, 31 January 2014 (UTC)