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

[Eliot Kimber <ekimber@contrext.com>]

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Ã