Talk:WikiConference India 2011/Submissions/Accelerating WikiBooks

WIKIMANIA CONFERENCE INDIA 2011

[2011]

Accelerating Wikibooks

Dharav Solanki

BT08B046@SMAIL.IITM.AC.IN, THEWINSTER ON WIKIBOOKS

�

Prototype Faster

Premise

We have a wealth of resources available which bears the Creative Commons license. In fact, the most sizable repository of such knowledge is Wikipedia itself. Yet somehow we fail to translate this vast amount of information into teaching resources on Wikibooks.

One might intuitively explain this apathy of Wikibooks citing the amount of expertise needed in creating the textbook as well as the demotivating sight of the textbook with empty sections (at a time when most of the effort is concentrated on trivial issues on a single section.).

Of course, we all agree on the proposition that textbooks are more than just a collection of facts. But the statement itself implies that at the minimum textbooks are supposed to introduce its readers to a certain amount of facts necessary to gain familiarity with the subject they are dealing with. When we look at textbooks from these two perspectives, we can devise a method which allows us to make constant progress without being demotivated and set the foundations for a useful and accessible textbook.

In this section, I present how this situation can be dealt with by using the paradigm of prototyping as fast as possible. “Prototype faster” as Guy Kawasaki puts it, or “Create once, iterate constantly” as Google says or “Move Faster” as Zuckerberg describes the same ideology, is a very practical paradigm. It creates meaning out of what we already know. The prototype doesn’t have to be immediately useful, the purpose of it is

• To enhance our own idea of what we want it to be.
• To gain familiarity with the tools (in our case, Wiki Markup, Best Practices, Commons, Latex, Formatting, Templates and so on)
• And specially applicable to the case of Wikibooks : Involve and engage other contributors in our cause.

Existing Knowledge

Facts

Wikipedia is a large repository of information and in many cases, exhaustive articles. The present methodology of using Wikipedia articles is to list them up for importing and then later on embed them in their respective places.

What we do not know for a fact is the number of Wikipedia articles that have been imported and then used as a foundation for creating textbooks. Are most completed Textbooks works that have been built from ground zero?

� There are a lot of courses available on the internet by Podcasters (PatrickJMT? FreelanceTeach?), Non profits like the Khan Academy and Universities like MIT. In many cases, these are exhaustive / sufficient for gaining a grip over a particular subject.

Problems

Building up on the text of Wikipedia is somehow inefficient. First of all, it requires an import which requires a request.

Secondly, when importing from Wikipedia, we do not have the option of selecting just the right text that is suitable for the purpose of the textbook.

Thirdly, when importing from Wikipedia. Authors are less likely to have defined the kind of information that they require. For instance, a textbook on Physics can be started with importing articles on Newton’s Laws of Motion. However, this text can be overwhelming to an author. At the same time, the author might not have completely defined his own target audience, level of depth and an exact list of concepts/topics/problems that he wants to cover.

Ideas

1) Importing from Wikipedia

As of now, we have identified two distinct problems. First is that importing articles or information from Wikipedia is cumbersome. The second is that the author is less likely to be aware of the exact information that he wants to use in his textbook.

One approach to solve the first problem is to design a new interface specific to an extension developed specifically for importing text from Wikipedia onto Wikibooks. The purpose of this interface is to streamline copying of text from Wikipedia onto Wikibooks.

The interface can be described as to cascaded windows, either window (or frame of the browser) representing the textbook and the relevant article respectively.

We have defined the interface. Now we define its usage. The author scans the Wikipedia article, and keeping in mind the outline that he has made on the Wikibooks section, he selects text within the article. All relevant information is automatically copied onto the Wikibook page. This can have a multitude of features, like if the author selects text from a particular section, the interface automatically creates that section on the Wikibooks itself. This facilitates organizing the information that has been copied. This will also facilitate the subsequent editing of the text.

Problems with the above approach

�

I personally cannot foresee any fundamental problem with the approach. However, its implementation might bring about certain problems which can deter the interest of the community in implementing such a system.

