possible documentation viewer?

[Sean Wheller]

On Friday 03 June 2005 18:56, Jeff Waugh wrote:
> > I like your points above, but I really would not like every disto based
> > on GNOME to have the same look and feel in the help system :-)
>
> Rhetorical question: Why? That is half the point of doing things
> "upstream".
>
> > I think what Yelp needs is a way for people to create their own custom
> > layer that changes and styles the content for the whole distro.
>
> That's easily done, and no reason to throw the baby out with the bathwater
> by switching to the lowest common denominator.

Am I? 

As I see it CSS does a much better job of formatting. But this is not just 
about formatting. If Yelp can support jscript, forms etc so that we can also 
add interactive functionality it would be a bonus. However, failing such 
support in help I would have to fallback to the common denominator.

My approach is just to side step the upstream when there is resistance that 
saps my energy. Sorry, once bitten twice shy. However, if you and Shaun can 
deliver what we have been talking about then I would definitely have to the 
route of dynamic transformation. It is a hassel having to transform to HTML. 
I don't do it because I think it is the most optimized route, I do it because 
Yelp does not support things that users have asked for or have complained 
about. My concern is the transfer of knowledge to a user, not the technology 
we use. Technology is just an enabler to accessing information in order to 
facilitate knowledge transfer.

Within the content certain functionality like dynamic generation of glossary 
sections is important. It saves authors hours of time. Take for example this 
phrase, "Install a DHCP Server to .... . A DHCP Server is a computer running 
the DHCP ...."

It would be much easier if I could just hyperlink to a glossterm in the first 
sentence "Install a <link>DHCP</link> ... ."

Now imagine how much time that saves over all the terms. Imagine if the terms 
are stored in once place and that glossary sections are automatically 
generated at time of processing. All the author must do is markup terms using 
the glossterm elements and bingo they magically appear in the output doc.

For this purpose I have created http://computerdictionary.tsf.org.za
This is available as a deb package and I am testing it before submitting it 
upstream. But it is now a build dependancy for the Ubuntu/Kubuntu 
Installation Guide.

One of the very unique things here at Ubuntu is that we do have a need to now 
produce docs for both distros. At KDE they just worry about KDE and at GNOME 
they worry about GNOME and each satelite project takes care of itself. Our 
circumstances are different. The intersting thing here is how to develop and 
maintain such a demanding environment. To do this we must step between the 
hail stones, from time-to-time, at least until such time as there is 
inter-operability between desktop help systems and support for the 
functionality authors need in order to facilitate knowledge transfer.

--
Sean Wheller
Technical Author
sean at inwords.co.za
084-854-9408
http://www.inwords.co.za
Registered Linux User #375355
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20050603/1c015701/attachment.pgp>