Separation of GUI and Application Status

It’s no fun if you need screenshots for documentation and then buttons change position and icons their color late in the game 😉

There’s the possibility of doing a graphical search-and-replace, but this only works for isolated details.

To really improve the situation, you would have to go beyond merely taking a bitmap representation of what is happening on the screen. Ideally there would be a clear separation between the state and the rendition of all running application represented on the screen. You could take a snapshot of that state and render a screenshot later on, with changed software, any theme and even a different language for all system/application-supplied strings.

Obviously there would be limits to how far the system and applications could be changed until a state couldn’t be rendered anymore.

The same architecture could also be great for scripting, alternative interfaces (various form factors, accessibility requirements) and on-the-fly GUI development and customization.

Window Control Marking Menu

While it’s actually about a marking menu implementation in Flash, this gives a good introduction: Extremely Efficient Menu Selection: Marking Menus for the Flash Platform.

Marking menus vs linear menus on Youtube.

Could marking menus be used for window management?

There could be a menu button, but that would often put the menu in a corner so that fewer directions could be used efficiently. The menu would have to be designed for either the right or left edge of the screen.

Requiring a right click makes the functionality hard to discover, but one could provide a hint attached to the mouse pointer.

The menu appears on pressing the right mouse button. The center is neutral and allows to cancel the operation by simply releasing the mouse button again. Selection of options happens based on direction alone, distance beyond the initial threshold plays no role. This allows fast gestures. It might be worth consideration to place Maximize in the center, as it is a rather safe command, but one might want to offer a different way to cancel the operation, then.

During menu-use, the pointer disappears and a line is shown to indicate the chosen direction / the gesture being drawn. Sub-menus are reached by changing direction or pausing, although there are variations of marking menus where the mouse button has to be released.

The current workspace can’t be selected. Sticky (always on visible workspace) is presented as exclusive option instead of a separate state as in the current linear menu.

Marking menus can be combined with other elements, here an alternative for workspace selection. Sticky is presented as a kind of parenthesis.

File Handling

Recent discussion on the Gnome-shell list made me think about file handling in general once again.

I think it would be beneficial to Gnome (or KDE or …) to have a long term plan regarding where some fundamental things should be heading. Here’s some food for thought, knowing that everything I bring up here comes with a long tail of questions:

Uniform file handling liberated from hierarchical file systems

Every new/separate piece of interface the user has to deal with means more to learn and more to remember (several instead of one mental model). This speaks against a separation between accessing files and managing files (a design decision for Nautilus that I wasn’t aware of, previously). It also speaks against having various interfaces for documents, images, audio and video files, each designed independent of the other.

The problems of having to deal with huge numbers of items and no sane way to put each item into only one category (folder) affects not only media files, but also documents.

Meta-data (tags, categories, relations) is the answer regarding organizing and accessing files. This should be handled in a uniform way for all kinds of files (maybe with exceptions for some system files).

But there’s a problem as long as users have to deal with hierarchical file systems. Meta-data on top means there will be situations users have to understand and deal with 2 systems where on could suffice. The question where files are actually stored should be part of the meta-data in some way.

Versioning

More people should get to enjoy the benefits of versioning. You shouldn’t have to drop to the CLI or install GUI tools. Versioning should be just there as open invitation and comfortable helper.
(Heck, a whole system installation could be a clone from a distribution repo, I guess.)

EDIT: KDE’s Dolphin will have version control support, although not quite in the open, direct way I’m envisioning.

Sharing

We not only deal with more files of an increased number of types, but also have more means of transfer and more places they end up on. Time for tracking which file in which version went where or to whom right from your desktop. The same mechanism could also help with managing archives on removable media.

To link or embed?

Should images in a presentation be linked or embedded? Both have their pros and cons. How about neither? As long as all parts are on the local system, use references to files. References that do not rely on a path or filename and thus do not break. If the main document is copied to a different system, make sure all the required files follow.

Compressor Plugin GUI

Sampo Savolainen asked me to design an audio compressor plugin GUI. This triggered a thought process with a first result that is guaranteed to be far way from what he had in mind, but before I may head in a more conventional direction, I just have to explore this 😉

Background info on dynamic range compression.

I wondered how one could express what each control of a compressor as the one written by Sampo does. Giving an idea of the signal path and relations between controls. Ideally without labels, even.


Full size

The controls provided are:

  • High-pass filter on/off for the analyzed signal. Left side. Here I neglected that the signal is split in 2, one for measurement, the other to apply the effect on.
  • Treshold. Green line in the graph. Should be draggable from the whole grap area.
  • Ratio. Blue fader with round knob, synchronized with the blue line/dot in the graph.
  • Markup gain. Fader with red arrow. The graphics show the relation to the first graph.
  • Attack and Release time. Below the stop watch icon. I’m worried that the chart below the faders is rather hard to get, so it might be best to drop it and to add labels.
  • Dry/wet amount. Right side. The output touching the right corner and the fader handle for this are one.

High-pass switched off:

On Hierarchical File Systems and Storage Location

The problem with hierarchical file systems

It’s clear that hierarchical file systems are not good for organizing music or photos. In short, the problem is having several attributes of interest, where no single one of them is more suited to lend structure than others. This same problem applies to all kinds of documents too, but the needs and wants regarding meta-data are more variable and harder to tackle there.

Specialized library-management applications, one for each kind of media, lead to a fractured user experience and data islands. It should be possible to exchange objects with meta-data over the net, without the user having to take special care. There needs to be a generalized solution.

This topic is old enough to be discussed in the FLOSS realm 😉

As long as hierarchical filesystems stay around as layer on the bottom, there will be cases where users are exposed to them. For example on installation, backup and restore. Generally all cases concerning the physical location of data. You get a leaky abstraction. The fewer concepts the user has to deal with, the better.

I think object storage with attributes should happen on the file system level, so applications can build on a common foundation and there is no lower layer poking through.

Storage location as attribute

With current files systems, storage location is implied by the path of a file. On systems of the unix family, with single-rooted file system trees, it’s not even obvious which drive a given path maps to. One symptom of this is that dragging files in a file manager from one place to another will either move or copy the files, depending on whether the places are on one drive or not. Quite a bit of background information is required until a user can understand this behavior.

I think storage location should be dealt with explicitly. To do so, it could be presented to the user as just another attribute in the form of a list of one or more locations.

  • Storage locations could be partitions on various media, or servers that do not reveal actual physical location.
  • Locally there would need to be a catalog of all known objects along with their lists of storage locations. It would have to be updated on remote changes.
  • Each location would have a catalog for its own content. However, I’m not sure if these should contain complete lists of the other locations per object.
  • To identify objects across several locations, they would need to have unique IDs as sole invariable attribute.

Combined with versioning, this could be an elegant way to deal with:

  • Downloads: store the origin of the initial version with date of retrieval
  • Uploads to file hosts or directly to contacts. It’s just adding a location for a specific version.
  • Constant mirroring of important data to another local location without any special tools.
  • Tracking backups. Keeping note of what versions of objects are stored on what removable media.
  • Mirroring/synchronization. Remote locations could be coupled with a schedule for synchronization.

Infolders – Informative Folders

There’s an old idea that has been floating around, about using varying folder icons to convey a little more information. Like switching to an icon of an old, used, dusty folder for folders that havn’t been touched in a long time or using more or less stuffed folder icons.

But what if we move a bit away from the graphical side of the folder metaphor, to have more room for information about contents?