Wikibooks:Reading room/Proposals/2010/December

Enabling subpages
I really wish subpages were enabled for all namespaces by default but am specifically proposing that we enable them for the Help namespace and the Cookbook namespace. Cookbook:Feature requests for the latter would make use of it and I'm wanting to move the FAQ pages to Help:FAQ/... for adding a search box to them to search on the Help:FAQ prefix. – Adrignola talk 16:17, 6 December 2010 (UTC)


 * I think we use the flat structure due to historic reasons the "/" convention was implemented on the Wikimedia software at a later date. I don't have any objections to move content that is close related to a "/" convention style structure and agree that it not only benefits in searching but could, dependability on the complexity of the subject, help navigation, and prevent duplications of content permitting a closely related coverage of the subject matter. --Panic (talk) 16:22, 6 December 2010 (UTC)
 * I would like to see subpages enabled for the talk spaces for both as well.
 * AFAIK the only namespaces that would be left without subpages enabled are File, Category, Transwiki, and Subject. I cannot imagine when having subpages for files would make sense. Pages in the transwiki namespace are intended to be temporary and often imported from projects where subpages aren't used so I don't see a need for it there either. I think at this time there aren't enough people making use of Category subpages for it to be enabled and who knows what odd behavior that might introduce. I wouldn't mind seeing subpages enabled for Subject pages if for no other reason than as an accuse to more tightly associate topic WikiProjects with their subject by making them subpages of a subject page, but like Categories people haven't been using them so there isn't likely to be a need for them right now. --dark lama  16:56, 6 December 2010 (UTC)


 * Actually categories have been using them. See Category:Horticulture for instance.  Also see Category:Book-specific templates with 300+ categories using pseudo-subpages. – Adrignola talk 17:19, 6 December 2010 (UTC)
 * I was suggesting there "aren't enough people" using Category subpages, not that Category subpages aren't used at all. Though I should of said not enough books use category subpages. I see though that I am wrong in both respects. I guess they started getting used more along side book specific template subpages. I guess that just leaves whether people think treating them as subpages would be useful or not, and what possible oddities enabling it might introduce. --dark lama  17:50, 6 December 2010 (UTC)
 * It'd be interesting to see what the developers' reaction would be if we asked for subpages to be enabled for categories. – Adrignola talk 03:08, 15 December 2010 (UTC)

Personally I would like the subpage structure to be enabled in all namespaces as well. Are there any known oddities? Thenub314 (talk) 01:44, 15 December 2010 (UTC)


 * I haven't heard of any project enabling subpages for the category or file namespaces to know. I know there are existing oddities for what we do have right now. If you add a page to a category and that category is a redirect, the page is still listed under the redirect rather than the category the redirect goes to. If you use the CAT namespace alias it adds a page to a category too, unless you use :CAT. The only oddity I can think of for enabling subpages for categories is the links in the generated list of parent pages ends up being treated as categories to add this category to, the links are moved to their category position, and as a result the parent list looks like "< < <". Of course that would be a bug if it did that. --dark lama  14:58, 15 December 2010 (UTC)


 * So, no problem with a bug request asking for subpages in Help, Help talk, Cookbook, Cookbook talk, Category, Category talk, then? – Adrignola talk 16:33, 15 December 2010 (UTC)


 * Sure go ahead. --dark lama  16:59, 15 December 2010 (UTC)


 * Filed as bug 26344. – Adrignola talk 16:11, 16 December 2010 (UTC)

