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