Survey of toolbox / palette UI?


#1

Hey folks, I’m trying to find examples / a survey of toolbox / palette UIs but it’s proving difficult to google. I’m talking about things like Photoshop’s toolbox:

<img src="/uploads/default/original/1X/617acc740781d2d3c78d2cb3577e55c7e3eceee1.gif" width=“298” height=“385">

I’m currently designing something that needs some kind of toolbox and I’m trying to explore different options (should it be like PS? should it be like Sketch where you don’t really have tools, but instead insert instances of shapes? something altogether different?). My googling has turned up lots of JS widget libraries and colour palettes but that’s not really what I’m looking for :sweat_smile:.

Anybody know of anything I should read up on while exploring this?


#2

this is a bit “Blast From The Past”, but i loved this in-depth analysis of the Kai’s Power Tools suite from back in the late 90s https://www.mprove.de/script/99/kai/index.html

one thing i really like (find fig. 9) is the sort of midi-board/slider ui for some of the adjustments, but with the actual values superimposed on the sliders themselves.

i guess the other thing is figuring out what sort of of app this is: is it a document-based app where the palettes are global but considered part of a workspace or is it something more like the kai model where the ui/tooling is specific to each open file (sort of like an ios model).

one thing missing from the exploration of those palettes is how photoshop/illustrator (and indesign in particular) think of arrangements of palettes as configurations. So you may have an arrangement of panes that you have open for prepress work compared to actual layout work etc.

i dunno, hard to say! i would probably scope out some uist papers if possible, that would be the conf to talk about this.


#3

At first glance, this looks fantastic! I haven’t read through it yet but just wanted to say I remember playing “Goo” obsessively on my step dad’s work computer as a child. So much funnnnn


#4

Alright, CHI paper dump incoming :stuck_out_tongue:

Using Earcons to Improve the Usability of Tool Palettes (Brewster, CHI 98) adds sound cues to the selection of tools from a palette in order to reduce user error. Their user study finds that it does work.

This paper describes an experiment to investigate the effectiveness of adding sound to tool palettes. Palettes have usability problems because users need to see the information they present but they are often outside the area of visual focus. Non-speech sounds called earcons were used to indicate the current tool and tool changesso that users could tell what tool was in use, wherever they were looking. Experimental results showed a significant reduction in the number of tasks performed with the wrong tool. Users lmew what the current tool was and did not try to perform tasks with the wrong one.

Multiblending: displaying overlapping windows simultaneously without the drawbacks of alpha blending (Baudisch et al., CHI 04) takes issue with alpha blending palettes on top of content, particularly in image editing, as it can distort the perception of color/brightness underneath the palette. They propose a solution that involves multiple blending techniques to create what they call “glass palettes”. Their user study finds that user prefer glass palettes, and perform better at the tasks they defined (recognizing the background properly).

Categorization Costs for Hierarchical Keyboard Commands (Miller et al., CHI 11) compares speed of command selection using keyboard key combos vs direct tool palette selection. They find that while 1-Menu conditions (for example Ctrl + one key) is faster than direct toolbox selection, 2-Menu conditions (for example Ctrl + one key, then another key) are performed slower than toolbar selection.

The study’s practical implications for design suggest that hierarchical, category-based keyboard commands do not provide a clear advantage when compared to toolbar-based selection. Figure 3 presents Toolbar performance from Omanson et al. and contrasts it with the 2-menu results from our study. After 3 blocks, participants were able to select an item from the toolbar at 1.9 seconds on average. At most, the keyboard sequence produces a selection time that is 300 ms faster. However, this difference is likely to be much smaller. Compared to our results, the time of 1.9 seconds is a conservative upper bound for toolbar performance since the toolbar analysis did not remove trials where users had to recover from selection errors. It is also possible toolbar performance would continue to improve after three blocks.

The Hotbox: Efficient Access to a Large Number of Menu-items (Kurtenbach et al., CHI 99) proposes a new kind of widget, named “Hotbox”, which aims to address the issues with menus/toolbars in highly complex professional software - specifically Maya, since the authors of the paper work on that product.

The HotBox works as follows. To display the Hotbox the user holds down the space-bar (with their non-dominant hand) when the cursor is in any of Maya’s windows. The Hotbox instantly appears, centered at the location of the cursor. The “rows” of the Hotbox (see Figure 2) behave like traditional menubars. Individual menus can be popped down like menubar menus by moving the mouse (with the dominant hand) so the cursor is over a menu label and pressing any mouse button (Figure 3).
Each row of the Hotbox corresponds to a particular set of menus (Figure 4). The top row, is referred to as the “com- mon” row. This corresponds to menus commonly found in most applications’ main window menubar (e.g., File, Edit,…). The next row down shows the items in the menubar for the window that the cursor is currently in. Below the center row of the Hotbox are rows of menus spe- cific to certain computer graphics tasks.
The center row’s menu label “Recent Commands” displays a list of recent commands issued by the user and allows a user to repeat a command without having to relocate the command in the menus. (Figure 5). The other menu in the center row, “Hotbox Controls” allows the user to control which rows of the Hotbox are displayed. This menu is a marking menu. In Figure 2, all the rows of the Hotbox are displayed. Using the marking menu a user can quickly display and hide specific rows. Figure 6 shows an example of changing the display of rows.
Besides presenting the user with rows of menus the HotBox one of the these zones has a different marking menu which can be accessed simply by pressing down a mouse button when the cursor is in the zone. These marking menus are used for user defined menus.
The Hotbox remains displayed as long as the space-bar is kept pressed. This allows a user to perform a series of commands without having to re-invoke the Hotbox.




The feature shipped in Maya, to positive user reception; some portion of their users in fact removed all menu bars from the screen, using HotBox exclusively (I don’t use Maya, I wonder if it’s still in there?).


#5

OK, some thoughts after having read this through more thoroughly:

The “rooms” concept is quite interesting,

The user experience is really like coming into a room with a special suited environment for one specific task.

It doesn’t really fit with the application I’m making, I don’t think (where the focus is less on processing an element, like a picture, than it is creating a bigger document (graphic / program)). But having isolated rooms / modes is a neat approach.

The bit about tools being represented by pictures of physical tools also stood out:

The tools no longer need to be modal like the KPT lens; they can be used in a very natural modeless manner. Pens, brushes and erasers are distributed all over the workspace. They are large, they drop real shadows, and the tips of the tools get pressed down while they are in use.

<img src="/uploads/default/original/1X/b84b910084e27a2d2522b2048aec62c1c7a7b134.jpg" width=“690” height=“444">

This resonated with me because I’m constantly feeling sad that all the magic has to happen inside the little rectangle on my desk / lap.


#6

Ahhh this is so good as well!!

Earcons remind me a bit about this DS game called WarioWare DIY, which is essentially a programming environment disguised as a handheld video game. From this fantastic writeup about the it (and about Super Mario Maker):

In WarioWare’s image editor, when you flip a stamp, the tiny caveman holding up the stamp also flips, showing you his back. When you play notes on the keyboard in music mode, tiny faces pop up to sing the notes to you. Each menu has different background music: When you go to set your game’s winning condition, the music changes to a celebratory march, like you’re in the home stretch.

These little interactions do more than underscore the effects of individual tools or functions: They make interacting with the interface playful and rewarding and joyful. They make what could have been a cold, intimidating tool warm and friendly. They also encourage discoverability: If all these buttons do cool things, won’t you try touching them? (emphasis mine)

Not exactly solving the same issue as earcons but nonetheless adds a little more liveliness to interface tools.


These are all really good, thank you both for sharing :slight_smile: