A lot of talk about usability nowadays. Foundation even managed to pick up a sizable grant to try and improve our projects in this regard. I've been arguing that we need better editing tools for a while now, even going so far as to create some of my own tools to try and make things easier for new editors.
I'm a technically inclined person, so I personally don't find wikis too difficult to use. Of course, this is in comparison to some of the other work I've done in the past with HTML and LaTeX markup for documents. I also do a lot of coding work, so symbols and markup and parameters aren't anything new to me. But I'm one of a relatively rare breed of technically saavy people. The vast majorty of people in this world aren't as comfortable with plain-text editors and markup as I am. Hell, the vast majority of people in my family, and at my work, and from my school aren't comfortable with those things either. It's just not the kind of computing that people have been trained to expect.
Wikis are hard. They're hard for the radical conceptual reasons of openness and freedom and collaboration. But they're also hard for the technical reasons: strange and cluttered interface, and the ad hoc markup language. On top of the challenges inherent in MediaWiki, there are the challenges of writing a book, a whole book. It's a lot to deal with, and even if we write all sorts of documentation, it won't be enough. Books are big, they're structured, and they need a particular flow and cohesiveness to them that don't just happen when you click Save page.
Some people won't be able to find the documentation. Some people just wouldn't read it anyway. Nobody is going to read all of it. I haven't even read all of it, and I've personally written a good portion!
We need some form of WYSIWYG, even if it's very simple. There are too many people that just can't or just won't use Wikitext. We need automation, at least at Wikibooks. Books consist of multiple pages, collection pages, table of contents, introductions, and appendices. They have templates too, and categories. We need a button to "Create a book" given a few basic parameters that will create all these kinds of pages automatically and correctly. We need the software to take care of the technical and repetitive work, and leave the authors to do the basic book writing. We need the software to follow the rules, so the contributors don't have to read volumes of documentation just to learn them. If the software just does things the right way, the barrier to entry will be so much lower then it is now. Until we have that, the only people who will be writing books are the technically-saavy editors, a very small subset of the people who we would like to have writing books.
Subscribe to:
Post Comments (Atom)
Don't forget the possibility of building alternate interfaces via the MediaWiki API. For heavily trafficked pages and sites such as Wikipedia it's not a great solution, but for Wikibooks and books which may have few authors and edits, it might work really well.
ReplyDeleteI don't know if this is useful or not, but I tried to increase the ease of creating the quizes on wikinews by using the preload=foo editintro=bar url parameters +lots of templates. (to turn the edit page into something like this). While still a far cry from WYSIWYG editing, perhaps something similar would also be useful on wikibooks.
ReplyDeletepfctdayelise, I have definitely thought about doing that before. Creating a separate interface program would be a really cool possibility. One other aspect of the API is that it should help simplify Javascript-based tools so we can do some cool AJAX editing stuff.
ReplyDeleteBawolff, I've definitely thought about the preload= and editintro= parameters, and been testing them in a few places. It's cool in some cases, but you would need to use a template when creating book links, for instance, and many people won't do that. I've also thought about using them in conjunction with the inputbox extension. See, for instance, the Book Creator tool I put together. It uses a combination of inputbox, editintro= and preload= parameters, parserfunctions, and even some custom Javascript (if you load it) to try and provide a lot of tools and information to potential book developers. It's a start, but you see the kinds of lengths I had to go to, and the kinds of results that I'm able to get from it. I do want to take something like this and make it a global tool (instead of living in my user space), but I haven't had time to do that yet.
Hmm, I guess it all depends on what kind of wikibooks you are thinking of. If you want to help people to write a book stub in 10 minutes instead of an hour, then use WYSIWYG and a "book assistant" or whatever you want to call it.
ReplyDeleteIf the goal is to have great looking, professional textbooks for use at universities, then the way to go is quite obvious to me: allow authors to use LaTeX instead of the wiki markup. TeX has been designed for textbook writing and LaTeX has been designed to help non-technical people, e.g., secretaries, to use TeX. Many academic authors use only LaTeX for scientific writing whether it's articles or textbooks. If you want to get those people on board, you have to adapt to their workflow for scientific writing. And that means LaTeX.
And as there are open source HTML and PDF renderers for LaTeX, the technical challenges of using LaTeX in wikis appear to be quite manageable.
I agree that practically all computer interfaces could have their ease-of-use improved.
ReplyDeleteHowever, I must point out that sometimes switching to WYSIWYG makes wiki harder to write.
@Martin Kraus:
Did you know that
Wikibooks already supports a subset of TeX and LaTeX?
Is that subset already adequate for people familiar with LaTeX, or is there something in particular that is missing?