[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Bug#32978: usability
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2001-09-26 18:03:56
[Download RAW message or body]

On Wednesday September 26, 2001 07:41, Thomas Zander wrote:
> package: noatun
>
> Hi, as we talked about the usability of Noatun some time ago on the
> kde-core-devel list, I promised to make suggestions as to the usability
> issues we now have in Noatun. Here is one on the configuration dialog of
> Noatun.
>
> Config dialog;
> it uses a OK, Apply and a Close button. The OK and the Close are
> effectively the same and users will expect the button where the Close is
> to be a Cancel, so the current config confuses users.
> Please change the Close to be a Cancel button with full functionality
> that fits ;)

Sure.  I never noticed any of that.

> Also OK-ing (or Applying) the dialog should save the config to file
> immidiately so when I change the options to allow only one instance of
> Noatun I should not have to close Noatun to get these options to work.
> Which is the case with my KDE 2.2.1

I think you misrepresent the situation here.  It *does* save the settings, 
and the settings take effect for every other option.  It's just a bug that 
this one setting doesn't take effect.

What would propose happen if someone turns on single instance mode, and 
other instances are open, by the way?  A dose of SIGKILL to the other 
processes?

> Further it is not natural to have to apply the changes for the
> plugins-options to apprear in the list on the left.

This one I have a problem with.  Where else do settings changes only take 
effect *before* you press Apply or OK?

> I suggest using an OK action which actively adds a plugin. This
> ok-action will then add the config option to the list immidiately.
> A combo with an explenation and an OK button at the bottom not unlike
> the top part of the new (not yet available in KDE221) effects dialog
> comes to mind.

Except that the term OK is already used in KDE, for dismising 
informational dialogs, right?

Also, if you think for a minute, this OK button will have the same effect 
as a button that's already there - Apply.  Seems natural to me that 
someone who wants things to take effect immediately will hit the button 
that makes things take effect immediately for every other dialog in KDE - 
Apply.

> In the plugins page, tab Playlist the entries are selectable with a
> radio-button the radio button is however not activated when the name
> just right of the radio button is clicked.

This is a QCheckListItem bug, then, but I'll work around it.  I suggest a 
mail to the Qt bugs mail address, pointing this out, so that every app 
won't have this same problem.

> The same page; when changing playlist it is good to warn the user that
> the new playlist uses another list and that the user will loose the
> current list when changing. Something like 'Changing playlist plugin
> will loose your current playlist and playback will stop'

Interesting.  I guess it can pop that when you select a new playlist.  
This is a case where "Do not show this again" will be handy.

> In the Young Hickory (who made up that name!) screen please change the
> groupbox to have a name, something like 'state icon'
> Then the options can be shorter;
> - Blink
> - Show current
> - No icon

Sure.

> Hope that helps!

Many useful ideas here.

-- 
Neil Stevens
neil@qualityassistant.com
"I fear all we have done is to awaken a sleeping giant and fill
him with a terrible resolve." - Yamamoto Isoroku
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]