AnirudhSanjeev

Contents

Contact information

Project

Project Name

Tuxtorial - Enhanced workflow and tools for creating, sharing, and consuming knowledge.

https://launchpad.net/tuxtorial

Project Description

Tuxtorial makes it effortless to create and host high-quality tutorials for the Linux Desktop Operating System. A clientside application captures screenshots at key points of a process, allows the tutorial author to add details and annotate, and uploads to the cloud where everyone can view and improve it. Tuxtorial gives the community great tools to share their knowledge on how to use their computers, and also makes all the information available in an easy-to-use centralized, semantic, open format.

The current workflow to create an image supplemented tutorial is cumbersome. Screenshots are captured at key points, saved, opened in external tools, edited one by one, and uploaded painstakingly to FTP or any online image hosting service.And writing documentation comprises of writing markup in HTML/Markdown/Mallard, and inserting the exact URLs of each image, which can prove to be an inefficient and ungratifying experience.

Tuxtorial aims to remove all the non-human components of the workflow - saving, cropping, uploading, and keeping track of URLs and markup are taken care of you, so the author can focus on what truly matters - the content.

The current planned workflow is as follows:

When the user starts Tuxtorial, he/she is optionally prompted to create a new user to restore the default Ubuntu theme, and language. This ensure consistency in appearence. The user then proceeds to do step by step what is to be taught via the tutorial. At each key step, a hotkey is pressed which captures the screen silently, and stores it.

When finished, the user opens up the "Storyboard" where he/she can edit images by means of a few inbuilt specialized tools. The user can add a snippet of text for each screenshot, as an instruction.

This is a mockup of the storyboard:

http://imgur.com/iGDyP.png

Since the data is available in a semantically clean format, it can be converted into HTML, PDF, ODP, etc. Most interestingly, I will support the ability to directly upload the tutorial to tuxtorial.com and is visible by anyone who wishes to learn from this tutorial. It's also a planned feature to allow users to upload directly to their wordpress blogs by the XML-RPC API.

This is a mockup of the tuxtorial.com cloud service: http://imgur.com/KxIgx.png

Clearly, this is a far superior method of creating tutorials, and since all non-human elements of the workflow are eliminated, I'm speculating that less technically skilled people will be able to share their knowledge and upload to the site, which can pass community review, and eventually make it's way into standard documentation systems.

I am not looking to replace yelp, docs on the website, etc. But what I am looking to improve are how tutorials are presented on formats like Forums and blogs. Also I wish to create a single collection of tutorials on the internet making them easier to find and improving the experience of every new linux user.

There is no limit to what can be done to improve the learning material. I am also experimenting with "script" dump files on the terminal, which will allow the user to record his/her terminal activities and annotate them for teaching more advanced/commandline centric activities.

Slides from a talk I gave recently about Tuxtorial are available here: http://www.slideshare.net/prototypeangel/tuxtorial-talk-1-pdf

Which have some more mockups and details.

FAQ

Here are some answers to some questions by Phil Bull on the ubuntu-doc mailing list. I am assuming many people will have the same questions, so I am reposting my response here:

Excerpts from Phil Bull's message of Sun Apr 04 04:40:25 +0530 2010: Question 1. I agree that the tool would make it significantly easier for writers to *create* screenshot walkthroughs, but what benefit will this have to *consumers* of the tutorials? Are there any plans to subject initial versions of the tool's output to usability testing?

Since the tutorials are available in unformatted screenshot/text format, it will be trivial to export them into whatever means the user wishes to view them in - PDF, HTML, etc.

Also, my long term vision is to write a separate application which will be shipped along with Ubuntu which will solely be used for delivery. The user can search for help which will query the updated database and download all the documentation for consumption in an efficient and usable format.

I plan to write to the gnome-usability team and IxDA for their feedback on my initial mockups and outputs when most of my academic work clears out in a couple of weeks.


