On Tue, Mar 22, 2011 at 11:51 PM, Rob Oakes <lyx-de...@oak-tree.us> wrote:
> While I have some ideas about why it may have happened, I think that Pavel 
> hit the nail on the head. When I talk to people about LyX, they seem to think 
> of it as a specialized academic writing tool. Basically, a program which 
> helps professors and students write a thesis or articles. (To be even more 
> narrow, it seems like many think it is for math and physics people to write a 
> thesis or article.) Which is to say, a specialized program with an incredibly 
> small user base and use.
> While that stereotype may be somewhat true (I don't think anyone would argue 
> that many of the developers and users are within academics), it significantly 
> understates LyX's appeal, especially if you consider the enhancements 
> available in the

To the extent that the stereotype is true, it may also be worth
considering what the reasons are for this, and if it is reasonable to
remove those reasons. Off-the-top of my head the following could be

1) Compile Errors. Normal users aren't used to dealing with compile
errors and shouldn't be expected to fix them. Even I don't like
dealing with compile errors all that much.
1a) Perhaps we could do some sort of bisect to determine where the
error is (either over the file itself or some fine-grained history).
1b) Perhaps we could improve the latex export so that compile errors
only occur if the user uses ERT. Particularly with beamer, this isn't
always the case.

2) Compatibility with Word. Typical users expect to be able to open
and save word documents.
2a) It is easy to bundle import/export filters so that the users don't
have to manually set up OOXML and ODF. This export wouldn't work as
well as e.g. OOXML <-> ODF though. One concern is that it may lead the
user to think this conversion is more supported than it really is.
2b) Normal users probably expect rich text paste as well. I usually
prefer plain text paste myself as I don't want adhoc formatting
showing up in my LyX file. We could have the option of either.

3) Not WYSIWYG.  Normal users clearly expect WYSIWYG. WYSIWYG and
WYSIWYM don't need to be mutually exclusive.  Ignoring the difficulty
in implementing for a while, having a WYSIWYG mode would be great.
After the content is complete, I go though a cycle of: Notice
something weird with the line-breaking in the PDF, muck around with
the LyX source hoping it fixed the problem; recompile PDF. This can
take a while and having a WYSIWYG mode could make this process a
factor of ten times faster.
3a) Psuedo-WYSIWYG. I find it helps to set the size of the LyX window
to be the same width as the PDF, so if I see a problem on the third
line of a paragraph in the PDF I can go straight to the third line of
the paragraph in the LyX window and fix it. Presumably LyX could
approximate the line-breaking algorithm of TeX and do a much better
job than I can by merely adjusting the width of the window. This would
be sufficient for me, but normal users may find another
not-quite-WYSIWYG mode more confusing than reassuring.
3b) LyX could bypass LaTeX. This is clearly what normal users are used
to. However this presumably wouldn't help in my use case where I am
submitting to a journal that provides a LaTeX style file.

So it seems to me that e.g. (1) should be fixed, and should be perhaps
be dealt with before we market LyX as being for normal users. Even (3)
could be fixed, and it would be good if it could, but it doesn't seem
worth the effort at the moment. (It certainly doesn't seem like
something that we should sit on our hands waiting for, and may in fact
dilute the WYSIWYM message).

John C. McCabe-Dansted

Reply via email to