No Subject

Sun Apr 4 00:39:23 UTC 2010

Hi Phil,

Thank you for your response.

Excerpts from Phil Bull's message of Sun Apr 04 04:40:25 +0530 2010:
> 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.

> 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?
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.

> 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?
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.

> 4. How can documents be maintained and updated, for example when a new
> Ubuntu version is released?
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.

> 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).
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.

> 6. Can you give examples of when a writer should and shouldn't use this
> tool to create a document?
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.

> 7. How will internationalisation and accessibility be addressed?
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.

> 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?
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.

> 9. Why is the project written in C#/Mono? Some distros are averse to
> shipping Mono-dependent apps.
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.

> 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?
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.

I will gladly accept any more feedback, suggestions and questions. The
more I figure things out now, the better I can set the goals and directions
and make something useful.

Thanks,
Anirudh
-- 
Senior Undergraduate Student, Indian Institute of Technology, Kharagpur
http://anirudhsanjeev.org

The Unix philosophy - Do one thing. Do it well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20100404/7cc6ec3a/attachment.pgp>