Single-window mode specification

introduction

This is the specification for the single-window mode, in addition to the multi-window one.

analysis + design goals

Designing the single-window mode (swm) interaction solution boils down to the following tasks:

1. understanding the user needs behind the huge request for single-window and base the overall design on it;
2. design the switching that controls which is the current active file under swm;
3. design the opening and closing of files under swm;
4. design working side-by-side with several files under swm;
5. redesign docking and tearing off of dockable dialogs, and whole columns of them.

understanding single-window

The interest from (potential and ex-) GIMP users in single-window is huge, literally 100 time higher than any other GIMP topic. Absorbing and classifying all the input, we define the following user needs that drive this interest:

single application instance

This is the user need to see the (usually single) GIMP application instance that is running represented as a single entity. e.g. one item in the ‘taskbar,’ only one menubar (not one for every open file).

stop fighting window managers

Users are fed up with GIMP dialogs getting lost under document windows; with the ‘taskbar’ being stuffed with non-entities; with having to raise several windows and dialogs separately when GIMP becomes the foreground application; with how window minimisation works. This has a lot to do with recalcitrant window managers and window manager hint translation on several platforms. All this cannot be ‘repaired’ by patching all these window managers and gtk glue code to non-linux platforms. Users see the magic bullet in stop fighting and going single-window.

single working plane

This is the user need for a continuous work surface where everything is GIMP, and only GIMP, in order to concentrate on their work. It also is the need for an end to every GIMP window, toolbox and dialog floating around in the desktop window stack individually.

Reminder: the world is still a 50-50 place: 50% of users want to keep the current multi-window way, and the other 50% is looking forward to a single-window interface.

Putting all this together, a single-window interface aims to fulfil the user need of 50% of GIMP users. We also feel that for each of these users, the user needs are slightly different: they consist of a linear combination of the three user needs outlined above.

expression

While further investigating the essence of single-window, we hit upon two orthogonal dimensions of expression of above user needs.

The first dimension is a scale with at one end the need for a flat + clean interface and on the other end the need for free-form working. These are defined as:

flat + clean interface

This is a purist form of the single working plane. All the elements that form the plane—toolbox, dockables, menubar, status bar and a ‘working space’ for working on the file(s)—are non-overlapping and with no gaps between them. As a result of this everything is laid out in rows and columns that pad themselves out automatically, and the working space is simply defined as the consecutive area that is left over on the working plane. Another result is that no matter how users configure their flat + clean interface, it is nigh impossible to create a mess. Everything stays neat.

free-form working

Here users need certain single window traits, but not all:

• they need the single working plane to block out all other applications on the desktop, like an opaque garden fence blocks the view to the neighbours;
• they need the single application instance;
• they also need that the toolbox and dockables are solidly located on the edges of the working plane, are always on top of other applications when GIMP is the active application, and cannot overlap with the GIMP files that are open;
• however, they find flat + clean too rigid, they need to be able to place any number of open files anywhere, any size they like, overlapping within the working space. Setting this up ‘just right’ needs to be a low amount of work.

Free-form means that—compared to flat + clean—extra measures need to be build in to manage a messy working space that can be so easily created. This includes a secondary representation of each open file, which lets users switch to any of them; measures to temporarily hide open files; measures to concentrate on one (or more) files for a while.

After presenting a flat + clean interface as the one and only form of single-window interface, the feedback told us that there seems to be an opposite free-form working need.

The second dimension of expression of user needs is at one end the need for concentrating on a single view and on the other end the need for working side-by-side. These are defined as:

concentrating on a single view

Although multiple files can be open, the whole working plane is occupied by a single view of the current active file. There is only a minimal, non-interfering representation of the other open files, which lets users switch to any of them (of course this is fast and direct to operate, because GIMP product vision demands it).

working side-by-side

There are different forms of of side-by-side working:

• sourcing material—inspiration, reference, graphics, layers, in the future: operations/treatments—from other files, while working on one or more files;
• synchronised working on a set of files, can be many, 15+, keeping them artistically together as a set;
• parallel views on the same file: different layer composition, zoom and/or position;
• seeing the same: synchronised zooming and panning of two or more files.

Working side-by-side asks for dividing up the working space into several ‘containers,’ to show each of the files (or parallel views on a file). There can be any number of these containers (within practical limits). The relative sizes and layout they need to appear in is highly variable, setting this up ‘just right’ needs to be a low amount of work. At any given time only one container can be the active file.

Discussing single-window always implied concentrating on a single view. But then in every discussion the concrete need for working side-by-side comes up.

The two dimensions can be multiplied out in the following matrix:

	concentrating on a single view	working side-by-side
flat + clean interface
free-form working	illogical combination

switching the current file

‘Is there someting better than tabs with filenames on them?’—ps

A good system for switching the current active file (within a single window) depends on:

• reliable and fast identification of each open file;
• fast, random access switches to make any open file the current active file—fast to operate that is, like switching between 3 files and do an operation on each, in 6 seconds;
• these switches should be discrete in size and make-up compared to the main action in the working space.

The real bottleneck is in the identification of the open files. The main methods for this are:

thumbnail

as generated from the (current) layer composition. This works reliably and fast under the same conditions that icons work reliably and fast: the macroscopic shape/motif and/or the macroscopic color for each one is really different. Besides that, what also really helps is that a significant difference in aspect ratio of the files is reflected in the thumbs. When these differences are there between each of the open files, this method for identification works most naturally. When this difference gets subtle, thumbnails get similar enough for identification to break down.

filename

almost always unique between files. Almost, because files can be in different directories/machines with the same name. Even under the best of circumstances—the filename of each open file describes it brilliantly and distinctly—there is the delay involved with users connecting the file to the name. And it gets worse from there, with more cryptic and nearly identical names, down to the hell of machine generated ones: IMG184645. It just gets slower and more error prone.

spatial

more a back-up system for when the above fail: ‘the original is on the left, the changed version next to it and the inspiration is on the right.’ Fits with a concentrated stretch of working. Can fall apart, simply with the passing of time or a change of what is on the working space. Must be ‘reprogrammed’ then.

So where is the bottleneck? It is in that identification by filename works well enough (according to our criteria) only in a minority of cases (say 30%) and by thumbnail even less (say 20%). Combining the two gets us beyond 50%, because so-so working thumbnails and so-so working filenames can reenforce each other to a usable result. Still, a sizeable percentage remains where only slower methods of further, deeper inspection—of the file contents (e.g. pixels or layer structure) in full fidelity; the canvas size; the repository location of the loaded file—can help to positively identify.

Combining a filename and a thumbnail into a small area can be challenge. Filenames render (in most scripts) into a long horizontal strip of pixels. We estimate that the aspect ratio distribution of the canvases of files is a twin-peaks curve, centred on the square (1:1) ratio, with peaks at approximately 3:2 and 2:3 ratios. In short: something blocky. Integrating the two involves placing the blocky thumbnail at the head or tail of the filename strip, or rendering the filename strip inside, above or below the thumbnail block.