However, it has to be kept in mind that this is not a rigid suggestion. What I have suggested here is merely a streamlined method of copying from Wikipedia onto Wikibooks. Having such an interface also allows you to selectively import text and at the same time give credit to the previous editors.

I emphasize here that any alternative approach which can facilitate such a transfer of information in a speedy and on-demand method will do the needful.

2) Importing from other Creative Commons Media

At present a large selection of courses are available in the form of video lectures. Such video lectures or a subset of a larger repository of creative Commons media.

A mere transcription of the video lectures mentioned can act as a very good primer or study guide of the concerned topic.

Moreover, once transcripts or lecture notes of such video lectures are put forward on Wikibooks, we have in place a fully functional textbook. Such a textbook can then be expanded upon by different authors and be specialized for students of different curricula.

If a lecture merely introduces a particular concept, the power of massive collaboration ensures that relevant information can be added on to the textbook. If a particular lecture merely walks through a topic, Wikibooks has the power to operate more on each of the concept involved and make a more meaningful text which encompasses each of the main ideas discussed.

A lot of Wikipedia articles serve as an example of an exhaustive treatment of the subject in question and an analysis of all the areas involved. However, such articles or sections are a rarity on Wikibooks. One might attribute this state of affairs to the fact that information appears on Wikipedia and then is organized into “meaning” by contributors who have something to contribute. On the contrary, on Wikibooks the process rarely goes ahead of collecting information.

Summary

As of now, several ideas have been discussed.

1. We already have a vast resource available that can serve as a platform to jumpstart the development of most textbooks. 2. It has been proposed that most textbooks do not develop because a lot of effort is directionless. 3. A new interface for copying from Wikipedia onto Wikibooks has been suggested. However, the purpose that is served is more important. This purpose is to first define an outline of facts, topics, concepts and discussions to be included in the textbook and then importing only relevant information from Wikipedia onto the respective sections of the textbook. 4. It has also been suggested that video lectures available under the creative Commons license can be of an immense value in the form of consolidated and functional textbooks which can then be developed in different directions. 5. The process of outlining a textbook will be described in the section “Developing the process : A “Wicked Start” Approach”

What next after the information has been copied?

Annotatons

Or simply put: discussions. However, most Wikipedians and Wikibookians will agree that the Talk:Module page corresponding to any article remains underutilized.

Problems with the Talk Page

This can be attributed to a negative Network Effect. Initially, a few users would use the Discussion page. In an ideal world, this usage should have an upward spiral. However, this does not happen because a majority of the users do not visit the Talk Page.

So, more people would use the Talk Page if it were more useful. But the Talk pages would be more useful if they had been used by more people to begin with. However, they do not provide any intrinsic value in the beginning. Hence such a negative feedback loop, or apathy, continues.

Such negative feedback loops can be broken easily with an external intervention.

Breaking the negative feedback loop.

I have seen certain features on Wikiversity that allow text to be cross posted on two pages and synchronized. The point is that, this functionality can be used to design an intervention.

On every embryonic textbook, have a sidebar on the side of every section. The functionality of this sidebar is to facilitate annotations, suggestions, problems and other direct inputs on the particular section. The most essential feature of this sidebar is to show recent discussions on the box, and to archive all inputs on the Discussion page, which can be discussed by the more enthusiastic volunteers.

However, a very desirable feature of this sidebar should be allowing a visitor to directly input his thoughts. This is akin to shoutboxes of the yore. �

One more desirable feature of this sidebar could be to ask several important questions to which a particular user can answer. Some examples could be “What is the one concept that you feel can be added here?”, “What is the one topic that has not been discussed properly here?” and so on. This could function not only as a review system, but the continuous suggestions and inputs by Wikibookians and visitors arriving from Google can go a long way in boosting the morale of the Author or the team of authors or community, if it is working on its entirety.

Customized Questionnaires

Customized questionnaires are not very different from what has been discussed above. However, the previous section dealt with the sidebar. This section is an independent method, which asks a visitor/volunteer a series of questions, which can help in building up Inputs, (repeat, input and NOT suggestions. Inputs are new pieces of information, concepts or discussions that can contribute directly to the building up of a textbook, in contrast to suggestions which merely end up being a possible approach that might be taken and most probably will not be taken.).

