Hi,
I was exploring the features of dita-ot, and found that most of its features are already in Scrivener 3. This latter seems to go over that “standard” long technical document development software, and does it with a human and pleasant user interface.
So, I wonder if Scrivener can replace dita-ot, or any other editor and publisher for that type of workflow, or if there are still relevant differences making Scrivener not (yet) suitable for the task.
Paolo
I’ve had a look at the page for a few minutes, and it’s basically an XML schema right (with optional alternative inputs it seems, including Markdown to some degree)? So the majority of what the engine is, the part you download and install, is a document production tool for XML input?
If that’s the case, I don’t see much overlap with Scrivener really. In the same sense that we would use Scrivener to write the content that becomes a Markdown (.md file), we can use it to write LaTeX content directly, or have Scrivener generate much of the syntax for us (e.g. the provided non-fiction template), and likewise we can use Scrivener to write XML content, or have it help us generate that content. Maybe that is DocBook, maybe that is DITA XML. Either way we may not have to overly concern ourselves with it while writing, which is part of what makes Scrivener a great technical platform.
Whatever the case, as with all markup, in the end we’re going to be pushing it through some engine to get a finalised document out of it, whether than be through Pandoc, MultiMarkdown, LaTeX or DITA OT.
So that’s why I don’t see where Scrivener is really going to be replacing it, no more than it would replace Pandoc. In either case, whether Markdown or XML, it’s not going to know how to do anything with that by itself. What we put into the Processing pane (or which prefab markup document type compile selection we use) is what handles that part of the equation.
I might be missing something though! Like I said I only skimmed the site a bit, and it’s full of dense RFCs and developer-oriented documentation.
I had been thinking it also included an editor, but by exploring the files it seems that this latter can be simply any XML text editor. Yes, it is just a schema, to be used with a dedicated editor (from FrameMaker to OxygenXML).
There are things in the syntax that must be in the supporting editor, and I was noticing that Scrivener has probably all of them.
In any case, I think that DITA, so rigidly (and sometimes obtusely) structured, is no longer the best choice for technical documentation (assuming it has ever been). So, at least for me it is not even a matter of trying to find a compatible editor.
Paolo
I’ve examined other topic-based writing tools, proposed for technical writing. My impression is that they are conceived by engineers for engineers, and not for writers. It may seem a subtle distinction, but it implies very different mindsets.
Most of these tools require you code your page. Scrivener lets you draft, scribble, patch, paint over it, and then takes care of converting it into obscure code. With Scrivener you can see and touch what you are doing. With the other tools, you are just offered a parallel window where to preview the page you coded, but you can’t touch it.
The reason why Scrivener is universally considered a software for creative writers is because it is creative software itself. We technical writers, in particular the ones forced to deal with matters we don’t love, feel the need to be considered smart, not creative. Creatives are losers, unless they play distorted guitar. So, we adapt to abstruse programs, ready to pay a ton for a raw text editor and a converter made in Java.
Since technical writers are paid much less than software engineers, if one has to learn coding, why not just learn to write software, instead of coding manuals?
Paolo
I don’t think Scrivener 3 can replace DITA. One of the advantages of an element structure based system like DITA is that you can use the various built in conversion systems for multiple different sources. That is going to be a lot more accurate than a paragraph and character style based system like rtf used by Scrivener. Still, setting up proper DITAmaps, correct elements, etc takes some time. It will be a lot slower getting started.
DITA can be rigid or loose. Generally one chooses a more rigid system if it works for a topic (like a concept, task, reference, or glossary), but you can use the generalized topic type or customize a type if you wish. In OxygenXML you can code or not as is easiest. I discussed this a bit in the Scrivener mac forum under the issue of footnotes.
I think you are missing how Scrivener works. Yes, the source is usually in RTF but the output to deliverables can be any number of formats, all under your control.
But use DITA as you like. Again, up to you. I am sticking with Scrivener for the reasons @ptram wisely summarises.
Scrivener will be a lot faster for writing than most other programs. However its conversions can be a bit limited. So as to not pick on Scrivener, in InDesign, you can export to a pdf or ePub. Your ePub will likely require some tweaking due to the differences in how XHTML and paragraph/character systems work. The easiest example is bulleted or numbered lists. In paragraph format systems, these are done with autonumbered paragraphs with a tab and indent of all lines after the first. This creates an absolute distance which is a problem in e-readers. Using an ordered or unordered list will look better in ePub/HTML. Another example is how each handles mathematical equations. They are very different beasts.
Just to be clear, getting started with Scrivener was fairly easy. In contrast, I stared at Oxygen for a couple years and hated it until I got past that and found it is an amazing program. Anyone who does all the coding of DITA directly in a simple text editor is a little massichistic.
Yeah, again I think there is perhaps an inclination toward thinking Scrivener should somehow replace typesetting and production engines, when really what it is mainly offering is a front end to these systems, a better way of constructing the source material that gets fed into these systems, and ultimately becomes formatted documents.
Scrivener is how you end up with the DITA formatted XML, or the LaTeX .tex file, or the DocBook XML. It isn’t the thing that takes that file and turns it into a PDF. It’s really no different in concept to using Scrivener to create an HTML file. It’s the .html file it makes, it doesn’t become the web browser itself and turn it into formatted text.
I don’t think it would be humanly possible for a single developer to make something like Scrivener and InDesign and all of these other things, in a single lifetime, or of any level of quality worth speaking of. We already know what that kind of diluted lack of focus looks like, even after countless hundreds of millions of dollars poured into it. It is spelled “Microsoft Word”.
I know this topic is a couple months old, but to answer again the originator of the topic: I don’t think Scrivener can replace DITA. Whether it is a reasonable tool to write DITA code as @AmberV suggests is possible.
But if you don’t know if you need it, you likely don’t need DITA. It excels in a multiauthor environment often with thousands of topic files, all standardized both in their look and in how knowledge is imparted. Like a lot of other systems, it can compile to a lot of different targets, but its strength is in systems where the reader does not want to read in a linear way, but rather jump around between areas they want to know more about.
Docbook is a bit different, and if I were writing a technical book intended for print and ePub mainly, I would probably use that instead in most cases. Paligo uses Docbook internally and is popular software for multiauthor technical documentation.