[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf
 main
 parent


EBN
by LB on Saturday 19/May/2007, @09:15
No trolling intended, but I wonder if (theoretically) these HIG-checks can be automated and for example be integrated in EBN? Somehow it doesn't feel right to do this manually. Thanks!
  Related Links
 ·   Articles on Usability
 ·   Also by LB
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: EBN
by Anon on Saturday 19/May/2007, @09:23
I think you're overestimating the mighty powers of the EBN :)

It's probably pretty hard to detect HIG violations (which are, of course, contraventions of *human*, aesthetic sensibilities of the running user interface) from static analysis of the program code. Maybe I'm wrong, though.
[ Reply To This | View ]
Re: EBN
by Robert Knight on Saturday 19/May/2007, @10:57
> No trolling intended, but I wonder if (theoretically) these HIG-checks
> can be automated and for example be integrated in EBN?

Some can be automated, and the EBN already has a few basic user interface tests which look for overpopulated menus and spelling errors.

The font and spelling checks probably can be mostly automated, but we don't have that technology yet - so doing it by hand makes sense. Even in areas which the EBN does cover, such as spelling errors, it cannot really prioritise them. That is, it doesn't know the difference between a spelling error that shows up in 15 point text in the main window from a spelling error which only shows up in an obscure dialog which is rarely used.

Finally of course, writing automated tests to answer more subjective questions is hard. Is this dialog intuitive to use? Is this warning message understandable? Does the application make me feel stupid? Does the application look pretty?

> Somehow it doesn't feel right to do this manually.

I disagree. This is about human interaction a computer, as such it isn't a technical problem, so trying to solve it completely using technology would be a mistake.
[ Reply To This | View ]
  • Re: EBN
    by Robert Knight on Saturday 19/May/2007, @10:58
    > The font and spelling checks probably can be mostly automated,
    > but we don't have that technology yet - so doing it by hand makes sense.

    Sorry, correction: We don't have the technology to do the font checks yet.
    [ Reply To This | View ]
  • Re: EBN
    by LB on Saturday 19/May/2007, @11:04
    >>Somehow it doesn't feel right to do this manually.

    >I disagree. This is about human interaction a computer, as such it isn't a >technical problem, so trying to solve it completely using technology would be >a mistake.

    Thanks, for your views, I understand you and agree with you.
    [ Reply To This | View ]
Re: EBN
by Anonymous Coward on Saturday 19/May/2007, @12:29
I'm pretty sure that the EBN could easily check for hard-coded colors and fonts pretty easily (it seems like a fairly simple task), but I wouldn't know where to begin writing such a beast.
[ Reply To This | View ]
  • Re: EBN
    by Paul Giannaros on Saturday 19/May/2007, @14:28
    But hard-coded colours are not always bad. It depends how they are being used, and scripts from EBN would have a hard time inferring that. Hard-coded font sizes/families are less easily justifiable ;-).
    [ Reply To This | View ]
    • Re: EBN
      by Luciano on Sunday 20/May/2007, @01:39
      Hardcoded colors are not bad if you do not care for accessibility. Otherwise they are a real problem.

      Themes like high-contrast do not work as required if you do not use system colors, for example, in the white-on-black mode, hard-coded black text will not be visible.

      Then there is the problem with color blindness, where color blind people may want to adjust colors so that, say warning/OK colors are easy to distinguish.
      [ Reply To This | View ]
      • Re: EBN
        by Chani on Sunday 20/May/2007, @06:51
        "in the white-on-black mode, hard-coded black text will not be visible."

        someone was complaining about exactly this in #kde today. he had a transparent kicker and a black background, iirc, and the text of programs was shown in black when they started up. :)
        [ Reply To This | View ]
  • Re: EBN
    by Ben on Saturday 19/May/2007, @14:38
    there are approx. thousands of different tasks which would need testing. when you have a clean environment people will not pollute the environment. The real point is to prevent that developers mess around. The earlier issues are caught the better.

    HIG means for me
    1. dont's use popups
    2. minimize clicks
    3. ensure everything can be done with key board (plug out your mouse)
    4. Think about contrast
    5. change the screen solution
    6. Remove all unnessasary text, menu entries

    In general look at all popup windows invocations in the source and rethink if they are needed. The mozilla search dialogue is a perfect example how to do it right. Same can be done for password field. As a educatory means just combine your personal popup dialogue with a really annoying sound, you really want to get rid off it.

    I am still a bit surprised about the placement of the "kill process" button.
    [ Reply To This | View ]
    • Kopete
      by Martin on Saturday 19/May/2007, @19:52
      Kopete in 3.x is a good example. Even if you turn off all configurable notifications, or set them to amodal, it *still* pops up dialogs where you have to click "OK" to close them. This happens whenever it experiences any of a number of problems in its communication to the various servers. After you click OK, you have to manually restore whatever connection went down.

      Here is how it should work:
      1) Remember the user's desired connection state for each protocol.
      2) If there is a problem, by all means indicate that by a warning triangle or so on the system tray icon.
      3) Then periodically try to restore the connection state that the user has requested.
      4) When successful, remove the warning triangle. By default don't pop up any message at this point either; frankly I don't care that much that jabber.org is back online.

      This constitutes a relationship of trust between me and the application. I tell it what to do and then trust that it is doing what it can to make it so. It need not come running back to me when it has a problem; I trust it do do whatever can be done to fix the problem.
      [ Reply To This | View ]
      • Re: Kopete
        by Ben on Sunday 20/May/2007, @06:35
        Kopete is a very good example. Indeed. kopete usually is run at startup and annoys me with a popup dialogue everytime I started KDE.
        [ Reply To This | View ]
      • Re: Kopete
        by Matt on Sunday 20/May/2007, @10:02
        I completely agree. This is especially annoying since jabber.org goes down so often. Same goes for AIM and MSN, but not as often. Automatic reconnect without complaining would be an enormous improvement for Kopete!
        [ Reply To This | View ]
      • Re: Kopete
        by Ben on Monday 21/May/2007, @06:14
        http://konversation.kde.org/screenshots/konversation10_1.png

        E.g. why to we have two windows here? Don't you think it looks ugly?
        [ Reply To This | View ]

 
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )
  "Karate is the ideal counterpart to programming and really great to get your head cleared." -- Michael Brade
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.
[ home | post article | flat forty | subscribe | search | rdf ]