Change default search options
I'd like to change the default search options from the main, Wikibooks, and Subject namespaces to the main, Subject, Cookbook, and Wikijunior namespaces. The former is what is selected for "content pages" but the latter actually contain content pages or our version of portals. Wikibooks and Help are covered by the third option at Special:Search. – Adrignola talk 16:37, 15 December 2010 (UTC)


 * A previous suggestion was to limit the default search to the Subject namespace, and see about having the search auto suggestions show only pages from the subject namespace. I still think that would be the better option. People are more likely to search by subject when wanting to learn a subject, rather than have a specific title in mind. --dark lama  17:02, 15 December 2010 (UTC)


 * I notice that even though subjects are included in the default search, they aren't shown in the search suggestions unless I specifically begin a query with "subject". From what I've found we can't change that.  A concern would be that if search is limited to subjects by default the lower number of subject titles as compared to book titles would cause readers to depart in frustration when they don't immediately see a book on a specific piece of software for instance. – Adrignola talk 17:21, 15 December 2010 (UTC)


 * IMO search should include the content spaces, because (somewhat paraphrasing the above) otherwise everyone is entirely at the mercy of the subject hierarchy. Listing pages that mention something is, in my experience, useful.


 * For the longer term, I've had in mind for some time (but it's been languishing on my desktop for lack of time to pursue it) an arrangement in which each book &mdash;or page, IIRC&mdash; could register "keywords", which would then be searchable through a 'keyword pseudo-space' mechanism... whose inner workings I had some notions for, but hadn't worked out in complete detail when last I actively pursued the idea. My hope was that decentralized listing of keywords by each book (or page?) would be better maintained, locally, than the subject pages are globally.  If I'm remembering rightly (a big if), the basis of the inner workings was that (is this even true?) search favors matches in page titles over matches in page content.  --Pi zero (talk) 17:45, 15 December 2010 (UTC)


 * Would this be something similar to what I did for the subjects, redirecting from the term of the same name as the subject to the subject page? Titles are favored.  Search for "languages" and you hit the redirect at Languages rather than getting a result page. – Adrignola talk 20:03, 15 December 2010 (UTC)


 * The suggested titles drop box requires JavaScript. JavaScript could be used to prefix searches with "Subject:" so that it is implied. Could also fall back to the default search when there are no pages beginning with Subject:whatever is typed, and maybe add a check for :whatever is typed to force the default search as well. The link you referenced means that only one namespace can be searched at a time. However the mediawiki API suggestions that multiple namespaces can be searched at once since it provides a way to list each namespace to be searched. Even if only one namespace can be searched at a time JavaScript can repeat a search for each namespace. --dark lama  19:26, 15 December 2010 (UTC)


 * Sounds good. We'd be able to implement that without requesting developer action.  Since that would be able to be implemented, any objections to the above proposal for the traditional search page? – Adrignola talk 20:03, 15 December 2010 (UTC)


 * I think if this is to be done, it should be in addition to Cookbook and Wikijunior being added and Wikibooks removed from the default search, so there can be a fallback for people with JavaScript disabled or not using a JavaScript enabled web browser. Also this is still needed for browsing search results when a page by a given name doesn't exist at all. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  20:52, 15 December 2010 (UTC)

Keywords
I mentioned this idea in the preceding thread, and wasn't instantly laughed out of the reading room for it, so I'm providing the available details here, defects, gaps, and all. Part of the reason I got bogged down in it was that I lack various requisite technical knowledge; perhaps someone else here can do more with it than I could.

Each book main page, and perhaps some book subpages and even subject pages, would specify, via a template call, a list of "semantic keywords", or "keywords" for short (technically, semantic key phrases, because they could have spaces in them). When a user does a search, keywords would be potential matches for the search.

Why

 * More articulate search guidance. A flat keyword-space can embody a great deal of information about what a given book or page is related to, whereas a subject hierarchy actively works to minimize how much complex information is provided about any given entry.  Symptoms of the inadequacy of the current search strategy are that users are motivated to create book-main-page redirects, and that users are motivated to put their books into multiple categories (and therefore have to be admonished that most books should only belong to one).  I wrote a long-winded soliloquy last year about the importance of improved search facilities to the growth of the project.
 * More general participation in maintaining the search infrastructure. Those who maintain books tend, I think, not to get involved with maintaining the subject pages (nor bookshelves before them, which as I understand it was a major reason for replacing bookshelves with subject pages that wouldn't require as much manual maintenance).  But hopefully, maintainers of a book would get involved in choosing keywords for it.  Wider participation is a basic good for a wiki.

How

 * For each keyword, there would be a keyword page that would be a possible search match. Ideally, if the keyword was exactly what was entered, one would be taken directly to the page rather than merely seeing it listed among search results.
 * Page name. One could simply call the keyword page for keyword k by the name k, in mainspace; it would then be sort of like a disambig page on Wikipedia.  However, it would be good for the name of the page to have "keyword" in it, so that when it does occur in a list of search matches, the user will instantly know it for a keyword page.
 * One could call it k. I've no certain technical knowledge of whether this naming scheme could support taking a search on "k" directly to the page, or one would then always have to select it from a list of matches.


 * A sexier solution would be to add a Keyword namespace, and call the keyword page k. We could set up a shorthand.


 * Page content would always be just an unparameterized template call, say ; there would be absolutely no customization of any keyword page. (If I could figure how to avoid creating the keyword pages at all, I'd propose that instead.)  The template would use DPLs.  It might list subject pages first, then book main pages, then subpages.  Although it would be technically possible to let target pages assign different priorities to their keywords, that probably wouldn't be desirable because it would need a more complicated interface at the target pages.

--Pi zero (talk) 02:49, 21 December 2010 (UTC)
 * For each keyword, there would be a hidden category, perhaps named by simply prefixing " " to the keyword page name. If one wanted to list book main pages separately from subpages, one might have two hidden categories per keyword to make this distinction.

New wikibook Brief Template
I see lot of newly started wikibooks which are nothing but titles or some small writeup, I am not against such startups. However, I propose that we must have a initiator of the book write some brief about what the final book will look like. This can be a standard template which can define few things as under:
 * 1) Intended scope
 * 2) Intended Audience Level
 * 3) Additional tangential topics which might be welcomed.

