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, I'll probably have to revisit what I wanted to do, as I get more familiar with the instrument.
I was originally picturing something for typical off-instrument webhelp, in the usual tri-pane setup. (Actually, I was planning to inquire a step further and see if there was a way to integrate mind-mapping software with Flare so that the normal Contents pane on the left of the tri-pane setup was replaced with a tag cloud of words and phrases, each of which was a condensed topic heading, and as you moused over the tag cloud, the corresponding topics would appear in the display window on the right in rapid succession. In fact, I was picturing getting rid of that middle border between the two inner panes so you'd have a single window with the tag cloud mostly on the left, and then the topics appearing on the right or somewhat in context as you moused over the cloud.)
But even with tri-pane webhelp, the browser-dependent behavior that Robert talked about, and the high overhead in trying to avoid that, makes this kind of approach impractical.
For on-instrument, the screen is not huge (it's still a good size), but these are lab techs performing diagnostic tests and the navigation path through the documentation tends to be pretty strict in order to keep people on target. Link rollover previews might result in a busy, distracting screen. Although, there are hotlinks in different places. It's just that you have to actively touch/tap the link to get to where you're going. Given the particular workflow, that might be the preferred way.
I'll regroup and come back with any results if I get any further with this.
Thanks for all the help!
On Tuesday, November 04, 2014 2:19 PM, Tony Chung wrote:
Neither the user nor the app need to adjust their behaviour. The operating system does it for them. The OS automatically adjusts to suit the input method. If a developer codes the popup behaviour according to standards, Windows will know whether a mouse is hovering, or a finger is tapping. The single tap should show the same behaviour as hover.
On Tuesday, November 4, 2014, Mike Starr <mike -at- writestarr -dot- com> wrote:
> So hundreds of users would need to be instructed in how to change the
> default configuration? That's not the sort of thing I would normally advise.
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l