Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GUI KDE Software

OpenUsability and KDE: Cooperating on KPDF 184

Posted by timothy from the ensmoothening dept.
sultanoslack writes "More from the world of usability in KDE -- there's an interview up where Albert Astals Cid, the KPDF maintainer, and Florian Grässle, a usability engineer from OpenUsability on working together to make KPDF more usable and some of the challenges in working together in a developer / usability engineer team. We've been seeing more from the OpenUsability folks lately, and they'll also be present doing a talk and staffing a booth this week at LinuxTag, Europe's largest Open Source conference." This interview-with-screenshots provides a neat look at the interaction of usability concerns and software development.
This discussion has been archived. No new comments can be posted.

OpenUsability and KDE: Cooperating on KPDF More

OpenUsability and KDE: Cooperating on KPDF

Comments Filter:

  • Nice development (Score:5, Interesting)

    by moz25 ( 262020 ) on Monday June 20, 2005 @07:35PM (#12867848) Homepage
    I certainly welcome this development. Usability is not exactly the first thing that comes to mind with a lot of open source software. This is an area that proprietary software companies still have an edge on because they're also in a position to pay for the extra work going into interface design.

    Basically there are several aspects a good interface should fulfill -- like preventing errors before they happen and the user has to deal with them or giving the user control and freedom over the application (and not vice versa), offering an efficient interface and so on.

    I'm not sure how errors can be prevented, assuming that they're not within control of the application. Does he mean design errors? Can someone explain?

    • Re:Nice development (Score:4, Interesting)

      by kebes ( 861706 ) on Monday June 20, 2005 @07:48PM (#12867932) Journal
      I agree with the "preventing errors before they happen" concept. Basically the application should warn you that a value is erroneous at the first opportunity. You shouldn't have to wait until you're trying to save a document for the error to screw you. You shouldn't even have to wait until clicking "OK" for an error box to show up saying a value is out of bounds... basically helpful tooltips should appear as you are typing, warning you if your input doesn't makes sense or is out of bounds or whatever.

      Applications can also be built to "look" for certain kinds of common problems and take action. For instance, an application can keep watch of memory or disk space, so instead of just getting a "disk full" error or whatever, the user is warned enough ahead of time that he can deal with the problem... rather than losing the work he's done.

      • Re:Nice development (Score:3, Insightful)

        by rg3 ( 858575 )
        Eventhough this doesn't relate to GUI applications, just imagine:

        $ rm -fr /
        This will erase the whole tree! Type "Yes, I know" to continue: _

        Even for correct input, an application should prevent you from making dangerous actions and things that, while for a computer are perfectly legal, might be an error from the human point of view.

        The rm example is just an example. You have to take into account the type of users that are using your application, if they're experts or not, etc. Well, sometimes a little bi

        • Re:Nice development (Score:2, Insightful)

          by N3Roaster ( 888781 )
          Safety features on command line tools might be nice, but it would be hard to incorporate that sort of thing in a UNIX environment where the tools are often being called from shell scripts and such. If simple command line utilities are going to try to keep me from shooting myself in the foot, I want a flag for releasing the safety.

          P.S. If '$ rm -fr /' will erase the whole tree, your permissions are seriously messed up.
        • The Z Shell [zsh.org] features some heuristics for that. If a command line performs a completion on "*" and the command is "rm", it asks for confirmation, even with -f:

          hisham@brick /Depot/test]rm a*
          hisham@brick /Depot/test]rm *
          zsh: sure you want to delete all the files in /Depot/test [yn]? n
          hisham@brick /Depot/test]rm -f *
          zsh: sure you want to delete all the files in /Depot/test [yn]?

          Obviously, as everything in zsh, this is configurable (setopt -u rm_star_silent to disable it).
      • KDevelop is a great example of this. That red cross next to a syntactical error makes my life a whole lot easier when typing quite quickly.

      • basically helpful tooltips should appear as you are typing, warning you if your input doesn't makes sense or is out of bounds or whatever

        Good usability tries to take this further. When designing, one anticipates errors the users might make, and removes the possibility for them happening at all (see Jakob's fifth heuristic [useit.com]). Simple example: instead of using a simple text box for date entry in the format dd/mm/yyyy and hoping the user reads the explanatory note next to the field, one might use three drop

        • So, three dropdowns is a usability feature? Then I don't want usability. It takes four or five times as long to pick three numbers from dropdowns than to write them in a textfield.

          Doing input checking as you type, or at least when you're finished and move on, is better. Then you'll only be hassled when you do wrong.

          • Yes, but that requires the designer to really think about what they're implementing, which is something they seldom do when there's a good-enough-for-most answer already in existence. UI designers are mostly sheep. Chancers. There's very few original thinkers among them. I know this because I am one.

    • Re:Nice development (Score:3, Insightful)

      by fermion ( 181285 )
      I'm not sure how errors can be prevented, assuming that they're not within control of the application. Does he mean design errors? Can someone explain?

      First, errors typically mean that the user did not experience the expected outcome, and is not typically a judgemental statement. My unmderstanding of this is that a human will expect certain things, and will act based on past experience. For instance, on a web page certain colors have come to mean visited links, while others will attract attention. So,

  • Good Thing(TM) (Score:5, Insightful)

    by neurokaotix ( 892464 ) on Monday June 20, 2005 @07:36PM (#12867860)
    The OpenUsability group is exactly what is needed in the Linux/open source community right now. Standards on how software should be layed out and behave is one of the major setbacks in the open source community. It seems as if just about everyone has their own version and great idea on how an application should be layed out. This is one reason (just one) why Windows will continue to have an edge in the desktop market. On Windows you can open just about any application and already know how to use it (at least, at the most basic level). If you've used Microsoft Word then you've got a head start on knowing Internet Explorer, Notepad, and Calc.exe.

    • Re:Good Thing(TM) (Score:3, Insightful)

      by Brandybuck ( 704397 )
      If you've used Microsoft Word then you've got a head start on knowing Internet Explorer, Notepad, and Calc.exe.

      How is this any different from KDE or GNOME? If I've used KWord, for example, I've got a head start on knowing Konqueror, KWrite and kcalc.
      • I hope they do it properly and *not* take any notice of GNOME.. thinks like being unable to cancel a lot of actions because the cancel button was deemed to be 'too complex' by the usability expert... hiding all the useful options so you can't configure the damned thing any more, making every single app have its own font/style settings instead of a global one.. not to mention putting the OK/Cancel buttons the wrong way around for the sole reason that it's 'different to microsoft'.

        • thinks like being unable to cancel a lot of actions
          Like what?

          hiding all the useful options so you can't configure the damned thing any more
          That's what GConf-edit is for. You can find all the settings the application has, including documentation for every setting. Makes more sense to me to have things hidden away behind a standardised interface than to have a menu/dialog option for options you're unlikely to change more than once

          font/style settings instead of a global one
          That's just plain baloney
          • He's just bitching because GONME/GOMONE/whatever the hell it was called turned out to be nothing but a load of hot air. :)
          • The "right" way being defined as the way Microsoft does it? Or do you have a real argument for why it's more "right"?

            It is a standard. It is carried through pretty much every operating system. I agree with the grandparent in this one. Not doing something simply because it is the same as what Microsoft does is just petty and silly, like saying we shouldn't have a network or a browser in Linux cause Windows has them.
            • I happen to think that having the "OK" button in corner is a logical and predictable place for the most frequently used button to me. Just because Windows does it doesn't mean it's the right thing to do.

              You could make that argument for everything, and say that we should all either be using Windows or that other applications should aim solely to duplicate the windows UI.
            • And by "every operating system", you mean Windows. Certainly, the only other major desktop OS, the Mac, does it it like GNOME does.

    • Re:Good Thing(TM) (Score:3, Insightful)

      by nathanh ( 1214 )
      On Windows you can open just about any application and already know how to use it (at least, at the most basic level).

      iTunes, Word, Photoshop, Winamp, Autocad, Antispyware...

      Yeah, they all look and work exactly the same. No differences whatsoever. Nosiree. Identical. Windows is a PANACEA for UI consistency, I tells ya.

    • Re:Good Thing(TM) (Score:4, Insightful)

      by pherthyl ( 445706 ) on Monday June 20, 2005 @10:35PM (#12868896)
      You're quite wrong in that respect. Just because there are two widget sets with about equal popularity on Linux doesn't mean that applications are not consistent.
      My Linux (KDE) environment is much more consistent than my Windows environment. In windows, a lot of apps roll their own widgets (off the top of my head, MS Office, Visual Studio, Firefox, MSN Messenger, Winamp, Various proprietary apps for hardware devices, Zonealarm firewall, AVG antivirus)
      Hell, every second application I use on Windows has it's own idea of what widgets to use or what keyboard shortcuts to assign.

      In KDE, the only application I run that doesn't use KDE widgets and standard keyboard shortcuts is Firefox. Every other application is very predictable and consistent.

      Also, consistancy goes further than just looks and keyboard shortcuts. In KDE, the advanced text editor widget is the same in every editor, so I get the same syntax highlighting and code folding and whatever if I'm editing C++ in KDevelop or if I'm doing PHP in Quanta or viewing a text file in Kate. In addition, I get the same spell checking whether I'm typing an email in Kontact, typing an instant message in Kopete, or submitting a form in Konqueror. I could go on. Network transparency, password storing, mouse gestures.. All these things are standard across the whole platform.

      Now that is a level of consistency not matched in ANY other platform.

    • Two words: Windows Mixer (Score:3, Interesting)

      by Ricin ( 236107 )
      Yes usability is very important and undervalued, but it's quite rediculous to see Windows as the shining light in this respect.

      I always say two words: Windows Mixer. Here's a (I suppose) utility that's meant to be used a lot by any and all users. But since it's birth (win95 or maybe even 3.x) it's been totally incomprehensible and it hasn't changed at all. Ask a random person to turn the microphone playing down but the recording level up (for example to reduce echos while in a conferencing app). They'll ge

  • Linux v. OS X (Score:4, Insightful)

    by dotslashdot ( 694478 ) on Monday June 20, 2005 @07:43PM (#12867904)
    What's the difference between Linux & OS X? Usability. And that makes all the difference. HUGE difference. KDE is great, Konqueror is nothing short of amazing in its versatility, but the lack of polish can really hurt Linux distributions. Do you want to spend your days trying to figure out why your scanner suddenly doesn't work well under the new Mandrake/Fedora/SuSe or do you want to use your scanner? Usability is important--even for Geeks--because allows you to accomplish what you need/want to do. If you enjoy trying to fix things, that's great, but most people need their computers for work/play and don't have the time or inclination to troubleshoot their main desktop computer.

    • Re:Linux v. OS X (Score:5, Insightful)

      by LMCBoy ( 185365 ) * on Monday June 20, 2005 @08:07PM (#12868049) Homepage Journal
      What's the difference between Linux & OS X? Usability.

      Eh...I'd say KDE usability is actually better than OS X in many respects. What you describe in your post is hardware compatibility, not usability.
      • The problem with KDE is, even if its usability is fine, it's all thrown out the window as soon as you open non-KDE apps, because in their infinite wisdom, open source programmers decided to divide programs up into groups, each group having completely different interfaces and settings. For example if you set up a theme in KDE, and you open a program which uses gtk, your theme doesn't work. The same goes for running QT programs under gnome. What genius decided that was a good idea? Surely the apps should use
        • Oh, come on. What you say about KDE and Gnome goes for use of various toolkits and libraries in Windows and OS X as well (the latter can even use two differet window border styles at the same time, for double consitency). Getting rid of the various toolkits will either kill backwards compatibility (how are you going to run Notepad or Wordpad if all you have is .NET without reimplementing them from scratch?) or future innovation (how are you going to develop good apps if all you have is $oldlibrary), and is
        • I don't know about vice versa, but GTK apps can be made to blend in quite well with KDE without resorting to having "sort of the same theme for both": GTK-Qt Theme Engine http://www.freedesktop.org/Software/gtk-qt [freedesktop.org]

        • Re:Linux v. OS X (Score:3, Informative)

          by LMCBoy ( 185365 ) *
          The problem with KDE is, even if its usability is fine, it's all thrown out the window as soon as you open non-KDE apps, because in their infinite wisdom, open source programmers decided to divide programs up into groups, each group having completely different interfaces and settings.

          Yes, this is completely unique to open source. OS X would never craft a commpletely unique interface for, say, Quicktime. Or The Calculator. It's all about the HIG for them, right?

          The larger point here is that opne source
        • The problem with KDE is, even if its usability is fine, it's all thrown out the window as soon as you open non-KDE apps

          Then don't use any non-KDE apps. I get through my day just fine without GTK/Gnome being installed on my system at all. I might just be able to do the reverse, if I were a fan of Gnome.

          For example if you set up a theme in KDE, and you open a program which uses gtk, your theme doesn't work.

          It does if you have the gtk-qt theme installed.

          Surely the apps should use the same toolkit for a
          • Then don't use any non-KDE apps

            Great, so the only way to make the Linux UI even remotely consistent is to uninstall half your applications. That's the most fucking stupid thing I've ever heard. Who the hell came up with that one? Not only the inconsistency, but now you've got two different sets of libraries runnign, eating up ram, and twice as much to upgrade/patch/install. All for ABSOLUTELY ZERO EXTRA GAIN. It's like having two steering wheels in your car, or two languages in one book. I think it's time
            • What the hell are you going on about?

              Great, so the only way to make the Linux UI even remotely consistent is to uninstall half your applications.

              KDE is a complete desktop environment. If you have both KDE and Gnome installed, then half of your programs do the same thing as the other half. It's quite possible to use KDE applications for everything, unless you're trying to run something that's not a typical desktop application.

              There are only a couple exceptions I can think of as far as 'things people wou
      • I agree that the scanner not working in the first place is a hardware compatability problem.

        However the poster seemed to be complaining about a scanner that *was* working and suddently stopped. This *does* seem to be a problem in Linux, it has happened to me and friends of mine (for me it is sound playback which quits and does not return unless rebooting, but plays just fine when it does work, for my friend it was a PCMCIA storage card that worked perfectly until he changed something supposedly unrelated a

    • Re:Linux v. OS X (Score:4, Insightful)

      by zsau ( 266209 ) <slashdot@thecart o g r a p h e rs.net> on Monday June 20, 2005 @10:10PM (#12868776) Homepage Journal
      Macs aren't the be-all-end-all of usability. The Mac UI has many problems itself: Consider the case of menus for instance. If you click, it closes the menu. That seems to make sense, except when you consider that it closes the menu if you click on a separator (which you probably did because you mis-aimed given that there's no clear separator between the separator and the items above and below ... now you need to open the menu again, re-aim, and perhaps repeat!), and the menu closes if you click an item with a submenu, which you probably did because you want the damn thing to open!

      Not to mention the amount of times I've been confused/lost time (or even slept in!) because some dialog boxes are instant apply, others are apply-when-you-close and others are explicit-apply. Of course you have to guess which is which (even different pages of the same, central System Preferences box behave randomly differently!), whereas in X, the different desktop environments either behave close enough or look radically different.

      I'm not saying that X-based Dekstop Environments have no usability problems, or even necessarily that they have less. I'm saying that we shouldn't glorify OS X, because it's just the same mess we already have, but with the menubar at the top of the screen.

      (Whether your scanner works isn't an issue of usability really (it's an issue of driver support), and in any case it's something that's being worked on. Many distributions allow you to plug in hardware and have it 'just work' nowadays, and just as Mac OS X has drivers for some thingns Linux doesn't, Linux has drivers for some (modern, desktop-oriented) things Mac OS X doesn't. If you want any random piece of hardware working, you use Windows.)
  • Glad to see usability of open source software coming to fore front of the development. This is vital in terms of winning the heart and sould (and mind?) of regular everyday Joe users.

  • Linux usability definitely needs a lot of work (Score:5, Interesting)

    by timecop ( 16217 ) on Monday June 20, 2005 @07:46PM (#12867920) Homepage
    The other day I downloaded Fedora Core 4 DVD to try it out.

    Usability problems already began right at the installer. Below is some things I noticed that should probably have been fixed long time ago:

    1) I noticed the installer was using gnome-themed Yes/No dialog boxes when it wanted to ask questions. The problem is, half of those dialogs used GTK2's Yes/No buttons (red/green circle) and the other half used GNOME's yes/no buttons - green enter symbol and a red X. This is very inconsistent and confusing to the user.
    2) At a number of times, default option in a Yes/No dialog was not the "cancel" one but one which would make irreversible changes. This is not good - what if someone accidentally presses "enter" on a dialog like this?
    3) Keyboard navigation, while present had several bugs. At one point, installer asked for a root password, and when I entered a "weak" password, it popped up a warning dialog about this. The problem is, after I dismissed the dialog (with a esc key), keyboard focus was no longer on the installer! (or anythign else for that matter, no amount of alt-tabbing or pressing tab would get the focus back on the installer. If someone without a mouse was running this, at this point they have no other choice but to abort the install and start from beginning.

    There was some other issues, but these are all I can remember off hand, and remember, this is just in the OS installer (GUI) itself! I can't imagine how much worse it gets once the system is installed and gets used. So, to make a long story short, any kind of cooperation to take usability one step higher is certainly welcome. Unfortunately this is only for a single KDE app, which isnt really unique in its function, but any change is better than nothing.

    • Re:Linux usability definitely needs a lot of work (Score:5, Insightful)

      by bullitB ( 447519 ) on Monday June 20, 2005 @08:15PM (#12868090)
      The problem is, half of those dialogs used GTK2's Yes/No buttons (red/green circle) and the other half used GNOME's yes/no buttons - green enter symbol and a red X. This is very inconsistent and confusing to the user.

      Not nearly as confusing as why everyone insists on perpetuating the Yes/No/Cancel paradigm. I don't see why no one else is adopting the new Apple-style verb-based dialog buttons. For example, in a Linux install I might see:

      "Your screen's fonts are of a really low resolution. Do you want to install 100 dpi X11 fonts? This will make the fonts look better, but you may want to not install the fonts to save disk space." ...with the buttons "Yes" and "No". This sucks. You basically have to read the entire alert to even know what's being asked, and even then there's some ambiguity. Does "Yes" mean yes, I want to save disk space? Does "No" mean I don't care about my hard drive, and want pretty fonts?

      A vastly more usable dialog would have buttons labeled "Install Fonts" and "Don't Install Fonts." No ambiguity, and the dialog itself is much easier to recognize.
      • You basically have to read the entire alert to even know what's being asked...

        Pardon me for being dense, but what the fsck is wrong with that? Let me guess, the next Apple interface won't even have text, and dialog messages will consist of pantomime quicktime movies...
        • Why do all that reading when you don't have to? It's about efficiency. If you can get the same thing across with little text and well-chosen button labels, why not do it?

        • Re:Linux usability definitely needs a lot of work (Score:4, Insightful)

          by pyrrhonist ( 701154 ) on Monday June 20, 2005 @10:53PM (#12869024)
          Pardon me for being dense, but what the fsck is wrong with that?

          What's wrong with it? It violates proper UI design!

          A properly designed dialog box does not force the user to think about what the choices will actually do. Dialog boxes with a long string of ambiguous text and Yes/No buttons violate this concept, because the user has to read the text very carefully before he makes a choice. This forces the user to stop thinking about what he was trying to actually accomplish with the application in the first place and forces him to figure out what the developer actually meant. This leads to both mistakes and a loss in user productivity. If the buttons are clearly labelled with what the choice will actually do, the user is less prone to make a mistake.

          • A properly designed dialog box does not force the user to think about what the choices will actually do.

            Aaargh! We've dumbed down the UI to the level of the flatworm! Why don't we just have a dialog box that has a nice smiley face and single button labeled "okey dokey"?

            If OSX is about not thinking, then keep it the hell away from me.
            • If OSX is about not thinking, then keep it the hell away from me.

              It's about letting the user get a vague idea of what's going on just by glancing. Every good UI has a presentation that allows this.

              Imagine you've got some batch process that runs under a GUI. Every once in a while, something comes up that needs your attention. A message dialog gives you some options. Imagine there are four types. Would you rather see "OK/Cancel" every time one pops up, or a couple of buttons that let you know exactly what

            • Re:Linux usability definitely needs a lot of work (Score:5, Insightful)

              by pyrrhonist ( 701154 ) on Tuesday June 21, 2005 @04:23AM (#12870264)
              Aaargh! We've dumbed down the UI to the level of the flatworm! Why don't we just have a dialog box that has a nice smiley face and single button labeled "okey dokey"?

              It's not "dumbing down the UI", it's making the user's choices explicit to help him avoid mistakes. This should be the goal of all UIs. Think about it. Is it easier and less time consuming to use an unambiguous UI? Sure it is. Wouldn't you much rather use a simple to understand UI? Sure you would.

              The user shouldn't have to figure out what the developer means by "Yes" or "No" in relation to the message in the box. Dialogs with a Yes/No choice are hostile to the user and time consuming for even expert users (i.e. you can't just click a button without checking if it's the correct one first even if you've encountered the dialog before). When the buttons explicitly tell the user what the choice is going to do, it is easy for the user to pick out the correct choice without having to think about whether "Yes" means one thing or another. Furthermore, when the choices are explicit, expert users can move through the dialog much easier.

              Maybe an example would help. Consider if the following horribly screwed up message was displayed by a dialog box:

              Would you prefer to not expurgate another drive instead of drive C?
              First imagine this message with buttons labelled "Yes" and "No", and then imagine it with buttons labelled, "Erase C" and "Don't Erase C".

              Do you see how it's explicitly obvious what is about to happen with the second set of buttons no matter how screwed up the message in the dialog box is? The user does not have to figure out what action the button is going to perform in relation to the message, because it's obvious.

              Do you see that no matter how complicated the choices are, it's always easier for the user if the actions are explicitly labelled?

              • Maybe an example would help. Consider if the following horribly screwed up message was displayed by a dialog box:

                Would you prefer to not expurgate another drive instead of drive C?

                First imagine this message with buttons labelled "Yes" and "No", and then imagine it with buttons labelled, "Erase C" and "Don't Erase C".

                Do you see how it's explicitly obvious what is about to happen with the second set of buttons no matter how screwed up the message in the dialog box is? The user does not ha

                • Your example is a bit disingenuous -- we could just as easily magine a dialog box with two buttons labelled "expurgate another drive instead of C" and "do not expurgate another drive instead of C", versus a dialog with a message of "Erase C ?" with "Yes" and "No" buttons. Which is easier to use?

                  No, you're not getting it. You've zeroed in on the fact that a developer could obfuscate a UI, but this is not what I was trying to illustrate. Thus you've simply succeeded in illustrating two examples of bad UI

              • The user shouldn't have to figure out what the developer means by "Yes" or "No" in relation to the message in the box.

                Call me an elitist, but I've no use for users who don't know what "yes" and "no" mean. Seriously. If my dialog text has bad grammar, then tell me and I'll fix it. If it's ambiguous, then tell me and I'll fix it. But slavish adherence to out-of-ass usability rules just so slashdot posters are happy is something I won't do.

                I have written dialogs that used verbs instead of answers, when it m
                • Call me an elitist, but I've no use for users who don't know what "yes" and "no" mean.

                  It's not that they don't know what "Yes" and "No" mean, it's that it's clearer and easier if they don't have to connect the "Yes" and "No" with choices given by the message in the dialog.

                  But slavish adherence to out-of-ass usability rules just so slashdot posters are happy is something I won't do.

                  As a UI designer, your job is to make it easier for all levels of users to use the application.

                  But I am not going to

                  • It's not that they don't know what "Yes" and "No" mean, it's that it's clearer and easier if they don't have to connect the "Yes" and "No" with choices given by the message in the dialog.

                    In real life conversations, outside of software, we ask yes/no questions ALL THE TIME. It doesn't confuse the people we are talking to. It doesn't make it easier for them if we hand them a cue card with possible answers on it.

                    Question: "Are you coming to the party?"
                    Answer: "Yes."

                    See how simple that is? I fail to underst
                    • In real life conversations, outside of software, we ask yes/no questions ALL THE TIME.

                      We also ask questions that provide explicit choices all the time too.

                      "Do you want pancakes or waffles for breakfast?"

                      Furthermore, real world metaphors rarely, if at all, ever apply to user interfaces.

                      It doesn't make it easier for them if we hand them a cue card with possible answers on it.

                      That's a bad metaphor. On the dialog, you're already handing the user a cure card with "Yes" and "No". Why not save the

          • Re:Linux usability definitely needs a lot of work (Score:4, Insightful)

            by John Newman ( 444192 ) on Tuesday June 21, 2005 @01:54AM (#12869848)
            A properly designed dialog box does not force the user to think about what the choices will actually do.
            I think you were thinking the right way, but you just gave a perfect example of the ambiguity of language that can torpedo the Yes/No/Cancel paradigm.

            It's not that the user shouldn't think about what the choices will do. Of course he should. That's the whole point of the box, to present options. (One of the repliers obviously misinterpeted your post in this way.) But the user shouldn't have to ever think about what the choices are, or have to stop to figure out how to properly interpret the text in the box. It's not about reading comprehension. It's about presenting a choice as clearly as possible. Verb-labeled buttons make the choices as stark as possible, so the user can spend his time weighing which choice is better, instead of working out what the heck the choices actually are.
        • Him: You basically have to read the entire alert to even know what's being asked...

          You: Pardon me for being dense, but what the fsck is wrong with that? Let me guess, the next Apple interface won't even have text, and dialog messages will consist of pantomime quicktime movies...

          The problem is that very few people read dialog boxes. This is a human attribute that is not going to change easily, so people who design things that people use should take it into account. Design of worker environments on
      • I don't see why no one else is adopting the new Apple-style verb-based dialog buttons.

        They are. Take a look at http://rox.sourceforge.net/phpwiki/index.php/Styl e Guide/Dialogs [sourceforge.net] for instance. (That's from the ROX Desktop style guide, because I use a ROX Desktop, but it shows that at least two non-Apple desktop environments recommend the use of verb-based dialog buttons.)

      • Not nearly as confusing as why everyone insists on perpetuating the Yes/No/Cancel paradigm. I don't see why no one else is adopting the new Apple-style verb-based dialog buttons.

        You're right on the money about just what a good idea it is. Ideally, you should be able to get the jist without even reading the main text. It's more efficient, as well as being less prone to error. But it's not exactly "new". It was one of the founding principles of the Macintosh interface in 1984, and it was one of those little

      • "Not nearly as confusing as why everyone insists on perpetuating the Yes/No/Cancel paradigm."

        In KDE having Yes/No/Cancel is considered a bug. If you find any please file a bug against the app.
    • The *default* button should always be the one that continues to the next step.

      Going back is a non-default action. ESC fills that role fine; although unimplemented.

  • That would be "kooperating", thankyouverymuch
  • provides a neat look

    Did we run out of adjectives?

  • And not only for PDF files. Just put a transparent layer on top of every page and let the user write his comments on it, make some sketches etc. and save it along with the commented file to some other person, eg. the author...
  • before worrying about usablity they should worry about functionality, I don't care how usuable a pdf viewer is if it renders incorectly to the point of being useless.
    • Care to be specific? KPDF renders all PDFs I've ever tried fine. If you have some that don't, then perhaps you should post bug reports and let the developers know what isn't working. That way the bugs can get fixed, and you won't have to sit around bitching on Slashdot (which helps exactly no one) anymore.
      • Well, it sure doesn't render all PDFs that I've tried. I keep a copy of Acroread around just in case. I keep Kpdf, Kghostview, and Xghostview installed and for any given PDF one of them or all three may fail to render it properly. They can also be extremely slow at times. While I'd say that MOST of the time the open source version are faster than Acroread I've seen exceptions (as recently as two days ago) that would take several minutes to display a fairly ordinary looking page in the open version and d
      • it missrendered all the math notation that latex produces. Which made it completly useless last quarter.
  • The first thing and most important thing missing from kpdf is the chapters view. what do i do with some small thumbnails if I want to see the chapters to jump there quickly. yeah and references in the pdf, they should be usable in kpdf, because if you have a 200 page manual and you want to jump from the index to the chapter and it works in all other viewers but not in kpdf, than something is wrong here.

  • Usability (Score:1, Interesting)

    by Anonymous Coward
    I have made several attempts to switch to Linux completely, but still find myself going back to windoze simply for usability. Take the process for downloading/installing new software - it's just a complete pain! I have tried a few different distributions hoping to find one that provides an intuitive way to do that. I'm not particular fan of .exe, but it does provide a simply way for the end-user to accomplish the task.

    If the Linux community really wants to get mere mortals to switch, make it so we can actu

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close