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

["Robert D Anderson" <robander@us.ibm.com>]

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: robander@us.ibm.com 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 <ekimber@contrext.com>
To: Zoe Lawson <zoelawson17@hotmail.com>, dita <dita@lists.oasis-open.org>
Date: 09/10/2019 11:09 AM
Subject: [EXTERNAL] Re: [dita] Questions regarding âthings you pressâ
Sent by: <dita@lists.oasis-open.org>

---

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" <dita@lists.oasis-open.org on behalf of zoelawson17@hotmail.com> 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