Possible questions could be,

• In the coverage of the topic, have you come across a popular misconception? What is wrong with that misconception? What is a more accurate treatment?
• The section mentions the use of Calculus to solve an optimization problem. However, is there an alternate approach possible? Describe it.

The beauty of such customized questionnaires is that it instantly taps into the knowledge of other users and gives them direction to make an external copy of what they know onto Wikibooks. For example, normally an alternate approach or a misconception might have been lying unnoticed on the Talk page. Now we have a whole new approach where it becomes mandatory to get in touch with the questionnaires answered by other Wikibookians or visitors. The author has more inputs that he can process.

The type of questions and the place of these questionnaires in the Media Wiki interface is something that I leave unto the Wikimedia Community.

A summary of what is to come

Getting the information in place is only one part of the picture.

It was touched in minor detail that copying of information would be much more useful if an outline is developed initially. The next section delves deeper into the problem of making roadmaps itself and puts across a few suggestions.

Developing the process: A “Wicked Start Approach”

Premise

Developing a roadmap for a textbook is a good approach, but rarely realized. However, the more general problem of “developing a roadmap” for any particular venture can be facilitated by something as simple as a checklist.

Making an outline of a textbook, although complicated in itself for an expert, is perhaps not so much as developing a Business Plan. The point here is not a comparison of the efforts put in by their respective authors, but a reminder of the fact that the latter has been simplified by a walkthrough/wizard/checklist approach in software like Business Plan Pro and Services like “Wicked Start”.

The one thing we can learn from here is that Starting Up a Book can involve the same secondary level of planning as that in a Business Plan, where in businesses have to identify resources, the market and other such details which are external to the core product/service. For Wikibookians, these might correspond to outreach campaigns, inviting collaborators and so on.

The one immediate resistance to this approach is that it does not allow a project to be straightforward. It adds a layer of complication. However, there is a simple workaround for this challenge. First, allow books to be started just as they are and keep the Wizard Optional. Second, finishing up the wizard checklist has to be designed not in a manner which enforces certain constraints upon the contributors but rather allows them to dissect the situation as much as possible.

In other words, the purpose of the Wizard and the checklist is to convey the seriousness of the work to contributors, and more importantly, design their contributions with this awareness. So, we gain two things: simplicity and a deeper involvement.

Checklists

This can be a central aspect of the “Wicked Start Approach”, wherein an author or the community which wants to start a project can identify certain milestones, referred to as elements here which can better help us make a Road Map. These Milestones are divided into Vital, Essential and Desirable and is a popular management/planning tool. The best thing about it is that it is not contrived, but is rather very simple and straightforward to be used.

Before discussing the outlining of Vital, Essential and Desirable elements, it has to be kept in mind that the nature of the elements or their attributes depends on the purpose defined. For example, Sidebars and case studies could be desirable if the purpose of the textbook is to be a free text on the subject. However, if the purpose of the textbook is to be an accessible, enjoyable read, then “Desirable” elements in the former case become “Essential” in the latter.

Vital

Once a purpose is defined, “Vital” elements correspond to those elements which give it an identity. The usability/accessibility is not considered.

For example, a refill with a ball point pen is vital for a ball point pen, even though we might not want to use a ballpoint pen that has no external body that supports writing.

Hence, Vital Elements can correspond to identifying a list of chapters and topics to be presented in each chapter. Once these are done, a barebones textbook can be made straightaway by copying from Wikipedia.

Other vital elements can be identified once this approach has been taken by a few projects and the discussions on the particular project reveal how the progress could have been better.

Essential

The essential elements are those which make the project usable without much adjustment on the part of the user.

One simple category of “essential” elements/tasks is making a text around the topics, or writing a proper section by embedding all segregated topics.

Desirable

The “desirable” elements are those which make the Project more useful or valuable. For example, “At a Glance” sections, or “Tips”, or a case study of a particular problem.

