TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
You know, the word "subtab" existed in the document that I was asked to update, and I went looking for it to see if it's an accepted UI term. Just Bing-ed it (have I done the loathesome and invented a new word? What is the Bing equivalent of "Googled"?) Well, anyway, just searched for it and there are only about 35,000 results, which for the web is pretty small. Evidently the term is pretty geeky and not much in evidence.
I'm all for avoiding geek speak and UI-developer terms wherever possible, but I don't think using no UI term at all is acceptable in this application. That's because not only do most windows contain a top row of about 4 or 5 tabs, but they also contain a second row of tabs (the aforementioned "subtabs") AND many radio buttons, buttons, fields, and lists. This is one UI that is chockablock full of software controls.
I can give my user some help by identifying the type of item he's looking for. I break the usual rule about not including the terms button, field, list, tab, *subtab* etc., just so the user knows what to look for. "Tab" instantly states that it's one of those square things; "subtab" establishes that it's on the second row. (I don't say "tab on the top row." I wonder if I should. Gaaaahhhh!)
As for asking for, and getting, a redesign of the software, with or without my participation, there is currently no possibility of that happening.