Tooltips?

By way of some minor feedback from a new RISC OS user, I’m finding that intuiting functionality in UIs is tricky (and of course I’m presented with lots of new UIs as a new user).

As an experienced user of GUI applications, like most people these days of course, I know for example that the buttons in StrongED are likely to involve various editing, checking and executing features common in a code editor. I am presented with icons in the toolbar and would probably exactly understand their function, but the icons alone aren’t necessarily sufficient to infer function for the 1st time. Icons are a good mnemonic, but users have to be educated at the onset (especially where there aren’t strong standards or conventions). Consequently, I have to find help/documentation to learn what buttons do, or attempt to get clue through experimentation.

Most modern GUIs have adopted tooltips has a way to convey very short functional descriptions of UI elements such as buttons, and also to expand truncated text. I do also see applications where text is truncated and there’s no way to expand the enclosing window to read the hidden information! Although that’s certainly an application design issue, tooltips would help the application designer by providing a cheap way to show such text in full, even if they decide not to allow container resizing or scrollbars.

Because I don’t see them, I assume tooltips aren’t a standard GUI toolkit feature(?). I suppose there are alternatives, such as having a status line that shows short help text when the user hovers the mouse over UI elements, but these have to be designed into apps at a much higher cost to the developer.

Run Help, from Apps on the iconbar.

Help’s icon appears on the right of the iconbar, and you can click it to toggle help messages on and off.

Most modern GUIs have adopted tooltips has a way to convey very short functional descriptions of UI elements such as buttons, and also to expand truncated text.

Indeed – those of us who have used RISC OS for what seems like forever have been pleased to see the OS in use at work develop what we already had at home. :-)

First among the additional items at work was a GUI…

As Michael points out loading the Help application is quite handy and once you get used to things, not having it loaded saves iconbar space.

Run Help, from Apps on the iconbar.

Well, there you go! Very nice.
Kinda surprised you have to run another app to get this, but I’m only expressing my preconditioning in saying that.

Of course, this doesn’t address the potential use of a ‘rollover expansion’ of truncated text, but maybe you’ll tell me there’s another standard app that does this for all apps ;-)

Tooltips weren’t really a feature of Windows until Windows95. RISC OS predates Windows, period. So we developed our own way; and the best thing is that you can turn the damn things off. I’ve been using Windows for, like, twenty-plus years. I do NOT need to be constantly reminded that the red ‘X’ is “Close”… Tips are useful at first. Afterwards, silence please!

Wrt the PI port (which I guess is where we will get the majority of our new users from in the near future) Is it worth making Help more obvious such as putting it on the pinboard or even starting it as the desktop loads.

Shoot me down if I have got this wrong. I think Help works as follows: 1. the wimp tells Help when the pointer is over something, 2. Help broadcasts Message_HelpRequest (&502) with info about what the pointer is over, 3. when a task receives this it can choose to reply with Message_HelpReply (&503) which contains the zero-terminated string to be displayed as a tooltip.

This is all very well, but probably of little use to the beginner. What is needed are amenable tools that use this set up. It is easy to write html that will display tooltips with a sufficiently modern browser. You use the :hover pseudo-element to switch to “display: inline;” instead of “display: none;” for the tooltip stuff. The advantage of this over Help is that the tooltips are not restricted to text – you can have graphics and sound – and you do not need to know about wimp-programming. A well-placed # in the CSS file will turn them off. A text editor and a manual about CSS are sufficient. Tooltips can be a boon for tutorial material. It would be good if StrongED supported them.

Kinda surprised you have to run another app to get this, but I’m only expressing my preconditioning in saying that.

The point being that you can use a different app and get a different result. Try BubbleHelp for example: http://www.vigay.com/thirdparty/index.html#bubblehelp

Of course, this doesn’t address the potential use of a ‘rollover expansion’ of truncated text, but maybe you’ll tell me there’s another standard app that does this for all apps ;-)

Well it would be up to the app that had truncated the text to provide it via the help protocol, which is perfectly simple to do… but I doubt anyone thought of it. ;-)

Ideally (for some value of ‘ideally’) the wimp would do that for icons with truncated text.

starting it as the desktop loads

ISTR this has been previously suggested; it’d be a useful improvement. Experienced users can always disable it.

I think Help works as follows:

That looks about right, though I’ve not bothered to look at the PRMs or anything, just going from memory for something I coded a decade ago… ;-)

It is easy to write html that will display tooltips with a sufficiently modern browser.

…eh? Has exposure to Windows corrupted your memory? In RISC OS land, the Desktop and the Browser are different things. You can have all the clever CSS you want, but that won’t help on the desktop, unless we’re to move to a virtual-web-desktop (which would no doubt please Google).

If I have got the wrong end of the stick, please correct me, but I don’t see what HTML/CSS has to do with tooltips on RISC OS.

BTW, +1 for autostarting !Help on the Pi.

In Filer windows with truncated file names you might like to try Andrew Booker’s !FullNames which I have running happily on my BBxM. It’s available from http://www.ajb121.net/riscos/ – I have it run at startup and it gives the full filename as a tooltip when you hover over a truncated name (ending in …).

… the Desktop and the Browser are different things.

Yes indeed. But the concept of tooltip surely embraces anything that is visible on the screen. I hate using browser interfaces for user input on the whole. What ISPs are pleased to call control panels are usually horrid. Even so, you have to admit that CSS makes offline html documents marvellously easy to style graphically. I would like some of that for the Filer. Why, for example, are filer-menu data and window background colours hard-coded into the Filer module, instead of being programmable in editable files, held in Resources maybe? Why cannot I choose where the window furniture goes, the same way that I can choose where the smarticons go in a StrongED mode.

Sorry, I am in pipedream mode right now. The point is that the GUI could be a lot more flexible than it is. Browsers and Filers both render to the screen a complicated tree-structure. Browsers use style files. Why not something similar for the Filer?

Perhaps I am remembering RisciX whose GUI was configurable on a per directory basis. A directory could contain a hidden editable file (names beginning with a slash would be the default for concealment) called maybe /style. It would be consulted by the filer when redrawing the directory’s window – colours, relative positions, what to hide, ordering of the contents, etc – and when user-actions take place: clicks, drags, keypresses, hovers, etc. The style file would describe how user-actions are bound to filer-actions. For efficiency the /style file’s contents would probably have be cached, and the directory’s menu would give an option to refresh the style. It might well be sensible to have user-definable types of directory – all those possibilities from &1001 to &1fff – with a common style file for each type. One might keep all the style files /style_xxx in one place, in !Boot perhaps.