This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I have moved the previous content to Wikibooks:Formatting help, as the content was not necessarily a prescriptive guide to consistent Wikibooks. Dysprosia 05:03, 2 Mar 2005 (UTC)

title casing

In spite of the previous statement that Wikipedia-style case was the norm, a very large number of articles have been created with title case. I think it's pretty clear that most people prefer it that way.

Wikipedia is very different from Wikibooks. Link renaming is nearly universal on Wikibooks. Wikipedia relies on a software hack to make the wiki appear to be case-insensitive to the casual observer, but this hack doesn't work for Wikibooks. (the software uppercases the first letter automatically)

So a technical hack (kludge, really) on Wikipedia leads to Wikipedia policy, but that hack doesn't apply on Wikibooks.

Anyway, we already have lots of books using titlecase. (just look at recent changes) It is thus terrible to give any advice other than "follow what the rest of the book does". If such advice were to be given though, it would have to be toward the ever-popular and natural titlecase.

AlbertCahalan 16:56, 14 May 2005 (UTC)

Albert and I have discussed this on several occasions on the cookbook's talk page and more recently on my talk page without agreement. He prefers title case, but as I came over from Wikipedia, I prefer Wikipedia's naming conventions. Up until today, the naming convention for Wikibooks was to capitalise like Wikipedia (i.e., the initial letter capitalised, with only proper nouns capitalised thereafter). Albert has added his opinion to the naming conventions today, that is, to follow the current naming convention used within a book, be it title case, Wikipedia's titling scheme, or a mixture of the two.

I think that we need some feedback on this issue. What does everyone else think should be done? Maybe we can come up with some sort of consensus. (_Donovan|Geocachernemesis|^Interact) 04:22, 15 May 2005 (UTC)

Use whichever is the convention for each book. I prefer Wikipedia's myself. - Omegatron 02:10, 16 May 2005 (UTC)

What happens if a book is using a mixture of the two styles, and one contributor prefers title case, then systematically moves the names of all pages to title case? That's what AlbertCahalan has been doing with Cookbook over that last few months (admitidly, a majority of Cookbook's pages may have been in title case before he started). Would it be fair for him to then claim that the convention is to use only title case? Not really. I think that we do need to have a standard for Wikibook's as a whole. Meta would prefer it to be Wikipedia's naming convention, but I'm not going to let my ego get in the way, and I'll accept whatever convention the Wikibooks community adopts. (_Donovan|Geocachernemesis|^Interact) 03:09, 16 May 2005 (UTC)

Ahem. I actually did think that the Cookbook was pure titlecase at first, because that's the way most of the recipes were. So, when I stumbled across the odd Wikipedia-style title, I was sure it needed fixing. This wasn't just a case of me showing up and deciding to convert a Wikipedia-style book over to titlecase. I think it would be fair for me to claim that titlecase was the norm, particularly for the recipes. Since the recipe contributers are far more varied than the tool and ingredient contributers, I think we can take that as the majority opinion. AlbertCahalan 04:02, 16 May 2005 (UTC)

Note that this isn't just about the Cookbook. At least one book is using "Book Title Name:Page title name", and "Book title name:Page title name" is probably in use too. I certainly would respect that if I were editing those books. Respecting this is no different from respecting anything else about a book: use of a navagation template or boilerplate header, use of "Book:Page" or "Book/Page", simple layout or crazy abuse of templates, etc. AlbertCahalan 04:02, 16 May 2005 (UTC)

I'm sure that most of the recipes were in title case, but under Wikipedia's naming scheme, recipe names should probably be capitalised anyway. It would appear to any newcomer that title case was the norm for the whole book. So, I suppose that my main gripe is with the ingredients section, where names of ingredients are not title case under Wikipedia's naming convention. When I started contributing ingredients, there was definitely a mixture of styles. (_Donovan|Geocachernemesis|^Interact) 04:27, 16 May 2005 (UTC)

Please continue the title casing discussion at Wikibooks talk:Manual of Style#title category vs subject category. --DavidCary (talk) 12:42, 24 August 2009 (UTC)

inter-wiki template usage

This is moved from Wikibooks:Votes for deletion. I have declared this invalid as this is a GLOBAL template used on all wikis and all languages. The Foundation would have a hissy fit if we tried to delete it, so we must instead decide on amending the Manual of Style for its usage. Please do not cast further votes as they will not count in any way. Garrett^Talk 14:07, 12 August 2005 (UTC)

I think this template was a wonderful idea and it was really well done, but I think in practice it's not worth having. For background, this template will generate a wikipedia logo and the message "Wikipedia has an article about this subject: TheSubject".

