Desktop Metaphor

[cxzuk]

Do you think that the desktop metaphor for orangising information is "out dated"? What is your fav way to orangise your information?

MikeyB

[AJ]

Hi,

Although it sometimes feels outdated, I'm happy with the desktop metaphor and am very familiar with it.

I think that fast searches could be the thing that changes how this works (although how, I'm not sure). For example, the Vista/7 Start Menu's - I'm much happier using the new search-style menus than I am using the old "Programs->Applications->Notepad" system. In fact, I'm so much happier with it that I don't bother with desktop items or quick launch now.

I think that this "real-time search" thing is still only in its infancy and offers lots of potential. Somewhere.

Cheers,
Adam

[AndrewAPrice]

I've bought up this topic a lot in my attempt to find a modern multi-taskable GUI that is different to the standard desktop-metaphore and WIMP. Try the Whiteboard metaphor where anything is editable, and you can select any free space on the background and start working and erase anything to clear up more work room.

You can also extend WIMP to the point that it has no concept of resolution or orientation (only aspect ratio). Especially useful for a tablet or a surface PC if you could just spin a window around, stretch it out huge for everyone to see or resize it small so multiple people can be working at the same terminal.

Actually there's no reason we need to find a metaphor that imitates something in the physical world. Built a data-centric UI from scratch where programs are merely plugins in a consistent environment that implement new ways to modify and interact with your data.

I think that fast searches could be the thing that changes how this works (although how, I'm not sure). For example, the Vista/7 Start Menu's - I'm much happier using the new search-style menus than I am using the old "Programs->Applications->Notepad" system. In fact, I'm so much happier with it that I don't bother with desktop items or quick launch now.

The majority of my applications overtime appear on the first list of the Start Menu so I seldom need to search or go into a sub menu.

[NickJohnson]

The desktop metaphor definitely has its place, and is probably the most intuitive for new users because it acts in a predictable way and applies to most programs' interfaces easily - it's not really "outdated". That's why every major operating system uses it as a primary interface (at least on desktop systems).

However, I find it slow and overcomplicated for things like programming, because it's hard to keep many windows both quickly accessible and suitably large, and to find files/programs quickly. 90% of the time, I have Firefox at full screen, gvim at full screen, and a couple of xterms, all on different virtual desktops, with no graphical file manager. Every program I open frequently is mapped to keys, and everything else is quickly accessible from a terminal; keys switch between desktops. I think greater use of the keyboard is the real key to productivity for "power users"; it's just hard to find because few normal users want the steep learning curve. The virtual desktop/taskbar/tabs system is also great for productivity, because it lets you focus, use all of your screen efficiently, and quickly switch tasks.

I also think the real-time search idea is a good one, because it gives power equal to a command line in terms of access speed, because you only need to type the name of a program to run it, but also doesn't require memorization of programs' names. The only issue is overhead, which would become a major problem on a non-*nix system where programs aren't always in specific directories, unless you made a giant cache.

My current plan for a GUI (which is a while off in the future for my project) is essentially a set of graphically enabled teletypes that can be increased in number on the fly. Each starts with a shell, but when another program is launched, it can draw whatever it wants on the screen and accept mouse and keyboard input. It can also be run to draw on a newly created screen, which is destroyed when the program exits. The shell can be made to accept emacs-style key chords or have vi-style mode switches to make commands faster.

[earlz]

The desktop metaphor definitely has its place, and is probably the most intuitive for new users because it acts in a predictable way and applies to most programs' interfaces easily - it's not really "outdated". That's why every major operating system uses it as a primary interface (at least on desktop systems).

However, I find it slow and overcomplicated for things like programming, because it's hard to keep many windows both quickly accessible and suitably large, and to find files/programs quickly. 90% of the time, I have Firefox at full screen, gvim at full screen, and a couple of xterms, all on different virtual desktops, with no graphical file manager. Every program I open frequently is mapped to keys, and everything else is quickly accessible from a terminal; keys switch between desktops. I think greater use of the keyboard is the real key to productivity for "power users"; it's just hard to find because few normal users want the steep learning curve. The virtual desktop/taskbar/tabs system is also great for productivity, because it lets you focus, use all of your screen efficiently, and quickly switch tasks.

I also think the real-time search idea is a good one, because it gives power equal to a command line in terms of access speed, because you only need to type the name of a program to run it, but also doesn't require memorization of programs' names. The only issue is overhead, which would become a major problem on a non-*nix system where programs aren't always in specific directories, unless you made a giant cache.

I really love virtual desktops, it's sorta hard for me to remember to use them though for whatever reason..

and I really wish every program(including windows explorer) had tab-completion...

[cxzuk]

Heya

I personally believe that each "view" (in the MVC term) should consider each interface the device has. Consider a netbook and a laptop. While very similar, the differences have a huge impact on users experience.

I believe that applications should be "redesigned" (the GUI) to work on a netbook. The screen size alone means that traditional applications either are difficult to use or are completely unusable. An example is openoffice. Because of the lower workspace available on the desktop, openoffice rearranges the top menus (font select, Bold, Italic etc) to cover over 50% of the screen. Meaning the space available for me to view/edit my document is unusable.

The same applies to mobiles, tablets etc too. You have to consider touchscreens, limited keyboards, screensizes etc

I read all comments, and found them all useful. Heres just a few views on some things people said.

@NickJohnson

The thing i got most from your reply is that, everyones needs are different. While i use my computer is a similar, It really does depend on what people are using the computer for.

Also, I would try and not consider the practicalities of something too much. Design it to what you want it to do, If it requires a massive index for realtime search, then so be it If you want this feature, and you have the best functions are algorithms there is, there is nothing more you can do. dont let it stop you from providing the feature tho!

@MessiahAndrw
Im a massive fan of WIMP! I grew up with the Acorn RiscOS, of which the operating systems concepts were truly before its time.

I like the idea of a metaphor that doesn't imitate something in the physical world. Tho im very interested in the idea of a "Whiteboard", I guess you just box off an area on the screen, "zoom" into that part, and edit away? U want a button on it, you add a button, want a diagram, add a diagram. ?

I love this topic, and thing everyone should have a good think about it.
MikeyB

[cxzuk]

and I really wish every program(including windows explorer) had tab-completion...

What you really want is every input text area to have tab-completion. Doesn't sound like too much for a request to me!

MikeyB

[AndrewAPrice]

I personally believe that each "view" (in the MVC term) should consider each interface the device has. Consider a netbook and a laptop. While very similar, the differences have a huge impact on users experience.

Exactly. I think vector graphics will also play a big role in the future of UI's (like the route Microsoft is taking with the Windows Presentation Framework which is an improvement over their fixed UI frameworks). The reason vector graphics are important (as well as colour spaces but that's out of this thread's scope) is because of the wide range of devices of various sizes, distances from the user, and resolutions.

For example, I'm using a 23" LCD monitor that does 1920x1080, you can get cheaper models of the same size that only do 1600x900, and I'm sure in the next decade monitors of this size will get up into the 2000s in vertical resolution. Which each generation, I don't want the text and icons on my screen getting smaller and smaller until barely readable. Nor do I want just increase the text size while icons and borders shrink. No, I want to be able to specify, say, how big a centimetre (or inch) is on the screen, and from that it should scale the entire UI, so that 10pt text as well as all buttons should be exactly the same size on a 1600x900 screen, on a 1920x1080 screen, and on paper if printed out, the main difference being that the 1920x1080 screen has sharper curves and can fit more detail into images.

On top of that I should also be able to apply a zoom, so for example a large screen television that I am 10m from won't attempt to use the same scale as a desktop monitor I'm barely 1m from.

I believe that applications should be "redesigned" (the GUI) to work on a netbook. The screen size alone means that traditional applications either are difficult to use or are completely unusable. An example is openoffice. Because of the lower workspace available on the desktop, openoffice rearranges the top menus (font select, Bold, Italic etc) to cover over 50% of the screen. Meaning the space available for me to view/edit my document is unusable.

Look at the ribbon interface in Office 2007/2010 - http://img.labnol.org/di/office-word-2010.png.

The same applies to mobiles, tablets etc too. You have to consider touchscreens, limited keyboards, screensizes etc

Exactly! And multitouch displays (that is, two or more fingers/styluses can be registered independently) need a new user interface to take advantage of them. For example, if you have a window open on the screen, you could place a finger at two corners and drag in/out to resize the contents, you could rotate the window in the same manner - without any loss in detail if you use vector graphics to draw the contents of the window.

I like the idea of a metaphor that doesn't imitate something in the physical world.

Perhaps it was necessary to imitate the physical world in the past to make it easy for millions of office workers around the world to quickly feel comfortable moving from their traditional desktop to the computer. But tomorrow's users would have grown up with the UI of today's game consoles, phones, netbooks, and desktops so it'd be much easier for them to pick up a more advance (not necessarily complicated) UI.

Tho im very interested in the idea of a "Whiteboard", I guess you just box off an area on the screen, "zoom" into that part, and edit away? U want a button on it, you add a button, want a diagram, add a diagram. ?

There isn't a reason to "zoom" though you could very well make it a zoomable user interface. I was thinking more along the lines of you can write anywhere you want on the screen. You could highlight an area of the screen and "indent it" so that you can scroll up and down on an endless page within that highlighted area. Or you could highlight another blank area of the screen and turn it into a spreadsheet. Highlight another area and turn it into a webpage. Infact, you could embed the webpage (albeit very small) into the cell of a spreadsheet if you wished. An artist can draw anywhere straight away on their screen, and after they've done a basic sketch, and when they select their paint program all that happens is a toolkit of brushes and colours will appear and they can paint over their sketch, then highlight their sketch to save it. This is the sort of consistent interface I'm talking about.

[earlz]

Tho im very interested in the idea of a "Whiteboard", I guess you just box off an area on the screen, "zoom" into that part, and edit away? U want a button on it, you add a button, want a diagram, add a diagram. ?

There isn't a reason to "zoom" though you could very well make it a zoomable user interface. I was thinking more along the lines of you can write anywhere you want on the screen. You could highlight an area of the screen and "indent it" so that you can scroll up and down on an endless page within that highlighted area. Or you could highlight another blank area of the screen and turn it into a spreadsheet. Highlight another area and turn it into a webpage. Infact, you could embed the webpage (albeit very small) into the cell of a spreadsheet if you wished. An artist can draw anywhere straight away on their screen, and after they've done a basic sketch, and when they select their paint program all that happens is a toolkit of brushes and colours will appear and they can paint over their sketch, then highlight their sketch to save it. This is the sort of consistent interface I'm talking about.

That sounds just delightful.. this would also require quite a bit of extra programming for each application made though..

[cxzuk]

@MessiahAndrw

While i can agree with most of your points, i do think they solve particular problems in UI. Im currently thinking that no UI will be the right solution. And that my OS should allow the flexibility to provide ANY UI that the application/user needs. =]

@earlz

With tools these days, Programming is so so so so much easier. Programs can be written in minutes. I really wouldnt be worried about this =] Imagine your OS and the features you want to provide. Everything else will slot together in time!

