

Flatland & hierarchies in UI design  - dirtyaura
http://ignorethecode.net/blog/2009/10/11/flatland/

======
NathanKP
I agree that a graduated hierarchical system is best. A good model for
designers would be the techniques used by modern game designers. Most modern
games are extremely complex and have a graduated system in which you master
one aspect before moving on to the next. If learning a program or OS can be
done in a similar manner to learning a video game it might work.

Personally I think the solution to the "hierarchical" problem is search. Apple
has done a great job with the Spotlight tool. A similar "search" based
function launcher might work well to provide access to features that beginning
users don't care about but advanced users want.

~~~
ugh
What are you referring to? Did you read the linked article?

------
cturner
I'm using the opportunity of this article - which is centred around iphone
issues - to discuss something related I've been thinking about in the hope of
thoughtful feedback.

There's a progression through ideal structures as your volume of data changes.
1) Flat. Like the filesystem with early versions of DOS. 2) Tree. As presented
by contemporary operating environments. 3) Tagged collections.

There's a recurring pattern where you have a home directory and you get so
much data in it that you start losing it. I might deal with five support
requests a day, and want to reference them for the next two years. I can
usually remember when I dealt with them chronologically, but don't trust the
standard filesystem (and backup operations, etc) to preserve this. This guy's
comments about spaciality are apt for the iphone setting.

This quest for spaciality gets taken to stupid conclusions, as in the OSX
finder (I'm now diverged from this guy's post). Spacial placement is
irrelevant for anyone dealing with large amounts of data, and not a priority.
And that's pretty much anyone who uses their computer for work.

I've written a unix tool that allows me to manage my data as collections of
projects. It's called silo. To create a project I do this:

    
    
        $ si project name
    

It creates the following:

1) Directory: $HOME/silo/20100102.aa.cturner.hostname.project.name

2) Symbolic link to that directory at $HOME/seq/03.project name

The filename in #2 above assumes it's the fourth third project I've created -
the next one will be 04, then after 09 it renumbers them so they all have the
same number of digits so ordering works for visual display and tab completion.
I can destroy projecs, and then rebuild the sequence structure to compact it
with 'si -r'. It gives me unique paths for tab completion.

I can rsync these structures around and have complete confidence that it will
retain the date, username and hostname for me to order and sort on, because
it's inherent to the filename itself of the base directory. This makes for
easy backup arrangements using crontab and sshkeys.

I haven't released it yet because I'm just to finish off tagging. Tagging will
allow me to crete a second symbolic link structure so that I can go into this
directory to find links into the projects which relate to work:

    
    
        $HOME/tags/work
    

Filesystem metadata is the wrong direction because it doesn't work across
simple backup solutions properly, and if you're discouraging users from
backing up then you're doing something wrong.

You could offer GUI environment consumers an interface that was both
discoverable and scalable by moving the emphasis on 'directories and files' to
'projects and documents'.

Back to the issue of structural complexity. We've had flat languages
(scripts), then programs with goto (still pretty flat), then structured
programming (tree). Then modules and packages which is starting to enter
collection territory, and cpan - more so. But that emphasis is on the library
systems rather than the code. I sometimes thing about this at a high level and
wonder how far you could push the boundaries on building a 'collection-
oriented' programming language. For example - could I have a cron script that
threw a launch wrapper at all folders which were tagged 'cron.run.me' and
which weren't currently tagged 'running'? Within the project the logic could
just be pointers to modules. The effect would end up being a bit like the
scheduler you get in socket programs where there's a list of things to do, and
the effect of an action in that list would be to defer something by
registering it in another list for some other action to deal with, and then
closing.

