Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

What Features Would Make a "Better" GUI? 158

Rudyatek asks: "When it comes to desktop OSs, there has been much talk about 'the end of the desktop', 'reinventing the GUI', etc. Usability has become increasingly important as we battle the ugly UIs of Windows and X11, and watch companies like Red Hat and Ximian try to improve them. But I'm curious if anyone has any clear ideas on what a truly 'better' UI would really be like? As a hobby OS programmer I have a great interest in alternative OS ideas, and this is one that I hear more complaining about than actual ideas. Anyone have ideas?"
This discussion has been archived. No new comments can be posted.

What Features Would Make a "Better" GUI?

Comments Filter:
  • by Krueger Industrial S ( 606936 ) on Sunday November 24, 2002 @02:58PM (#4744230) Homepage
    Everyone keeps talking about a "Better GUI" but nothing ever emerges. Why? Because there's really nothing wrong with the Windows GUI (or the various GUIs for Linux that are essentially knock-offs of Windows). The real problem is that nobody can stop hating Microsoft long enough to admit that they've done something well.
    • Yeah, Windows created the GUI, suuure. Ever seen a Mac? We had gui's while everyone with PC's were playing Commander Keen way before 1990.

      Sure, to eject floppies you had to throw them in the trashcan, but it's always better than having to actually push the button yourself ;)

      Even so, neither Apple or Windows 'invented' the GUI. Even Mac OS is a knockoff of some ol' horrid gui, years before you ever had 3.1. Forgot it's name, too lazy to google, but stating that Windows actually invented something instead of making a crummy knockoff is just plain wrong.

      But i must admit Bill did do something right: marketing and hyping products. Technically, Win95 was just a MS-DOG frontend, but boy they could market it just right. And they havn't stopped since :o)

      • no technically win3.1 was an ms-dos frontend. win95 was the first partially 32-bit OS, and there is much that could be changed with GUIs.

        For starters, get rid of the desktop and just get a big list of tasks. You don't want to have to hunt things down on a computer. You want to do things.
        Second of all, we need to get off the file name bandwagon. What we really need is a searchable live indexing service. Such a service would, upon serialization (saving) of the files, store in an index all the properties of the file for later searching. This is far more intuitive than a file name. For instance say you have a powerpoint project which you are serializing, well low and behold thanks to this new OS you can now search on the indexed executive summary, the number of slides, any property of the object you are serializing, and if the system is really nice and extensible, you can supply name properties and values that are also indexed.
        There should be a section on the tasks screen with your inbox (not just email but just tasks assigned to you), and multiple outboxes.
        Eh, thats pretty much it. Mainly we just need to abandon this unnecessary attachment we have with file names, and our love of the desktop, and we need to embrace object stores, property based indexed search, and task oriented computing. All of these are getting closer and closer to being there, but nobody seems to want to just make this simple but most effective system.
        • I meant to say '...you can supply named properties and values that are also indexed...'. Sorry for the confusion.
        • This could very well be implemented on top of any existing OS. I am making a prototype of it right now using java and Swing. Where there are different roles granted to different users. There are different tasks and objects which different users can access. It has a very small and simple set of interfaces which you implement to make a task (which is really just like a method on an object).
        • Names are actually very useful. Imagine if the phone book were organized the way you suggest. Instead of looking the name up alphabetically, you would have to remember specific characteristics of the person: height, weight, religion whatever. You would have to be sure you had a unique combination or wade through a potentially long list of candidates.

          Of course many operating systems including Windows offer at least part of what you're suggesting, but as a secondary option, not to replace filenames which is still the most powerful method for most people to find files.
          • I understand what you are saying, but I think you misunderstood me slightly. I have nothing against names, and the ability to supply named properties and values would accomplish the same point (Especially if there are predefined views or Collections of objects). Also, I left out of my above posting that, everything is classified to the extreme, and that interface names would take the place of folders. For example: Say you have a set of images that you want to associate with project4. Well instead of making a new folder to store it all in, you define a couple of interfaces (provided with a gui method) such as a Project4 interface (which could extend other interfaces). Then when you save the images, you don't save them in a folder. You define which interfaces it implements besides its standard JPEGImage class or whatever its object classification (along with the other interfaces you associate with JPEGImage). After you define every interface it implements, you set all the values (there can be different frames for each interface, and some interfaces could be filled in automatically by the program). After its saved it would be a simple query to determine all of your Project4 files or just return a single object. And if you want you can set the default Object class to implement the NamedObject interface. Simple, easier and more powerful to query, multiple views of same data, more meaningfull names (doesn't have to be some crazy concocted name), can implement multiple interfaces and therefore it can be indexed more than one way (many more). Also, it forces you to conform to its method of organizing data which is more logical than being able to put multiple file types in a single folder, just make an interface and have everything in the project or whatever extend that interface. And it makes security a breeze by just giving every role and user on the computer their own interface name. I don't know about you, but this seems to me to be a far more powerful method of computing.
            • I can see I did misunderstand you. I thought you were suggesting methods to be used by end-users, not programmers.
        • Yeah, filenames are a pain. Except when you know where the file is, and can open it up right away. I'd rather do that than "search on the indexed executive summary".

          I disagree with other stuff too - I think we need to focus more on DATA oriented computing. So that we have some data, and we can then edit/view it in anything that supported that sort of data. Get rid of proprietary data formats, and we can then edit data as we see fit (ideally, anyway).

          The problem with "task oriented computing" as I see it is that you often end up with "now start the text editor" meaning the single program on the system that can be used for editing text (the way MS is going with Word, it seems). However, I regularly use 4-5 different text editors/word processors on my machines. Sometimes because one is lacking a feature that I need, but sometimes one is just more suited for a given task.

          OpenOffice is great for large, freeform documents, for example, lyx is better for more structured writing, vim is my choice for coding, etc etc...

          And how do you define all the things you use a "text editor" for as tasks? There's no limit! (e-mail, letters, scholarly writing, technical writing, coding, invoices, etc)

          Maybe I'm just misunderstanding the term "task-oriented", but it seems like a rather limited way to function to me.
          • OK, I'm not saying objects having names is a bad thing. Essentially I'm saying the current path mechanism can sometimes be quite limited read my above comments on the ability to add names to Objects. Mainly I'm just saying that we should classify documents instead of creating an adhoc folder hierarchy. Again read my above comments. And as far as the task oriented view goes. Different tasks can be done with different programs. Every object that implements the required task interface can be enumerated if need be. And the applicability of the "text editor" in all the areas you mention above just shows the systems lack of common interchangeable effective text editing objects (I've mentioned in another article a while ago that the most ideal computing environment would be to get rid of programs all together and just have a large set of interconnectable objects.). Although, one of the tasks could very easily be query objects. If you just want to do a bunch of "of the moment" operations. Also, this is very data oriented, it essentially turns every file into an object with properties, as in you just deserialize it and go (ideally). Read above, I'm making a prototype client using java and Swing. Rest assured I'll post something on slashdot when its runnable to the point at which people will at least partially understand what I'm getting at.
      • You're thinking of the Alto developed IIRC in 1972 at Xerox's Palo Alto Research Center(PARC) by Alan Kay also of Smalltalk fame. Unfortunately, Xerox decided the Alto wasn't commercially viable. However, later they did manufacture the Star Office System, but with a $17,000 price tag it didn't sell very well. I believe this was in 1981 or thereabouts. Someone please correct me.

        It was during a tour of Xerox PARC by Steve Jobs and some others from Apple where the Alto was demostrated that Jobs and company hit upon the ideea of building a computer featuring a GUI operating system. Since Xerox had determined the Alto to be commercially unviable, Jobs was able to convince some of the PARC gang to jump ship.

        This led to the development of the Lisa at Apple, which was really revolutionary. I believe it was Smalltalk based and did not incorporate a Finder as it was not really needed in the Smalltalk environment. Another group at Apple was working on the Macintosh though which as everyone knows was launched via the famous 1984 commercial during that year's Superbowl.

        I don't know if it was internal politics that led to the predominance of the Macintosh over the Lisa or not. I do know that later Apple basically landfilled their entire factory run of Lisas from which they drew some rather well deserved criticism at the time since these computers were in their own way as revolutionary as the Amiga, and Apple could have at least sold them at discount to shools and libraries.

        Oh, and as a side note, Bill Gates got the idea for Windows after seeing a demonstration of the Macintosh at Apple. This was the basis of the famous "look and feel" lawsuit that Apple filed against Microsoft. Part of the agreement for Microsoft investing $150,000,000 into Apple in 1997 was that Apple would give up it's claim of patent infringement against Microsoft.

      • Sure, to eject floppies you had to throw them in the trashcan, but it's always better than having to actually push the button yourself ;)

        This is one of the parts I hate the most about the Macintosh--the fact that the floppy and CD drive eject mechanisms are completely under the operating system's control. I have had a Mac crash on me several times with a floppy or CD-ROM disk still in the drive, and it's no small task having to wrestle with the computer in order to get the disk out before the computer starts up again and tries to boot from it. Give me a plain beige box with clearly-labeled eject buttons any day. Plus, I have always found the metaphor of putting your disk, which contains data you want to keep, in the Trash Can, which contains data you want to get rid of, in order to eject it to be a little... iffy.

    • 1) Microsoft didn't do it. They copied it off other companies.

      2) There are new GUIs (Palm, Nokia) and they are definitely successful.

      3) I would argue that the Internet/Web-Browsing interface was a new GUI, and it was also successful.

    • All GUI design which is now used is derived from Smalltalk-80. Go read the book or find an old copy of the Byte Magazine which had a special feature on it, and you will have an understanding of all the guidelines those people used in creating a user-friendly and user-empowering graphical desktop environment.

      One of the design criteria in the Xerox Smalltalk-80 environment was also that the system should encourage the user to learn to program the system, in addition to only using it. The closest that proprietary GUI's have come to this goal was Apple HyperCard.

  • by fuzzbrain ( 239898 ) on Sunday November 24, 2002 @03:01PM (#4744252)
    Some of the most interesting window managers I've seen lately are those that are controllable from the keyboard, like ratpoison [sourceforge.net] and ion [cs.tut.fi]. I've been using Ion just about exclusively for the past month and it is really quite good. You can arrange your windows the way you want once and save the configuration so you'll never have to waste time moving xterms around so you can see them all. And because all desktops are tiled, screen real-estate wastage is minimised.
    • ratpoison is awesome. I used ion for almost two years, but made the switch to ratpoison a few months ago. Once you get the keybindings on ratpoison set up the way you want, it's the most usable interface imaginable. And not a single pixel is wasted: every square inch of the screen is used.


      Nothing beats ratpoison on a Xinerama display.

  • I was always more effective with Norton Commander/Midnight Commander (linux version). Just because you can do something does that mean you should?

    The three-D Gui is pretty good, the monsters in Quake just jump right out at you. It's workable as long as you remember where you left the glasses.

  • by augros ( 513862 ) on Sunday November 24, 2002 @03:07PM (#4744291)
    Well, there's always true translucency. Yes, it's mostly pointless, but it's so cool to look at. But if you're going to allow that, then you have to make everything hardware accelerated (just for speed). And if you're going to do that, well, you may as well base everything on a recognized standard such as PDF for cool scaling and whatnot, and then well ... you've got Aqua, and Quartz Extreme. So why not throw in a robust video layer too. And implement that funky vsync tweak that makes window movements sooooo smoothe.

    I dunno, XFree has made little progress in these directions and I just doubt it'll ever get up to par. I'd like to have native rotation, and a fast shapelib. Maybe I'm just wrong though. Everytime I tell people about the real problems I encounter with XFree I'm told they don't exist. Or they mutter something about the protocol. All I know is that I don't give a damn about network translucency (I'm no admin, just a user), I want my bloody alpha translucency. And the slowness and bugs ARE really there.

    The toolkits have really progressed over time, QT and GTK really are top quality. The only layer that I find lacking, surprisingly enough is the Window Management layer of the UI. Most window managers are either ugly or half complete (like MetaCity and Sawfish2 -- which I'm told have the FEATURES of being half-complete). The cool and configurable ones, like Enlightenment DR16 are buggy as HELL. And E17 doesn't look like it'll ever be realeased.

    As you can see, I could go on for days on my misinformations, but I'll cut it off here. At least I know I want a hardware accelerated, eye candied up, configurable UI.


    • I'd pay someone half a year's worth of sexual services if I could keep logs running dimly in the background while keeping my interactive CLI windows on the front.

      That, and the network transparency. Oh, and the ability to move around in 3D representations of networks. Just so that I were not expected to visualize them barely in my head all the time. That makes my thoughts fuzzy and responses to realtime challenges - like gf's speech or overrunning cars - slow.
  • by korpiq ( 8532 )
    3D: space allegory:

    • directories as rooms
    • files as objects
      • executables as tools: scissors, hammers...
      • packages as boxes/bags
      • ...

    • movement around unrestricted, be creative instead of locking down to real-world movement style
      • doors can appear anywhere, any size
      • backing out to upper level with a single movement (stepping back- and upwards?) always possible



    Scripting by dragging tool (program/action) icons onto a document and connecting them with reactions (follows / pipe to / while / if). One such document (sheet) can be used as a subprogram in others.

    A desktop that continues left and right (not up or down) from visible area. Activities in unseen parts are mapped to stereophonic sounds with or without visual hints. turning head / pushing with mouse bring that side visible. Just like virtual desktops except for the part of the audiovisually directing hints.

    BTW: if you have been annoyed by sound feedback from your UI, you have had the sounds too loud. Same goes for visual hints. Keep them low/small and short enough not to disturb you, just visible/audible enough to inform you. Helps with becoming closer to your content (be it then cli terminals) when your UI acts as what feels natural for you.

    Vocal interfaces to chats: irc2speech and VoIP. No sad attempts to have computer understand speech. It's always faster to write that script with a keyboard. So why'd we need that D&D scripting? To ease the text2concept work for the brain. Our brains have it easier with pictures. So D&DS would be for those who like to continue coding even half asleep =)

    That's just some. FP, I think, no more; had too much to say :P
    • I have never seen a 3D GUI which wasn't gimmicky and ultimately doomed. There's a couple of reasons for this, of course:
      • Our field of view is a 2D plane, so things in 3D tend to be hidden behind other things
      • Monitors are 2D
      • Input devices are 2D

      Even if huge advances in technology allowed for output and input in 3D, I don't think that 3D would necessarily be any more efficient. The idea is that the user has total control over the interface. The way to make everything accessible is to put it in one dimension less than the one we exist in. It's the same reason that 3D chess boards (in all their various rulesets) tend to suck - things get in your way.
  • Desktop metaphors (Score:4, Interesting)

    by qengho ( 54305 ) on Sunday November 24, 2002 @03:10PM (#4744315)
    The "desktop" metaphor is getting increasingly outdated, but I haven't seen a really good overhaul yet. There are some links at this site [saumag.edu], the most interesting of which is David Gelertner's LifeStreams [acm.org].
  • Readable fonts (Score:5, Insightful)

    by lightspawn ( 155347 ) on Sunday November 24, 2002 @03:12PM (#4744325) Homepage
    Maybe you can play around with text files to tweak your system's fonts, but most users have neither the technical expertise nor the inclination.

    If you release a distro with unreadable font, people don't say "hey, this distribution isn't configured very well". They say "Linux is hard to read".

    Oh, and can we please have checkboxes that make it obvious whether they're checked or not?
  • They all suck. (Score:5, Insightful)

    by GiMP ( 10923 ) on Sunday November 24, 2002 @03:38PM (#4744482)
    Everything out there now sucks.

    There have been some neat ideas tossed around, including those with are not only 3d.. but '4d', allowing you to track file and system history through a 3d interface.

    Eventually we will have commonity hardware that can display 3d (opposed to hardware which currently only displays on a 2d surface).. at which point we will need a truely 3d interface, we should develop this interface now... rather than waiting for the hardware before building the software. History has proven that progress is best done with software pushing the development of hardware, not the other way around... current hardware is fast enough to write software that could be viewed from a 3d display, even if such displays aren't available yet :)

    There are a few features I'd suggest for 2d widget s like those with GTK..

    The tabs in GTK are done terribly wrong as they are modelled after Microsoft's equally bad tab widget. If there are more tabs than can be displayed, then the tabs should either create a new row (causing problems with nested tabs which shouldn't ever be used anyhow), or it should provide a menu for the selection of the hidden tabs like with SGI's Motif (which is different than plain Motif).

    Close buttons for windows should be on the upper left side of the window.. I'm not sure why Microsoft changed this (and hence creating a whirlpool effect); Windows 3.1 had a upper-left close button, MacOS has it, MWM (and clones/spinoffs), etc. It much faster, easier, and more natural to have it on the upper left. I believe Microsoft's intention was that it should be difficult and slow to close windows.. something that may help novices from making mistakes (which is why MWM and clones, including Windows 3.1 require it to be double-clicked); however, I find that a lot of people new to computers cannot find the close button due to it's location... advanced users are just annoyed or learn to use keyboard shortcuts.

    Speakers of languages based on latin are instinctfully drawn to the upper-left.. this is why having a menu in the upper-left is more effective than one in the lower-left (Microsoft Windows 95, per default). This can be different for those who read/write languages from right->left or from bottom->top. I believe Microsoft put their menu on the lower-left as it was initially designed to be 'supplimental' to the desktop icons which would be more prominently placed in the upper-left. However, desktop icons are a bad idea.

    Desktop icons are a bad idea. There should be a distinction between the execution layer and the runtime layer. A menu-bar which provides the execution layer then a 'viewport' for the runtime layer. Putting launchers in the runtime 'viewport' causes confusion between the runtime and execution layers. Think of a panel in Gnome as the 'execution layer', this is where programs are executed from.. and then the desktop where windows are allowed as the 'runtime layer'. This also means that programs should not be allowed to overlap the panel.

    I must agree; however, that the PalmOS interface is quite adequate considering some of it's defiance of some of my suggestions (desktop icons , for instance). However, their desktop icons could be easily replaced with a 'spring-loaded' folder such as in MacOS.. this would provide the abstraction of the 'execution' and 'runtime' layers by providing a panel, while still being usable on a small display. This 'spring-loaded' folder while minimized would sit along the bottom of the display for easy access while the user is utilizing any programs within the 'runtime' layer.

    A distinction between 'runtime' and 'execution' layers should require that the 'runtime' layer cannot overlap the viewport of the 'execution' layer, but the 'execution' layer's programs should be able to visually overlap programs contained within the 'runtime' layer.. as would be necessary for menus or usage on small displays as found on PDAs. :)
    • sounds too much like running around to me, i think I'll just sit here and use my lazy 2d interface.
    • Close buttons for windows should be on the upper left side of the window.. I'm not sure why Microsoft changed this (and hence creating a whirlpool effect); Windows 3.1 had a upper-left close button, MacOS has it, MWM (and clones/spinoffs), etc. It much faster, easier, and more natural to have it on the upper left. I believe Microsoft's intention was that it should be difficult and slow to close windows.. something that may help novices from making mistakes (which is why MWM and clones, including Windows 3.1 require it to be double-clicked); however, I find that a lot of people new to computers cannot find the close button due to it's location... advanced users are just annoyed or learn to use keyboard shortcuts.
      I don't really see how a close button in the upper-right corner is any slower in use than one in the upper-left corner, but apart from that your information is not 100% correct: the close buttons from Windows 3.1 still exist in Windows 9x/NT/2000/XP. You can still double-click the application icon in the upper left corner, which is exactly the same as what you did in Windows 3.1.

      So the old way still works for people used to it or for people who prefer it that way, and MS added a faster alternative (at least in my opinion) for the others.

    • Re:They all suck. (Score:3, Insightful)

      by Gothmolly ( 148874 )
      Please provide basis for all of your wild assumptions:
      "Speakers of languages based on latin are instinctively drawn to the upper-left". Why? Why not the Germanic languages too? We all start reading from there... if anything, the close button should be on the lower right, to signify that you've read everything.

      To paraphrase you, your whole post sucks.
      • I didn't say that germanic languages were excluded, I was making an EXAMPLE. Yes, germanic and other indo-european languages would also be included.

        That would be much more instinctive than being in the upper-right... Since all of the menus and toolbars are at the upper-left, the user needs not to move their pointing device far to reach this area... whereas they would have to move to the complete other side of the window to reach a button on the lower-right.

        The most efficient way of using the mouse is to keep it in the upper-left of the window for easy access to the menubar, titlebar, and toolbar. If the close button is on the lower-half or the right side of the window then the mouse must be moved far for that operation.

        Usage of the minimize, maximize, and shade buttons on a titlebar are not necessary and could be placed without significant damage on the right-side of the window.. which would help avoid confusion for novices whom wouldn't naturally look there; however, they could be used more efficiently at the upper-left...\

        The only reason that Windows users think that the upper-right buttons are ok is because they've gotten used to it that way..

        Just look at a Qwerty computer keyboard.. there is a reason that the ESC key is at the upper-left :)

        • The most efficient way of using the mouse is to keep it in the upper-left of the window for easy access to the menubar, titlebar, and toolbar. If the close button is on the lower-half or the right side of the window then the mouse must be moved far for that operation.


          Sorry but you're full of shit. It SHOULD be a little bit difficult to close a window. If I am aiming for the File menu and I miss by a bit and click the close window button, I'm going to be pretty pissed off. Of course your obvious counter for this is saying that you should have to double click to close the window, ala Win3.1, etc, but if that's the case, why not just use the 'Close Window' menu item that IS part of the window drop down on the top-left-hand side of the Window (on Windows at least, and most WMs that ape Windows functionality)?


          In other words, STFU. You're not a UI expert, don't play one on Slashdot.

          • Actually, Windows 3.1 stole it's look from MWM which is copyrighted 1990'.. BTW: current versions of windows you can still double-click in the upper-left to close the window... and although this IS ok, I think that having it single-click is best.

            I always have my close button in the upper-left and I've never accidently closed the window. If it was a problem, the file menu could have padding so that it visually appears further and users wouldn't click so closely to the titlebar. However, I've NEVER seen a user have a problem with accidently clicking close (or window's drop-down menu) instead of 'file'..

            And most WMs don't ape Windows' functionality, they ape Windows' user interface.. I'd call Microsoft Windows anything but 'functional'.
  • by GusherJizmac ( 80976 ) on Sunday November 24, 2002 @03:47PM (#4744543) Homepage
    Disclaimer: This isn't really good for programming, but for using a computer

    Look at the Palm OS gui. The Palm was the first widely used PDA because it's interface is so intuitive and easy to use. Why?

    There is no concept of a "running application", nor is there a real concept of files or a file system. You basically just switch between apps, and you never have to worry about exiting, saving, quitting, etc. Furthermore, you are very abstracted from files. Each app knows what bits of data were created with it, and which to let you open.

    Now granted, the apps on a PDA are much simpler than those on a desktop machine, but the concept is still good.

    Applications are always available and you don't worry about "runnig" or "quitting"
    Modern OSes have virtual memory, so there is really no need to worry about apps running and not being used. With slight additions of features like app "sleeping" (disallowing it from using CPU cycles on demand), File->Quit is a thing of the past. Just leave apps running when your first start them (or start common ones at boot time). The Mac OS X Dock fakes this pretty well by combining an app launcher and task bar. It's great, because I always do the same thing to use a particular app, regardless of whether or not it's running.

    Removing the "file" metaphor, and the concepts of "saving" a file
    By having applications constantly save files, and additionally version them as well, the user really has no need to ever save. I mean, you don't "save" your memo-pad entries or contacts in the palm, because you don't need to. They are simple structures, so versioning isn't needed, but for larger documents, something similar to the VMS file versioning can be used. Furthermore, since you abstract the user from managing files, their task is greatly simplified; you just click on your app, and choose which thing to work on. Since it's always saved, you never need to worry about exiting, or crashing, or anything. Additionally, apps know what files they created and can open, so the user never has to wade through files that aren't relevant to the current application (Mac OS 9 faked this by using the Type/creator codes).

    Files, folders/directories, running apps, are a construct the user shouldn't need to be exposed to. That is why the Palm is so simple to use, and browsing in Windows Explorer is such a pain (for the avg. user).

    • by josepha48 ( 13953 ) on Sunday November 24, 2002 @04:13PM (#4744766) Journal
      Don't forget integration. In the palm OS the 'Applications' are integrated pretty well. You ahve an address book that when you are in email you use the same address book. They are getting more integrated in more recent versions of the Palms OS.

      The problem with Windows, MAC, UNIX and Linux, etc is that the apps do not integrate cross desktops. There are many different address books and while you can import between many of them you still have to import. It should be an address book format standard in $HOME/.addressbook or something that every app uses as a standard place. The user should not have to think about this. There should be a standard look and feel, no mater weather you are using kde gnome, blackbox, etc, they should all behave and look the same like windows apps and mac apps do, or like Palm does.

      Alternate form of input. The palm does not have a f***** mouse or keyboard (standard you have to buy one seperate and dont need one), it has a stylus and grafitti(sp).

      Also transferring data between palms is not rocket science. You beam data from palm to palm. With desktop computers you have to think about this and install software and hardware and jump through hoops. Palm is simple and so should a desktop be.

      If it were me I would start with something simple like blackbox and make it such that a person had simple access to the necessary applications. Most people just use net and doc processing and maybe excel, so I would start there. Keep it simple!

    • by ClosedSource ( 238333 ) on Sunday November 24, 2002 @10:09PM (#4747686)
      "Now granted, the apps on a PDA are much simpler than those on a desktop machine, but the concept is still good."

      Scale matters. Many good models based on narrow functionality break down when more general functionality is required. Remember all the talk of making software as easy to use as a toaster? Well, you can do it easily as long as the functionality only requires a slider control and a start button. You can't even make a radio as easy to use as a toaster.
      • Maybe I'm the only one, but most of what I look for in a good GUI is access to my system's config. I almost exclusively use SuSE because YaST makes it incredibly easy to do what I need to do. Whether it be Windows, Linux, Palm, Mac, whatever, what's the use of having an idiot-proof GUI if you can't get down and dirty when you need to? My point: Unless a gui lets me do what I need to do, it's worthless. Easy or not.
  • Re: Menus (Score:2, Insightful)

    1. circular context menues, with common items in the center, can less common ones on the outside, I belive that there is no GUI API which makes this easy.

    2. Nothing radicaly different from whats gone before, no one likes to leave old habits.

    3. Non of that rearanging of menues which apperared in ME ond office, it just gets confusing when menu its move arround.

    Also speed is the most imnportant, responsivness aids learning and easy of learning is key to easy of use, as well as a whole host of other factors of course

  • by AdamBa ( 64128 ) on Sunday November 24, 2002 @04:30PM (#4744871) Homepage
    What you want is to take the best of the command line and the GUI together. OK the "best" of the GUI ain't a whole lot. But the idea is you start with a GUI-like screen, with a primary command-line at the bottom always waiting to accept a new command. Any commands that you type are automatically launched into their own little command windows (unless just launching a GUI app, I guess) -- but the primary command line still has the history of the commands available, standard shell stuff, etc. Then those little command windows are now stored as icons around the screen. If you open one, you can see the output of that command the last time it ran, and easily run it again if you want (with some standard key). Right-clicking on one of those little command windows gives you options, beyond re-running it, like editing the output in an editor, pasting the output into a new command (useful for using the output of something like "where" as an argument to your next command), mailing the output, feeding the output back into a new command (sort of like "take this previous command's output, feed it into a pipe, and connect the pipe as input to the next command I type in my primary command window"), etc.

    So you wind up with a command line prompt, but it uses the GUI space to handle things that get a bit clunky in a regular command line prompt, like history, pipes, etc.

    Needs work, but it's clear in my mind...that's the basic idea anyway.

    - adam

    • Sounds like a really good idea actually. GUI's are good for some things (finding things, choices from not so well used menus etcs). Command lines are good for other things (like ordering eg piping different commands together to perform some kind of composite). Combining the two would probably be quite hard to get used to (you would have to really use the mouse and keyboard rather than mainly using one of them like people do now), but could be a lot more powerful.

      If you find something that works that way then I'd start using it ...
    • I haven't used it recently, but I remember AutoCAD 12 and 13 allowed a user to use the menu or the command-line alternately. Any action could be done in either location, and the bonus was that menu, mouse activities generated events in the command-line pane.
      • I haven't used it recently, but I remember AutoCAD 12 and 13 allowed a user to use the menu or the command-line alternately. Any action could be done in either location, and the bonus was that menu, mouse activities generated events in the command-line pane.
        You are correct sir! As long as I've used AutoCAD (since Rel 9, around 1988) they've allowed multiple modes of interaction. Autodesk added new modes with subsequent releases, while still retaining the old ones. Here's a partial list:
        • Command line
        • Screen menus: like a sidebar, first by pressing a key, mouse support added later
        • Tablet menus: both the digitizer tablet and the buttons on the puck
        • Pull-down menus
        • Keyboard shortcuts
        • Popup context menus
        Plus, all of the above are customizable and programmable, using the built-in LISP interpreter, C, C++, or VBA.

        There are very few applications with graphical interfaces I don't get frustrated with and bitch about besides AutoCAD (if only they hadn't abandoned Unix with Rel 14).
    • I totally agree that there's an unfortunate clash between keyboard/console and mouse/GUI input at present. It's silly that I can form vastly more powerful commands at a prompt than with a mouse, and yet it's so hard to just select a list of arbitrary files to operate on in that command line (or, for those who prefer the mouse, to highlight *.bak to move elsewhere).

      I think the fundamental problem with today's GUIs is the way they receive input. Sure, you can have your super-3D-funky-translucency-skinned-configurable-w idgets, but ultimately they just display the same stuff slightly differently. When I can

      • use the mouse and keyboard together, effectively
      • script everything properly

      then we'll be getting somewhere. I rate the second point almost as important as the first, BTW. Serious people don't like repeating themselves, they use scripts. Today's GUI front-ends are absurdly hard to script, which is kinda silly since most of them fundamentally use a messaging architecture underneath, and the technology to do it has been around for years.

      Once I've got sensible input, from whatever devices, then I think the desktop metaphor is getting a little tired and we could do better now, but that's way down the list of things I'd like to see improved.

  • by joe094287523459087 ( 564414 ) <joe@jo e . to> on Sunday November 24, 2002 @04:30PM (#4744875) Homepage
    respond to my input automatically

    if i type "cstrike" start up counter-strike

    if i type "google" start up a browser and go to google

    if i type "letter to mom" or the start of a sentence open c:\data\letter_to_mom.txt in word processor

    if i type a name listed in my contacts, open the contact and an email message

    to use the cliched analogy of a car, i just want to get to my destination - i don't want to fuss with the tire pressure or change the oil first for every trip.
    • Typing provides a lot more possibilities than clicking. Clicking also can jog the memory as it's multiple-choice, unlike a space to type something.

      I'd use it, but only in addition to a GUI. Perhaps it should be natural langauge too ("what's the weather like in Auckland?"), as opposed to keywords.

    • I think you want to add abstraction, not remove it. If you remove abstraction, then the computer is a bunch of spinning metal and electrons.
    • Get yourself this >>>> Launchbar [obdev.at]

      Note: only for OS X.

      "aunchBar provides lightning fast access to thousands of files, web-bookmarks, email-addresses and applications just by entering short abbreviations. Type OW to launch OmniWeb, AHN to open the "Apple Hot News" web page, BM to write an email to "Bob Miller" or HP01 to locate a folder named "Holiday Pictures 2001".

      The set of items and their corresponding abbreviations don't need to be configured manually. LaunchBar uses a very powerful, adaptive abbreviation search algorithm that allows you to enter any thinkable abbreviation of the searched item.

      To ensure a maximum of keyboard control, LaunchBar can be activated very quickly using a system wide hotkey. "
    • to use the cliched analogy of a car, i just want to get to my destination

      Yeah, because when I get into my car, I just say "take me to work", and it drives me there all by itself..

      Err, wait - no, it doesn't. I still need to start it, put it in drive, use the accelerator, brake, and steering wheel, and navigate intelligently.

      i don't want to fuss with the tire pressure or change the oil first for every trip.

      "I don't want to install the CPU, plug in the video card and mouse, and install the OS every time before I start my app."

      Your analogy isn't clichéd, it's horribly broken.
  • by BSDevil ( 301159 ) on Sunday November 24, 2002 @04:41PM (#4744954) Journal
    I've seen a fair number of people mention that they want something closer to the command-line, and more involved file-system management. That may be fine for you, but what about for my grandma who just wants to use word, outlook, and her knitting pattern designer. She dosen't want anything to do with the command line - she wants a (virtual) button to press that will "make it go" and run what she means.

    So when you say a better GUI, I challenge you to qualify what you mean. Do you want a better GUI for the programmers and hardcore command-line-junkies out there, or do you want somthing for the majority of users who don't give a shit about the command line or the filesystem, and who just want to "make it go?"

    Fos us who like the line (and like things like gcc, regexps, or **nix), then maybe a GUI with command lines everywhere is what we need. But all my grandma (or Joe Sixpack) needs is a bunch of buttons - like (as someone suggested) PalmOS. Or a Mac.
    • Good insights.

      The GUI that can successfully allow both to co-exist will be the killer GUI that everyone uses 50 years from now. Power user? Tap one key and you get the command-line, uber-file-manager system. Out of your league? Tap another key and grandma can use it. Or even a whole spectrum - tap the "easier" key until it's easy enough to use! Tap the "harder" key enough times, and you get asked for a root password...

      The catch is, when will that GUI be invented? I think it's possible, but I haven't seen any GUI even in the ballpark yet. (The closest examples? Win+MS-DOS box, or better yet Gnome/KDE + terminal)

      • I think Alan Kay's Squeak [squeak.org] implementation of Smalltalk pretty much fits those criteria. I've spent some time playing with it and have to admit to being awfully impressed. It still has quite a way to go, but when it gets there it should be pretty amazing.
  • my list (Score:4, Insightful)

    by itzdandy ( 183397 ) on Sunday November 24, 2002 @04:59PM (#4745074) Homepage
    -speed.
    i want speed, i dont want to drag a window accross the screen and have to wait for it to arive, or have it jerk its way to where i want it. i want windows to pop up quickly. i want instant and accurate feedback on what my program is doing, is it busy? is it truely busy or is the UI lagging?

    -simplicity
    i want more control with less controllers. i dont need 7 buttons on each window to decide if i want to close, min, max, put to the back, bring forward, menu, etc. it should be(in my opinion):
    left, minimize and maximize
    right, close
    double click titlebar, shade
    right click title bar, menu
    maybee-right click minimize, put to back
    and and click in the window brings that window forward.
    any border should resize.

    -standards
    i want standard controls throughout apps. the file,edit,view, etc should all have the same layout on each application. preferences should always be in the same spot, everywhere, and help should always be on the right end.
    id also like the option of puting the menu bar on the top ala Mac, but i want that choice.

    -usable space
    i want usable desktop space. see fluxbox/blackbox. i dont want my file explorer to force me into a left side info bar. this should be optional. as in not like windows, but like mozilla.

    -solid code
    how about some solid bugfree code. something that wont crash because i did a rightclick/properties on a file while also doing a file copy.

    -personal
    i do like "skinning" to a certain extent. i like to be able to set color schemes and taskbar locations. but the buttons should be pretty much standard. Maybee be able to increase or decrease their size.

    -keyboard
    100% keyboard capable UI.
    easy to tab through open windows, easy to launch programs. standard shourtcut keys(cut/paste/copy/search) i dont run with just a keyboard, but some do mostly and i like keyboard shortcuts. using the keyboard and mouse together makes the UI way faster to navigate, assuming that your not running windows and have to wait for every little thing to happed before you even get input back.

    thats about it.

    kinda like BeOS..
    • Kinda like GNOME2:
      • pretty fast (could use improvement)
      • sawfish can customize the window decorations
      • standard UI with Human Interface Guidelines [gnome.org]
      • Nautilus can use a sidebar or not (and panels are customizable, of course)
      • it's quite stable for me
      • it's skinnable, and completely keyboard capable thanks to the Accessability Project [gnome.org].

      OSX is pretty close too.

    • Except for possibly "how about some solid bugfree code.", everything you've described is part of the Win2000 GUI.

  • Folks love to comment how ugly they think GUIs look under X in Netscape/Mozilla, and the same folks often suggest the solution is to use anti-aliased fonts. Sure, anti-aliased fonts are good.

    However, I'd like to share my experience with a very simple alternative method of getting really great looking fonts in X without installing or changing any software.

    Change your X11 display resolution so pixels are about the same size as the dot pitch of your monitor. The jagged edges of the unaliased X fonts totally disappear. Quasi font anti-aliasing is as good as true anti-aliased fonts but without the hassle! If I had my macro lens handy I'd take a photo of my monitor screen running 1600x1200 and show you the incredibly smooth font outlines I've got with this very ordinary variable width Times Roman 18pt font. If I reduce X to anything less than 1600x1200 like 1024x768, of course, the jagged edges return.

    • I'd take a photo of my monitor screen running 1600x1200

      That's really nice if you have a super high end monitor, but otherwise your refresh rate goes to pot, and it's even worse on the eyes.

      Anti-aliasing is a very good thing. Smoothing on an LCD is even better.
  • by Anonymous Coward on Sunday November 24, 2002 @05:11PM (#4745139)
    I want my computer/os/gui to learn from what I do. Do I launch mail at 9am every day? Then mail better be somewhere accesible at that time. Do I then load up a spreadsheet? Have it next in line. Make life easier for me.
    • Windows' first pass at this (hiding rarely-used Start Menu items) is really ugly. I think I'd rather have things in predictable places than have things in the order the computer guesses I'll use them in. Of course, you could have both: the Bayesian guesses at the top, a short gesture away, and the fixed, predictable locations conveniently nearby. (But that would be (gasp) redundant! For some reason UI designers resist making something accessible multiple ways. Getting past that mental block would be a big advance in itself.)
    • It would be nice to cache those things so that they load faster, but an interface that changes can be confusing. I hate it when XP hides items and then I have to reveal all items to get to something simple like "open"
  • The greatest problem I see is that when going graphical, the graphics are almost the things themselves. That is, clicking an icon, but mistakenly viewing the icon as the file itself.

    The GUI or the command line is only for access to what is really there, files, commands, graphics, etc.

    So, the first step is a better interface, would be to allow for many ways of getting to the same thing, at the same time. That is, keybindings should work at all times (somewhat similar to the way that MS does it in Windows). If there is a voice interface, it should not need a separate application. Think ST:TNG they talked and typed at the same time.

    Allowing for all interfaces to be merely a layer to get to what is actually being done should help those who want speed to get it, and those who want comfort to get it. Eventually, the interface layers should be non-cumbersome to the point where developers focus on functionality not interface.

    Watching people do things let me see different people either loving or hating:

    • key bindings
    • pop-up menus
    • global menus popping anywhere
    • voice


    As a small stab to develop work, I would think that the computer needs a basic "language". For example, "execute". The user can then set some form of interface to "mean" execute. Such as a single-right-click, or -, the word "execute", etc. In fact, I'd separtate interface from applications completely, and come up with an agreed upon language to let the two communicate.

    I think that once comfort becomes the norm, people will more readily ber able to realize the best GUI.
  • by briglass ( 608949 ) on Sunday November 24, 2002 @06:00PM (#4745556)
    MULTIPLE MOUSE POINTERS

    That's right, I would like to see multiple mouse pointers. Society is stuck on the singular-mouse idea. We need to move beyond this 20th century dogma and start developing a multiple-mouse environment. If we can put a man on the moon, we can add a second mouse pointer to a GUI.

    BUILT IN HOMELAND SECURITY ALERT SYSTEM

    Are we at orange or yellow? I have no idea! But if my GUI incorporated the Terror Alert System into the desktop, I would always know precisely how scared I should be. Right now there is a 14-Click pathway to information about our current Alert Level. With integrated Homeland Security Alertware, the 14-Click barrier could be broken, and America would be that much more safer. If the next popular GUI doesn't feature Alertware, then the terrorists have already won.

    SUPERFLAT 3D-THIN BUBBLE BUTTONS

    In the beginning, all buttons and menus were flat. Then, Windows developed buttons and menus with a 3D appearance. Windows 95 took buttons and menus to a new level by incorporating the 3D-Thin look. While these new buttons appeared 3D, they had that appealing Thin look. Windows XP revolutionized Three Dimensional flatness by inventing the 3D-Thin bubble buttons. These button, although appealingly 3D, are so flat that they appear to be bubbles. I don't know about you, but this is already getting old. We need to add another dimension of flatness. I would like to see Superflat 3D-Thin Bubble buttons! Although Three Dimensionally thin and bubbly, these buttons would appear to be Superflat. I could get a lot more done, as a user, this way.
  • This is probably more of a "Desktop Enviroment" more then just a GUI idea, but I'd like to see something where basic functions (in the internet age) are built in.

    As in you don't "open" an program to check your email but it's constantly open, checking mail and alerting you of new mail.

    Bah! I just don't know how to put this into words properly....
  • But most importantly you need a benevolent dictator to enforce the enlightened design.
  • I hoped to just moderate this thread, but it's not generating much good discussion.

    If you are looking for features to fix usability problems then you have fundamentally misunderstood the problem. There was essentially nothing missing from the original MacOS or Amiga's Intuition that you'd need to make a usable UI. In fact, feature (and processing power) limitations have inspired some of the most usable interfaces around (PalmOS, my Nokia phone).

    The other assumption of this question is the notion that usability is poorly understood. In fact, there has been extensive HCI (human/computer interaction) research, and it has produced some very readable, accessible books targeted at software people. The real question is: why don't we apply these lessons?

    • You mention "some very readable, accessible [HCI] books targeted at software people" -- are there any particular research papers or books to which you could provide pointers?
      • A very good and easy-to-read book is "Don't Make Me Think", by Steve Krug. The book itself is an excellent example of how to communicate information clearly and concisely. As a result, it is quick and entertaining to read, while still imparting lots of useful info.
        It is not aimed specifically at software people, but that's a feature, not a bug.
  • Why on earth do both KDE and Gnome make a "$HOME/desktop" directory? It's not for settings, they have .gnome and .kde for that. It's not a place to save my general purpose files, that's what $HOME is for. Besides, why should where I store my files have anything to do with what GUI I'm using (or if I'm using Midnight Commander).

    Unless someone can suggest a good reason I'd like to have /desktop removed entirely with /home in it's place. This means I get rid of that stupid home icon, too.

  • A good UI should first of all be fast. Everything should be responsive and quick. If I click to launch an application I expect the application to appear instantly. If I maximize a window it should maximize instantly. So on and so forth.

    The UI should also be full of every possible feature, and each of these features should be completely optional and customizeable. Transparency, animations, skins, icons, menus, buttons, bars, decorations, colors, everything should be customizeable to my taste.

    The UI should also be uniform. Even though everything is customizeable everything should look the same as everythign else. All applications should have the same style of window. All dialog boxes should be relatively uniform. Mac does a very good job of this.

    This is all assuming a GUI. Since the best UI is the perfectly customizeable one IMHO, a CLI has to be an option. The underlying OS in no way should require the user to see the CLI if they don't desire to see it. However it should be an included and optional feature. There should also be an audio interface, and a touch interface, so blind/deaf people can use it.

    It's not possible or realistic, it's idealistic. A 100% complete feature set with complete customizeability.
  • I do think that interface will be the major choice users make for their systems in the future. I run litestep on win98 and I forget about Gate's control over my mind a lot of the time...

    On the topic of graphic/mouse interfaces, what I yearn for the most is a popup (i.e. a click on the desktop) menu which always appears relative to the cursor. Imagine a disc which pops up centred about the cursor, the user becomes familiar with which direction a certain category of commands are kept and the distance the command lies from the centre. The mouse movement is then an automatic response (as opposed for hunting-movements channelled through small spaces to open up bigger spaces), and the 2D (as opposed to linear/1D) allows room for bigger buttons. Picture the positions of all buttons, relative to the cursor, as always being in the same place, like a desktop filled with icons. The menu reveals those icons surrounding the cursor, but if you know where your command lies you move the cursor straight to the edge - execution is more or less independent of the path the cursor takes. In the traditional sense the menu is 'guessing' that you meant to select this particular category.

    The important ideas here are: a cohesive branching of command categories, user memorisation of relative command location - the former trains the latter, and the result is automatic execution and minimised cursor movement.

    Some additions to the concept are: dynamic sizing of buttons with cursor movement (something like aqua's wharf but makes more sense in large 2D spaces), dynamic scrolling of the menu (cursor relative to screen appears to slow down while menu flows underneath) which is important for engaging popups at the edge of the screen, and lastly, integration with application windows, virtual desktops and system maintenance, where the "space" is unified and apps can be seen working inside the "hidden" popup environment - this would benefit from 3D scaling.
    I am extremely keen to be involved in such a project even though I stopped learning code years ago - I would be happy to flesh out a longer design analysis. Please e-mail me with your thoughts!
  • Two things:

    1) Applications need a standardized way of being able to insert data from other applications and sharing this info through an intelligent clipboard.

    2) Good support for object linking and embedding (OLE).

    I believe that Windows got this right a long time ago, and no Linux window manager or GUI interface has come even remotely close. Under Windows, I can open up Corel Draw, copy a vector image and paste it into Adobe PageMaker. PageMaker recognizes that it's a vector image, and lets me move one set of lines in front of or behind another, as I see fit. I can then group these objects, copy them, and paste them into Word. In Word, I can ungroup them, and modify them again as a vector image.

    In this example, I just used three completely unrelated programs (which don't have the ability to open the others' native file formats) without having to export files and import files to and from common formats, and without loss of generality -- my original vector drawing stayed that way (it wasn't made into a bitmap in the process).

    Alternatively, I could paste a linked version of the original Corel Draw file into my Microsoft Word doc, and whenever I update my Corel Draw file, the image in Word updates automatically -- OLE is very handy, and unless I'm mistaken, it's nowhere close to being supported by Linux programs yet.
  • The purpose of a GUI is to make the functionality of the computer accessible to people whose primary interest is not "muckin' about with computers".

    There's a limit to how 'intuitive' a GUI can be, but a good GUI has a sophisticated enough paradigm that once the basics are learnt they can be successfully applied to unforeseen applications.

    The desktop paradigm is perfectly workable, although it is generally implemented sloppily. The main problems are inconsistency and lack of feedback. For example, try explaining to a new user when to double click something and when to single click it, especially when often there is no feedback for 5 - 10 seconds even when an application is successfully launched.

    Frustrating to me, although probably less important for most average users is the huge resources required to make Windows, Mac and Linux GUIs responsive.

    It is also frustrating that applications seem to always forget settings. Users shouldn't have to resize and move their windows every time they load up, open/save dialogs should always remember where they are usually pointing to.

    GUIs have certain limitations, so there should always be access to a well designed CLI for power users.

    As far as consistency goes, Windows (all versions) cannot even maintain consistency in the plain OS, let alone amongst 3rd party applications. Linux is even worse. Macs do a much better job at this.

    My favourite GUI is BeOS. It is very sad that this excellent OS is all but dead. It is responsive, efficient, consistent and has a Unix CLI - even though its early in its development cycle. I am hoping that Moore's law, and open-source enthusiasm will lead to a truly user friendly Linux distribution. Red Hat 8.0 has made a lot of progress with attractive fonts and icons, and a moderate level of consistency. Unfortunately there is far to much copying of MS paradigms, warts and all, as well as more unixy drawbacks like the potential problems installing applications. Its definately getting there tho' - and other distributions like FreeBSD and Gentoo have good points that could be incorporated.

    • Red Hat 8.0 has made a lot of progress with attractive fonts and icons, and a moderate level of consistency. Unfortunately there is far to much copying of MS paradigms

      For now, this is exactly what is needed in order to get people to consider alternatives to Windows. The less of a problem that switching becomes, the more likely it is to be a viable option.
  • A good GUI should have;

    A dual panel file manager, like Midnight Commander/Krusader/Norton Commander.

    Tabbed xterms.

    A good CLI: The CLI isn't a GUI, but it is a UI, and a very effective UI for some types of computer interactions. I especially like the feeling of a consistent, single focus point of accessing and manipulate _everything_ on my filesystem.

    Multiple desktops/consoles, like KDE/Gnome/etc.

    Maximum screen real estate (see above)

    "Everything" must be able to be manipulated by keyboard short cuts. A mice is nice, but a short cut is more hot.(yuck)

    Decent default settings.
    There is a schizma between power users, and people who can be considered newbies /light users. When GUI producers caters for one group, the other group is alianated and vice versa.
    Maybe there should be a GUI switch, swithing between power user (advanced) and home user (simple), both with default settings that are apropriate.
    The GUI switching could also work across the apps; eg. in "simple mode" the mail client would have few, large icons with text beneath them, optimized only for: get, send, read, write and organize mail. No option for turning on html mails, no cc field, no advanced edit features etc.
    If the "simple mode" user needed any one of these features, they could costumize to their hearts content by selecting from the "advanced mode" representation, why deny people anything.

    Such a dual GUI setting could cater for the people with simple computer needs, without dumbing down the GUI for those with more complex needs.

  • i think we need a better UI as well as GUI. What abuout something that can read your jestures in air. Pair this with a multi-headed system and good apps (with extensive drag and drop support) you could have a winner.

    I personaly get tired of having to use a mouse for everything. Id like to just move my hand, or eyes around etc.

    to change the GUI tooo much more we may need to change how we interact with it all together.

    The GUI didnt take off until the advent of the mouse. Maybe another input device that compliemtns the mouse and keyboard... or replaces the mouse...
  • But it seems that what i want isn't what anybody else (at least of the posts i've read) wants. so the solution seems to be a completely and totally controllable and customizable user interface. one where the user upon installing the OS chooses exactly what he or she wants but in a way that i don't have to go and edit /usr/bin/desktop/blahblahblah...and putz around through code that i didn't write and may not understand or that the average user can't understand.
    or how about a UI that is dynamic. upon the first few startups and when new apps are used and new functions performed, the OS asks the user about the available options and so after a little bit of good use, everything is configured to at least the best available options for the user.
    i'm not too up to date on where exactly the software market is in this respect, and i am surely not a coder who can begin to work on this kind of thing myself. but a truly dynamic, customizable UI that learns from the user's input based on questions asked due to the user's actions would be wonderful.
    and as a start, how about we just begin with giving options as to the layout and configuration and don't try and hide the ways that these kinds of things can be done.
  • two key facts about humans: We are creatures of habit, and we like control.

    I know people who hate the "pesonalized menu" feature in MS Office 2000 or later (where items not recently used are hidden). As creatres of habit, they want to see "Print Preview" every time they click the File menu!

    But they also like configuratiblity where they can customize menus to their needs and create keyboard shorcuts instead of relying on a mouse all the time.

  • Something I find very frustrating about Windows and many *nix windows managers, is the propoensity to waste screen real estate on useless items and pleasantries.

    Take a full-screen window (such as IE) under Windows. At the top you have a title bar, then a menu, then a row or two of toolbars, then your actual application space, then a status bar, then the start bar. All in all, more than a fifth of my vertical space is wasted.

    Windows has one (poor) solution: auto-hide the start bar; but this also hides some useful indicators on your tray. IE (specifically) has a nice full-screen mode (F11) but again you lose your master menu system, tray icons, and still have a useless bunch of pictures at the top of the screen.

    I have long believed that a windowing GUI is an outmoded idea. Provide an "OS interaction" screen (full screen) with a menuing system, access to OS configuration, some monitoring/info, and a list of running applications. Each application runs full screen, with a single global hot-key to change back to the OS screen. There is some provision for a floating menu button and status icons (tray icons) over every application, or called up by a hotkey.

    While this moves back to a DOS/menu or Desqview view of the world, I have found that most users are more comfortable with a clear menu system in which there is only one way to do something, and with applications which seem to take over the computer instead of sharing it.

    Another feature I have found useful to myself and end users is visual presentation of options and immediate feedback. I am thinking particular of a DOS editor called PC-Write; there were several other programs at the time (including the Borland IDEs) which did similar things. At the bottom (or top) of the screen was a bar with 10 segments, representing the actions for the F1-F10 keys. It was easy to tell at a glance what pushing a particular key would do for you. What if more, if you pressed ctrl, alt, shift or any combination, the bar changed immediately to display the meta-F actions.

    Most software today expects you to use a toolbar (point & click), navigate a menu using several keystrokes (or point & click), or discover deep in some forgotten help file the special key or key sequence you need for a particular task. This makes improving productivity (by reducing mouse dependancy) extremely difficult.

  • Random Ideas (Score:2, Insightful)

    by Anonymous Coward
    Few random ideas:

    (i)
    Well, I, for one, would like to see the window title bars becoming task bars/tabbed panes, and the start menu attached to the title bar, not buried in the bottom left of the screen. I'm not talking exactly about a tabbed-wm like PWM, more like each window being an xemacs buffer, so that every application is "in" every window, just only one in the foreground of the window at a time.

    (ii)

    Right-button menus. Context menus aren't bad as such, but why aren't ALL menus available on right click ANYWHERE. Grey out inapplicable entries, don't shuffle them around for each different object. Think Amiga+MagicMenu - all actions available in the same places each time, just greyed out if they are irrelevant. Also, make sure they appear on button down, not on click. Windows RMB menus really suck that way.

    (iii)

    Well integrated GUI/CLI combo. Think Common Lisp CLIM. If you've never used it, check it out. XMLTerm is a similar idea.

    (iv)

    A decent file manager. Think Directory Opus.

    (v)

    Animated icons and sounds.

    (vi)

    Vector graphics for most operations.

    (vii)

    Resolution-independence. MY SCREEN is 120DPI, DAMMIT, but a 10pt font should be THE SAME PHYSICAL hold-a-ruler-to-the-screen size as on any other screen. Just more readable than on a lower DPI screen. Very few GUIs get this right.

    (viii)

    No more cryptic little icons on toolbars. Humans invented writing for a reason. If you need an obscure little picture, put the writing underneath or beside it. "Tooltips" are an admission of defeat by lazy GUI designers.

    (ix)

    Bring back the on-screen FKey bar. F1-F12 printed along the bottom of the screen, along with what each key does, was immensely usable, fast, and obvious. "modern" GUIs really neglect the keyboard.

    (x)

    Amiga-like removable media handling. Disk goes in, icon appears on desktop. Disk comes out, Icon disappears. Icon corresponds to the volume label, not the drive the disk is in. So one can take the disk out and put it in a different drive, AND THE SYSTEM DOESN'T CARE. You can install a program from your fifteenth CDROM drive, AND THE SYSTEM DOESN'T CARE.

    (xi)

    AppDirs. Don't confuse the user. Make the filesystem hierarchy where applications live. Means installing is "drag icon off the cdrom onto the harddrive". Don't invent an alternate hierarchy in the Start Menu like Windoze does, or glom everything together in /usr like traditional Unix does.

    • (iii) Well integrated GUI/CLI combo. Think Common Lisp CLIM. If you've never used it, check it out. XMLTerm is a similar idea.

      (x) Amiga-like removable media handling. Disk goes in, icon appears on desktop. Disk comes out, Icon disappears. Icon corresponds to the volume label, not the drive the disk is in. So one can take the disk out and put it in a different drive, AND THE SYSTEM DOESN'T CARE. You can install a program from your fifteenth CDROM drive, AND THE SYSTEM DOESN'T CARE.

      (xi) AppDirs. Don't confuse the user. Make the filesystem hierarchy where applications live. Means installing is "drag icon off the cdrom onto the harddrive". Don't invent an alternate hierarchy in the Start Menu like Windoze does, or glom everything together in /usr like traditional Unix does.


      Mac OS has all of these (although 9 is missing the strong CLI).

      Mac OSX has, in my opinion, a fantastic CLI/GUI combination. If you want the power of the CLI you can open the terminal and run your computer from there, and you can spawn as many new shells as you like. Keep the terminal app on the dock and you have one click access to a CLI from the GUI.

      Since way back in the dark days of Mac OS removable disks mount only when inserted into their respective drives, and eject automatically when unmounted. There is no drive letter system, and the Finder's window isn't cluttered with icons of drives you can't use, only available volumes at the time of opening the window (or upon insertion of a disk/connection to a network volume)

      Apps can be anywhere, and will load from anywhere. If you move an application from its original location it will still launch perfectly. It doesn't care where it is. The Dock doesn't care either, no do aliases (shortcuts).

      Windows shortcuts, and the start menu, get stroppy when locations are changed, but Mac aliases and dock icons keep track of where their targets are without user intervention.

      Installing apps is a case of dragging to where ever you want your app to be (usually the Applications folder)

      Uninstalling apps is as simple as dragging it to the trash. None of the cumbersome uninstall nonsense in the Windows system.

      People seem to either love or hate Mac OSX (It's too cartoony/childish/not manly like "real" unix etc etc and other such bollocks), but I think it's a very impressive system. Uniform in buttons, dialogs, menus, keyboard shortcuts and with the Dock - the best system I've seen for managing and launching apps and documents (you can keep files and folders on the Dock too).

      If you dislike the eye candy (animated dock and windows) then you can turn it off. You can customise icons easily, plus, you have that all important easy access to the CLI, where you can do anything that the plain old vanilla Darwin can do to control your machine.

      Oh, and if the single button mouse thing is keeping you away, budget $15 into your account and buy a standard PC USB mouse (even the wheel works). You'll find you don't really need it though.

      Of all the GUIs available at the moment, I think OS X is the best of the lot.

      Look at it this way, as a friend of mine told me the other day: Mac OS X is a server strength operating system with all the power of Unix that your granny could install and use (but that won't frustrate the power user through lack of functionality).
  • Experiments in "3D" interfaces always seem well-intentioned, but miss the point. When folks start placing the user in a virtual environment, making it necessary to "walk around" a cluttered file system or data structure, it becomes far more cumbersome than the file manager metaphor.

    For my money and/or time, the proper direction for a 3D GUI would be something like a combination of Personal Brain [thebrain.com] and the GUI from Minority Report. (Don't laugh, I'm serious!) You want to give the user the ability to establish relationships between chunks of data, and visually echo those relationships in the UI -- thick cord connects to parent; thin line connects to peers; ghosted dots indicate references; etc.

    So the "depth" isn't really about being inside a 3D space -- it's about always having related data nearby and available while keeping unrelated data out of the way. And, again, we know what's related, and in what way, because the user has established these relationships.
    • For my money and/or time, the proper direction for a 3D GUI would be something like a combination of Personal Brain and the GUI from Minority Report. (Don't laugh, I'm serious!) You want to give the user the ability to establish relationships between chunks of data, and visually echo those relationships in the UI -- thick cord connects to parent; thin line connects to peers; ghosted dots indicate references; etc

      I have a working but basic prototype of a system I built to do this plus a whole lot more (the basics come from a different but important field of data management) that I've been meaning to turn into a proper product for the last 5 years or so.

      I'll be putting some more work into it next year, anyone who's interested drop me a line.... I don't think it'll change the WIMPS part of GUIs (i.e. you'll still be running programs in windows with menus), but it could drastically change the way you organise your life on a computer.

      --
      T
  • Past years studies have proved that we couldn't improve GUIs in a significant way without forgetting about most of actual concepts.
    So we DO need to forget about files and applications and think about objects, commands and transformers.
    We must concentrate in the user's locus of attention, monotony, non-modal GUIs, no more customization, taking care of visibility and affordance, noun-verbs and verbs-noun constructions... Also we must improve and separate highlighting, indication and selection over objects. I think we must implement unlimited selections, undos/redos, global search engines, document indexing.
    These are very concrete concepts towards future GUIs. A ZIP GUI (2D Zooming Interface Paradigm) can therefore be the clue to all these problems, and a common way to implement modern concepts.
    Moreover, realisation and maintenance costs for such GUIs can REALLY be loooower than the actual ones.
    I am seraching for people willing to try developing a prototype for such a GUI for Linux (or some other OS). Do not hesitate to contact me.

    sebastienjust@free.fr
  • by fava ( 513118 ) on Monday November 25, 2002 @02:30PM (#4752685)
    On kde-look [kde-look.org] there is a very nice looking replacement proposal for kicker and the desktop metaphor.

    The author proposes a card based metaphor which would allow you to mix and match componants to create your own desktop environment. There is no code yet, just some annotated "screenshots" here [kde-look.org] and here [kde-look.org].

    In the discussion there are several people volunteering to help code so this project may actually become reality.
  • There is only one thing that ultimately counts: usability. The quality of any interface depends solely on how effectively it can be worked with. What features make an interface effective to work with largely depends on what you want to do with it. Your average office worker likely loves the simplicity with which a good point and click interface lets him do simple things, J. Random Hacker likely loves the power and flexibility of the command line. Nevertheless, I know few hackers who don't prefer GUIs over CLIs when it comes like highly visual tasks such as web browsing. Disclaimer: the following is largely a collection of my observations of wins and losses in existing GUIs. There's nothing revolutionary here, probably not even anything innovative (unless taken in the `MicroSoft's tablet PC is innovative' sense).

    Modern GUIs tend to be full of colors, icons, animations and decorations. While nice to look at, these are all bad.

    1. Animations are bad.
    Animations distract the user, waste user time, and keep the system from doing useful things. Simple animations can be helpful (such as indicating the position of the icon while a window is being iconified), but smooth maximizing|minimizing|dropdown just slows down both the user and the system. I especially hate buttons etc. that grow or shrink when the mouse moves over them and change the whole layout of the controls in the window.

    2. Too many controls is bad.
    Controls are what make a GUI a GUI. Buttons are the most common, and provide one-click access to functions. However, modern, feature-laden applications usually have far too many of them. I saw one user with all toolbars that his word processor offered open at the same time, occupying half the screen. The idea behind toolbars should be that they provide easy access to commonly used functions. Having to search through half a screenful of buttons is not my idea of easy access. While typing or reading (the main activities on a computer), these controls are dead weight at best, distracting at worst.

    3. Too many colors is bad.
    While colorfulness can be visually pleasing, it is always distractive. It's much easier to find ones way through a black-and-white GUI than through one where every square centimeter has a different color. The same goes for fonts. My GUI has basically 3 colors: white (background), black (foreground), and blue (background for highlit items). I am thinking that swapping background and foreground colors might prove easier on my eyes. I mstly use two fonts: monospaced for controls, proportional for content. Of course, the actual content might have additional fonts to indicate its particular structure, but the monospaced font on controls makes clear the distinction between controls and content. More fonts would be distracting.

    4. Desktop icons are useless.
    Most GUIs I know use desktop icons. Most people I know have windows that occlude the icons. What use are icons when you can't see them? Icons are good, but keep their number low and put them in a toolbar. Files and applications that you don't use frequently don't go in your toolbar, but in a popup menu.

    5. Inconsistency is evil.
    This is something that annoyed me to death when I first tried to Linux. It affects other systems as well, but especially Unices. There are a plethora of widget toolkits, each with their own look and feel. Themes help, but there are always applications that do things their own way. XMMS and WinAmp are good examples. Different interfaces make switching applications extra painful, as it requires adapting to the new interface as an additional step.

    6. Doubleclicking hurts.
    I don't know who came up with double clicking, and I can't understand why so many GUIs rely on it. Double clicking is hard to do and counter-intuitive. Old people can't do it. Click to activate, draw a box to select, drag to move. Right-click (not click-hold; it hurts, not modifier-click; it requires two hands) to do unusual things (e.g. renaming).

    7. Focussing unrequested popups.
    Don't you just hate it when you're typing something and some window pops up, causing the key events to go through the wrong windows? Especially for those who look at the keyboard while typing, this can really have disastrous effects.

    Now for some Good Things I've observed in various GUIs. I use WindowMaker as my window manager, and most of the wins here are found in it, but some come from other GUIs.

    1. Dividing the screen into areas according to function.
    WindowMaker dedicates one area to the dock. This is where you put icons for frequently used applications. Windows don't go there, so your icons are always accessible. The same should be true for the icons for iconified windows; WindowMaker fails me there.

    2. One input device for everything.
    Something that requires the mouse, should only require the mouse, and something that requires the keyboard should only require the keyboard. In fact, since the keyboard is mostly indispensible (despite speech recognition), everything should be accesible by keyboard. MicroSoft Windows 95 mostly does it right, only how do I get to the icons (that they foolishly put underneath my windows)?

    3. Minimize wasted space.
    This is hard to do inside windows, which are rectangular (and should be, because it makes it easy to lay them out efficiently), but one thing it does apply to is title bars. Usually, these are much wider than needed. I believe has fit-to-content title bars that can be dragged along the top of the window. This allows windows to overlap, but still be accessible through their title bars.

    4. Window groups and hiding.
    A huge win of WindowMaker is that it groups windows of the same application together. All of them can than be hidden and unhidden with one command, making switching applications efficient and eliminating the need for virtual desktops to keep applications out of each other's ways.

    5. Drag and Drop
    A feature that most GUIs have, which can greatly speed up working. X's select, paste feature is higly efficient, so is MS Windows's dragging files to other windows to view them, or to directory views to copy them (I know they didn't invent it, but they have it).

    6. Expressive dialogs.
    Grasping graphics is fast, reading text is slow. I read this on Apple's site somewhere, and wholeheartedly agree with it: The ideal dialog has a short but to-the-point title, a text with a more detailed description, and controls that describe what they do. Examples:

    BAD:

    Confirmation

    Are you sure you wish to delete this file? Doing
    so completely removes the file from your
    computer.

    [ Yes ] [ No ]

    GOOD:

    Delete File?

    Are you sure you wish to delete this file?

    [ Delete ] [ Don't delete ]

    Optionally, this could have a [ Help ] button which would give a more detailed description of why one would delete or not delete a file.

    A number of random thoughts to conclude. Configurability is a ducious feature. I think it's good to be able to customize the interface to ones own preference, but it goes against uniformity. It would be nice to be able to script GUI operations somehow. I think Windows 3.x had some kind of macro recorder that might have done this, I've never used anything of the sort, though (I grew up with CLIs). Saving window positions is good. I like my windows arranged in a certain way, so I have the system remember how I had arranged them, and restore their positions next time they're used. Now I _really_ need to go sleep (+1 Insightful).

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Working...