Developers' side bar
Categories: Development<< | Page list | >>
Concept site. Everyone is invited to add a comment to this site at any position. This is being used as a test, to avoid copies of text that appear alot with citations in mailing list or forums. Does this Wiki lock sites during editing?
Does the user really need to be able to edit everything? In the end he will make use of it, and lose alot time. The idea behind WYSIWYM is to focus on content. A more complex layout and formatting algorithm can then do the rest. Example: Setting the text color independent of a layout-file is, and will allways be: WYSIWYG.
LyX already made a few steps into a WYSIWYG direction, and the decision has to be made if those features shall be removed or kept. Extending this with enough features to satisfy everyone destroys the basic idea behind WYSIWYM.
The content editor has to be as simple as possible. An other program can, before compiling the export, replace parts of the text or modifly something to provide a more detailed layout.It should use existing standards.
A Minimum number of elements should be used.
Hardly anyone would limit himself to the few really need elements. That is why it might be better to allow any element: dynamic toolbars for any (user specific) elements. This includes user specific display style of those elements in the editor, and also formatting for the export.
Headline/heading/caption/title are navigation points.
They normally contain keywords of the following content. To number them is only needed to find a section faster in print media. Elektronic media use hyperlinks and thus do not need numbering. The headlines form nested lists, how deep they are nested defines the level of the headline, so no different level elements are needed.
Paragraphs and list are both the same: text.
List are indented text, while paragraphs are usually longer text blocks. So there is only need for 1 element, that covers both functions. Tab will indent it, which can be formatted with bullet symbols like common lists. Shift+Tab returns to a higer level, and text, if it is the highest. Current LyX could be extended with this input type. How this 1 element is used defines if it looks like a paragraph or like a list. Enumerated/ordered lists are not needed at all (Please provide an example where is might be needed). LyX also has a "list" list: What should that be?
Changing from headline to text can be done with a single toggle button, and automaticly on the first(head)/second(text) line in a new container.
Figures, diagrams, videos, pictures, external tables
All their information can be stored in their files. Nothing needs to be entered in an editor. The editor only references an object. This requires new file formats. Encapsulated formats can work as a quick solution.
An other option here is to use Hyperlinks for objects, and select if they should be included (automaticly) or remain external. E.g. the reference to a figure is the hyperlink to it.
A grouping element to group a headline with the right paragraphs and other block elements. Created automaticly when the user hits text indent or tab, closed on e.g. shift+tab. This defines that the container contains the headline and the text.
A special math environment is not userfriendly and has to be avoided. Inline elements for equations: symbols, units, functions ... . A table of symbols or list of common functions could even allow fully automatic detection and provide an overview. The operator signs can be put outside of environments. The current normal text, bold ... in LyX is also more layout than semantic. There is no need for many different unit types. There is no need for different fractions. There is no need for a special bracket element. It can be detected automaticly.
For footnotes, side notes ... how it looks depends on the used layout file. This already is something like content importance level, but implementing that might be too early. It would mean that the reader of a document can select the content importance level to get a short document with most important facts, or a long document describing all details.
Important for electronic media. Replaced by referencing in print media. But both use the same element!
Something like Title, Author, ... belongs here. adding RDF to the xml-file?
When the layoutfile is a txt-file, then the editor might get low priority in the development because more work should be done on content, than on layouts.
How does the user view the document while editing? That can be most important, because that is what the user will see while using LyX all the time.
More complex, needs "good" default values.