OSDev.org

I've been thinking about user interfaces for a while, and I'm wondering if the classical WIMP (Window/Icon/Mouse/Pointer) interface and the desktop metaphor is really the right or only choice.

In WIMP interface, rather than a window representing an output source and a form of interacting with the application, most users tend to think that the window IS the application.

I'm thinking about alternative user-interface designs. Why do I want to implement something other than WIMP? Because I can (this is a research OS).

My first "alternative UI" idea was to have each applications' viewport stretch across the entire screen (except for a bar at the top), called a "page". The bar at the top lists the open pages, which you can switch between. Then I thought to increase productivity you could have side-by-side pages, and perhaps floating pages you could move around yourself - but this would be essentially describing a window.

How can a multitasking system enable it's user to be productive (while keeping away from the WIMP interface)?

Usually, you're only doing one thing at a time - a main activity (browsing the web, using a word processor, writing code, playing a game), but also perhaps with several side activities (instant messaging, watching a movie, downloading). The focus should be on that main activity.

I think we can learn a lot from Archy. It features a consistent interface through which you work - that is based around

content persistence, modelessness, a nucleus with commands instead of applications, navigation using incremental text search, and a zooming user interface (ZUI).

But I got to thinking that would be far easier to design such an interface if all the commands are built into the UI, but this limits the flexibility of the system to be what it was initially designed to do. For example, you'd want to be able to add features to the system (e.g. a way to manipulate images, a way to browse web pages, a way to compile your code) that was designed by a third party. In a traditional system these would be applications, which would invoke using the a command line and/or interact with through a window, but I'm thinking about something completely different.

Imagine you had a completely consistent environment, based around the concept of data. The environment must allow you to create, view and manipulate your data freely as you see fit. This data maybe a text document, a spread sheet, a video, a piece of source code, or a web page. Rather than having "applications" which you load and work in, applications are instead abstracted as "formulas" which you load into the environment to tells it how to manipulate a certain type of data.

This may not be the correct way to go about it, but I'm interested in something which can provide a modern multitasking evironment but is radically different from classical UIs.

I'll start by saying that I didn't read your whole post as I'm pretty much in a hurry now. I have done some research on ZUIs but I'm not sure they're very practical in OSDev'ing, I'd see them more in the multimedia field. I don't find them as intuitive as GUIs when it comes to choosing options or browsing through filesystems (no one actually needs to zoom into a folder to understand the concept).

