Some interesting interface ideas

Posted on by Chris Warburton

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!