zdesktop

Zooming into a hierarchy of nested directories (FileMage)

Zoomable User Interfaces

Command line interfaces are very powerful but they are suited only to expert / advanced users. Graphical user interfaces are intuitive but what you see is all you get: you cannot automate manipulations as in scripts, you cannot indicate what is not immediately visibile, etc. Today the user interface is crowded by windows, icons, menus you can point at; the graphics is fancier (animations, transparency) but not useful (high-resolutions screens often display as much information as an old 80-by-25 character display).

Zoomable user interfaces exploit a natural way to organize / navigate files. You can zoom out to get the overview or zoom in to details, as desired. There is no need to open the application, load the data, edit, save the data and close the application. Just zoom in, edit and zoom out when you are done.

What we have now

ZDESKTOP is a zoomable file system viewer. Directories are rendered as square boxes. Hierarchy of directories are rendered as a hierarchy of nested boxes. Text files and images are simply rendered as they are. Objects in a directory are layout in a square grid, some space (user selectable) is left among neighboring objects.

ZDESKTOP is designed for efficiency: speed and low memory consumption. Directory's content is loaded only if the directory is whithin the area visible on the screen and if it is big enough; otherwise the corresponding thumbnail is used. Thumbnails are generated when directories are visited, a default thumbnail can be specified.

ZDESKTOP is easy to use. The interaction is implemented as follow (it can be changed in the future):

• use the mouse wheel to zoom in and out, press the mouse wheel (middle button) and move to pan
• single left click to zoom a given object to full screen (if you click the empty space among objects, you are clicking the directory, so the directory is scaled to full screen)
• left click and drag to move a given object (if you move the object outside its box nothing happen in the filing system: the file is not moved outside the corresponding directory)
• left double click to activate handles to resize the object
• single right click to zoom back (push away) a given object - right click will be probably used for context menus when available

ZDESKTOP is java based, hence it is multiplatform. It has been tested under Microsoft Windows, Linux and MacOS.

What we are doing

Here's a short to do list.

• slow access to remote data (disk I/O, network throughput): objects are loaded in independent threads; modified objects (e.g. thumbnails) are saved in independent threads
• slow rendering: speed up by using coarser representations when displayed representation is small; otherwise use progressive refinement whenever possible
• invisible objects (outside viewable area): use spatial indexing techniques; invisible objects (too small to be seen): use filter before load
• populated directories: they are nodes with a lot of children-nodes, childrens should be grouped together in macro-nodes
• heavy objects (like BIG pictures or complex vector graphics): should have thumbnails or simpler variants to be used when their displayed representation is small; should be divided in chunks to be used when only a portion is displayed (chunks can populate a directory with the same name)

What we see in the future

Here's some idea for the future.

Interaction enhancements

• EDIT: editable text when it is large enough (refer to Archy The Human Editor -THE- by Jef Raskin); editable images (sticky tools will appear around the image); editable metadata (currently metadata specify position, dimensions, colors, transparency, etc)
• DRAG/MOVE: currently it is continous, there should be a user-selectable discrete grid; alignement tools to ease the layout should be included; dragging a file to a different box should result in a file move operation (remember that boxes represent directories)
• layout: currently objects arranged in a square lattice; spiral phyllotrees are one of the most efficient ways to arrange an unknown number objects so that they do not overlap
• layout as it is done in TeX: an horizontal/vertical sequence of boxes (they may contain recursively other sequences) interspersded with stretchable space / elastic gum (fill)
• treemap concept: currently only the position is exploited; color and size can also be exploited to convey more information (e.g. newsmaps, hard disk views, etc)
• layers: there should be at least one layer for sticky objects that do not undego pan/zoom; this layer can be serve several purposes: display object-specific editing tools; clipboard pocket for cut-copy-paste operations; magic lenses...

(Scalable) Graphics

• vector graphics support: at first with simple text metafiles (list of drawing commands), then with standard formats like SVG (scalable vector graphics)
• hardware graphics acceleration, such us OpenGL (3D) and OpenVG (2D)
• 3D graphics support: as in PDF files where the user can interact with 3D objects; interaction should be as simple as in Google SketchUp
• JPEG-2000 support: it is more efficient than the well known jpeg, it is scalable (decoding the first portion of a file yields a reduced resolution image) hence when zooming out thumnails need not be generated, it is has tools like region-of-interest and precinct (decoding a portion of a file yields a portion of the image) hence when zooming in the entire image need not be decoded and clipped

(Active) Metadata

• metadata storage: now metadata (position, dimensions, colors, transparency, etc) is stored in a file with the same path/name and .zzz extension; a mirrored tree structure can be used to leave the original tree untouched; a database can be used to store efficiently such many little files, spatial indexing can also be used
• extended metadata to let the user associate methods/code to events (e.g. right-click to pop-up a given context menu, double left-click to call the associated application); this will let the user create a GUI without using a GUI library, windows will be directories, buttons will be images with code associated to events, etc. The GUI will be managed by managing files/dirs.

Plug-in (formats support)

• plain text with support for simple modifiers such us *bold*/italic/ _underline_
• plain text with tags to modify font, size, color (syntax highlight), paragraph justification, line spacing, etc
• plain text with LaTeX tags (useful to typeset math, greek text, etc)
• Microsoft office format support (Word, Excel, PowerPoint): at first with a visualization plug-in, next with a visualization/limited-editor plug-in, in the end the user wil see the icon, then the preview, then the application will be opened (and the window will occupy the corresponding zoomed area on the desktop)
• Adobe Acrobat PDF format support (including 3D object support)
• others: rich text format (RTF), etc

The far future

• Everything is a file (or everything is a device, as in Linux). Programs can be seen as a hierarchy of functions, if you put every function in a file, then a program can be transformed into a hierarchy in the filing system. The same can be applied to variables (no more problems with scope of variable, just use the right path). The same can be applied to objects (made of methods/functions and properties/variables). To run a program simply copy the hierarchy from C: to CPU: The same can be applied to file attributes: the hidden flag of the file FOO can be implemented as a file (FOO/hidden) with the proper content.
• Infinite namespace (blurring distintiction between filename and content): today the filename (including the path) and the content are two different things. Think about the possibility to have the content as the last part of the filename. Renaming/moving could be done by editing the filename (no specific function needed). Of course, beyond read/write/append also delete/insert should be allowed in the middle of the file(name).
• Tag based filesystem: today the file system is strictly hierarchical; as a workaround you can use links to see the same file in two different directories; tags however are much more flexible: to put a file in a given directory means to attach the directory name as a tag; block/set operations become possible, as vicinity intersection in search operations (have a look at the future vision in ReiserFS)

History

2007 v3 by Silvio Moioli

Partial rewriting. Multi-thread management of semantic zoom. Server/client split.

2006 v2 by Michele Bologna

Complete rewriting. Visualization of directory trees. Semantic zoom: automatic creation and use of thumbnails. Objects can be moved. User configurable visualization parameters.

2005 v1 by Vincenzo Manzoni

Zoomable visualization of images, text and directory trees. Metadata in XML files. Only pan and zoom of the desktop.

2004 v0 by Andrea Vitali

Idea to replicate the application designed in 1984 by Jef Raskin, Apricus Inc., to ease the management of database in hospitals. When started, you were presented with the city map. You could zoom in hospitals, buildings, floors and finally rooms. When patient data was visible it could be edited.