Single-window mode specification

introduction

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

module vision

what: Single window mode is an extension of GIMP’s workspace configuration system. This regulates space, order and hierarchy of file canvases, command structures (menubar, toolbox) and auxiliaries (dockables, dialogues).

for who: GIMP users: see product vision. For long-term work and drive-by editing. On files big and small, stand-alone and in sets.

the value: Enable at any moment to set up a workspace that is ‘just right,’ for channelling creativity and/or productivity. Enable users to traverse the workspace hierarchies as fast as they can think of it.

design requirements

user needs

The interest from (potential and ex-) GIMP users in single-window is huge, literally 100 times 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.

Requirements

When we look at these user needs in the context of the exisiting GIMP we can make a list of requirements for the single-window GIMP:

All functionality that is in the multi-window system is still there in the single-window system
- in a single app instance
- in a single working plane
It must work across dual monitors
It must support the creation of hierarchies of dockable dialogs
- which means they must be able to be organised into a structure
- when floating they are in their own window—or window-like container
It must support easy and speedy file switching. This means top-end of professional users, working across many files and requiring very fast and pain-free access to them, must be supported.

Key functionality

configuring the working plane:
- toolbox
- tool options
- dockable dialogues
- working space and the size and position of the viewport of each open file within
switching the current active file
working side-by-side
initiating opening and closing of files, especially the short-cuts

Design Scope

Some parameters which express the limits to which we will will design. This does not mean that actions outside these limits will not be possible, or not be supported. rather that they fall outside the considered limits to which we will design for optimum use.

Files open: 0- 30

Consider, however that the more files there are open at any one time, the harder switching and configuration of these files becomes.

Files open and visible 1-23

When more than one file is open and visible, it is assumed that these files will be able to be viewed concurrently.

Consider the higher the number of open and visible files, the harder it becomes to see these files, and configuration becomes increasing complicated.

Workspace configuration

When a workspace is configured often, configuration needs to be fast

When a workspace is seldom configured , configuration can be slower.

expert evaluation

Here is the list of ‘workspace configuration systems’ to evaluate:

tabs with text labels, as employed by web browsers (special section: chrome’s tabs on top as window handles);
windows in window, as prominent on ms-windows;
the image parade + polaroids system as described in peter’s blog;
split panes in gtk: gtkpaned widget;
the curlyankles extension library to gtk;
the current multi-window system of GIMP;
windows-7 snap, peek and shake

analysis + design goals

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

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

understanding single-window

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 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.

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 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 WM issue

Let’s not kid ourselves: the fact that users can work on several files inside a single application window, means that this application must offer a substitute for window management to let users regulate on which file they are working at any given moment; how much can be seen of any file at any given moment; which size and position relationship there is between all open files at any given moment.

A practical example is what web browsers do with tabbed browsing: very simple rules take care of above requirements: show one webpage at the time, switched by tabs.

A bad way of going about this is trying to implement a knock-off copy of desktop window management inside the application working space. Apart from the difficulties doing this right for multi-platform and the suspicion of rigging up a travesty, the ‘quite but not quite’ factor will only lead to unfulfilled user expectations. Instead we must look for a system and representation that does justice to the fact that we are inside an application.

One thing that really needs to be kept in check is the amount of UI chrome (identification label, move handle(s), resize handles, buttons for quasi-wm functions, e.g. close, hide, lower, minimise, maximise) that is introduced beyond the basic file display-shell (canvas [+ scrollbars] [+ rulers]). All this eats into the available working space (yes, sometimes not, but then it is stuck under other things, so not working). It is clear that this UI chrome cannot overlap the file’s canvas. It could however share space with the scrollbars, which are nearly always there. Another bold solution is to not show certain things, like the identification label, ensuring that users’ needs are taken care of in another way.

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, identification breaks down quickly.
filename: almost always unique between files. 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: the thumbnail is 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.

one more thing

Let’s not forget one important factor, users:

they engage with the files they are working on, making identification not a zero-knowledge game;
they ultimately recognise files by the composite displayed on the canvas, their layer structure and layer contents;
they do have in a lot of situations control over the filenames they use, making it their own, hence usable system.