MikeyB

[AndrewAPrice]

That sounds just delightful.. this would also require quite a bit of extra programming for each application made though..

But so is in some cases a WIMP application vs it's command line counterpart? That's not to say a bad API could not doom any wonderful concept to failure. It would be an event-based system like any other with its toolkit of widgets and handlers.

[cxzuk]

I personally think it would make programming applications easier and quicker.

Consider this. If an applications view could be selected depending on some parameters such as the interfaces available [keyboard, mouse, screensize etc], and the USER (the calling application [User-Agent]) the Model and Controller (MVC) wouldnt have to be programmed over and over again.

e.g. You have gcalc (windowed UI) and bc (command line). Both are calculator applications. If you were about to select the needed UI you could build one app to suit both needs. "calc".

Code: Select all

User-Agent=bash;Interfaces=kbd,mouse,VGA800x600 calc

Would result in something similar to bc

and

Code: Select all

User-Agent=Xorg;Interfaces=kbd,mouse,VGA1024x768 calc

similar to gcalc.

Im also thinking this could work with "pipes" too. After all who says a "USER" needs to be a human? The "View" doesnt have to be graphical either. You basically just specifying the structure of the output from the program.

Rather than a User-Agent a more generic parameter could be used. "Content-Type"

Code: Select all

Content-Type=xml grep filename.txt "bob"

