Wednesday, July 30, 2008, 11:35:13 AM, Hussein Shafie wrote: > Daniel Dekany wrote: >> Tuesday, July 29, 2008, 5:44:36 AM, Jean Jordaan wrote: >> >> [snip] >>> While I don't use a split view all the time, when I need it, I REALLY >>> need it. >> >> It's not rare that I find myself using it when writing documentation >> in Word either. Also looking at the TODO reveals that someone else has >> already requested it too (unless that was me). And this all is really >> something when we are talking about a feature whose lack is not an >> absolute show stopper; users used to report only those, and maybe >> don't even realize when a new feature would make their work more >> convenient, not to mention writing an RFE. So maybe the idea that >> split view is not important should be revisited. >> >> Something that could *somewhat* make it less important is a bookmark >> feature (Add bookmark X and Go to bookmark X), but XXE doesn't have >> that either. Not out-of-the-box at least. It also certainly not good >> for the popularity of the product that out-of-the-box (yes, >> customization is important, but the default configuration should be as >> good as possible, especially as that gives the first impression about >> the product) it doesn't even have a navigation (kind of ToC) >> *parallel* with the normal view, so you can't just use that for >> somewhat redeeming the lack of the above mentioned features. >> (Switching between style sheets is slow, especially for big documents, >> so one has to customize XXE to have parallel ToC... and even then, >> that navigation view is quite awkward, as you have to select >> (double-click) the titles, not just move the caret there, and then >> switch the focus back to the parallel normal view, also, the ToC view >> takes screen place from the normal view, unless you constantly resize >> it back-and-forth, which is of course annoying). BTW, yet another >> navigation issue is that if I follow a link, I can't jump back (unless >> there was only one link in the document that pointed to the target), >> as XXE doesn't seem to remember from which point did I jump there, not >> even if the document wasn't modified at all since the clicking of the >> link. It should work like in modern Web browsers, as far as the XXE >> didn't lose the track due to too fundamental document modifications. >> >> To sum it up, I always thought that XXE could become significantly >> better for editing non-trivial documentations if it puts more focus on >> the navigation tasks. But currently, I believe, there is negative >> synergy coming from the lack of many common navigation features. I'm >> not sure that the XXE team realizes this, and that they do that with >> the proper weight. >> > > Thank you for this constructive email. It deserves a detailed and honest > answer. > -->> You are right when you say that the XXE team is not really conscious > of the navigation problems you have. > > Everyone here at XMLmind daily uses XXE to write non-trivial > documentation. A large document is *always* split into several XML > files. A file contains a chapter, a section, an appendix, a glossary, etc. > > In practice, we always work on small XML files. In this case: > * We don't need to have a good ToC. > * We don't need bookmarks. > * We don't need to open the same document in two different windows: one > window to see a part of the document and the other window to see another > part of the document. > * We don't have performance problems.
For the kind of documents like for which DITA was designed for that strategy may works acceptably well. Of course then you need global search and such extra scruff... But there are the book-like docs, and there seeing the whole document as a single entry is surely a better strategy, since then finding/restructuring/finding things are easier, and in general managing the stuff is easier and more natural that way, but only if you had a good inter-XML-file navigation of course. And, I believe actually it goes to DITA-like documentations as well, because nothing is as properly structured as the XML node tree itself, so adding an extra layer of structuring by blasting the XML node tree to multiple files just *shouldn't* make sense if you think about it. It may does make sense due to the limitations of the tools you use, but inherently, as a data handling strategy, it doesn't make sense. It's the XML schema that defines how to structure the information, and that should be enough. Well, you guys work on XML-database things, so you certainly feel that splinting an XML document into multiple files is tearing the tree apart at more-less arbitrary and otherwise static points, and it must be just a workaround to fight the limitations of certain tools. The software that reads the XML should be able to do that segmentation of the XML file ad-hoc, which is a more flexible, more adaptive way that the old-school big-files-are-evil-so-blast-everything-into-multiple-files approaches. After all, XML file should not be seen as a terminal node that is monolithic. If you open up the file, it expands to a tree... maybe with some annotated nodes (kind of bookmarks) in it. And then you don't even have the problems like for some commands you need a global version (global = applies to all opened files, or to all files in a directory, etc). The editor may employs tricks to segment the XML *internally* (for performance), but similarly as XML database that goes towards seeing even multiple XML documents as a part of a single big entity, the XML editors should go that way too, not splitting even a single XML document into multiple files. (Just imagine what would happen if MS Office requires you to split the doc-s at chapter boundaries...) > For time to time, we just need to collapse/expand some parts of the > document. Maybe I misunderstand what you meant by that, but collapsing doesn't sound to be very fast solution for me... it's just not in pair with quick ToC navigation + multiple views. -->> Now, some facts: > > [1] XXE is designed to author ``topics'' (? la DITA) and then to > assemble them into a master document. XXE is not designed to author > large monolithic documents. We do not intend to change this. Because... you don't like having more customers? :) I mean, OK, you designed it for DITA-like documentations, no problem with that, but there is nothing wrong in widening your perspective at later points. Non-DITA-like stuff exists. Situations where you want to navigate within a file exists, and not even rare in many applications. Also again, even for DITA-like stuff, splitting things to files (a low-evel and stiff way of structuring) is may not be the best way. But, yes, I see you has this Document Repository stuff and want to integrate that... we will see how it will look. -- Best regards, Daniel Dekany
