Difference between revisions of "Rethinking GIMP Tool Options"

From GIMP GUI Redesign
Jump to: navigation, search
(add user scenarios)
 
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
  
Tool Options have grown out of the need for having a greater control over the active tools behaviour. However, there has not been a clear guideline of how this interaction is supposed to take place. Examples of what this project addresses are: interaction with the live canvas object; widget lay-out and design; working with setups.
+
Tool Options have grown out of the need for having a greater control over the active tool's behaviour. However, there has not been a clear guideline of how this interaction is supposed to take place. Examples of what this project addresses are: interaction with the live canvas object; widget lay-out and design; working with setups.
  
 
== Vision ==
 
== Vision ==
Line 7: Line 7:
 
The vision during the design process is based on GIMP's [[GIMP_UI_Redesign#product_vision|product vision]] combined with the specific needs during interaction with the tool options. The vision follows below:
 
The vision during the design process is based on GIMP's [[GIMP_UI_Redesign#product_vision|product vision]] combined with the specific needs during interaction with the tool options. The vision follows below:
  
* Tools in GIMP enable hands-on manipulation of the compostion, direct on the canvas.
+
* Tools in GIMP enable hands-on manipulation of the composition, direct on the canvas.
 
* The tool options enable the fine and precise configurations that make the tool fit the job.
 
* The tool options enable the fine and precise configurations that make the tool fit the job.
 
* Configuring tool parameters can happen anywhere from almost continuously during a work session - to once in a user's lifetime.
 
* Configuring tool parameters can happen anywhere from almost continuously during a work session - to once in a user's lifetime.
Line 14: Line 14:
 
== Functionality ==
 
== Functionality ==
  
A first step is to assess the current state of the GIMP tool options. Given the wide range of functionality provided by the tool options it was chosen to break down the tool options to their smallest building blocks and work from there.
+
A first step is to assess the current state of the GIMP tool options. Given the wide range of functionality provided by the tool options the choice was made to break down the tool options to their smallest building blocks and work from there.
  
On a toolkit level the smallest building blocks are the visual widgets that, put together, form a graphical user interface, however in the decomposition of GIMP tool options there were also larger functional blocks of widgets and adapted widgets with specific functionality. The full break down can be found in [[Tool Options widgets]].
+
On a toolkit level the smallest building blocks are the visual widgets that, put together, form a graphical user interface, however in the decomposition of GIMP tool options there were also larger functional blocks of widgets and adapted widgets with specific functionality found. The full break down can be found in [[Tool Options widgets]].
  
 
== User Scenarios ==
 
== User Scenarios ==
Line 61: Line 61:
 
* switch back to document1 or document2
 
* switch back to document1 or document2
 
* return to specified tool setups of document1 and document2
 
* return to specified tool setups of document1 and document2
 +
 +
== Evaluation ==
 +
 +
The user scenarios above are a means to evaluate the tool options of GIMP and similar programs. The scenarios are not a strict script to adhere to, but a generalized way to explore the range of functionality provided. The full evaluations are provided in [[Tool Options evaluations]] and consist of evaluations of Inkscape, Krita, MyPaint, Scribus, Photoshop, Illustrator, InDesign and GIMP.
 +
 +
== Analysis ==
 +
 +
Based on the evaluations extensive analysis was performed, which lead to a number of more or less general observations. As this is a key point in the process, the full outcome of the analysis is below.
 +
 +
When working with canvas tools, it is '''not optional to engage with the tool options'''. Checking the tool options parameters is an important part of ensuring that the tool is set up for the next task. There is a definite ‘starting to use the tool for the task’ moment. at this moment the tool options have to be checked, and adjusted when necessary. From there starts ''use of the tool'' with possible combinations of further refinement and setups. 
 +
 +
For '''smaller, single screens''' (1440 and smaller, down to the supported 1280 minimum) the current 5-icon wide toolbox + tool options default setup on the left of the canvas is an unfortunate waste of space. We note that when the available screens scales down from 1440 to 1280 wide, the available width to the toolbox + canvas (i.e. excluding a fixed, default 200 pix width for the dockable dialogs on the right) decreases by 13%. For our design purposes, this is a fluid range, not a discrete step.
 +
 +
In other programs we see a  lot of '''A–B segmentation''' of tool options. This relies on 2-tier structure, major options and minor options, which is a scheme that is hard to uphold in our context (expert use). Ideally we strife for a system that ''feels like single tier''.
 +
 +
A–B is used because of a '''chronic lack of space''' for the permanently visible part of the tool options. This is in part by choice, e.g. proximity to the canvas, room for the canvas and other UI, distances within the options, avoiding busy layouts. The tool options space is also variable, caused by different screen sizes and user layout choices.
 +
 +