In practice, when this template is used it ends up taking a considerable amount of space on the page, making it half banner ad, half reference section. If anything, I think wikibooks needs to be discouraging links to wikipedia. The reasons are:

1. It leads to lazy writing: a subject that could be covered in a page or two isn't covered at all
2. It fractures the reading experience: if it's required for reading, hundreds of people are following a link when one author could have summarized the important issue, or restated a definition
3. It confuses the reader: a reader will think "is this something I need to go to? is it required or not?" and "how deep should I follow the links if I don't get somethings discussed in the wikipedia article?"
4. It scatters content: If these are instructional resources, it would be nice to print them all out without too much trouble. Following endless links is going to hurt that
5. It hurts contributions: This is the worst for module stubs, which contain a little bit of information, and not much else, and then have this prominent link to the wikipedia article (which likely contains lots of information) on it. The contributor would think of it more as a cross-project redirect than something that merely should be mentioned "by the way," thus, they might believe that the module is somehow supposed to be sparse, and only link to the wikipedia.
6. The wikipedia itself has problems with too many links: "Over-Wikifying. Wikipedia thrives on internal links, but keep it within reason."

However, note that

1. Giving links, to the wikipedia or other sites, is excellet for reference sections, further reading sections, and prerequest discussion sections. But none of those examples requires a cool logo or anything that takes up so much space.
2. One of the most valuable things the wikipedia provides is its vast and rich links. Such a complex and semantic-rich web helps when you want to explore a subject and the google results just aren't giving you what you need. For wikibooks, I think our value is in that we can explain topics really well. I think we should have as a goal for people to say in two years: "oh yeah, you're stuggling in that class? Try looking at the wikibook on it. It's short, but I found it to be really helpful." (And then two years after that, they'll be saying "read the short introductory book first, and then try some of the other longer books that get into more depth.")

MShonle 01:34, 12 August 2005 (UTC)

• Comment - I agree that we should avoid direct linking to Wikipedia in most cases. But, I think that the indirect link provided by the Wikipedia template serves a useful function. When used properly, it can be used to encourage contributors to leave out detail that doesn't relate directly to the book it appears in. For example, in the Cookbook, the potato has uses in cooking that should be written about in the Cookbook, but the history of cultivation is not that important, so the Wikipedia template would link to all of that extra information on Wikipedia. The main problem may be that the template is not being used correctly (like, not being placed at the bottom of the page, where it is less distracting), perhaps we should clarify the existing guidelines for its use? Geo.^T 03:02, 12 August 2005 (UTC)

• Comment - This seems rather an odd choice for VfD. I agree with your assessment, but I'm not sure if deleting it is the right thing to do. Perhaps it just needs guidelines on when to use it. We use it in Grand Theft Auto: San Andreas, since the 'pedia article on the same subject does actually contain some information not available in the Wikibook. Instead, we could have just added the 'pedia article as an 'external link' at the bottom of the page. We've additionally linked the first instance of the phrase "Grand Theft Auto: San Andreas" to the 'pedia article too, so the template is arguably redundant in our front page. I don't know which is best. Hence this is a comment rather than a vote. Perhaps I'll wait to see what other people think. P.S. The incredibly long 'pedia link you've given in your above text seems to be bogus. - Aya ^T C 03:17, 12 August 2005 (UTC)

• Weak Keep - This is something that is very common on most other Wikimedia servers in various capacities. There are many links from Wikipedia to Wikibooks (I think perhaps there should be more) using precisely this sort of template. I call this the "medals" section, because some Wikipedia articles have 4 or 5 of these little templates that point to all sorts of Wikimedia content on other wikis (such as Commons, Wikisource, Wiktionary, Wikinews, and Wikibooks). It starts to remind me of the pile of ribbons that an admiral or general has on their uniform. IMHO it is also just as tacky looking, but that is another issue. I've added some of these in the past to some Wikipedia articles, as well as to some other articles, although I havn't done it here on Wikibooks yet. I think the place to discuss this issue is more the Wikibooks:Manual of Style rather than a VfD discussion. It is not if this template should exists but rather where it should be used. --Rob Horning 11:49, 12 August 2005 (UTC)

previous and next links

I'm actually a newcomer, though I've been a contributor of Wikipedia for about ten months, so I admit I don't completely know what's going on.

I would like to suggest, though, if it hasn't already been considered (I couldn't find it), to include a guideline to include previous and next links at the bottom and/or top of every page. These are, after all, books, and it makes perfect sense for it to be a chain of pages from start to finish.

I also would like to suggest that these previous and next links, and, if wanted, "up" links, follow a strict format, e.g. use << Previous Page and Next Page >> (with Previous Page and Next Page as the acutal title of those pages, not just "Next Page"), or Previous Page: Title or whatever you think is better. Neonumbers 22:40, 19 August 2005 (UTC)

