Hi Nandeep,
This is regarding the possible GSoC project about "Making Beacon
Usable". I wanted to work with the doc folks directly on this one so
I can include in my proposal the most wanted feature add-ons/
improvements.
Since Beacon isn't widely used currently I was having trouble
finding people acquainted with it. So calling out to all Doc people,
what can be done to help Beacon float further?
Thanks for your interest in the project! Although Beacon allows for
basic GuideXML editing, there is a lot that can be done in the
usability aspect. Beacon isn't really used by any documentation folks,
which defeats the purpose of the tool - hence the main focus this
summer would be to analyze the areas in which Beacon could be
improved, and implement them.
Some points off the top of my head:
a) UI Spruce-up: Make it easier to edit specific portions of the
document. Currently there is DOM tree displayed in the bottom-left,
some enhancement can be made to it, so that a user can jump to any
portion in the document and make a quick change.
b) Replace text-boxes with a Rich Text Editor: Currently, tags like
<p>, <b> and <e> have to be manually added by documentation writers,
as the XML inside a <body> is displayed verbatim in a text-box. This
text-box can be ideally replaced by rich-text editor like MoxieCode,
TinyMCE or FCKEditor - which would have to be modified to understand
GuideXML tags allowed inside <body>
c) Make it easy to author new documents: Editing an existing document
is certainly a lot easier than creating a new one in beacon; the
primary reason being that adding new sections and block-level tags is
not really very easy. Currently, we use a drag-and-drop approach, but
it's not very easy to visualize where you're actually dropping the new
element. This aspect could do with a complete overhaul.
d) Easier Deployment: Another reason why beacon isn't used widely is
because it hasn't been deployed for public use. We need to make some
changes in the back-end to make sure it can be deployed with minimum
fuss - see next point.
e) Back-end changes: Currently beacon uses two temporary files - one
for the actual XML and one for the displayed HTML, per GuideXML file
being edited. This approach requires a web-server writeable directory,
which makes it a little cumbersome to deploy. Also, someone had
discovered a security vulnerability with this (which has been fixed
since); it's probably worthwhile to take a second look and probably
rewrite this portion.
f) Support for collaborative editing: Most documentation is written by
a group of people, so it would be neat if beacon could store the
document centrally and allow multiple people to collaboratively work
on it. Google Docs is a good inspiration here, we could throw in
authentication against Gentoo's LDAP server too
All of this is probably not achievable in a single summer, so you
could probably pick out a few ideas and send in your proposal - I'll
be glad to mentor the project. You would need to know PHP, Javascript,
some AJAX concepts and familiarity with XML and XSLT beforehand,
however, if you don't - we can use the community bonding period to get
you upto speed!
All the best, and I look forward to reviewing your proposal.
Cheers,
Anant
--
gentoo-doc@lists.gentoo.org mailing list
Making Beacon Usable
