dita-lightweight-dita — archive

Slide specialization first draft

From: Don Day <[email protected]>
To: [email protected]
Date: Mon, 02 Nov 2015 16:26:00 -0000

I agree with Tim's rollup recommendations. I have had the same experience with simple DITA content that I have used as dynamic slide content. My eventual steady state practice is having effectively a domain based on <section outputclass= aside > that isolates slide-specific key points within a topic that can manage the more semantic or instructor-oriented content. It turns out to be a lot of work to effectively duplicate the slide info in both places but that seems to be just the nature of dual-role content. Also, I am now exploring the use of more than one such section per topic since sometimes it can be handy to author a simple slideshow within a single topic, shedding the content management overhead of a map driving topics of slides. There is a link to a working version of this method in this note (which has other useful background): http://svdig.ditamap.com/2013/03/meeting-it-was-with-you-all-along-adaptive-dita/ -- Don On 11/2/2015 9:26 AM, Tim Grantham wrote: Hi, everyone. I recently completed a proof of concept transform that enables my product, DITA InPrint, to publish PowerPoint slides from DITA maps and topics. Some interesting architectural and authoring issues came up regarding using DITA to author and publish slides, ones that suggested to me that a topic specialization, such as the one below, might not be the best way to go about supporting slide output with Lightweight DITA. A domain specialization, perhaps, but not a topic specialization. DITA was (IMHO) designed primarily to support printed and Web output. Slide output is quite different from those media. Slides were not designed as a medium for browsing, reading, and searching content -- they were designed as a medium solely for highlighting content. Users don’t want a lot of content on a slide; in fact, slide authors are actively discouraged from putting a lot of content on a slide, because audiences want and need slide content to be a distillation of content – the less browsing, searching, and reading they have to do, the more they like it. In addition, it’s much harder to separate slide content from its presentation: much of slide content actually depends on its presentation, in terms of both length and language. Also, slide content is highly dynamic. Authors constantly change slide content to suit different audiences: not just within individual slides, within decks of slides. In DITA, this effectively means authors would spend a lot of time authoring and updating maps, as well as topics. All of these issues have solutions. I’m not suggesting DITA should not be used for slides. But it does require revisiting some of our assumptions about DITA. I have trouble accepting that a topic specialization for slides would be practical, especially as it would by its nature be mainly a set of presentation elements – and DITA is supposed to be about maintaining a separation between content and presentation. Nor do I see any serious user of PowerPoint wanting to give up their editing environment to author slides in DITA map and topic editors. It might be useful to have a domain specialization for slides: this would enable authors to create topics initially intended for slide output, but still be able to re-use the content for other types of output. But that still leaves us with having to decide what current element(s) in base DITA to use for slide content output and/or as the basis for a slide domain specialization. I believe the <abstract> and <shortdesc> elements are the most likely candidate elements to use for publishing to slides (not for the slide notes content). They are, according to the DITA standard, used to contain the initial content of a topic, and therefore will most likely contain the most important content of the topic, as well as likely the most concise content, making the content of these elements the most suitable content for distilling the topic into what can most easily be displayed in the limited real estate of a single slide. The <abstract> element provides a very rich content model, supporting all the types of shapes/objects that are available in PowerPoint. The content of the <body> element is probably the most suitable element for slide notes. It does provide the slide author/presenter with access to all the details that might be needed to answer questions about the visible content of the slide. But PowerPoint doesn’t provide a very good way of displaying table or graphic elements in the slide notes. It might be better to skip outputting the <body> element entirely, or only output the text content of the first few elements, or some other method of re-using the content of the <body> element, without having to include all of it. Again, a domain specialization might be helpful here, such as a <slidenotes> element specialized from, say, the <ul> element. Of course, another approach would be to use a conditional publishing attribute to profile content for output to slides – the DITA 1.3 standard has the @deliveryTarget attribute for this purpose. But this approach decreases the amount of content that can be re-used across multiple media. If we do want to maximise re-use of DITA content for all media, including slides, then I believe this means that authors will need some additional training. This hasn’t really been necessary for print versus Web output: in fact, authors are typically trained to follow writing guidelines that eliminate the need for them to have any concern at all about whether the output is for print or Web. I don’t believe this can be the case for slide output -- at least, not in the short term. In the long term, I think that re-using content for slide output will require a set of authoring guidelines, and/or a domain specialization, and/or topic specializations that implicitly (not explicitly) support re-use of content for slide output. Regards, Tim. Tim Grantham Grantham SoftWorks 519-865-1237 27 Queen Street Paris, Ontario N3L 1C3 From: [email protected] [ mailto:[email protected] ] On Behalf Of Carlos Evia Sent: Monday, October 05, 2015 11:35 AM To: [email protected] Subject: [dita-lightweight-dita] Slide specialization first draft Dear all, Here's the first draft at a slide specialization for Lightweight DITA based on the example Michael explained in today's call. Credit to John Hunt. <slidetopicid= slide_one > <slidetitle>My slide</slidetitle> <slideprolog> <slideauthor>Carlos Evia</slideauthor> </slideprolog> <slidebody> <slidekeypoints> <title>Key points</title>   <lcObjectives><lcObjective>...</lcObjective></lcObjectives> <p>...</p> <ul><li>...</li></ul> <ol><li>...</li></ol> <simpletable> <strow/><stentry>...</stentry><strow/> </simpletable> </slidekeypoints> <slidespeakernotes> <title>Speaker notes</title> <p>...</p> </slidespeakernotes> <media> <title>Media</title> <object>...</object> <p>...</p> </media> </slidebody> </slidetopic> Slide topic template And here's the template used to generate the specialized slide topic above - <topicid= slidetopic outputclass= slide_topic > <titleoutputclass= slidetitle >Structured Content</title> <prologoutputclass= slideprolog > <dataoutputclass= slideauthor specrole= prompt >author name here</data>  </prolog> <bodyoutputclass= slidebody collection-type= sequence > <sectionoutputclass= keypoints > <titlecontentrole= generate >Key points</title>  <lcObjectives><lcObjective>...</lcObjective></lcObjectives> <p>...</p> <ul><li>...</li></ul> <ol><li>...</li></ol> <simpletable> <strow/><stentry>...</stentry><strow/> </simpletable> </section> <sectionoutputclass= speakernotes > <titlecontentrole= generate >Speaker notes</title> <p>...</p></section> <sectionoutputclass= media > <titlecontentrole= generate >Media</title> <p>...</p> <object>...</object> <fig>...</fig> <image>...</image> </section> </body> </topic> -- Carlos Evia, Ph.D. Director of Professional and Technical Writing Associate Professor of Technical Communication Department of English Center for Human-Computer Interaction Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 This email has been checked for viruses by Avast antivirus software. www.avast.com