You might be interested in how we did this with the 1911 Encyclopædia Britannica Project. There is a standardized template that we used to aid in the links between pages, and a link to the overall book table of contents. Something like this could be simplified for an individual project, or even made "generic" to put into a book.

Keep in mind that each Wikibooks seems to have its own group of authors, and there are some stylistic differences between each Wikibook because of that. Still, if you feel inclinded on a Wikibook that you are partial to and think it could use a nagigation aid like this, please feel free to put that on the Wikibook, and even add instructions for "optional" styles to include a template like you are discussing. See also 1911 Encyclopædia Britannica Style Manual that goes into more details on how it is used in Wikisource. --Rob Horning 02:09, 20 August 2005 (UTC)

I would also like some guidance as to recommended ways of providing next and previous links. At the moment I'm using { {auto navigation|next|prev} }. Is this a generally used feature? Also, should footnotes go above the links or below them? Yan 12:44, 15 May 2007 (UTC)

Could we add in something in the style guide such as

Modules in most books are intended to be read in an ordered sequence, such as Chapter 1, Chapter 2, etc. Hence authors are encouraged to provide clear links to the next (and possibly previous) modules in a book. There is as yet no standard convention for this, and given the various audiences for books, there may never be. However, several standard navigation templates are documented at Wikibooks:Template messages/Navigation.

--Yan 13:03, 15 May 2007 (UTC)

Keys and keyboard references

