[JSPWIKI-913] HADDOCK: remove hover-to-reveal behaviour for editor toolbar icons

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.10.2
• Fix Version/s: 2.10.3
• Component/s: Editors, Templates and UI

Environment

Client is:

• Firefox 40 (Ubuntu 14.04).

Server is:

• JSPWiki v2.10.2-svn-25 running in GlassFish v4
• Container managed authentication is enabled using a file-based realm
• HTTPS is enabled
• JSPWiki policy is locked down such that only authenticated users have access (both read and write)

• Assignee: Dirk Frederickx
• Reporter: Dave Koelmeyer
• Created: 29/Aug/15 06:51
• Updated: 15/Nov/21 13:49
• Resolved: 12/Mar/17 18:45

Description

With fix https://issues.apache.org/jira/browse/JSPWIKI-908 basic editor toolbar icons were added back to HADDOCK (thanks).

The problem with the current implementation is accessing them is rather tedious. A user first has to hover the mouse over the paint drop icon, wait for the horizontal icon menu to reveal, then move the mouse in a linear horizontal motion to the desired icon. If the icon happens to be at the end of the row (say, the "Font" icon), and focus with the mouse is lost, the menu disappears and the user has to repeat the operation again (hover -> wait -> move).

I've already had to do this multiple times and I'm a pretty steady hand. It makes unnecessarily hard work of operations that should be a fast point and click operation – as it would be with a simple static icon.

On a 1280x1024 display at 100 percent zoom, the current icon set only covers about a third of the potential space that could be used in the same horizontal row, so it's not like any space will be wasted per se.

The improvement request here is to consider placing common editor toolbar commands back as static buttons.