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