dita — archive

Re: [dita] Questions regarding âthings you pressâ

From: Robert Anderson <[email protected]>
To: [email protected]
Date: Tue, 10 Sep 2019 16:22:00 -0000

Just an FYI on the history here - I looked up the definition of <uicontrol> we had in DITA 1.0, and it really is virtually identical to what exists in DITA 1.3. The only edits have been the same general style tweaks done everywhere, updating short descriptions to start with a consistent pattern and adding the use of <xmlelement>. DITA 1.0: http://docs.oasis-open.org/dita/v1.0/langspec/uicontrol.html DITA 1.3: http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part2-tech-content/langRef/technicalContent/uicontrol.html Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification Marketing Services Center E-mail: [email protected] 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA Eliot Kimber ---09/10/2019 11:09:31 AM---Thinking about my own use of the UI domain, the things I most need to describe, for example, when di From: Eliot Kimber <[email protected]> To: Zoe Lawson <[email protected]>, dita <[email protected]> Date: 09/10/2019 11:09 AM Subject: [EXTERNAL] Re: [dita] Questions regarding things you press Sent by: <[email protected]> Thinking about my own use of the UI domain, the things I most need to describe, for example, when discussing how to interact with an editor in the course of a DITA authoring tutorial, are menu items in their menu context, dialog or window names, and buttons on dialogs, e.g.: Do File -> New to bring up the New File dialog. Enter the filename in the "name" field and press "OK" to create the new file. Of those, the menu cascade is the most compelling from a formatting standpoint, since the connector between items should be generated (the "->" in my example). For the others, a visual distinction is not necessary needed or wanted, as Zoe explained, but there can still be a need to make a visual distinction even if it's just a font change (but not a regular/bold distinction) just to clearly distinguish window or button names. For buttons it's sometimes useful to render the button name as a button, i.e., in a box with rounded corners. As for the logical hierarchy of UI components, here's a page a I found that has some nice diagrams of the Swing class hierarchy: https://www.ntu.edu.sg/home/ehchua/programming/java/J4a_GUI_2.html The second picture shows that Swing distinguishes text components from buttons generally, and then within each of those categories has a number of concrete kinds of controls. A similar distinction could be useful in a reworked UI domain. Cheers, E. -- Eliot Kimber http://contrext.com ïOn 9/9/19, 7:20 PM, "Zoe Lawson" <[email protected] on behalf of [email protected]> wrote: I m still working through the second stage proposal for things you press. Original email https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201906/msg00033.html draft proposal here: http://tools.oasis-open.org/version-control/browse/wsvn/dita/trunk/DITA-2.0/stage-2/Issue257-thingToPress.dita As I m working through some of the review comments on the stage two proposal, I m coming across bigger questions. 1. Where to put it. I m contemplating dumping it in the software domain, but that doesn t feel overly correct. Should there be a hardware domain? (Would the hazard stuff fit into it? Are there other things to go in? I don t have hardware experience to guess.) 2. Migration theories. If you have a new element that could replace existing elements but don t have to, what do we want to recommend? You can, this is how, but you don t have to? Thanks, ZoÃ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php