Question 2. Making documentation tools easier to use can encourage good contributions, but it also makes it easier for inexperienced people to create poor-quality work. You say that "less technically skilled people will be able to share their knowledge"[1], but is it wise for people to take advice from non-experts? How will users be able to find the good-quality tutorials in amongst the low-quality ones which will invariably appear?

Answer : The answer for this is the same that ensures the Wiki model works. All tutorials can be subjected to peer review, commenting functionality will exist, and a user can "fork" the tutorial by downloading the project files and modifying them and re-upload correct version.

In future iterations, I wish to model it after launchpad/github's workflow so that any changes - from trivial mistake correction to translation, etc can be handled.


Question 3. You mention that fragmentation is an issue for open-source documentation [1] (and I completely agree). Won't this project add to the fragmentation issue?

Answer : Well, there is one option which I'm still debating on. I could keep the source code for the backend unreleased for a small duration of time until a critical mass of documentation has been acquired, after which I release the source code, rather than keep the backend development in the open like how the client will be.

Another advantage of this is that since I'm doing this as a full time startup, this will definitely help keep any potential revenue acceptable.

What I am not hoping to see is different distros, communities, languages, etc hosting their own copy of this which makes it eventually harder to find for someone looking for that information.


Question 4. How can documents be maintained and updated, for example when a new Ubuntu version is released?

Answer : I'm afraid I do not have a elegant enough way to deal with this issue. My best guess is to mark out the most popular tutorials and ensure that community members re-create the same steps with minimal change in content, and to do it for all the tutorials - similar to the efforts by the Ubuntu Manual project.


Question 5. I'm assuming from your mockups that tutorials take a strictly linear format. How can the user deal with multiple choices (i.e. branches in the sequence of the tutorial).

Answer : I considered making the system extremely flexible in making the entire tutorial structured like a graph rather than a single line. Even in the initial stages of planning, this proved to be a bad idea and was scrapped. I am confident that after spending a few weeks working on this, and talking to users on what they want, I can implement said functionality without much difficulty.

I am going to focus largely on what the community wants in this case, and direct development in that direction.


Question 6. Can you give examples of when a writer should and shouldn't use this tool to create a document?

Answer : I don't think this is a good tool for writing articles about system administration, server configuration, etc. (although lately I've been experimenting with ways to use the "script" command to record console activity, parse it, annotate it and use it inside this)

This would be a horrible way to write articles on how to use Vim or Emacs. But I am sure it will be unparalleled if one wishes to write a tutorial to do something like this: http://tinyurl.com/ya6l4k9 [article about some photoshop techniques]

In the article I have linked to, imagine if there was only text - you will be asked to click on the "delete layer" button, you might not know which one it is. An image will help you associate what's on your screen with what's there in the tutorial.


Question 7. How will internationalisation and accessibility be addressed?

Answer : I am looking at the option of exporting .po files inside the project model, so users can open it in their favorite editor and modify it and all tools pick up this information.

Also, I am planning to add an option for the users to translate directly on the website. I like launchpad's approach, and might even consider directly trying to integrate with Launchpad when the time comes.

But the entire application will be written with i18n in mind.


Question 8. If a user posts a tutorial to tuxtorial.com, will there be any transfer of rights from the user to the hosting company (i.e. you)? Who will own or have the rights to the material and how will it be licensed?

Answer : The author will own the copyright to the created content. Since the website will allow pdf downloads, and allow others to modify this work, the user can request the work to be licensed under Creative Commons sharealike, or GNU Free Documentation License, etc.

I plan to write to the Ubuntu legal team (if there is one) for help regarding this issue. But rest assured, everything will be done in the spirit of Open Source and Free Software.


Question 9. Why is the project written in C#/Mono? Some distros are averse to shipping Mono-dependent apps.

Answer : I am aware of the unfortunate controversy surrounding Mono. I have written nontrivial applications in most common stacks (GTK-mm, pygtk, qt, pyqt) and found GTK# apps the easiest to write and maintain. Since this won't be _shipped_ with a distro I am assuming it is safe from being excluded.