What about a template (e.g user input) to be used for keys on a keyboard (since the <kbd> tag isn't supported in mediawiki yet).

<span style="color:#000000; background-color:#DDDDDD; background-image:none !important; border-color:#DDDDDD; border-style:outset; text-decoration:none !important; padding-left:0.2em; padding-right:0.2em; border-width:0.15em; font-size:95%; line-height:95%; font-family:verdana, sans-serif; font-weight:bold;">{{{1}}}</span>

Example: F11

And a similar thing for menu entries (e.g {{{1}}}) like the following woudl be usefull as well ... me thinks:

<span style="color:#000000; background-color:#DDDDDD; background-image:none !important; padding-left:0.2em; padding-right:0.2em; border-width:0.15em; font-size:95%; line-height:95%; font-family:verdana, sans-serif;">{{{1}}}</span>

Example: Edit

Good idea, bad, comments? --80.237.152.53 12:20, 31 August 2005 (UTC)

It's a very good idea. By doing this readers can easily tell whether something is a key or not. Foxjwill 23:29, 19 February 2006 (UTC)

This is very specific styling which is only relevant to some books. Books should also be allowed to implement such an idea differently. I don't see the necessity to make this explicit in the WB-wide Manual of Style.

I do, however, think that what you suggest is good practice and the kbd-template is a good idea. If we could abstract the idea to: "Use HTML elements or templates to structure content" then I might agree to include it here. --Swift 09:54, 21 November 2006 (UTC)

Use of Templates

I would like to propose that there be a guideline for modules in the Template name space. Templates should be small pieces of wiki-text that are intended to be used throughout a book, bookshelf or the entire wikibooks project. I think whole articles should be in the main name space for searching. A naming convention in the templates name space similar to the one in the main name space where if there are book specific templates there may be a main book template at Template:Book and other assorted templates at Template:book/refernce. What should be at the Template:book page is a mystery to me, maybe it shouldn't be a template but a list of the templates in the book. Msmithma 04:49, 17 November 2006 (UTC)

Do you have some examples of content pages being added to the Template namespace? --SB_Johnny | ^talk 11:13, 17 November 2006 (UTC)

I ran across one Template:High School Mathematics Extensions/Primes/Modular Arithmetic and moved it into the main namespace and then realized I should probably ask if that was OK so I asked the IRC chanel and got that there was no policy. I also posted to the main authors talk page as I guessed he didn't know how to include pages from the main name space and was puting articles into the templace space for easy inclusion.Msmithma 18:21, 17 November 2006 (UTC)

This is, indeed, odd and should probably be discouraged. I would have thought that Help:What is a module was enough to explain to people that the template namespace isn't for content (a module is only in the main namespace). Either way, I would imagine this only came up because the author(s) didn't know that normal pages could be included in other pages (like so: {{:Name of page}}). Explain that to them and I imagine this will go away. I don't think we need this in policy but it should be more clearly explained elsewhere (e.g. on Help:Templates). --Swift 09:37, 21 November 2006 (UTC)

Proposed change to the equations guidelines

Commonly in textbooks the first time an important equation is introduced it is boxed. I think that this approach should also be officially condoned if not encouraged. Here's an example from the Physics Study Guide

${\displaystyle \sum {\boldsymbol {F}}=m{\boldsymbol {a}}}$

notice that the embeding is in a template so that the style can be uniform across the entire book. Msmithma 05:08, 17 November 2006 (UTC)

NIST and ISO have for typesetting math (some of which I do, but not all) in the follwing document

• Barry N. Taylor (2004), Guide for the Use of the International System of Units (SI) (version 2.2). Online Available. National Institute of Standards and Technology, Gaithersburg, MD.

Msmithma 02:40, 21 November 2006 (UTC)

I'm both a little worried about instruction creep and think this should be up to specific book editors. You are, however, welcome to write an essay or a local manual of style to spread the good word. --Swift 09:46, 21 November 2006 (UTC)

What about <ref>/Cite.php?

I'm curious as to why it is Wikibooks policy to use the old Footnotes3 system as opposed to the newer Cite.php system. Transition started on Wikipedia quite a while ago; wouldn't it be a good idea to start with the newer system before there is a huge precedent? Are there technical reasons that the older system was chosen? ­—Auk 21:01, 15 January 2007 (UTC)

I'm wondering the same thing here. This old method (ref and note) do not assist the users in determining which reference number goes to which note number - it seems to assume that there is one reference number per note. So if you have multiple to the same citation, the user has to look at the links to see which one. The tags are one up, so each new you have will create a new number - the same s are not grouped to a citation at the bottom. Harriska2 21:51, 12 February 2007 (UTC)

I agree. We should at least mention the new system in the footnotes section. How about

There is also a more recent system for producing numbered footnotes, which you may prefer to use.

-- Yan 19:41, 16 May 2007 (UTC)

Why?

Which is the reason for this? Had some discussion about it? Some link? Helder 21:10, 4 March 2008 (UTC)

Wikibooks:Manual of Style is being constantly violated

Wikibooks:Manual of Style explains how "cover/title pages" should be organised and what is their relation to book table of contents. The rationale is quite obvious: you cannot have the table of contents on "Book/Contents" page, because this way all backlinks in chapters would lead reader not to the table of contents, but to some other page. As result, when user wants to jump from one to another chapter, they would need to click twice (first to reach the table of contents, then to reach the desired chapter).

And what is the reality? Let's look on some featured books: Spanish, European History, French, FHSST Physics. Plus some other good books: Russian, German, Italian. All are a clear violation of this rule. --Derbeth ^talk 12:13, 6 December 2008 (UTC)

First of all, the Manual of Style is a guideline rather than a policy. While it should be adhered to, it is not required (there would preferably be a good reason for this).

Secondly, the Manual of Style seems to have been made official in August 2006. The contents pages of all the books mentioned, except Spanish, are older than the guideline.

Thirdly, I couldn't find any discussion of this on the guideline coming into effect on the talk page. That event may not have gotten the publicity it deserved.

That said, I do agree with Derbeth and the guideline that including the contents on the main page is a good idea and would support anyone making the necessary changes. --Swift (talk) 14:40, 6 December 2008 (UTC)

Are there any really good examples around of elegant compliance with the contents-page guideline? I've just visited about a dozen featured books, thinking I might choose between, or even improvise from a synthesis of, several different approaches to compliance — and the only featured book I found that had a contents page at all was US History, which (though I've certainly no complaint with it as a book) didn't strike me as handling its title-and-contents pages particularly gracefully. Pi zero (talk) 17:28, 6 December 2008 (UTC)

I've made some changes to WB:MOS to try to address this problem to make it clear there are several styles and to make it clear its more of a guide than a requirement:

--darklama 18:31, 6 December 2008 (UTC)

Since I don't remember voting for that guideline I've attempted to examine the community approval process but couldn't find one, nor have I seen a tag to indicate it was a proposed text, it was tagged as adopted by Whiteknight 23 August 2006, I've checked that page talk list and all Whiteknight's edits around that date, can anyone provide validation to this community guideline, I'm still a bit peeved on how the bot policy discussion process was shortcuted, if this is a similar case and someone is opposing the existence of the guideline, then it should be tagged as guideline proposal... --Panic (talk) 19:28, 6 December 2008 (UTC)

I've just "demoted" it back to {{proposed}}. Please shout if you know of where this was discussed. --Swift (talk) 03:52, 7 December 2008 (UTC)

From what I could find, up until about that time there was no guideline template to mark pages as guidelines. So I think we should assume good faith here that the change was due to the guideline template having been just created. The actual discussion and consensus to treat it as a guideline may be much older than that, but Wikibooks just didn't have any template to mark them as such yet. --darklama 14:26, 7 December 2008 (UTC)

No one is making accusations of bad faith here. Its just wrong procedure. --Panic (talk) 19:30, 7 December 2008 (UTC)

