Saluton Run :) On Mon 18 May 2009 22:19 +0200, Run Paint Run Run <[email protected]> dixit: >> I have just one suggestion, but it is tightly coupled with my way of >> thinking about this kind of books ;) I think that the perfect place for >> tips and tricks is a wiki and not a book for one main reasons: the wiki >> allows readers to improve the tip/trick and update it when needed. It is >> more "alive" than a book, even if the book is online. For such a mutable >> thing as a tip'n'trick collection for a piece of software, keeping the >> book up to date is difficult, and in a wiki the effort is somewhat >> shared. > > The Tips wiki is wonderful, but I think my approach has merit.
I was not trying to imply the opposite. A book has its advantages (many of them listed by you in your reply), it's only I prefer the wiki approach. > The wiki is a vast collection of often esoteric, terse tips. This is > useful for intermediate/expert users who already have a decent idea of > what they're looking for, but for new users it only furthers the > stereotype that Vim is obscure and difficult to use. And I'm afraid you're right here. I agree, vim suffers from the "way too difficult to learn" stereotype and maybe the wiki contributes to that image, too. > In Vim Recipes I have a far narrower focus, so can expand on solutions > to common problems, presenting them in an optimal fashion. Indeed, by > maintaining a common voice the book can suggest the best solution for > a given problem, rather than the grab-bag approach of the wiki. That > said, I could certainly do a far better job of pointing to relevant > pages on the Tips wiki from the recipes. It can be very useful for people that, after consulting the book, wants to go deeper. I like the idea. > The goal is to publish large quantities of tips copied from others > rather than aiming for a sensible moderated collection that is > generally useful. Yes, I understand your point here. The Vim wiki is vast and having some kind of "frequently used tips" is very useful, specially if well organized and put in (online) book form. > Conversely, the official Vim documentation is refreshingly thorough, > as is befitting a reference work, but that depth makes it unsuitable > for quick study. Yes, you're right. The Vim documentation is great (probably the best software documentation I've ever read) but it is very difficult to find what you need if you are a newbie, even with ":helpgrep". Not very useful if you are in a hurry, want to do something a bit complex and you don't know where to start searching. Your book is useful there, too, although the tips wiki is easy to search, too. > In my experience, books released in wiki form are rarely significantly > expanded from their original remit, and the editor's primary role > becomes reverting spam edits. You are right here: people put themselves in "book mode", where they read but not modify. You rename "wiki" to "book" and everybody stops editing! I've seen many cases of this, and sadly those "wikibooks" revert to a spam trap. > I have made the book's source available in a Git repository, and > indicated my willingness to accept patches/suggestions, by e-mail. The advantage of a wiki here is that edition is a burden shared by many. If you can afford the time to be the editor, the end result is a better source of information, since all of it will pass through your hands. Another advantage is that the text will be more homogeneous, since only one person is writing. As I said, a book have some advantages over a wiki... although I still prefer a wiki ;))) No, really, I have a couple of recipe books (Perl Best Practices, Perl Cookbook, Mastering algorithms in C, the cookbook at ActiveState for Python, etc.) and I use them a lot. I would prefer them to be user-editable, but it's ok if the editor is just one person and he/she updates the book from time to time. I love paper books, not for any rational motive, but for the feeling, but online books, updated from time to time, are much more practical to me. So, while I still would make a wiki and not a book, I know I'm going to use your book ;))) > I also intend to add blog-like comments to each recipe page. I feel > that this is a reasonable compromise, but if the consensus is that a > wiki would make more sense, I'll set it up. I think that, for your aim, the comments are enough, because with them you will spot bugs, improve recipes, etc. without the need to set up a wiki. And more important: if you think that a book and not a wiki is the way to go, don't let people have a consensus for you ;) You do the work, you decide. People will still read your book even if they prefer a wiki. I'm going to use it, that's for sure. > Another benefit of my approach is that I'm able to produce the book in > different formats. I generate PDF and HTML at the moment, and would > like to expand this to ePub, at least. That's another advantage, specially the PDF version, because it allows you to have a local copy of the book in a very proper format to make searches, reading, etc. Have you thought about making the book available for Devhelp? I think it is not a bad idea, but I don't know the kind of effort needed for that :? > Long term I'd like to offer a paperback version, as well, which again > depends on consistent formatting of the source. Paperback versions usually drop to obsolescence fast when they are related to software things, that's why I prefer electronic versions, but usually they sell reasonably well. > I hope this goes some way to explaining why I'm being difficult. ;-) Again, I was not trying to imply that your way was "difficult", it was just different to what I would have *liked*. As for what I would have *done*, that's another matter: I'm very lazy, and probably I would have done an HTML version and not set up a wiki O:))) Again, thanks a lot for your book and thanks for making it free :)) -- Raúl "DervishD" Núñez de Arenas Coronado Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
