OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Reviewing User Interface domain


Upon hearing that the user interface domain hasn't really been given a heck of a lot of thought since DITA 1.0, I'm beginning to think it's worth a revisit.

In the software world, UIs have changed a lot. We probably want to reflect it in the domain, possibly by figuring out what may be some new common specializations, and then some base items for specialization for folks who want to take it further.

Based on what I've heard and experienced, we're not including a lot for the hardware world (i.e. physical user interfaces, not virtual ones).

I liked the direction our conversation was taking about "User Interface" really meaning any user interface, whether it's software, hardware, cybernetic implants, VR experiences, whatever.

I don't know if revisiting the user interface domain is a separate request, or just an outgrowth of "a thing you press".

Minimally, we should rework the description to be more inclusive. As folks have said, the lines between software vs hardware or virtual vs physical interaction things is getting fuzzier and fuzzier. I don't think splitting the domain is wise.

Perhaps uicontrol becomes the base element that can be specialized into whatever new and exciting GUI tools come out.
Elliot proposed the idea of having different options for things based on whether you can just A) click/select/action it or whether B) it's a place where you can enter information.
I want to keep menucascade. Potentially swapping out uicontrol for whatever we call A above. Are there other types of menus/options? Do we need something for dealing with trees?

I think shortcut needs to be revisited. The current example works for highlighting a specific letter in a menu word. However, in many cases, the shortcut has little to do with the name of the action. Either there are several more characters (e.g. Alt+something) or the shortcut is completely different. How would we use the existing shortcut for the common "Paste" (where does the Ctrl+V go?).

I wonder if we want to revisit screen. Part of me wants to rename it "terminal" or "console". It definitely still has value, because we still have text-only stuff to document. I got confused by "The default print representation is to enclose the screen within a box, suggesting a computer display screen." I realize I'm looking at an HTML version, but our example doesn't have that.

Minimally the description of wintitle needs to be expanded make sure we cover some of the different options, or at least modern naming conventions (panels, panes, popups, etc.). Does wintitle become the basis for specialization?

Do we need a secondary title/label level? Most GUI have the main dialog/panel/screen/pane, and then there are often labeled sections within it. Do we need something to differentiate between the "title" and the section label?

Do we need something specific for "tabs" in a UI?

Would an "icon" element that's a specialization of image be useful? When I'm writing, I often have standards about what information needs to go with the icon, how it's displayed, how I refer to it, etc. It might be nice instead of remembering
<uicontrol>icon name</uicontrol> (<image href="">
That I could just use something like
<icon href="" name="icon name"/>

Whatever we use for 'thing to press' should be included. Do we need other types of physical things?

Do we need something for physical actions? Swiping, pinching, turning, rotating device? Are there differences between "gestures" and other physical actions? e.g. swipe vs shake?

Scott Hudson had a decent requirement of needing to combine the label with a setting. (And I recommend following his link to the topic to see how he's using <userinput> and <option>.)

Do we make a zillion special elements for common UI things which might scare people for having too many options? Do we add a few and specify and element designed to be specialized?

Definitely want more discussion, but these are some thoughts that have been rattling around in my brain this week.

Zoë



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]