This would tell grep to output to an XML format, changing the standard "view" which is normally line seperated.

Yes, It has deep similes with the web and the terms used are from those ideas. What you think tho?
MikeyB

[AndrewAPrice]

I've done a lot more thinking about the white-board metaphor. I've refined my idea more so (and I think it would be fairly trivial to implement). The screen would be made of one large widget parent, and any widget can hold child widgets, creating a complex tree. Most controls (including the parent widget) will have two default actions assigned to them (unless explicitly overridden); dragging with a mouse or stylus will cause a brush to imprint itself onto the widget, and clicking inside a widget and then typing automatically spawns an editable-text child widget. Inserting other child widgets, such as group-box, graph, web browser, etc would depend on if the pointing device has two buttons. On a two button device this could be as simple as dragging a rectangle with right mouse button so that a toolbar appears so you can select the widget to load. On a one button device (such as a touch screen), you could select the widget from a toolbar always on top of the page (the equivalent of a start menu) and then drag it out to place it.

Applications, of the classical sense, would register widgets and brushes with the GUI. For example, if you installed a video playing program, it would then appear as a widget that you could place onto the screen anywhere you want, and then select the video clip to place inside of the widget's borders.

The white-board metaphor alone won't be very practical, but you could combine it with a Wiki metaphor to make it so (finally a metaphor that isn't based on the real world!). Rather than requiring the user to interact with "files", the drive can contain Wiki pages. Not only can you insert cross page Wiki-links (especially useful for those who require note-taking, researching, brain storming, to be able to create a new page, write anywhere they want, then link their pages together however they want), but the system can treat normal files as pages (for example, a video clip would be treated as a page where the root widget is a video playing widget, if an editing suite is installed the page root's would be the editing suite's widget), and programs (the program's root widget may be a configuration dialogue). Since all programs, files, and pages can be abstracted as widgets, you can insert an instance of any file, program, or page into any other page (along with a range of similar actions, such as insert a copy rather than a link to it, and export a widget as its own page).

Multitasking is inherent in such a design. There is no need for multiple viewports to do multiple things at once, since you're able to insert all of your documents and widgets onto a single page. If you want multiple pages open at once, you can simply insert them into frames inside the current page. If you want make a child widget (such as a game, video, a child page inside a frame) full-screen, you could perhaps double-right click on the widget's border, and the that widget will now be the screen's parent widget. Then in the title bar (or in the right click menu for 2 button systems) there would be a list of parents, so you could zoom back out. Also in the same menu there would be a button to take you back to the main Start page, in-case you redirect the root to a page (for example a video) and you cannot return back.

And finally, the system is persistent. When you log in, the current page aswell as all your widgets appear just as they were when you logged off.

[js]

@MessiahAndrw : what you're talking about looks a lot like SqueakNOS (Squak (a smalltalk implementation) with No Operating System, thus running directly on top of the processor).

http://wiki.squeak.org/squeak/1762

[cxzuk]

I've done a lot more thinking about the white-board metaphor. I've refined my idea more so (and I think it would be fairly trivial to implement). The screen would be made of one large widget parent, and any widget can hold child widgets, creating a complex tree. Most controls (including the parent widget) will have two default actions assigned to them (unless explicitly overridden); dragging with a mouse or stylus will cause a brush to imprint itself onto the widget, and clicking inside a widget and then typing automatically spawns an editable-text child widget. Inserting other child widgets, such as group-box, graph, web browser, etc would depend on if the pointing device has two buttons. On a two button device this could be as simple as dragging a rectangle with right mouse button so that a toolbar appears so you can select the widget to load. On a one button device (such as a touch screen), you could select the widget from a toolbar always on top of the page (the equivalent of a start menu) and then drag it out to place it.

Perhaps treating the text and brush as widgets would be wise too? Have no default action, and have the user select what tool they want to use?

Applications, of the classical sense, would register widgets and brushes with the GUI. For example, if you installed a video playing program, it would then appear as a widget that you could place onto the screen anywhere you want, and then select the video clip to place inside of the widget's borders.

Again, just a suggestion, but why not have a "clip" tool, in which you can then select the Content-Type of that area. Its much more MVC, and if the area uve selected simply just holds the users data (weburl? videourl? brush vectors? etc) you can change the View whenever u wanted =] (brush vectors <-> text <-> SVG <-> JPEG etc)

