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 issues. 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