This template can be default of the discussion. I propose this as on many topics there is very elaborate content is already available on wikipedia. When writing the wikibook this will bring some focus. Any thoughts ? (Yndesai (talk) 09:16, 21 December 2010 (UTC))


 * For whatever reasons new book seems to have fallen out of use. I hope the reason is not because people no longer wish to or are no longer motivated to encourage the development of new books. Using Wikibooks does or should cover scope, audience, providing an outline of topics to be covered, etc. which is linked to from the new book template. I like the idea, but I have to wonder what that would mean for any new templates when people have stopped using the ones already available. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  10:10, 21 December 2010 (UTC)


 * Note the usage requirements on the template. If a new book's main page is reviewed (as I often see is the case) or properly categorized (as I usually try to ensure), then the instructions state that the template is not to be used (and the bottom section specifically recommends removal).  For my part I always try to welcome new users, which provides them with a link to Using Wikibooks and a whole lot more. – Adrignola talk 13:33, 21 December 2010 (UTC)


 * I have seen the new book template and its good practice to direct the new book writer to "How To" kind of instructions. My main concern is if the subject have really elaborate content at wikipedia then the intent of the wikibook has to be known. Lets take an example of Renewable Energy wikibook I am interested in working on, there already exist a wikipedia portal on this subject which has lot of content. So for contributing to wikibook, I need to know how the wikibook be different from the content of wikipedia. If it is availabe then the contribution can be in right direction. —Preceding unsigned comment added by Yndesai (talk • contribs)


 * Wikipedia's intent in theory should be to just give an overview or the highlights for a topic with external links for more info on the same topic. A person should be able to walk away from a Wikipedia article understanding the general nature of a topic with just enough of an idea to know what other people are talking about, but not necessarily how to apply it. Wikibooks's intent is to give in depth details for a topic with only a few external links to related topics. A person should be able to walk away from a Wikibooks book having been educated on a topic and be able to apply the knowledge learned to their life. How elaborate or similar Wikipedia's content is isn't really relevant to that goal, nor a good way to compare or determine what a Wikibooks book should be about. I think the right direction is ask "How do I teach this topic so people can learn the topic and apply what they learn in a meaningful way?" --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  04:57, 22 December 2010 (UTC)


 * Apology for not signing my last comment. Thanks for giving difference between wikibook and wikipedia in simple terms. So I then I propose an additional title in Using_Wikibooks : What a wikibook can contain it can elaborate type of possible content of wikibook like "How To", "Apply Knowledge in real life", "Teach step by step" etc. However, each wikibook must have a purpose of the wikibook mentioned in the discussion page. This will provide the contributor a direction in which the wikibook can be taken forward. (Yndesai (talk) 05:47, 23 December 2010 (UTC))


 * I think there isn't really any limit to what a Wikibooks book can contain, the approach just needs to be educational and do more than just inform people about a topic. Generally step by step or how to instructions have not been considered enough to qualify as educational in the past. I suppose from my perspective at least a book is within Wikibooks' scope if a person can learn the skills needed to think independently, to adapt skills and knowledge to new situations, to weigh their options, and to make any educated decisions on a topic once the book has been read. I think describing Wikibooks' scope in those terms may fall a bit short though in that annotated texts may only provide new insights into the possibly literary interpretations of a work. OTOH I suppose it could be said that annotated texts could teach people the skills needed to think independently through teaching new perspectives and ways to look at the world, which may help people to adapt to new situations, may provide more things to consider when weighing options, and may overall help people to make more balanced/richer decisions. I do agree that each book must have a purpose and should mention that purpose somewhere within the book. Currently the purpose is typically mentioned on a book's main page as part of its scope, or in some sort of introductory or "about this book" type of chapter. I think this is mentioned already in the manual of style and in the proposed update to What is Wikibooks. Using Wikibooks may already cover it as well, but if not I agree it should be. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  15:05, 23 December 2010 (UTC)


 * Thank you for your reply. I was finding it difficult to contribute without the "about this book" sections in many of the books. However, I am now getting hang of it and contributing my bit for other to review and comment. Since it is wikibook "about this book" section might get written only after good amount of contribution have come. I do not think we need to really stretch this topic any longer. Thank you once again for your valuable inputs. (Yndesai (talk) 04:46, 24 December 2010 (UTC))