Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
GUI Businesses Software Apple

Human Interface Subtleties in Software 53

Posted by timothy from the ineffables-in-action dept.
Disoriented writes "As a GUI designer and programmer I enjoy sites like this. The info here is fairly old, dating back to Classic Mac OS, but it illustrates the kind of details users look for in a well-polished GUI." Mac-centric, but there are good points made in here for anyone working on GUI applications -- less bitter than the Interface Hall of Shame, too ;)
This discussion has been archived. No new comments can be posted.

Human Interface Subtleties in Software More

Human Interface Subtleties in Software

Comments Filter:

  • Quinn! (Score:4, Informative)

    by daeley ( 126313 ) on Wednesday March 05, 2003 @06:00PM (#5444342) Homepage
    Whoa, talk about going back to the future.

    For those who don't know Quinn, IIRC he's the guy who wrote Internet Config for the Mac, what 10 years ago? Up until that point, you had to change internet prefs in a bunch of different places. With his program (which, again IIRC, was eventually integrated with the OS), you could change it in one spot.

    All hail Quinn! :)
    • Anarchie? Internet Config? Whoa! WHOA! Time warp!

      My head is caught in a time warp to back when I did Tech Support at an ISP!

      God, all those hours spent trying to help Mac users (with NO Internet Config) to hook up their modem, dial into an ISP, and get their IP address. Internet Config was a godsend.

      If I ever run into Quinn, I'll buy him a whole pitcher of beer!

    • Nitpick (Score:3, Insightful)

      by bill_mcgonigle ( 4333 )
      Quinn is un-exclaimed - it's "The Eskimo!" that's exclaimed. :)

      And yeah, anyone who keeps their internet settings at an OS level owes one to Quinn. It's an obvious concept that noone seemed to think of for years before Quinn did. And he didn't patent it.

  • GUI target size [Tog] (Score:5, Informative)

    by redelm ( 54142 ) on Wednesday March 05, 2003 @06:01PM (#5444359) Homepage
    This is a good article, and if you like it, you might like some of Bruce Tognazzini's work here [asktog.com].He also has a book out "Tog on Interfaces".

    One of his major points is the size of GUI targets. The edges and screen corners are easy to hit, but grossly underutilised by GUI designers. This causes more RSI in users than necessary. I've worked some apps with poorly chosen target locations and defaults that were just murder on my wrist.

    • The edges and screen corners are easy to hit, but grossly underutilised by GUI designers.

      This is, of course, why the Mac has a systemwide menu bar at the top of the screen, instead of a NeXT-style menu palette or a menu at the top of each window. The top-of-the-screen menu bar is said to be infinitely tall, because you don't have to worry about the Y coordinate when you click on it. Just push the mouse forward until the pointer stops moving, then click.
      • This is, of course, why the Mac has a systemwide menu bar at the top of the screen, instead of a NeXT-style menu palette or a menu at the top of each window.

        I think you'd find a menu pallette that popped up under the mouse cursor with a single click - paticularly if implemented as a pie menu - would be significantly faster that the Mac's single menu bar. There is a point at which having to move the mouse only a tiny distance outweighs having an infinitely high target.

        There are other examples where the Mac's single menu bar is not the best solution as well, such as multiple monitors, or very high resolutions.

        • I think you'd find a menu pallette that popped up under the mouse cursor with a single click - paticularly if implemented as a pie menu - would be significantly faster that the Mac's single menu bar.

          Marking menus. Sure, it's okay for selecting from one of, say, six choices. But the menu bar is hierarchical in nature: under the File menu you have these items, and under the Edit menu you have these, and so on. Marking menus don't work well for that.

          There is a point at which having to move the mouse only a tiny distance outweighs having an infinitely high target.

          Not really. I'm sure you're getting at speed here, and how much of a pain it is to drag the mouse all that way to the top of the screen, but if speed is your criteria then hotkeys will always win the race. They're incredibly fast-- instantaneous-- but they're also incredibly user-hostile.

          There are other examples where the Mac's single menu bar is not the best solution as well, such as multiple monitors, or very high resolutions.

          Actually, in both of those cases the single menu bar is the best solution, due to that "infinite height" property I mentioned.
          • Marking menus. [...]

            No reason why it couldn't be used to duplicate the top menu bar, with heirarchies and all. There's a *lot* less mouse movement, and speed comparisons should be identical once past the initial "hit".

            Not really. I'm sure you're getting at speed here [...]

            I am, and not everything has a hotkey. As I said, there's really going to be a point where moving the mouse barely a centimetre outweighs being able to just fling it at the top of the screen. Besides, sometimes your hand is already on the mouse and the approrpriate hotkey combo would be under your mouse hand and you'd be moving it back to the mouse afterwards anyway, so using the mouse is quicker.

            Actually, in both of those cases the single menu bar is the best solution, due to that "infinite height" property I mentioned.

            Practical experience tells me otherwise. The single Mac menu is a pain because it is only present on the primary screen, so if your cursor is on another screen it's got a *long* way to go. This can be exacerbated by having screens running at different resolutions (particularly different vertical resolutions). While Windows' menu-in-the-window method solves this problem, it unfortunately suffers a near identical one by only have a single taskbar in the primary screen (Windows' (IMHO) superior task switching paradigms lessen the impact, but it is a problem). OS X of course gets the double whammy by only having the menu *and* the Dock on the primary screen. What they need to do is duplicate the taskbar/Dock on all screens (with only the windows/apps present on that screen in it) and in the case of the Mac, duplicate the menu across screens. The argument against this is probably one of complexity, but if you're dabbling in multi-monitor setups, you should be well beyond the point of a marginally more complex interface being an issue.

            I'm sure you have some UI guidelines you can quote saying it's a bad idea. But like tabs, actual real-world usage blows the theoretical handwaving out of the water.

            Of course, having a menu and task list that could be made to pop up under the mouse cursor would neatly solve both issues, but I have not the time, skill or interest to bludgeon a unix WM into doing what I want and it's way too radical a departure from what's "normal" to even be considered by Apple or Microsoft.

            Similarly, high resolutions become a pain because of the distance one has to move the mouse cursor to get to the menu. This issue is exacerbated by the Mac's traditionally slow mouse tracking. You *can* get various hacks and tweaks to boost the tracking speed, but IME they all ruin the acceleration curve.

            • There's a *lot* less mouse movement... As I said, there's really going to be a point where moving the mouse barely a centimetre outweighs being able to just fling it at the top of the screen... The single Mac menu is a pain because it is only present on the primary screen, so if your cursor is on another screen it's got a *long* way to go...

              Usability is not defined by mouse mileage, nor by differences of tenths of a second. Sorry.
              • Y'know, after reading this thread I can't decide if you're an arrogant teenager with an extremely nasty case of cluelessness, or a particularly skilled troll.

                If you're a troll, my god man, you're brilliant; keep up the good work. If not, well, ummm, it's okay, have mommy change your diaper and I'm sure you'll feel better soon...
                • How's this for a troll? Get bent. You have posted exactly three comments to Slashdot. Two of them have been directed at me, and both of them have been personal attacks. If you don't have something constructive to add-- which you evidently haven't since January 28, 2002, then what say you get the hell off my back?
              • Usability is not defined by mouse mileage, nor by differences of tenths of a second. Sorry.

                You just love the Chewbacca defense, don't you ?

                Once you've finished beating that poor straw man to death, feel free to address my prior statements.

          • Quite often, after doing something with a menu, the user wants the mouse pointer pretty close to where it was before he went for the menu. Putting the menu at the top of the screen makes it easy to hit the menu, but then getting back means a harder movement -- typically halfway across the screen without the edge of the screen as a backstop. What's more, you shifted your gaze up to the menu bar, so you have to find the target with your eyes before you can jump to it. A menu system which kept the pointer and your gaze in the right part of the screen would be faster.
            • Yeah, if it were not for reality.

              Pie menus only really make sense when you have one fixed menu with max. 6 choices. Contextual menus keep changing (else they wouldn't be contextual) and get more annoying the more items they have and/or the closer they get to the edges of the screen (because they keep running into them).

              Anyway, neither are sufficient compared to what a permanent menu bar offers - which leaves us with the decission where to put that.

              • I'm indifferent to pie menus, personally.

                But: The very fact that contextual menus keep changing is what makes them crappy. I'd much rather ALL actions were on the right-click, and irrelevant ones GREYED OUT, rather than moving stuff around in a context-sensitive menu and preventing me muscle-memory-learning where they are.

                Amiga MagicMenu worked the way I like.

                Also, amiga menus allowed you to multiple-select by holding the right button down while clicking with the left on the menus - much handier - meant that most "preference dialog" style interactions could be done instead with toggle items in the menu.

                Actually, one of the "subtleties" in the article I kinda-sorta dislike sometimes is the diagonal-submenu thing, since Amiga-pattern multiselecting preferences-menu usage is to scan large numbers of submenus - so the "quickly flashing up and disappearing" submenu behaviour is one that I sometimes prefer.

                I also hate the way the top-of-screen menus mean your mouse pointer ends up away from what it was - but I also hate the way right-button menus do that! That's why I experimented with pointer-relative hierarchical right-button menus. You can give them a try by running a .jar file that fakes them by hiding the real mouse pointer - see
                here [www.iol.ie]. Note that the jar will just display a grey window - you'll have to click on it.

              • You're probably right that six wedges is about the limit. But why can't pie menus be hierarchical? If the pointer moves more than N pixels from the starting point, a (pie) submenu pops up. You'd probably need to use one wedge of the submenu as a way back to the parent menu. I've never tried pie menus, but I'd like to.

                I agree that a menu bar is useful, but I want the frequently used functions on a right-click menu as well. A few years ago I spent much time with a desktop publishing app that had everything in the menu bar accessible from the right-click menu -- there was one choice in the top-level menu for each pull-down in the menu bar. It had way too much stuff, and if I didn't use it for things I had to look for or think about. For functions I knew and used often -- e.g. edit-menu, bold/italic -- it was faster, and less disruptive to my train of thought, than the menu bar.

                As for where to put the menu bar, the edge of the screen makes sense if, and only if, you're talking about a window manager or an app in full-screen mode. What do I do when I want several things on the screen at once? One possibility is to have edges of the window block the pointer (it's possible under X -- there's a maze program floating around that does this) unless a special "let me out" action is taken. That gets you the "infinitely tall" effect without involving the edge of the screen.
                • Well, most people (on Windows at least) do use full-screen (or rather maximized) mode. And "block exit" mode makes having multiple windows on-screen less usefull - well, if you have decent drag'n'drop capabilities ;-)
    • "The edges and screen corners are easy to hit, but grossly underutilised by GUI designers"

      I dont get this - what about all the drop down menus that are at the top edge of the screen.

      What about the START button in the bottom left - and top left on Macs?

      What about the information status bars on the bottom of web browsers?

      No - I think that the biggest problems with online GUIs is the tendancy of designers to model their interfaces after traditional text based "interfaces" like newspapers and books and traditional publishing styles.

      There is not much innovation (in the mainstream) to navigating an interface.

      There are major problems with full GUI interfaces - one is efficiency.

      I am a perfect example of this - I am a very proficient AutoCAD designer and I close every single menu thats in autocad. I can type any command with my left hand faster than anyone I have ever met can click on it...

      I despise any sort of clickable GUI in this environment as it requires my cursor to travel away from my primary focus of work - which is with the lines of the drawing. I would prefer to have more flexability with the keyboard as well - there are things that GUI (interface) designers just cannot know unless they are a full time production user of an interface.

      For example in AutoCAD I should be able to toggle between orthographic and free movement constraints with a key-press combo - like ctrl+shift. I also should have totally transparent zooming and panning (especially panning) with a ctrl+shift+alt or some other key combo...

      GUI targets on the periphery might seem like a good idea to the casual user of them - but when having to interface with a machine for many hours each day, every day - having things either totally controlled by the keyboard, or at least as close together as possible is important.

      In CAD design applications - the focus of the mouse cursor should be all manipulation of the object/information. The keyboard should be used to issue commands. This minimizes the movement of the mouse and makes drawing/designing much more efficient.

      The worst is when you have to remove your hand from the mouse in order to type something.
      • I agree that keyboard shortcuts are important. But most people don't use them. On top of that, even keyboard jocks use the GUI, at least when they are first using a program. && on a lot of programs, doing most everything from the keyboard just doesn't make sense - OS interfaces and word processors (for tasks such as changing font faces &c), for example.

        As for the button on the edge examples you give, most of them don't count as stuff on the edges and corners from the perspective of a GUI designer. The advantage of putting something along the edge of the screen is that you simply have to shoot the pointer in the direction of what you want to hit and click. This only works if the clickable area for a widget literally goes all the way to the edge of the screen.

        The widget bars at the bottom of web browsers don't do this because nothing goes to the edge of the screen, and most of it isn't clickable, anyway.

      • Re:GUI target size [Tog] (Score:5, Informative)

        by AT ( 21754 ) on Wednesday March 05, 2003 @07:33PM (#5445197)
        What about the START button in the bottom left - and top left on Macs?

        Bad example. On Windows (up to 2K, anyways), the start button is slightly off the corner. If you whip the mouse down to the lower right until it hits the edge, you'll actually be past it! Those extra pixels between the edge of the screen and the Start button just sit there being wasted. Gnome gets this right, and I suspect KDE and the Mac do a better job, too.

        • KDE gets it. There are a few pixels between the border and the button in Kicker, and it doesn't highlight quite right, but if you click, it will come up.
        • The absolute corners in OS X are used by the screen saver/screen locking app. The corners can be set to be 'hot corners' to trigger the screen saver. By default, I think, they are unused.

          There isn't a true equivalent to Window's 'Start' button, though -- no one piece of the Mac GUI gets that high a percentage of the use. Which is a whole 'nother thing to talk about...

        • On Windows (up to 2K, anyways), the start button is slightly off the corner.

          This has been fixed in Windows XP. You can now just throw your mouse to the bottom corner and hit the Start menu. Actually, this is the first that I've noticed it, as I was so used to the flaw in previous versions of Windows.

        • By default on XP, the start button is right in the corner of the screen, so you can't overshoot. But if you prefer to have a larger task bar, for more than one row of buttons, the start button is docked to the top-left corner, so you end up with a large chunk of dead-space underneath it!

  • Attentive User Interfaces (Score:3, Informative)

    by chemstar ( 457943 ) on Wednesday March 05, 2003 @06:10PM (#5444455) Homepage
    For those who may be members of the ACM [acm.org], the new issue of the ACM magazine Communications has an excellent issue regarding Attentive user interfaces [acm.org].
  • I noticed that KDE has some of the features mentioned. I don't know about GNOME, but Mozilla doesn't have these.

    - Sub-menus won't open if you move towards an already opened one.

    - When you type, the cursor is hidden.

    I think there might be a few old mac users on the KDE team.
  • This article really should be "A dozen or so things about a half dozen pieces of Mac OS software a geek thinks are cool." Most of his points are valid, but overstated. However, I do disagree with one thing: in the finder (Classic and X) when you drag a file, it does not at first highlight the window that it is in. It's not until you draw that file over another window does the other window get highlighted. Okay, so far so good. However, when you drag the item back to its original location, the originating window gets highlighted. I don't think this is optimal behaviour, but the author of this little web page goes to lengths to point this fact out! If you're going to highlight a window, always do it or never do it.
    • Well spotted. I too thought that on return to the original window the target highlighting should disappear as, in simple terms, there ain't no bleedin' target as you ain't doin' nuffin!

      The other one that I thought he overstated was the fact that his mailer was cool because it had one scroll bar for the whole message composition window rather than the admittedly disgustingly ugly multiple-region setup of the thing he was comparing it to. This is no different from what old text mode (console-based) mailers have done since the beginning of time. (e.g. Pine, which I still use). So the reason the Mac app was so great was because they had't broken an already working paradigm.

      I prefer to simply look at the interfaces from hell and laugh/cry than to have a presentation of supposed good ones where sycophants fawn over them barf-inducingly.

      YAW.

  • Semi-OT: Interface Hall of Shame (Score:4, Informative)

    by Narchie Troll ( 581273 ) on Wednesday March 05, 2003 @08:28PM (#5445549)
    That isn't the Interface Hall of Shame, it's the "OS X-centric Hall of Shit." iarchitect.com is gone, but the Wayback Machine still has it.

    Interface Hall of Shame [archive.org] A lot of this OS X IHoS's sections are like those in the original Hall of Shame. Interesting. The original is no longer up to date, however. I'd have loved to see their views of OS X and Windows XP, as well as the up-and-coming X Window desktops.
  • I hope the people who make stuff like, KDE/Gnome/Windows pay attention to stuff like this. Especially the busy cursor, pointer obscuring, and the heirarchial menus. If there was some way to configure KDE or Windows to follow these behaviors that would be very awesome. Does such a thing currently exist?
    • The diagonal drag thing for submenus is implemented in KDE3.1 - I don't know how long it's been there. I actually thought it wasn't until I read this article and tried it - I guess it really is that intuitive and subtle.

      The pointer hiding works in kde3.1 as well. I don't know about Gnome, but I do know that the windows UI is seriously behind KDE/MacOS classic/MacOS X.
  • The post mentions two websites, firstly the (very very old) HI page, which believes that submenus are the dog's bollocks (that means they're great, for you Americans), and the interface hall of sha,e which has the following to say about submenus:

    "Submenus are possibly the only interface element that can be physically very hard to use, and therefore should be avoided in UI design at all times, if at all possible. "

    I also question the reason for this appearing on slashdot at all. What's next - good interface design on the Commodore 64???

  • Who needs them (Score:4, Funny)

    by __aafkqj3628 ( 596165 ) on Thursday March 06, 2003 @02:42AM (#5447333)
    Who really needs a GUI for an application these days, console-based apps will once more rule the world. Bwahahahahahaaha!!!!

Slashdot Top Deals

The solution of this problem is trivial and is left as an exercise for the reader.

Close