All I'm saying is that the right procedure may have taken place, that the community should assume in good faith that the right procedure did happen, and the reasoning that discussion to make it a guideline would of took place around that same period could be wrong. Back than the guideline template was new and prior to it, identifying guidelines seems to have been handled differently and not always consistently.

I am of the opinion it should remain a guideline unless consensus supports making it a proposal only as would be the right procedure today for changing the status of a policy or guideline. --darklama 22:12, 7 December 2008 (UTC)

That implies that we should consider it as bad faith if the right procedure did not happen, there is no call for that, the user is well known, the action was equal to how the same user approved the bot policy so I fully expect not to find any community validation of it. For what I understand about his rational, it was based on a "unstated consensus" on the topics by the existence of a common practice, this works but until another user raises an objection, making it a null action in the first place. I don't think this should be considered an abuse but also see it as problematic if later it serve to validate position like you expressed above "now that it is, lets require formal consensus discussion to revert it", this is wrong and again makes it clear that there a huge difficulty to keep things constant, clear and in an equal playing field for all.

I'm still expecting someone to point out that same relational to attempt to steamroll the next discussion about the keeping of the new set of flags... --Panic (talk) 00:24, 8 December 2008 (UTC)

Here is an historical observation that may help to clarify the current status of the MOS. If we can agree on the status, hopefully we can then move forward on discussion of the content of the MOS without having to constantly guard ourselves against the emotional baggage that tries to creep into discussions that touch on past motives.

The title pages material was merged into the MOS from Wikibooks:Title pages on 24 September 2006, following a discussion on the latter's talk page that decided to merge it into the MOS. Here's a choice excerpt from that discussion.

Well, according to the schedule given, this policy/guideline is up for discussion this week, ending on Sunday. In the previous section, it was suggested that it actually belongs well as part of the Wikibooks:Manual of Style and Whiteknight offered to merge it. The Manual will be reviewed at some point in the future. ... --Swift 17:20, 21 September 2006 (UTC)

At that time, the MOS was already tagged as a guideline, and so it's easy to see how, moving forward from that point, the anticipated later review of the Manual might have gotten lost track of and never happened. However, Title pages was merged with the understanding that it would be subjected to review — and, in fact, the person who advocated the merge based on that expectation is the same person who has now changed the status of the MOS from guideline to proposal. It seems that the future (when the MOS will be reviewed) has arrived; I suggest we take the status as is (proposal) and move on. Pi zero (talk) 12:44, 8 December 2008 (UTC)

That's a good solution. Thanks for going through the page histories and talk pages to track this down. --Swift (talk) 01:06, 9 December 2008 (UTC)

I think darklama got me wrong. What I think is that pages like Book/Contents or Book/TOC should be strictly prohibited. I'll repeat what I've written above: such pages lengthen the distance between book chapters from two to three clicks (normally: click on "< Book" backlink to get to the contents and then link to another chapter; with this defected design: click on the backlink to get to front page, click to link to the contents, click to the link to the chapter); what's worse, in such cases "Book" is a page containing large graphics which take long time to load so the readers suffer even more. I suggest writing explicitly in the manual of style that it is not allowed to place book table of contents on any subpage of the book; however it is allowed to place the front page as a subpage. --Derbeth ^talk 11:37, 7 December 2008 (UTC)

Yes I did misunderstand. In that case, I think some books use Book/Contents as the table of contents and Book/Contents/Page to work around the problem you described. This also isn't that big of a problem if navigation aids are used on every page to switch between chapters as some books do. --darklama 14:26, 7 December 2008 (UTC)

Two comments.

• Derbeth seems (?) to have suggested that the Title doesn't have to go on the main page. It was my understanding that the Title is, by definition, that which readers should see first when they come to the book — and the main page is what they will see first when they come to the book, therefore any Title that isn't on the main page is, by definition, in the wrong place.
• Both of you seem to be assuming that the "up" link from a section page is somehow constrained to go to the parent page. Why? If the purpose of the "up" link from Book/Page is to go to the Contents, wouldn't it make sense for the "up" link to simply target where it wants to go — whether that target is Book, Book#Contents, Book/Contents, or Book/TOC?

Pi zero (talk) 15:09, 7 December 2008 (UTC)

I think that is one of the sticky points of the MOS. A book doesn't have to include a title page at all, but a book is expected to include a table of contents. Where the title page and table of contents should go varies, but there are at least two common conventions that were adopted as being the right thing to do, even if it could cause some trouble. One is the main page of the book and the other is as a subpage with a specific name.