The project can serve its core purpose without the Desirable elements, but only gets better once these elements are added.

Persuasive Design

Eliminate Learning Curve

Or rather help in it.

It is a big value in the Wikimedia Foundation projects is to be open and explore and experiment.

However, what does excessive information and less work done result in? Lesser grasp over the subject, in our case – familiarity with contributing on Wikipedia is compromised.

Have you ever observed how Facebook introduces it’s users to its interface? It guides them through everything. And it gets them started. And it treats every user differently based on how much they have used Facebook and how farther off they are with their profile.

� How do we implement such a system with Mediawiki? We do not need an overhaul. All we need is masking of the interface and better use of the user’s personal dashboard. We do have a lot of cross posting functionalities and RSS feeds, which might be helpful in customizing the user’s personal page – and making it a dashboard from where a person can then explore better.

Such feeds can be Tasks, Tips, Updates and new edits and perhaps News.

Fascilitate Contributions

What can someone who has stumbled across a project contribute in 5 minutes? Discussions: crosslink on every section and every section has a discussion page ala Tickler on Facebook.

Tasks, as a template below and as a separate page/module ala Discussions/Talks.

Suck people in the culture

Let small contributions build up, see how it progresses, inform people what is happening. See where their contributions land up.

The satisfaction should not be limited to people being able to watch their contribution online. What happens with it over time? Over time, it does NOT even get edited! At least, that’s the present scenario. The whole idea of building up an ecosystem around the book is to let the book development move faster.

Crowd sourcing

Tasks

Wikipedia epitomizes crowdsourcing. Does Wikibooks do it? That is where we lack. We miss out on our own USP : crowdsourcing. The very definition of having a crowdsourcing economy is Wikinomics : and ironically we at Wikibooks fail to keep it at decent crowdsourcing levels.

We have to learn from Wikipedia and we have to learn from MicroTasks. We might even have to learn from Amazon Mechanical Turk. However, the creation of repetitive tasks is not what we are after. We are after value : and if “Mini”Tasks suit us then so be it.

Such tasks can be of a variety, they can serve a definite purpose or they might be open ended. For example, building up discussions and organizing debates around current topics, keeping in mind a discussion of the fundamentals can help us generate good examples for topics, as well as case studies. All we have to do is encourage Wikibookians to have open debates at social media places.

I personally discuss a lot of topics with my friends either on G+ on FB and have saved those discussion, with their permission, to make blog posts out of them. How we end up crowdsourcing such a functionality, is a topic I’ll leave for the community to discuss. The one immediate benefit is that people are OPEN to discussion and have LOADS of opinions always. This is much unlike contributing to a project which requires knowledge work.

However, open debates and discussion on new media that pours in is just one avenue. And it is not even crowdsourcing to be precise. What it does end up doing is generating invaluable amount of information and analysis for a particular topic.

Some tasks have been described below and perhaps suitable mechanisms that are streamlined and effective can be designed around them.

• Scavenging
• Cleaning Up
• Editing
• Identifying important topics, facts
• Quality Control
• Proofreading
• Feedback
• Quality Creation
• Turn discussions into actionable items or reference items. If nothing can happen, archive/discard them.

�==== Layers ====

Our traditional understanding of the media wiki software is to have an open to all policy. This in principle is good, but needs some tinkering with in order to make it useful for creating books at a good pace.

The initial proposition in which to perspectives was suggested for looking at the textbook can be used to understand this proposition.

One perspective was to look at the textbook as a whole some work while the other suggested that the textbook and at the same time be looked upon as a collection of facts.

This suggests to us that textbooks need not be made by one single author. From practical experience as well, we can conclude that one textbook requires involvement from multiple dozens of people.

The present position is that the Wikibooks interface and functionalities should be designed keeping in mind that both casual contributors as well as authors who have taken up the cause of creating a good textbook will contribute to it.

A simple division of labor here is that relatively minor but important tasks can be listed out which can be taken up by casual volunteers or even authors if they wish to. However, maintaining the integrity of the textbook is a task that can be left upon the authors.