I'd like to bring Smalltak into discution. Search it on Wikipedia, I'm to lazy to provide a link right now, but here's my idea: as good ol' arrogant LoseThos said in numerous threads, OSes and compilers (or development tools altogether) were really close fields. To some extent they still are but both these areas have become so complex that each one is sufficient to be part of its own project. If you do want to go the extra mile, you might want to consider somehow integrating development tools with your GUI (and I'm not necessarily talking about usual RADs). If you think about it, even CLIs are made up of a language + an interpreter. It's supposed to be that way - something flexible that will let you tell the computer what you want it to do (I mean, from a user's perspective). Today's GUIs are not flexible enough IMHO.

I'm playing devil's advocate on myself here. I've been giving a lot of thought the of a window-based system is not entirely bad. Windows allow you to resize your workspace and arrange it however necessary (word processor open, a web browser window to reference, and a IM window).

I also think, we shouldn't be tied to modeling things after the real world, as seen with the desktop metaphor (modeling things are real life - the "desktop", "folders", "trash can", spreadsheets/word processors being "files" spread across a desk). From the desktop metaphor we have just built layers (pop up menus, tooltips, task bars) which have no real-life counterpart, so in essence when designing a GUI there is not necessary to emulate real life counterparts, but there should also be no need to purposely avoid doing so if a real-life model provides the perfect abstraction (though not the only abstraction).

The future's users will be bought up using today's Uis, with the far future's UI users bought up using tomorrow's UIs. While back in the 80s, it made perfect sense to a person who has never worked a GUI before to relate the environment to the desktop metaphor, but I don't believe that is still necessary when dealing with a generation who grown accustom to working with a modern UI.

There are ways to modernise WIMP without working against it. The Office 2007 ribbon is a good example in my opinion. (At first I missed the toolbars, but then I realised change can be good). I see there is a design trend now to move away from the same look everywhere to the program individuality.

What I was suggesting above about a global interface for accessing everything would ultimately be a bad thing. Consistency means there is general farmiliarity when switching between programs and there is less for a user to learn, but too much consistency lacks variation. When I install a new program, I want it to be laid out and behave differently. I want to explore, I want to accomplish the same task in new ways. This is in direct contrast with what is describe in The Humane Interface; a modeless system that provided only a single way to accomplish a task. If this were true, why do we like to explore new operating systems, try new browsers, when the one we already have fits our needs perfectly? An operating system built around that principle would be a Communism-in-an-OS (or vendor lock-in), hindering our individualism and free market choice of software.

But maybe what I am describing as a worst case scenario is actually an extreme. On an application-level I believe there should only be one way to do things (one way to change the font in a word processor), but on a system wide scale I believe each word processor should have the freedom to implement it slightly different.

What I was describing about about a consistant interface where programs are formulas for access data would make a good shell concept, rather than the entire interface of an OS.

This has turned into a random pool of ideas.

Lets add some more to the pool of random ideas.

Each human works differently. They have different memories and associations, and will therefore try to accomplish a task in diverse ways. By forcing a specific approach on the user you are hindering the user since it might often happen that that way is not the comfortable way for him to do so. Essentially, you should allow for a wide range of methods to reach the same goal.

Since system designers are lazy, they keep dragging on about consistency in order to only have to do one and only one approach and not upset too many end users too much in the process.......

Combuster wrote:Since system designers are lazy, they keep dragging on about consistency in order to only have to do one and only one approach and not upset too many end users too much in the process.......

Hmm... I'm not sure about that; I think the problem is that we haven't really thought of many options (yet?)...

hmmm, user Interfaces again, ok ...
there is a principle that says WYSIWYG
aka (What You See Is What You Got)
so when you wnat to develop your own GUI, you need to take care
about that principle, to make GUI easy enough for anyone have minimal computer skills,

windowing system,icons,...,etc, is the most acceptable for wide
computer user, (because 70% of user hate shell/terminals)

CheerS ,
a.T.d

i586coder wrote:hmmm, user Interfaces again, ok ...
there is a principle that says WYSIWYG
aka (What You See Is What You Got)
so when you wnat to develop your own GUI, you need to take care
about that principle, to make GUI easy enough for anyone have minimal computer skills,

WYSIWYG refers to spreadsheets and such, not to GUIs. And I disagree with you on your last sentence: making a good GUI isn't that easy and you can't do that with minimal computer skills, unless it will suck big time (due to the lack of performance and most probably functionality also).

I think what he was referring to was the fact that the average Joe computer user can work with a GUI better than they can with a command line.

Sorry, you're right, I should start wearing glasses

My OS's user interface is based on a game sys gui, that is its a menu driven gui, so only needs a keyboard (but you can still use a mouse).
Its base on my observation, of neebs to PC and game sys, the neeb to PC's alway took a long time to find there way around the gui, but neebs to game sys could use them from the start.
So i thought why not use a Game sys type gui for running normal user program's, as well as game sys, phone also use a simular gui.
But than my OS is single tasking and based on a game console OS, so its fiting.
But i see no reason why multi-tasking, desktop OS can not use a simular gui.

TBOS' interface is a classic command-line shell. Nothing special, just working the same as any other CLI.

Something I've thought of:

There are no applications (but there are files, or persistent data structures, or whatever). Instead of applications, there are components that are connected together. Each component implements set interfaces based on its capabilities. When I say interface, I don't mean the traditional definition of an interface. Instead, when I say interface, I mean a set of streams of data. For example, the input stream interface would have one incoming stream of data, while an output stream interface would have one outgoing stream of data.

Upon startup of the system, the user would basically be presented with a file browser, and list of actions(components) and a bar at the bottom of the screen for assembling them together. The system can automatically connect the components' interfaces. For example, if a user dragged a jpeg file into the bottom bar and then dragged the view action into the bottom bar, and the user clicked go or something like that, the system would try to find a component that could read the output of the jpeg file reader component. The viewer would not have to read JPEG files, the JPEG reader would convert the file to raw data and present that data on its IImageAndMetadata interface. If the system finds a viewer that implements this interface, then it can connect that viewer's incoming port to the JPEG component's outgoing port. However, let's say that there was no viewer on the system that could display the IImageAndMetadata interface. In this case, because the IImageAndMetadata interfaces derives from the IImage interface, the system would look for a viewer which implemented this interface. If finally, no viewer could possibly be found, the system would display an error.

For editing a file, the system would do the same. It would find a component that could read the IImageAndMetadata interface. When the user clicks save after editing the image, the user is prompted to chose an output file. The system then connects the editor's outgoing IImageAndMetadata stream (or IImage stream if the editor does not support metadata) to the JPEG writer component's input stream.

This allows for generic editors and viewers to be written. You won't need to have 5 different media players because some don't support certain formats. If you only had a media player that could play mpeg movie files and you wanted to play something in the .mov or .asx format, all you need is a component that can convert between the two. In this case, the system would connect the asx reader component's IVideo interface(which exports raw video data) into an mpeg writer component's input IVideo interface and it would connect the IVideo out interface (which would normally be sent to a file output interface) to the media players input IVideo interface.

I hope I explained that nearly well enough to understand. I know that my idea is confusing and it would be easier if I had some sort of whiteboard to draw it out for you or something.

Sounds like you're trying to do plugins basically. Or codec's if you're talking about multi-media. Very similar concept, even down to the byte-streaming of raw data. This is why you can use windows media player to play .divx, .mpeg, .mov, etc. It doesn't care what the format is, as long as you have an installed codec that can read the required format. Same concept, you're just trying to broaden it a bit more, which sounds like a reasonable idea. The problem is, how would you go about the streaming? I mean, what if I wanted to write an image editor, how would i save as a .jpeg? Who is responsible for the settings (compression level, etc). Is there a .jpeg module that is just responsible for reading/writing .jpeg files into/from raw data? Who defines which interfaces? What about things like word documents? Is there going to be a generic interface that the formatter is required to convert to the specified format? How would one add onto a format (for example, if one format supports stuff that others do not, like hyperlinks, colors, text sizes, embedded spreadsheets, etc). It is easy enough to come up with a generic codec format for reading/writing video and audio, since the information is almost always the same (a resolution, bit depth, and color info, # of channels, or audio at a certain frequency, stereo, mono or surround, or a variable # of channels. Trying to make something generic for other stuff is not as simple, since there are so many ways, and information that is specific to certain applications. It sounds like an idea, not really sure if it's a good one or not. I would love for all applications to easily support multiple formats, so I can choose any application, and it would work with the file type of my liking, however, realistically, not all similar formats are close enough to work together.

Theres one thing I have to say is really nice about a WIMP GUI. If you are working on a large program, its nice to have multiple source files open at once and to switch through them easily, or be able to resize them and put them side by side. I dont think its particularly the desktop metaphor that makes it so most GUIs work this way, its just the nature of what you want to get done. The advantage of GUI over command line is that you can run multiple programs at once and have simoultaneous outputs going at once. I may be unimaginative, but I cant see how else you can do this other than some kind of a window, whether you call it a page or whatever.

Hi,

yemista wrote:The advantage of GUI over command line is that you can run multiple programs at once and have simoultaneous outputs going at once.

For lots of OSs it's possible to have several virtual terminals with a CLI running on each. For example, in Linux (without any GUI) it's normal to have about 10 virtual terminals where you press "alt+F1" to "alt+F10" to switch between them.


Cheers,

Brendan