Also, I contribute code to the MonoDevelop project, and did my GSoC there in 2009. I have a sizeable amount of experience with this stack - from optimizing to packaging to distributing, so this is my interim choice.


Question 10. How will your start-up company generate revenue around this project? Will the viability of the website depend on the success of your start-up?

Answer : Our central theme is to monetize traffic to the website in as ethical ways as possible. The popularity of Linux is growing at an explosive pace, and adopters are constantly looking for ways to use their new operating system.

Even if we have to abandon the start-up if it doesn't work out, all the source will be freely available, and I will gladly transfer control to anybody willing to maintain it.

To recap, I think this could be useful to the Ubuntu Docs, as long as we're careful about applying it in the right situations, and as long as the technical and social issues I've asked about above can be dealt with in a satisfactory manner. It deserves to be developed further. Thank you again for your questions. It made me think about some issues that I hadn't anticipated. If you won't mind, I would like to include some of your questions and my responses as part of my application.

If you would be willing and able to do other projects instead, which ones?

No. I am not willing to do any other project.

Why did you like this idea?

Tuxtorial is the current and sole focus of my Startup company - Ninjagod. I turned down job offers to work on documentation systems as I believe that high quality learning material is the missing link in Desktop Linux. Extreme fragmentation, poor search engine visibility, bad quality of forums, etc, make for a very ungratifying experience. Everyone wants to write code, nobody wants to write learning material, and the situation keeps getting worse.

I feel that I have found the solution to this problem by identifying a pain point and fixing it.

Please describe a tentative project architecture or an approach to it

Client: Written in C#/Mono with GTK for the UI. It serializes the internal representation of the tutorial structure to XML And stores all the images in a subdirectory before and after modification. Each tutorial is saved as a "Project" and can be saved and restored by the client anytime. Since the metadata is stored as text, the tutorial can easily be put on version control as well.

The exporting functionality will be extensible - users will be able to add as many exporters as required. This functionality will be exposed by the Mono.Addins framework.

The client will send data to the server via REST. The content is currently compressed into a single file, and sent as base64 to the server in utf8 encoding. Better transfer mechanisms are being investigated.

Server: The server will be written in Django, with a relational mapper and an extension to implement the REST functionality. The web application is relatively trivial to implement and a basic funcational version has already been built.

Give us details about the milestones for this project

  • Step 1: The tutorial save and restoration engine can serialize and restore stub data. [COMPLETE]
  • Step 2: The client can listen to global keybindings and determine when to take the screenshot [COMPLETE]
  • Step 3: The client saves the metadata and the image into the project directory [COMPLETE]
  • Step 4: Storyboard view fires up after user marks tutorial complete
  • Step 5: Storyboard can display different thumbnails in a scrollable interface. (See mockup)
  • Step 6: Storyboard view shows image and user can enter text
  • Step 7: Storyboard view enables switching of images by thumbnails and the remaining UI is persistent
  • Step 8: Storyboard view hooks into save and restoration mechanism implemented earlier
  • Step 9: Implement functionality to export to HTML using a template engine in a separate utility
  • Step 10: Write in a basic Upload view into the client. Add "Export to HTML" as an option
  • Step 11: Plug in functionality from Step 9.
  • Step 12: Test being able to create a tutorial and export it to HTML.
  • *Milestone 1* Basic functionality.
  • Step 13: Write the REST server in django, to extract metadata and print it to console
  • Step 14: Write small commandline tool to take in a project and upload to REST
  • Step 15: Make sure uploading works and server sees what the commandline tool expects. Write unit tests.
  • Step 16: Implement saving to database in django, when request comes in from client.
  • Step 18: Plug in uploading functionality to the Client. Write test inside client to upload and expect change in database.
  • Step 19: Write a simple view for tutorial in django. the REST request should return a URL which would render this view
  • Step 20: Display and open URL when the tutorial has been uploaded
  • *Milestone 2* Basic cloud functionality.
  • Step 21: Implement a frontpage, displaying latest uploaded tutorials
  • Step 22: Plug in basic search on server
  • Step 23: Other server improvements
  • *Milestone 3* Advanced serverside functionality
  • Step 24: Implement image editor inside client
  • Step 25: Migrate upload mechanism to Mono.Addins.
  • Step 26: Write an upload-to-wordpress plugin and bundle.
  • Step 27: Implement functionality to translate tutorial strings inside client.
  • *Milestone 4* Advanced client functionality