“Open up, Create Systematic Chaos, Make Meaning”

1. “Open Up” corresponded to crowdsourcing. 2. “Creating Systematic Chaos” relates to meaningful, but discrete contributions by volunteers, which could either be a simple suggestion/annotation/questionnaire or a more meaningful and familiar contribution in the form of Media Upload or a completed section. 3. “Make Meaning” refers to the more dedication-intensive task of coming up with a textbook that matches professional standards.

We have covered the first part, “Open Up” in Crowdsourcing. Now we cover “Creating Systematic Chaos” and “Making Meaning”

Volunteers and authors

Refraining from going into the nuances or excessive details, volunteers will maintain the development of the textbook.

Overseeing the addition of new material, seeing that a particular task has been fulfilled or not and all variations of simple tasks that were outlined earlier will be covered by the volunteers. �

It has to be noted that there is no authoritative/merit based demarcation of the roles of volunteers and authors.

The entire concept of using this division of labor is simply a way to put forward the idea that the development of a textbook requires both higher order thinking and finishing off minor, trivial items. The tedious context switching can become turn off for contributors. When the development process is outlined in such a manner, it become much easier for a person to assume a role suitable to him.

Such a categorization is simply a case of letting people focus on their core competencies. It is much easier for experts to make sense out of chaos rather than to take up a project from scratch. Expecting to achieve a large number by trying to constantly multiply zero with some other number is futile. However, in the same analogy, the contribution of the volunteers can be likened to a sum which grows every time a task is completed, and the contribution of the authors can be likened to raising that sum with an index greater than one.

The important part of the analogy is that the resultant number won’t be large if it is not raised by a good index. It will also not be large if the base itself was not large enough to begin with.

Outcome based Thinking

Define outcomes, associate tasks

It becomes much easier to stay motivated when we finish a project, as small as possible.

This paradigm is external to the above specified modus operandi of Wikibooks. Unlike making changes to Mediawiki software and designing the interface, this section deals with how users should think while working on a project.

Perhaps, this could become a common policy or at least a guideline on the Wikibooks community.

Coming back to the topic, a contributor can define an outcome. Such outcomes could be finishing up a particular section of the textbook, making images or charts and diagrams for a particular section or even finishing up with the chapter summary.

What is important here is that each outcome has several tasks associated with it. Not only does this help in achieving an outcome, it also helps in moving through the to do list that has been generated by the entire community. If you think about it, there is multiple motivation here. First of all, you are taking several items off the to- do list and at the same time you are making concrete progress on the textbook.

Summing it up, during the formation of the book and its development, several tasks might have been suggested. Each task on its own might not be able to make anything meaningful for an average Joe. However when a country to focuses on an outcome, immediately picks up all the associated tasks and finishes it. Hence, we have taken our do what you like community and added just the right amount of systematic work to it.

Do, Review, Make it better

All of us have been taught the importance of learning from mistakes right from a childhood. However, it does not always show up in all of our work.

Do, review, make it better is an approach which learns from our experience. However, more often than not this process is not deliberate.

The advantage in making this process deliberate is that we create new practices that can see through the community so that what is innovation for now becomes common sense for contributors to or three years down the line.

One must understand that this approach is valid for and in fact, most useful for, trivial actions. These could be making an image, creating summaries, internalizing trivia sections.

More uses and context of these systems will come to light when these are actually used.

Kicking off the two systems

As much as these will serve the community when they become an integral part of the process, we could start off with users maintaining logs of “Do, Review, Make It Better” on the Talk Pages of appropriate sections. Associating Outcomes to Task can be done by a page where each section corresponds to an outcome and its contents correspond to the task.

However, the system will become more beneficial when the completion of tasks, achievement of outcomes, and amount of progress made and review logs generated cease to be texts and become objects upon which operations could be performed.

For example, an RSS feed of tasks could help in retaining interested contributors. A progress chart can be a very good motivator for everyone.

The review logs, instead of being maintained on a secluded area, could become opt-in widgets where you enter your thoughts and all of this is embedded into a separate easy to browse, and learn section. �