We are assuming the backlinks are constrained because they are created automatically by the software for each sublevel in the page name if the previous sublevel exists. Like Foo/Bar/Buz would automatically create links to Foo and Foo/Bar if Foo and Foo/Bar exist as pages. So we have no control over the backlinks and where they go. People create navigation templates to work around the limitations of the built-in navigation aids though. --darklama 15:39, 7 December 2008 (UTC)

This is, indeed a point of contention. I agree with Derbeth in preferring to have an overview of the contents on the module main page, but disagree that there should be any sort of prohibition against TOC pages. The reasons are that different books will have different styles of structure. Like Darklama pointed out, many books have navigation aids (especially those that pre-date the automatically generated links).

Were a book to have a great number of pages and appendices, it would make good sense to list only some of them on the main page (a gateway, of sorts) and direct users to a more concise table of contents, located on a sub-page.

Still, I think the Manual of Style should advocate the principles laid out by Darklama that content should be placed as close to the main page as possible. I strongly dislike splash pages and think they should be strongly discouraged. Still, I don't see any need for this to be a policy, rather than a guideline.

Also, I think that in most cases, people will be responsive to mentions of this guideline and offers to move pages around. The structure of books with no editors in sight can simply be changed on the spot. This is, after all, a collaborative effort. --Swift (talk) 01:06, 9 December 2008 (UTC)

It was my understanding that the Title is, by definition, that which readers should see first when they come to the book — and the main page is what they will see first when they come to the book, therefore any Title that isn't on the main page is, by definition, in the wrong place. No, there's a simple solution: link to Book/Cover instead of Book from book catalogues. You want to see the cover page only once - when you visit the book for the first time. But if the book has, say, 30 chapters, you don't want to wait for the terribly large image on the cover page to load and click to get to the table of contents and click again to get to next chapter - 30 times. I think that what the book structure should make easier is actions that are performed oftenly (going back to the table of contents) rather then actions that are taken only once (visiting the cover page).

I'm strongly against Book/Contents/Chapter naming scheme - it's making simple things complicated only because of one page - cover page - that occupies main book page. Is there any sense in having, say, 30 pages to have unnecessarily too long names (which harms making links to these pages etc.) only because there's one page that readers see once?

The solution I am talking about is an official policy on Polish Wikibooks. --Derbeth ^talk 11:48, 9 December 2008 (UTC)

Two comments.

I've only looked at about half of the (English) featured books (roughly, the first half alphabetically); but amongst those, the one I found most smoothly navigable is European History — which has its Contents on a separate page, and doesn't put the chapter pages under the Contents. It has navboxes at the top and bottom of each chapter that IMHO are unusually simple, clear, and easy to use. Some of the most difficult-to-nagivate featured books rely on the automatic up-link. Some of the featured books have navboxes that I found quite confusing. There are featured books out there that have perfectly reasonable structures that are so different from each other that devising any sort of standard navbox format seems remote (not impossible, perhaps, but requiring a lot of perspiration and probably a pretty substantial amount of inspiration). Overall, I'm inclined to believe that additional recommendations on these aspects of structure would be premature at this time.