We recognise the clear '''difference between the situations''':
 +
* tool setup for the next (phase of the) task, e.g. setting up a brush;
 +
* live canvas object parameter changes, e.g. adjusting the size of a pending rectangular selection.
 +
We also see that in a GEGL future, ''these converge''.
 +
 +
Layouts: '''horizontal vs. vertical'''—and the mid-form: square. Horizontal layouts lead to controls with uniform height (toolbars are either a single line or two-line), designed for compact width—this makes these controls compatible with vertical and square layouts (discrete lego blocks). The GIMP vertical layout leads to (5-icon) wide widgets with longish (= clearer) labels. These are not ''that'' compatible with horizontal or square layouts. Note that there is less vertical space available on most screens, meaning vertical layouts ‘cost’ relatively less. Also, square layouts maximise the the competition with the canvas for space.
 +
 +
Speed of use is optimised of the '''whole widget layout region''' is also recognisable (without doubt) ''and'' works as an area to '''start''' the interaction with this widget (press inside to start changing).
 +
 +
'''Making use of screen edges'''. Placing widgets at the exact screen edge and making them work with their whole area (see above) would give them ''the 5km-wide-(or high)-effect'' (as seen for the mac menu bar). However the availability of such edges is in doubt, because desktop environments and infrastructure utilities are increasingly claiming them, and multi-monitor setups dissolve part of them.
 +
 +
Substantial '''variety in the number of options'''. Having to place only a few options leads to generous/wasteful use of space. The area for option display is quite static in size (changes with screen sizes and sometimes user resizing). It does not adapt to the number of options, this leads sometimes to large empty spaces, sometimes to overflow situations (with in other applications: unreachable options, in GIMP: a space-eating scrollbar).
 +
 +
Seeing the '''immediate effect on the canvas''' of parameter change of a live object in the tool options is ''vital''. Changing a live object on the canvas has to '''reflect immediately''' in the tool options parameters, because this helps with the on-canvas interaction itself.
 +
 +
How do users know they have set up their tool correctly for the next (phase of the) task? It is the ''combination'' of these factors:
 +
# from '''experience''', they just know it is right (this is easiest for discrete mode switches on–off, 1 out of N); this is part of having mastered the tool;
 +
# they know it doesn’t matter that much, '''they simply compensate''' in their own tool operation for the lack of a perfect tool set up, still achieving ‘perfect’ on-canvas results; this is also part of having mastered the tool;
 +
# with live canvas objects, they know they '''only have to get started''', roughly in the ballpark, to refine it further to ‘perfection’;
 +
# a '''preview, or indication''' of the parameter (say, the brush outline) can be evaluated, also in combination with the canvas content;
 +
# a '''try-out session''' with the canvas content, changing parameters and applying to the canvas until the set-up is ‘good enough’, then the session ends and real on-canvas task starts.
 +
 +
'''Refining the tool setup''' while doing the task is actually a pain in the neck, it stops the flow. It is alleviated a bit at this moment by shortcuts for changing ''some'' parameters; keyboard modifier switches for changing modes. The multiple, switchable tool setups strategy can help by making accessible very different parameter setups in random order. But these have to be made, beforehand, or out of presets, or while doing the task.
 +
 +
Static display vs. '''transient interaction'''. After interaction with a parameter widget has started, a mode has been entered and a lot more input events and screen real estate for interaction becomes available. Screen real estate for showing widget interaction stays very limited however, see below.
 +
 +
'''The holy grail of transient windows'''—from dialog boxes to heads-up displays—is that they are exactly ''here'' when you need them (to check, to interact) and never in the way of where users want to inspect the canvas (or other windows), right now.
 +
 +
It is clear that showing and interacting with tool options is divided into:
 +
* '''peripheral''': it must be out of the way of ''what matters'' on the canvas; but not miles away, right on the edge is right;
 +
* '''central''': the main thing within view, right here, right now, is the display of and interaction with tool options.
 +
 +
'''Semi-transparent elements''' over the canvas. Yes, it can be made to work with a flat (not 3D), non-subtle, black + white only widget set. Yes, users can see what is hiding on the canvas under the element. But ultimately, these elements simply ''get in the way'' of getting things done one the canvas.
 +
 +
Correct '''parameter grouping''' helps with swiftly understanding parameter and using them. This also works by a group ‘not existing’, like psuedo-whitespace, when users do not need anything from that group.
 +
 +
'''Docking of tool options''' is always in relation to the canvas. The toolbox needs (for most users) to be right near the canvas (edge), because it sets and indicates the current tool, which is the only way to directly interact with the canvas. Apart from learning about the available tools (remember: ''using'' trumps learning in GIMP) and having direct-click access to setting the current tool, the toolbox seems (surprisingly) to play only a minor role.
 +
 +