The white-board metaphor alone won't be very practical, but you could combine it with a Wiki metaphor to make it so (finally a metaphor that isn't based on the real world!). Rather than requiring the user to interact with "files", the drive can contain Wiki pages. Not only can you insert cross page Wiki-links (especially useful for those who require note-taking, researching, brain storming, to be able to create a new page, write anywhere they want, then link their pages together however they want), but the system can treat normal files as pages (for example, a video clip would be treated as a page where the root widget is a video playing widget, if an editing suite is installed the page root's would be the editing suite's widget), and programs (the program's root widget may be a configuration dialogue). Since all programs, files, and pages can be abstracted as widgets, you can insert an instance of any file, program, or page into any other page (along with a range of similar actions, such as insert a copy rather than a link to it, and export a widget as its own page).

Exactly!

Multitasking is inherent in such a design. There is no need for multiple viewports to do multiple things at once, since you're able to insert all of your documents and widgets onto a single page. If you want multiple pages open at once, you can simply insert them into frames inside the current page. If you want make a child widget (such as a game, video, a child page inside a frame) full-screen, you could perhaps double-right click on the widget's border, and the that widget will now be the screen's parent widget. Then in the title bar (or in the right click menu for 2 button systems) there would be a list of parents, so you could zoom back out. Also in the same menu there would be a button to take you back to the main Start page, in-case you redirect the root to a page (for example a video) and you cannot return back.

Agreed, but im currently of the mind that, A widget must know about going fullscreen (the application must understand what it means). Which means they must also supply a return function. Otherwise its just a bad application =]

And finally, the system is persistent. When you log in, the current page aswell as all your widgets appear just as they were when you logged off.

Good ideas
MikeyB