European History is not an example, it disregards the slash convention, you get a link to the "cover" in each page (sadly we can't disable that) and as a way to address the problem they had to implement navboxes.

Navboxes are workarounds for ill conceived structures (or forced upon the Wikimedia software), there are no other benefits, most of them don't really help, they are fixed structures (would be great if they were dynamic), that are hard to maintain, requires above average understanding of the Wiki software and ultimately put a barrier to participation, at best they are a time sink, people should concentrate about content not how piety it looks like (even more since most people that like pretty things already took steps to do that locally or special setups, ie using the skins feature or browser addons)... --Panic (talk) 06:32, 10 December 2008 (UTC)

Wikibooks:Naming policy says that chapters should be called Book/Chapter. EH adheres meticulously to it; now that you've forced me to reread that policy in light of the current discussion, I realize that I was mistaken in my implicit criticism of EH for not naming them Book/Contents/Chapter — that would have been a violation of policy.

Halfway between the two topics (slashes and navboxes), I agree it would be nice to be able to disable the automatic up-link.

Concerning navboxes, although you have mostly strong criticisms of them, you say it would be great if they were dynamic. Dynamic in what sense?

We are in agreement on some of your points. Most navboxes don't really help — check. They tend to be hard to maintain — wholeheartedly check (though my natural reaction to this problem is to add it to the list of things to do: find a way to make navboxes easy to maintain). People should concentrate on content rather than on how pretty it looks — qualified check. Most contributors should be unburdened by such concerns, certainly, but if we took that principle to its logical extreme then wikimedia should not have bothered to develop its software. In this particular case, this is for most readers a visual medium, whose use will be more pleasant if its appearance facilitates its function, and whose level of use will depend on how pleasant it is to use. I'll say again that I agree some way should be found to make navboxes easy to maintain. (A thought worth pursuing: it is already necessary to maintain a table of contents, so an ideal solution for navbox maintenance would cause navbox maintenance to be an automatic consequence of TOC maintenance. Hm.) One point on which we appear to disagree is your blanket characterization of navboxes as a "workaround" — except in the sense that the best known way to do anything is a workaround for not knowing of a better way. And here too I'll repeat my earlier agreement: most navboxes don't help. However, my experience thus far has been that not using navboxes doesn't help either; only the rare well-designed navboxes help. Pi zero (talk) 15:21, 10 December 2008 (UTC)

It seems desirable from an organizational point of view that catalogs take you to the same page that you would be taken to by asking for the book by name, which is to say, the book's main page. Concerning large images on the main page, the MOS since the rewrite seems to be sending a mixed message: it does say "Splash pages should be avoided", but then the examples at the bottom of the Structure section specifically include Spanish, which uses a splash screen. I would be in favor of replacing the Spanish example with European History; I'm not going to condemn Spanish for its splash screen, but also don't consider it a good qualification for making Spanish one of three exemplars of superior book structure. Pi zero (talk) 04:35, 10 December 2008 (UTC)

Actually, both of these have splash pages. I kept Spanish in the list of examples because it was already linked text that I edited. I do like its table of contents as it isn't just a simple list, and contains more complex contents that benefit from a sectioned layout (lessons, appendices and other materials). What I'd like to see is a few pages that take different (but in each case, successful) approaches to this meta content. I'd be happy to see more pages added with a bit of annotation about their strengths. Maybe we could set up Help:Layout, and/or Help:Navigation that could have discussions about and galleries of various approaches that people find useful. --Swift (talk) 06:19, 10 December 2008 (UTC)

I particularly don't see a special benefit on making all books seem alike, diversity is good, if we must put some structure down just do it to avoid ugly mutants, do an exclusion with not to do or avoid at all cost (I would propose adding Navboxes to that :) ), another thing I personally dislike is having huge pictures on the "cover" (I'm a Google man, but I recognize there are Yahoo people to...) --Panic (talk) 06:41, 10 December 2008 (UTC)

Ya I added Spanish and the rest. I actually tried a few different books at first, but I think these three at least provide good demonstrations of how different books can be in terms of their main page, table of contents, and the like. Some other books I tried I think were too similar to each other which wouldn't really demonstrate as well how different books can be. I think having divers examples is important to understanding how different books can be while still having some key things in common. --darklama 17:45, 10 December 2008 (UTC)

Instruction creep

I'm afraid we may be going down the road of instruction creep here. I'm certainly not innocent of this myself. We have a very broad topic and it's easy to keep adding to it.

For the purpose of this proposal for an official guideline, I think we should aim to keep it short and to the point, leaving out informative sections and keeping only those that we deem necessary. I'd advocate for keeping only those topics that are frequently mishandled. I'd love to keep the rest, but place these on help pages which new and experienced users alike can use to read up on various style and structure techniques.

I think that help pages such as Help:Table of contents and Help:Navigation that would illustrate different approaches. There is also an undeveloped Help:Manual of Style that only discusses local manuals of style. --Swift (talk) 04:00, 12 December 2008 (UTC)

I agree the navigation section should go, whether to use navigation at all or not is a personal preference, and not really something agreed on. I think the table of contents section is necessary though and doesn't contain any instruction creep. More detail description of the in and outs of the table of content use to be included and I think that was instruction creep that could go on another page. I think a page like Help:Book Elements or Help:Book Design could be helpful and could include lots of element or design ideas for books. I don't think separate pages for each element/concept would be useful at this time, but I could be wrong. --darklama 14:53, 12 December 2008 (UTC)

Wikibooks:Book structure

I think it could be a good idea to split the structure part away from this Manual of Style. It might actually be better to move the stylistic parts to Help:Manual of Style and rename this as Wikibooks:Book structure. My rationale is that the stylistic bits needn't be an official guideline and are much more of an instructional guide, rather than a clarification of why one way of doing things is best.

The book structure is another matter. This would benefit from a discussion on the best common practices that have developed (table of contents pages, splash, etc.). --Swift (talk) 04:01, 12 December 2008 (UTC)

Manual of style as a name should be dropped, I agree, but what parts are you referring as "stylistic" ? One thing I've seen happening with the new proposals is that they are to much centered on definitions and not making clear the needed requirements or guidelines, making them to verbose, and overcomplicated, a recent example is the navbars text that was added, you version didn't particularly provide a special definition or explanation but indicated a guideline, after the alterations it now doesn't give an guideline but a rational that can go both ways (as it is there is no need to pass that part as part of a guideline), the other problem we could address is to reduce duplications, like the title section (already covered on the title policy) a plain statement indicating that will suffice. --Panic (talk) 06:33, 12 December 2008 (UTC)

