Two weeks ago I was at the Conference of Australian Linux Users and I
wrote "LyX Developer" on the bottom of my name badge to see what
responses I got. I got plenty and they were all very favourable and
encouraging. "LyX is cool!" was probably the most popular response.
About 80% of the people I spoke to had used or were using LyX and almost
everyone else had at least heard of LyX.
On the last day I decided to run a LyX BOF and to actively gather some
user feedback as well as test the water for some of our planned changes
(gui-indep in particular). What follows is a summary of the BOF and
other conversations during the conference. Some of these things we
already have planned but I think its still important to include them in
this list of user-derived comments. There were 12 people at the BOF
besides me -- 8 hadn't heard of LyX before the conference. All up I
spoke at length to at least 30 people about LyX and many more
interrupted conversations to offer "LyX is cool!" type comments.
General Feedback
================
* LyX is cool
* Users love our philosophy of enforcing styles and concentrating on
content
Most Annoying Features
======================
* Tables that get wider than the window and can't be editted easily
- this was in fact the only major complaint I got and everyone
had experienced it.
* File transfer/interchange of documents with pictures
- The difficulty of sharing documents with others.
In particular ensuring that all the relevent files are
bundled together. All the people with this complaint
resorted to storing each new document in its own subdirectory
to ease the bundling process. Some of these people suggested
embedding the images into the .lyx file while others would be
happy with an automated tarring and untarring facility.
* Collapsing spaces when deleting a selection.
- Although everyone rapidly learned the workaround of inserting
a new space. Thus its really only a new user complaint as
everyone learns this LyXism and adapts to it. We do need to
fix it in the next major release though.
Requests
========
* A list of all supported packages and classes be made available on the
web site.
- this could probably just be a repackaging of LaTeXConfig.lyx
- the main concern here was wanting to know what we do support
natively in LyX so newcomers could see what was available.
* HTML export of LaTeX documents.
* Table width and column width settings
- tabularx support would be very nice
- some visual feedback as to which columns/tables have fixed
widths -- no suggestions though.
* Pictures in any graphic format
- ability to use gifs, jpegs etc
- display onscreen and have LyX do whatever extra processing
(conversion etc.) that is required to get those images into
the exported document format.
- someone suggested using MIME types to manage both the
processing required and the possibility of double-clicking
to start an appropriate image editor (eg. the GIMP).
* .layout file creation/management tools
- a LaTeX-to-layout parser would be ideal
- otherwise a GUI tool for maintaining layout files. The
description of this tool was essentially a generalised
version of Martins Tcl/tk tool for use with his neoprene.cls
* Multipart document [MPD] support should ensure correct use of \input
and \include. TOC support for MPDs with the same hypertext style
traversal across file boundaries.
- there were also calls for some semi-automated way to split
an existing document into multiple parts. An automated
"split-document-into-one-file-per-chapter" facility would
be a good first step. Many thought this facility should be
driven from the TOC popup (doesn't kLyX do something like
this?)
* Extended version control support
- highlighting of changes between revisions and other niceties
- Support for other version control packages -- mostly CVS.
We should probably look at modularising this support since there are
so many version control systems around and everyone has their personal
favourite. VC-independence through a VC-manager similar to the
spell-checker manager perhaps?
Feedback on our Future Directions
=================================
* System/GUI independence received praise from everyone (GNOME, KDE or
otherwise). The suggestion of a curses port also got some interest:
"Wow, excellent!" A number of people also felt a Windows port would
be very useful because they could then promote LyX as a
cross-platform editting standard within their University department
or company.
* Unicode is seen as a good and bad thing. Everyone wants a compile
time option to disable it although there were a few who'd use it.
However everyone agreed there is a need for Unicode.
* SGML/XML output using jade as an alternative to sgmltools
* Be able to handle documents of 300-400 pages or more in a single
file without crashing like Word does
* XML file format to replace .lyx format. Some people suggested using
libxml for this. I'd suggest we could move lyxrc to XML as a first
test because with a lyxrc DTD we'd have config file validity testing
for free using any validating parser. It could also make creating
the Preferences popup and handling easier. libxml is very low level
and is still evolving.
* The idea of a scripting language received reasonable support although
quite a few were worried about the possibility of macro-viruses.
I've been thinking a bit about the applications of scripting
languages in LyX while writing this up and can see the greatest
benefit in things like version control independence and spell-checker
independence since we can have a generalised manager class that uses
scripts to implement the different services.
Many felt that scripts weren't needed in documents but the option of
extending LyX arbitrarily without having to recompile and reinstall
was a very good future direction.
Other Comments or Concerns
==========================
There was some concern about GNOMEs libart extensions to onscreen text
kerning and direct output to Postscript from their printer modules. As
I understand it, libart is an antialiased canvas that can render
onscreen or direct to a printer (Postscript or otherwise) through a
separate driver. This ability and the drivers are apparently all
independent of Ghostscript (reinventing the wheel?) but are based on the
algorithms in TeX (I don't know if they are reusing/reengineering the
code from TeX or not). There are also other major changes being made in
the GNOME font engine/s and a couple of users were concerned that this
may affect either our GNOME port or LyX in general.
I'd say the GNOME port would be able to utilise the libart antialiased
canvas for the Painter implementation okay but as we don't WYSIWYG our
screen I doubt we could utilise the export-to-printer facilities offered
by libart. But then I don't know much about libart's reimplemented TeX
algorithms either -- I suspect its text placement only on a given line
and not figure or table placement.
There were one or two comments about template files although these were
mainly just bad storys about Word templates. Everyone seemed happy with
the very simple document skeleton arrangement we use for templates.
Noone thought semi-automated wizard templates were a necessity
(especially since it'd probably mean macros in documents).
--
Allan. (ARRae)
