I came across this post from the CC News feed that Cookbookers might
be interested to read:
Thefoodgeek.com is licensed CC-BY so I think their material could be
repurposed in the Cookbook if desired.
Incidentally it might be useful if the Cookbook had a page listing
other freely licensed recipe/cooking resources.
They've just been waiting in a mountain for the right moment:
I just finished watching Richard Baraniuk's 2006 talk at TED
ce_learning.html) and took a look at Connexions. I notice that
they use CC-by-2.0 (note it's not ShareAlike). So, that is a
potential source of content in the future if WMF migrates in the
I'm only just starting to explore it, I may have more to share
later. If you're interested, take a look: http://cnx.org/
How strict is the 800 page upper limit for printed books? Is there a
way we can increase this limit (possibly for a higher price point)? I
don't want to say it's common, but I've already found one book that's
larger. Foundations of Education and Instructional Assessment, First
edition (there are three separate editions of it!!!) is a whopping 870
pages long, not including all the optional frontmatter that could have
been included. Obviously, for groups who have put so much effort into
their books, I would like to find a way for them to be able to buy and
I tried it today, and the "load collection" feature doesn't appear to
be working on en.wikibooks. I've tried with several saved collections,
and none of them will load. I don't remember the last time I tried to
do it, it may have been before the flaggedrevs extension was
installed. Any ideas on what might be causing this? Is this error
happening for anybody else?
-----BEGIN PGP SIGNED MESSAGE-----
I haven't seen this yet posted to the Textbook-l list or foundation-l
so I wanted to make it known that Wikibooks is winding down its logo
vote over the next couple weeks. While we're asking people not to
specify color, text, and there may be some minor tweaks to style, the
end logo will be look extremely similar to what we decide here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
First off, I've seen some of the new software changes on the wiki, and
they look great. As promised, I got my first book today, and I'm
racing through it to come up with feedback for the PediaPress people.
I have lots and lots of feedback already, most of it is not urgent or
anything and some of it is going to be difficult to implement because
it's sort of wikibooks-specific. Having a robust set of configuration
options that can be set on the wiki would help alleviate a lot of
these things without having to tie the extension to any single wiki.
1) On the table of contents, it says "Articles", when that word really
doesn't mean anything for books. The first heading that says
"Articles" should either be changed to the name of the book or should
be removed entirely. Actually, you could probably read the value from
[[MediaWiki:Article]] to make this solution portable.
2) Subpages shouldn't be prepended with the name of the book. For
instance, the chapter should just be titled "CHAPTERNAME", not
"BOOKNAME/CHAPTERNAME". Maybe we could have a way to override the
displayed name of a chapter, which would make good sense for books
where technical difficulties prevent the name from being displayed
properly on the wiki.
3) On page "ii" it should probably contain the name of the wiki where
the PDF was generated, and a link. Maybe also some kind of note that
the "authors" are volunteers at the project, and that the name on the
front of the book is an editor, not the "author" of it.
4) On the cover, the editors name should be marked with "edited by" or
"Editor." or something so people know it isn't an author. On Page "i",
it should say "Written by the volunteers at project X, edited by Y".
Or something like that.
5) I like the way external hyperlinks are put into footnotes. Maybe we
could have something like a special <footnote> tag, or a <div
class="footnote"> or something that would allow writers to put certain
notes in the page footer. This would be a great substitution for some
of the messagebox templates that act like footnotes on the wiki.
6) Math formulas are generally very well rendered and handled,
although integrals, limits and summations seem to be a bit cramped.
7) "articles" should each begin on a new page (I'm using the word
"article" here so as not to be confused with the collections concepts
of "chapter" and "page").
8) Chapter headings should probably be on their own page, not just as
a bigger heading before the next chapter heading.
9) I would love it if authors could specify some kind of "print name",
such as in their preferences. That way people could be recognized by
their real names if they choose, instead of by their on-wiki
10) Some images look very pixelated and fuzzy. What kind of
compression is used? Can it be improved?
11) I'm sort of surprised that PediaPress doesn't post some kind of
disclaimer here somewhere. Like "PediaPress and it's affiliates aren't
responsible for the content of this book...". I'm even thinking that
[[Wikibooks:General Disclaimer]] should become a permanent part of
these books (But I want to see what people like Mike Godwin say about
it first before I go on a crusade about it).
This is about it for now. Most of my other nitpicks have to do with
formatting issues that we can fix by overriding templates, so I won't
mention them here.
Just wanted to post a quick message to the list here to say that I got
my first book in the mail today! Actually, I think I would have gotten
it on Tuesday except there was a holiday and then the UPS guy came on
wednesday when I was at work.
The book looks awesome, much better and much higher quality then I was
expecting. I've seen books before that were self-published and
print-on-demand that were of very low quality, and this is not one of
them. It's a good weight paper, good printing and typesetting, nice
cover, etc. It's going to be so much more awesome when we get
customizable cover images and ISBN numbers, but that can wait.
The book dimensions are a little smaller then I expected (I didn't
pull out a ruler or anything beforehand), but it's not too too small
by any stretch. I wonder if we could have the option to have a larger
book size (8x11 or something)? That would help for books with more
content, to help keep them under the 800-page limit by increasing the
amount of "stuff" per page.
Anyway, I'm still at work so I can't give it a complete review now.
However, it's very awesome! I'll post more feedback tonight when I get
we received a lot of feedback that suggests, that the extension needs
some usability improvements if it shall be useful to casual visitors. I
´ll share our thoughts on how to improve the situation and it would be
great if you could share yours.
We distinguish two use cases:
* Users want to create collections
* Users want to share/find collections
= Creating collections =
The main challenge for most users is to discover this feature at all -
as most visitors simply ignore the sidebar. The current solution
having a dedicated portlet for the extension labeled "Create book" is
the best we could think off so far. We plan to remove all but the "add
wiki page" links if users have no active collection. This will save
some space in the sidebar making it less obtrusive if users are not
interested in creating collections.
When compiling collections users are limited to add articles they are
visiting (except for categories). We thought it might be beneficial to
permit to add articles which are linked on a page without visiting
them. The idea is to have an advanced book-creation-mode which allows
for easier collection building. It could be activated if users have
non- empty collections. Using JS article links could be enhanced to
have an "add article" button if users hover them. This mode could be
displayed and disabled in a box in the upper right content area. See
the following link for a mock-up:
We refactored the collection page which now allows to resort articles
and chapters using drag and drop. A more fine grained and verbose ajax
progress was implemented when documents are generated. As this is not
yet updated on Wikibooks - you can always find the latest version of
the software running at http://simple.pediapress.com/w/ .
= Sharing / Finding collections =
The current implementation allows:
* saving collections in user or global namespace
* all collections are listed in the category collections
* manually editing (e.g. adding them to more categories)
* direct links to load, or export collections can be created and used
on other pages (this needs some documentation though)
Still missing is some mechanism to track, describe and promote
valuable collections - distinguishing them from those trial or
outdated collections that start piling up in the collection category.
Maybe one could use ordinary wiki pages ("featured collections") to
list good and maintained collections. Collections could also be linked
from topic main pages (books, portals, ...). Do you think this will be
sufficient or is a more formal and technically supported solution
Please comment and post your thoughts on how to improve the usability?
I've been putting together a colleciton for Wikijunior:Colors, and
I remembered that the printed books don't come in color. That's a
shame, because this is a charming little book for kids that relies
pretty heavily on colored pages. What are the chances that we could
get some kind of "color option" for printing the books? How much would
that affect the price?