"what parts are you referring as "stylistic" ?" The Style section and its subsections. Stuff on headings, references and mathematics notation.

I wholeheartedly agree with you on definitions vs. guidelines. --Swift (talk) 06:51, 12 December 2008 (UTC)

I disagree because without definitions of what something means there could be no clear context in which a guideline applies. People could argue until there face turns blue as to whether or not a guideline applies in situation X if no agreed to definition exists to go by. I think there is also no need to see things as definitions vs guidelines, or as pages being either a definition or as a guideline. I think clear guidelines use some definitions. --darklama 15:10, 12 December 2008 (UTC)

Definitions are needed (and as I said above I don't have a solution to the problem, I doesn't like the idea of having a single page with all the definitions, like it was once proposed but then we should keep the text to the point and as small as possible, even if it has to be split into smaller sections so it can be manageable. I think this is why Swift is also proposing splinting the text. The other aspect is how things are worded, it comes to a point were there is no need to have it on a guideline or policy, since it becomes non enforcible or ceases to provides any guide, this is plain to see in what became of the navigation section, it started as "use as less as possible" to "you can use but there are problems and it can be done x,y and z way and remember that k also does it", confusing and provides no clear optimal path, the guideline to reduce the use was lost. --Panic (talk) 17:34, 12 December 2008 (UTC)

I have several thoughts on what should be done as well. Personally I would prefer that the tips section from Wikibooks:Naming policy was moved to this page and expanded on. I would like to see the styles part focus more on the need for books to have their own style guideline written up, provide examples of what a book's style guideline should define, and focus less on specific styles. I think the heading section might need to stay though, because level two headings I think is a guideline worth mentioning here as being a requirement across books. I think a lot of the concepts covered in WB:LMOS should be added into this proposal. I think the navigation, and math formulas sections along with similar sections from WB:LMOS should be moved to some help page more focused on describing different styles in more detail. I don't think there is really any benefit in renaming WB:MOS. I think style includes structure, WB:MOS just needs to focused more in some areas on what books need to define themselves, so that a clear distinction exist between what all books are expected to have and what all books are expected to define themselves. --darklama 14:40, 12 December 2008 (UTC)

Splinting related info across several pages can be counter productive especially something that was already accepted as consensual. Moving parts to a non adopted text will reopen discussions and you will not guarantee that the expansion you intend to do will be accepted (or have the same value), in this case its best to duplicate the content making a note that if adopted said duplication will be resolved by proposing a deletion of that part of the text on the old policy/guideline.

The problem with the "Manual of Style" is that it tries to be a manual while attempts are made to adopt it as a guideline, as a manual the number of subjects it covers is not a great problem but guidelines, as seen above, need to be concise and stick to a single subject. It also just looks too weird having a guideline manual of style... --Panic (talk) 17:34, 12 December 2008 (UTC)

Well I guess effort could be duplicated here for now and hold off proposing their removal from the naming policy until later, although I don't really have a problem with their removal now, even if things weren't to go as I would like later.

Manual of Style seems like a common cross-project naming convention used by every English project I've looked at. People are probably expecting to find information under this name. I don't think there is a problem with the name, manuals can be as short or as long as people want, and there is nothing that says that policies and guidelines cannot be in the form of a manual. Perhaps you are misinterpreting the meaning of the name as well? Consider what wikipedia has to say about style guides: "A style guide or style manual is a set of standards for design and writing of documents, either for general use or for a specific publication or organization." --darklama 20:01, 12 December 2008 (UTC)

I have not explored other Wiki projects enough to have an informed opinion, but nothing dictates that our project needs to comply to what exists elsewhere, but that is not the important thing, what is important is the guideline in the context we are using them, are not the same other common propose guidelines. In Wikibooks guidelines establish best practices that ought to be fallowed and are only open to infringement if supported by a good enough reason, they don't have the same propose as generally the word implies and is not compatible with the concept of a manual (a small reference book, especially one giving instructions), the main purpose of establishing a guideline is not to be instructional or define concepts, but to define procedures, what to do and what not to do, as black and white as possible, creating gray zones reduces the clarity of the text and opens it to contradictory interpretations, something that is even more problematic... In any case guidelines and policies should be clearly named and to the point, Manual of Style is vague (and redundant) and as proposed above it should be split into smaller and more manageable parts for adoption. I wouldn't object keeping the page as a centralizing point to all things that relates to book styles... --Panic (talk) 20:42, 12 December 2008 (UTC)