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@g.o mailing list
|