'''Sharing tool setups between files'''—including the opposite: not sharing between unrelated files—is naturally handled by the opportunities that 10 (or so) application-global setups per tool offer.
 +
 +
The '''whole widget set''' (see [[Tool Options widgets]]) performs the following functions:
 +
# clarify things, like groups
 +
# show/hide other widget (group)
 +
# set 1 out of N
 +
# switch on/off
 +
# perform action
 +
# set numerical value
 +
# input text
 +
# pick a resource (pattern, brush, etc.)
 +
It is clear that for most of these functions there are currently several specialised widget designs/ implementations—e.g. more direct interaction; can deal with many items—in the widget set used by GIMP for tool options.

Latest revision as of 12:58, 24 September 2012

Introduction

Tool Options have grown out of the need for having a greater control over the active tool's behaviour. However, there has not been a clear guideline of how this interaction is supposed to take place. Examples of what this project addresses are: interaction with the live canvas object; widget lay-out and design; working with setups.

Vision

The vision during the design process is based on GIMP's product vision combined with the specific needs during interaction with the tool options. The vision follows below:

  • Tools in GIMP enable hands-on manipulation of the composition, direct on the canvas.
  • The tool options enable the fine and precise configurations that make the tool fit the job.
  • Configuring tool parameters can happen anywhere from almost continuously during a work session - to once in a user's lifetime.
  • Changing tool set-ups will never break user’s workflows.

Functionality

A first step is to assess the current state of the GIMP tool options. Given the wide range of functionality provided by the tool options the choice was made to break down the tool options to their smallest building blocks and work from there.

On a toolkit level the smallest building blocks are the visual widgets that, put together, form a graphical user interface, however in the decomposition of GIMP tool options there were also larger functional blocks of widgets and adapted widgets with specific functionality found. The full break down can be found in Tool Options widgets.

User Scenarios

Scenario 1 - tool selection & adaptation

  • pick a toolbox tool
  • set options parameters for the task at hand
  • start working with the tool on the canvas

Scenario 2 - tool setups

  • work on the canvas
  • use tool required for the task
  • change the parameters of the tool options, creating a new setup
  • work with the new setup
  • change back to the previous set-up at will
  • continue work on the canvas
  • switch between setups randomly and create new ones as needed

Scenario 3 - tweaking tools

  • work on the canvas
  • refine the tool options for the task to meet requirements
    • swift
    • exact
  • continue work on canvas
  • repeat as often as needed

Scenario 4 - tool options interaction with canvas

  • select a tool to work on the canvas on a live canvas object
  • adjust tool options as needed
    • change immediately reflected on canvas
  • alter canvas object
    • change immediatly reflected in the options
  • randomly repeat as needed

Scenario 5 - setup interactions between documents

  • work on document1 and document2 with specific tool setups
  • open document3
  • create new tool setups as needed for document3
  • switch back to document1 or document2
  • return to specified tool setups of document1 and document2

Evaluation

The user scenarios above are a means to evaluate the tool options of GIMP and similar programs. The scenarios are not a strict script to adhere to, but a generalized way to explore the range of functionality provided. The full evaluations are provided in Tool Options evaluations and consist of evaluations of Inkscape, Krita, MyPaint, Scribus, Photoshop, Illustrator, InDesign and GIMP.

Analysis

Based on the evaluations extensive analysis was performed, which lead to a number of more or less general observations. As this is a key point in the process, the full outcome of the analysis is below.

When working with canvas tools, it is not optional to engage with the tool options. Checking the tool options parameters is an important part of ensuring that the tool is set up for the next task. There is a definite ‘starting to use the tool for the task’ moment. at this moment the tool options have to be checked, and adjusted when necessary. From there starts use of the tool with possible combinations of further refinement and setups.

For smaller, single screens (1440 and smaller, down to the supported 1280 minimum) the current 5-icon wide toolbox + tool options default setup on the left of the canvas is an unfortunate waste of space. We note that when the available screens scales down from 1440 to 1280 wide, the available width to the toolbox + canvas (i.e. excluding a fixed, default 200 pix width for the dockable dialogs on the right) decreases by 13%. For our design purposes, this is a fluid range, not a discrete step.

In other programs we see a lot of A–B segmentation of tool options. This relies on 2-tier structure, major options and minor options, which is a scheme that is hard to uphold in our context (expert use). Ideally we strife for a system that feels like single tier.

A–B is used because of a chronic lack of space for the permanently visible part of the tool options. This is in part by choice, e.g. proximity to the canvas, room for the canvas and other UI, distances within the options, avoiding busy layouts. The tool options space is also variable, caused by different screen sizes and user layout choices.

