Some interesting interface ideas
I have recently started musing
about possible new ways of interacting with a computer. Of course, I do
this a lot, but here are some ideas I have been pondering (when my
programming improves I might be able to prototype these ideas for use in
Warbuntu):
1) Tabbed
interface.
Individual applications have tabs in them,
the taskbar-style widgets usually running along the bottom of the screen
are like tabs, so why not set the whole computer interface into a tabbed
environment?
Every
application would be fullscreen. There would be no floating windows so
programs with such awful interfaces as recursive windowing systems (I
mean YOU Photoshop!) would be avoided at all costs. Viewing multiple
areas on the screen (like the GIMP’s various dialogues) could be done
via panes.
At the
top of the screen there would be, right in the centre, the name of the
current tab. The name would be editable, so files can be opened (using
search), URLs can be visited (names would not be “Firefox - website
name” they would be “http://www…………” like in
Sugar),
programs can be launched, etc. Basically it would be like the
GNOME
deskbar.
Beside this there would be options for
controlling the computer, like
logout/shut
down/restart/lock screen/etc.
Fork 1) Underneath this would be a universal
toolbar. Like
AmigasOS (sans
MagicMenu)
has one menu at the top (and this is used in
OpenStep too so
GNUStep uses it and apparently
Apple
MacOSX does too) but it would
extend down to new, open, save, cut, copy, paste, etc. buttons. There
would be a few catagories of these, each in named tabs (Office, Web,
Graphics, Multimedia, etc.), so that graphics applications would work in
the same way with the same toolbars, textual applications would work in
the same way with the same toolbars, etc. These toplevel tabs would be
the parents of the rest of the tabs.
Inside these, underneath their toolbar,
would be the application tabs. These would be named after the
application, so
“Writer Word
Processor”,
“Calc
Spreadsheet”,
“Impress
Presentation”, “GIMP Image
Editor”, “Inkscape Image
Editor”, etc. this would follow a sane naming scheme which I will
put in a seperate entry, since it has become too long here and deserves
to stand alone incase later citation is desirable. Inside each of these
would be the individal open files, the currently active file having its
name in the top
deskbar-type box (with
metadata aligned to the right (or left in right-to-left languages of
course) to allow files to have the same name and avoid messy
hierarchical filesystems).
Fork 2) Use an arbitrary tabbing system,
like current virtual desktops, where tabs can be arranged on a
per-project type basis (ie. Having multiple webpage tabs available with
click which contain information for a document being word processed.
This would be possible in scenario 1 only for single tabs of each type,
ie. switching to “Web” could show the previously looked-at webpage, but
other pages would need 2 clicks, Web then the desired page). This would
lose the universal toolbar idea, and could either use a toolbar in each
application, or switch between standard
toolbars.
The
starting tab could be a list of common applications, and maybe even
include little applets like the
Mezzo
desktop of
SymphonyOS.
Various keyboard shortcuts could navigate
the tabs (Ctrl+cursor keys and such), making this system very keyboard
friendly, and thus very fast for those who know their way around a
keyboard and who know the shortcuts.
2) Thumbnail file
browser
After
watching Macslow’s
little
video demo I began to think how easy to use such an interface would
be with a remote control. Direction buttons, along with perhaps some
secondary up and down buttons (channel, volume, whatever) being used for
page up/page down.
Images can obviously be given thumbnails in
such a way, and therefore be easy to browse. Videos could be represented
by thumbnails, and TV series or
movies with a disturbing
number of sequels could use a standard image, or if one is not
available an arbitrary thumbnail from a video inside (which could be
fast-forwarded or rewound by the user to get a recognisable image) to
act like directories (with an Up or Back arrow image available inside
any non-top-level directory). Music could be stored per album, with
album covers for directories obviously, then the same inside with
overlayed track numbers.
Of course, the idea of directories
should
be gotten rid of, so in a full computer environment, not limited by
the limited input of a media centre style setup, this could be expanded.
With gestures available via mouse, or better yet some kind of
finger/physical pointing object
(touchscreen,
“Surface”,
whatever), the grid structure of elements can be disposed of. A
BumpTop/Lowfat
kind of file manager would be left, and I think the
Lowfat way of
pulling different objects together would be a good way of handling the
“directory” issue, getting rid of any kind of hierarchy by making
everything available on the same level, but capable of being organised
or grouped. (Although I am not sure how objects in this single level
would be grouped due to metadata, since a song can exist in catagories
based on artist, genre, etc., but only when going through a
multiple-level system (basically, narrowing down the current selection)
so staying in one level there would have to be multiple instances of
objects on display, which wouldn’t be good news for confusion levels
(unless some kind of overlay like translucent lines were used connecting
the multiple instances of the same object)
I say “objects” rather than images, music,
etc. as I think the idea of
KDE4’s
Plasma and its
“Plasmoids” is a good one,
which is essentially that of making small, arbitrarily created
applications movable around the workspace (I am on about the way it
handles icons here, where icons representing files essentially become
miniature representations of application instances (ever used an
interface which Iconifies instead of Minimises, like
RISCOS? Imagine every file icon
actually being an iconified viewer application with that file open) To
clarify what I mean, imagine dragging around an icon for a piece of
audio (let’s not use the term “file” here, as we are not bothered about
the hardware implementation). Instead of having an audio playing
application, which is fed pieces of audio, why not have play buttons
embedded onto the icon? In that way the icon is no longer representing
the audio so much as an instance of an audio player playing that audio.
Using the grouping of
Lowfat these could
be made into playlists of audio and video, slideshows of images
(although this is slightly less drastic, since images are represented by
themselves, and thus a “slideshow” would just involve shuffling through
the image objects), etc. Since applications aren’t constrained to
specific sizes or coordinates thanks to
Metisse and more recently
Compiz-Fusion,
there is nothing stopping application “windows” becoming movable,
rotatable, resizable (as in, proper resize, where it zooms in and out)
icons.
Every piece
of data would also have an Edit mode, which would just be a slightly
more complicated version of the play instance, and thus the UI should be
similar.
Ah, the
tangents my mind is going off on tonight! The tabbed idea might be a
solid base to work from to produce a consistent (and therefore slightly
limited, but vastly easier) variation of what we already have, and that
idea has been bouncing around for a while in the cavernous space behind
my eyes. The second, however, is pretty newly formed, although has
obviously been quietly swelling somewhere in my mind as the various
links I gave added to it. Now the pan is boiling over and I am enjoying
the sweet sweet flow of scalding milk that follows. What’s more, it
should appeal to the computer users that think
a spinning OpenGL
carousel of faces instantly makes a 2D list of users more “user
friendly” (as in, bombard them with so much eyecandy they are too busy
masturbating over it to notice how much their computers are costing).
I’ll try to make a Moho animation to visualise the crazy forks I am
taking with this one. Ooo it’s edgy!
PS: The service pack maker is coming along
nicely, I’m learning Python pretty quickly. A few troubles with circular
dependancy inclusion at the mo’, but easily solvable if I use a global
dependancy list, rather than a per-package one.
Tatty bye!