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

List:       kde-usability
Subject:    Re: Knotify configuration improvements
From:       Celeste Lyn Paul <celeste () kde ! org>
Date:       2008-06-21 13:38:12
Message-ID: 200806210938.13455.celeste () kde ! org
[Download RAW message or body]


One thing that stands out the most: please do not next tabs within other 
elements, such a group boxes and lists.  It is very confusing and you are 
losing a lot of space to borders and padding.  In KDE3 we tend to make 
exceptions for this in certain places which works out OK some of the time 
because of how it is designed.  But as a general rule, it is too easy to 
abuse or misuse it.

From the looks of it, you just have a single config option for each tab.  
Since you are already using an expandable widget, you could/should probably 
just list all of the options there.  There is no need to futher obscure the 
options from the user in another layer.  You won't be using much more 
vertical space because you will be saving a lot from not using extra tabs, 
borders, and padding.

As a side not, it seems like rich information list views are the new thing in 
KDE4.  Fredrick might have to update his listview page 
http://ktown.kde.org/~fredrik/listviews/.  In the mean time, I think rich 
information lists could replace some of the contextual on-demand option 
display we relied on in KDE3.  We are looking at lists this week for the HIG 
SoU project and I will ask them to consider lists as a way of managing 
options as well.  Rich information lists could be a good thing -- as long as 
everyone does them in the same ways.  From a dev perspective, it would also 
be good to have a single class to do RILs instead of the diverse mass of 
classes that exist now.  It will be easier to maintain consistency and know 
you are doing it the right way.  Plus, we wont have 10 people extending the 
list in 10 different ways to do the same thing.



On Friday 20 June 2008 15:42:27 Gunjan Patidar wrote:
> Hi All,
>
> I find the kde's notification system's (KNotify) configuration UI quite low
> on usability. The configuration is available at system
> settings->Notifications and within various application's configure
> notification menu item.
> the problems with this interface are:
> - Its difficult to find a particular event for which one wants to set up a
> notification
> - there are lots of icons, text and inputs visible
> - multiple configurations might be required sometimes[explained below]
>
> I'm starting out on developing for kde and would like to redesign the
> knotify's configuration UI. I have prepared a rough mockup for the
> interface i want to build.
>
> In the new UI, the 'Event source' combo box would be replaced by Groups.
> New Groups(or subgroups?) can also be defined by users.
> The various input fields at the bottom would be hidden and replaced by a
> collapsible tabbed widget which is shown when the user selects an event.
> this interface addresses the following issues,
>
> - A user may want to set notifications for individual events. It is also
> likely that he wants similar notifications for a group of events. for eg a
> user may want to see a passive popup every time he switches his desktop. If
> he has n virtual desktops, he need not set n notifications which are
> ideally similar. It is more logical that he is able to create a
> group(subgroup within a group?) of events and set notifications for the
> group.
> - Grouping also makes it simple for a user to find his event of choice
> without browsing through a long list of events. Also UI becomes uncluttered
> as other groups(without focus) can be collapsed. This reduces number of
> icons and text directly visible for which user is not concerned.
> - User need not see all the options all the time. Only when he selects a
> particular event, for which he wants to set a notification, should he be
> confronted with various options.
> - in system settings->notification, application and player settings tab
> seem pretty unrelated. they can use some rearrangement
>
> Do you think it would be any better. Also can you suggest any other
> improvement??
>
>
> Regards



-- 
Celeste Lyn Paul
celeste@kde.org
KDE Usability Project
usability.kde.org
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]