From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-doc+bounces-954-garchives=archives.gentoo.org@lists.gentoo.org>) id 1JfBmT-0008WS-P0 for garchives@archives.gentoo.org; Fri, 28 Mar 2008 10:25:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ABEB7E09C7; Fri, 28 Mar 2008 10:25:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 63846E09C7; Fri, 28 Mar 2008 10:25:52 +0000 (UTC) Received: from [172.21.4.86] (mnit.ac.in [210.212.97.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E3D2867158; Fri, 28 Mar 2008 10:25:42 +0000 (UTC) Cc: gentoo-soc@lists.gentoo.org Message-Id: <64A6CA67-22CD-4F76-9D64-1AFA90DF04C1@gentoo.org> From: Anant Narayanan <anant@gentoo.org> To: gentoo-doc@lists.gentoo.org In-Reply-To: <b59c1640803271407n7246df9aqca23e64ccce23210@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Precedence: bulk List-Post: <mailto:gentoo-doc@lists.gentoo.org> List-Help: <mailto:gentoo-doc+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-doc+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-doc+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-doc.gentoo.org> X-BeenThere: gentoo-doc@lists.gentoo.org Reply-to: gentoo-doc@lists.gentoo.org Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: [gentoo-doc] Making Beacon Usable Date: Fri, 28 Mar 2008 15:53:42 +0530 References: <b59c1640803271407n7246df9aqca23e64ccce23210@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Archives-Salt: e40da05d-8198-448a-bb49-3955b9771d23 X-Archives-Hash: af494523387a9ef34d8112751a78079d 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