We recognise the clear difference between the situations:

  • tool setup for the next (phase of the) task, e.g. setting up a brush;
  • live canvas object parameter changes, e.g. adjusting the size of a pending rectangular selection.

We also see that in a GEGL future, these converge.

Layouts: horizontal vs. vertical—and the mid-form: square. Horizontal layouts lead to controls with uniform height (toolbars are either a single line or two-line), designed for compact width—this makes these controls compatible with vertical and square layouts (discrete lego blocks). The GIMP vertical layout leads to (5-icon) wide widgets with longish (= clearer) labels. These are not that compatible with horizontal or square layouts. Note that there is less vertical space available on most screens, meaning vertical layouts ‘cost’ relatively less. Also, square layouts maximise the the competition with the canvas for space.

Speed of use is optimised of the whole widget layout region is also recognisable (without doubt) and works as an area to start the interaction with this widget (press inside to start changing).

Making use of screen edges. Placing widgets at the exact screen edge and making them work with their whole area (see above) would give them the 5km-wide-(or high)-effect (as seen for the mac menu bar). However the availability of such edges is in doubt, because desktop environments and infrastructure utilities are increasingly claiming them, and multi-monitor setups dissolve part of them.

Substantial variety in the number of options. Having to place only a few options leads to generous/wasteful use of space. The area for option display is quite static in size (changes with screen sizes and sometimes user resizing). It does not adapt to the number of options, this leads sometimes to large empty spaces, sometimes to overflow situations (with in other applications: unreachable options, in GIMP: a space-eating scrollbar).

Seeing the immediate effect on the canvas of parameter change of a live object in the tool options is vital. Changing a live object on the canvas has to reflect immediately in the tool options parameters, because this helps with the on-canvas interaction itself.

How do users know they have set up their tool correctly for the next (phase of the) task? It is the combination of these factors:

  1. from experience, they just know it is right (this is easiest for discrete mode switches on–off, 1 out of N); this is part of having mastered the tool;
  2. they know it doesn’t matter that much, they simply compensate in their own tool operation for the lack of a perfect tool set up, still achieving ‘perfect’ on-canvas results; this is also part of having mastered the tool;
  3. with live canvas objects, they know they only have to get started, roughly in the ballpark, to refine it further to ‘perfection’;
  4. a preview, or indication of the parameter (say, the brush outline) can be evaluated, also in combination with the canvas content;
  5. a try-out session with the canvas content, changing parameters and applying to the canvas until the set-up is ‘good enough’, then the session ends and real on-canvas task starts.

Refining the tool setup while doing the task is actually a pain in the neck, it stops the flow. It is alleviated a bit at this moment by shortcuts for changing some parameters; keyboard modifier switches for changing modes. The multiple, switchable tool setups strategy can help by making accessible very different parameter setups in random order. But these have to be made, beforehand, or out of presets, or while doing the task.

Static display vs. transient interaction. After interaction with a parameter widget has started, a mode has been entered and a lot more input events and screen real estate for interaction becomes available. Screen real estate for showing widget interaction stays very limited however, see below.

The holy grail of transient windows—from dialog boxes to heads-up displays—is that they are exactly here when you need them (to check, to interact) and never in the way of where users want to inspect the canvas (or other windows), right now.

It is clear that showing and interacting with tool options is divided into:

  • peripheral: it must be out of the way of what matters on the canvas; but not miles away, right on the edge is right;
  • central: the main thing within view, right here, right now, is the display of and interaction with tool options.

Semi-transparent elements over the canvas. Yes, it can be made to work with a flat (not 3D), non-subtle, black + white only widget set. Yes, users can see what is hiding on the canvas under the element. But ultimately, these elements simply get in the way of getting things done one the canvas.

Correct parameter grouping helps with swiftly understanding parameter and using them. This also works by a group ‘not existing’, like psuedo-whitespace, when users do not need anything from that group.

Docking of tool options is always in relation to the canvas. The toolbox needs (for most users) to be right near the canvas (edge), because it sets and indicates the current tool, which is the only way to directly interact with the canvas. Apart from learning about the available tools (remember: using trumps learning in GIMP) and having direct-click access to setting the current tool, the toolbox seems (surprisingly) to play only a minor role.

Sharing tool setups between files—including the opposite: not sharing between unrelated files—is naturally handled by the opportunities that 10 (or so) application-global setups per tool offer.

The whole widget set (see Tool Options widgets) performs the following functions:

  1. clarify things, like groups
  2. show/hide other widget (group)
  3. set 1 out of N
  4. switch on/off
  5. perform action
  6. set numerical value
  7. input text
  8. pick a resource (pattern, brush, etc.)

It is clear that for most of these functions there are currently several specialised widget designs/ implementations—e.g. more direct interaction; can deal with many items—in the widget set used by GIMP for tool options.