Why will your proposal benefit Ubuntu?

Ubuntu relies on it's vast and colorful community to provide support. While documentation and forums go a long way in answering a few questions, there's only a certain limit to how useful and comprehensive they can be.

By providing the community tools like Tuxtorial to share their wealth of knowledge with the world, I'm confident I can build one of the largest consoldiated knowledge base all licensed under free and open terms.

Open Source

Please describe any previous Open Source development experience

Patchbin

Patchbin is what pastebin is to text. And then some. Upload a patch, and get a link to the patch which shows side by side diffs, code review functionality, line by line commenting, email notification of comments, etc. And all this without any registration/paywall/etc. Patchbin has received a lot of positive feedback and even some community contributions, but is yet to attain critical mass in usage.

Splatter

Splatter is a desktop application for bugzilla and launchpad. Construct complex queries over multiple bugtrackers and various parameters. All the results of the query are tracked in a single interface. Comment on bugs, view details, track unread comments, updates, etc. Unclutter your email inbox from bugtracker messages.

Features:

  • Syncs with bugzilla 3.4 via XML-RPC
  • Read comments on bugs
  • Post comments to bugs
  • Unread comment indicators
  • Sync with multiple bugzilla installations and query them all
  • Improved support for query constraints fetching from the bugzilla installatino
  • Everything is synced to disk, so even if the app closes, all your bugs don't.
  • Query by name, product, importance, status, summary, comments, etc.
  • Create multiple queries that are refreshed periodically

Patchbin is currently in active development.

TaskForce

This is my largest project till date, still in active development. Built as part of the Google Summer of Code 2009 with the Mono Project, this tool brings Task-oriented programming into the Monodevelop IDE for Linux. The Splatter tool mentioned above is an offshoot of TaskForce which will be merged back in.

It's hard to describe the tool's exact functionality. In short it allows you to specify the task that you're working on, and tracks the "context" of that task. It then modifies the IDE functionality, code completion, etc to streamline itself for the current task. Tasks are loaded from the external bugtracker.

CodeLibrary

It's a standalone app and a Monodevelop addin to allow developers to share small snippets of code on the fly. It is loosely based on Acire - the python snippet collection, but enables uploading snippets directly from inside the IDE, and searching snippets in fulltext and synchronization with cloud services. The source for this hasn't been pushed to a public source host yet, but will be as soon as the GSoC application season gets over.

OneClick

My first FOSS contribution was a small WordPress plugin to solve a major pain point - Installing plugins and themes. Back in 2007, people had to use FTP to upload scripts. I wrote something to automate this procedure, and people loved it. Over 80,000 used Oneclick and many still do.

Oneclick was abandoned and taken up by another maintainer. The plugin was officially deprecated since Wordpress 2.7 when the same functionality came as part of the WordPress core.

Oneclick won the 2007 WLTC Plugin development competition

License: GPL

Others

Some other smaller projects which I've written over time:

Why are you interested in Open Source?

While I will fight for my freedom, rights and privacy, I prefer open source for it's technical merits. The idea of peer reviewed work, which began as labor of love strongly appeals to me. I am very turned off by consumerism, greed and the endless pursuit of fiscal joy. To see so many individuals spend their precious free time doing so much work to help the community - through software - is inspiring to say the least.

Every time I see people helping others with their problems, no matter how simple they might be, it reinvigorates my faith in humanity. This kind of mentality is one I feel, and I can't find much in my elite engineering university.

Also it's an operating system built by hackers, and thus is very friendly to hackers like me. My command line, text editor and operating system are no longer tools - they are like limbs now. I no longer have a choice - I'm forced to use these tools, and forced to contribute back and improve them. Because I won't have it any other way.

//TODO: Make this less cheesy

Availability

How long will the project take? When can you begin?

I want to focus on putting out a stable production quality tool by August 2010, in order to help in efforts for Ubuntu 10.10 (Magic Monkey?).

Work is actually underway right now, and has been for about a month.

How much time do you expect to dedicate to this project? (weekly)

30 - 40 hours.

Where will you based during the summer?

Bangalore, India (GMT +0530)

Do you have any commitments for the summer? (holidays/work/summer courses)

None. Light travel inbetween.

Please designate a back up student (in case you need to withdraw your application)

I designate my friend, Nikhil Sarda if I have to withdraw my application: email: diff.operator at gmail.com IRC nickname: diff

Other

Have you ever participated in a previous GSoC? (describe your project)

Yes. I worked with the Mono Project in 2009 launching a huge effort to bring Task based programming into the MonoDevelop IDE. The project was completed, but not merged into the tree as it's large and still needs more work. The project is still actively being developed.

Have you applied for any other 2010 Summer of Code projects? If yes, which ones?

None.

Why did you apply for the Google Summer of Code ?

This project is actually part of my Startup company, and will continue to do it regardless of the outcome of the Google Summer of Code selection. The trouble is that I'm in India and seed funding for small open source companies are extremely hard to come by. The monetary benefits will definitely go a long way in helping us take our small company off the ground.

Also, doing this will improve visibility. My project suffers from a Catch 22 which implies it won't be useful unless it's popular and it won't be popular unless it's useful. Some publicity via community members will go a long way.

Why did you choose Ubuntu as a mentoring organisation?

I have been using Ubuntu since early 2007. I share Ubuntu's vision of providing something that's supporting the four freedoms, and also focusses on making it accessible to new and inexperienced users. My initial experiences with linux were harsh, but after discovering Ubuntu, it was slightly improved and has gone uphill ever since.

The real reason I like Ubuntu is because of the very pragmatic, helpful and friendly community. I like being part of something bigger, and like the concept of meeting many wonderful people through this community. I need guidance on how to work with the community. While I can write a little bit of code, I am unsure about how to approach people and grow around my tool. I am reading Jono Bacon's "The art of Community" and learning a lot, but I could really use the support and help of the Ubuntu community to take my project off the ground.

Another reason why I want to participate is to fully explore the degree and depth of the Ubuntu project. What I initally thought was a remastered distro from Debian is actually a humongous tight engineering effort by several people. I originally thought of Launchpad to be a code host and bug tracker, but found it to be much much more, and am discovering new things everyday.

Why do you want to participate and why should Ubuntu choose you?

I wish to participate for the following reasons:

  • I work extremely well under pressure, and will be able to accomplish a
    • lot more if the entire community is watching what I do.
  • The financial support, along with the money saved from my previous GSoC
    • will help bootstrap my open source startup and go a long way in providing for rent, living expenses, etc.
  • I wish to use this as a networking opportunity, and meet new people and
    • make wonderful new professional and personal connections.

Ubuntu should pick me because:

  • I am a self taught programmer. I've never had a single computer science
    • course in my life, but everything I've done is out of passion. I hope I've made my passion about fixing the knowledge sharing problem evident.
  • I will end up becoming a long term contributor. I still actively
    • contribute to the project I did my 2009 GSoC with.
  • I have a gift for seeing pain points, which sometimes borders on the
    • compulsive. I have many fascinating ideas which I'm sure will go a long way in helping make Ubuntu the best desktop experience there is.

GSoC/2010/AnirudhSanjeev (last edited 2010-04-10 18:07:44 by 203)