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

List:       kde-usability
Subject:    Re: KDE improvement suggestions
From:       Uno Engborg <uno () webworks ! se>
Date:       2005-02-24 19:32:18
Message-ID: 421E2BC2.7010206 () webworks ! se
[Download RAW message or body]

Aaron J. Seigo wrote:

>On Wednesday 23 February 2005 05:52, Uno Engborg wrote:
>  
>
>>Here is ten other ideas, hope you won't find them too controversial.
>>1)
>>Perhaps konquerer should not show files that is of no use to ordinary
>>users (unless logged in as root).
>>    
>>
>
>there's no need for this imo... we start people out in their home folder and 
>the sidebar is rooted there as well ... that's generally good enough, and 
>doesn't get in the way of people who do need / want to get aroud.
>  
>
As you say, in most cases the user will stay in his home directory. 
However there are
cases where this is not enought. Imagine you have some shared resource 
that is
supposed to be accessed company wide. It would be nice if typical office 
users with
no or little unix knowledge could navigate too them without being disturbed
by folders that he doesn't need or even know what they are for and in 
most case are
not allowed to do much with.

You may argue that a good sysadmin could place links to that shared 
resource in each and every employees
home directory, and the user could reach this resorces from his home 
directory and the problem would allready
be solved,  as you suggest. However this has the disadvantage that the 
user may not be able to separate
his own resorces from company wide ones.  He may also find the sysadmin 
additon of links to
his home directory an invasion of privacy.

It further have the disadvantage that if the user shares his directory 
to windowos to samba the
link wouldn't work, not to mention that it probably would be harder
to remember the location if the file structure varied more than 
necessary from one platform
to the other. And lastly the sysadmin would have to check that no user 
have a  file or directory
with the same name as the link he intends to put in all user dirs.

So, as you see, there are reasons for an ordinary office user to 
sometimes leave his home. And when he
does we should help him so he doesn't get lost and that he can work in 
an efficient manner.

I think that, weather you think this is a good idea or not, depends on 
how you view KDE. i.e. if you see
KDE as a userinterface to unix, or as a way to enable users to perform 
their tasks.

It also depends on what audience we want KDE to have. If KDE should be 
for the home hacker that
want a tool to make it easier to see how unix looks like ,  this is an 
extremely bad idea.
On the other hand if we want KDE to be something you see in an office 
environment where 90% of the people
couldn't care less about unix, and is more interested in the figures in 
the last months sales report, this makes
perfect sense. Just ask your, or your  bosses secretary, what she thinks 
about your new /etc/ldap.conf or in
what order it should be used in /etc/nswitch.conf or if you should base 
saslauthd.conf on ldap.
Chances are your conversation will be very short.

The good thing though, is that the interested home unix explorer 
probably would have the knowledge or interest
to lern how to turn it off, while the office people who needs it, 
wouldn't know how to turn it on, and just say - buy us a simpler system.

Before you dissmiss this, you should really think, in what situations a 
user with no root password really
needs a graphical presentation of the files in directories like /etc, 
/bin, /dev, /lib, /sbin, /usr/bin, /usr/lib,...
If you really can dream up such a case, I would say that we have failed 
utterly in providing a good GUI
for non root users.

>  
>
>>It should be possible for the sysadmin to control what directories that
>>was hidden for each user and group.
>>    
>>
>
>this, however, makes sense =)
>  
>

>>The directories hidden this way, should not appear in normal file
>>dialogs either.
>>    
>>
>
>seeing as everything uses KIO, this isn't a problem.
>
>  
>
>>There would need to be some exceptions. E.g. if you 
>>create a program starter for applications:/ or the K-menu you would need
>>to access all executable files.
>>    
>>
>
>we use .desktop files for this, so this also isn't an issue.
>
>  
>
>>The basic idea should be that the user 
>>always should have access to the information he needs, but not more.
>>    
>>
>
>the problem is defining what "needs" means. as part of the Kiosk 
>infrastructure i think it makes sense. other than that, i'm not so sure.
>
>  
>
As you say, much of this can be implemented by Kiosk and other allready 
existing
infrastructures of KDE.  The differene is that it must be on by default. 
The people
who needs this will not be able to turn it on by themselves.

We  need to make sure that it is easy to turn off for the people who 
don't need or want it.
In any case the local sysadmin will have much better knowledge of what 
people need or not
than we ever can have. So we must provide him with good tools to control 
this.

>
>  
>
>>4)
>>Unless somebody somebody can explain how the side image of the K-menu
>>makes KDE more usable, could we turn that off by default? As far as I
>>can see the only function it has is to distract the user
>>    
>>
>
>how many users are distracted by it, exactly? peole aren't THAT helpless. yes, 
>aside from the fact that it makes it obvious which version of KDE you are 
>using, it's pure eye candy. but generally unobtrusive eyecandy that tells you 
>"this menu is special"
>  
>
I'm probably too sensitive, it allways makes me feel like KDE is trying 
to be some kind
of windows wannebe.  Not thats anything wrong with windows if we find 
something in
it that we could borrow or improve on to make our usability better, but 
just copy for
the sake of copying feels a bit cheep.

>  
>
>>Perhaps would it a good idea to split the programs and the actions
>>section into two menus a la Gnome or one broad menu a la windows XP. That
>>    
>>
>
>this really requires a good amount of studies done with actual users. it's an 
>extremely non-trivial change to make to not do so.
>  
>
True, this is a difficult task. In my oppinion the Gnome guys have 
failed in sorting what things that should go in
what menu but there is nothing that says we couldn't do it better 
especially since they now provide a
working example to improve on.

Our menu is allready split up in sections, so we are still stuck with 
the problem of what should
go into what section. So we could just as well make the most of it.

Generally I would say actions should be things that you can do 
independently of  what program
you are running. Things like taking a screen shot, doing system 
configuration tasks etc. but as you
say this need real user testing.

If you read KDE-mailing lists including this one you get the impression 
that the user spends 99% of their
time configuring their systems and 1%  working. In reallity, it is 
hopefully the other
way round, or at least it should be.  Separating the start of programs 
would make it
possible  to make configuration tasks, that users do quite infrequently 
and prevent them from getting in
the way of program starts, that people do quite frequently.

>
>
>  
>
>>The advantage of this is that, move, and especially link is much less
>>frequently used than move. 
>>    
>>
>
>the disadvantages includes that it overloads the right mouse button 
>functionaly, introduces  an inconsistency in how menus work, and makes using 
>context menus slower.
>  
>
I think you exaggerate the speed problem. This is used in windows, and 
so far I have
never heard a windows user complain about popup speed, neither have I 
myserl felt that windows is
particularly slow in putting up the rmb context menu.

>>A newbie sorting files will not know how to extend a selection and will
>>have to move his file file by file, each time having to answer the
>>question if he want to move, copy, link or cancel. Some newbies may not
>>even know what a link is, and would only be intimidated by
>>the link option.
>>    
>>
>
>yes, "link" requires training as a new part of the user's vocabulary; i'm not 
>sure how accurate the rest of the above paragraph is, however.
>  
>
I'm not sure what you believe is not accurate. Are you suggesting that 
we should not care
for newbies that don't know about modifier keys and easily can extend a 
selection? Or do
you suggest such users doesn't exist?
Or don't you think they will get annoyd by the menu, that they in more 
than 90% of the
cases will select "move here", less than 1% will select "link here", and 
hopefully even less
"cancel"?  Try to sort 50 images or so into a coulple of folders without 
using modifier keys.
(Not a too uncommon task in todays world of digital cameras).

>  
>
>>the edit menu. So perhaps we could add a "paste as link" next to the
>>ordinary paste item in the edit menu.
>>    
>>
>i don't think it's used often enough to warrant such an entry.
>  
>
You are right in that link is an extremely rare operation to perform. If 
you look at an average hard drive
you would probably find much less than 1% links, where most of them was 
created by some script
and not by a user using a GUI.  Just the same, there should be a way for 
the user to find out how to do it.
The popup on over a drop target  is not  visible until you actually try 
to drop a file somewhere,

I'm not dead certain that it should reside in the context menu, but it 
really should be available somewhere
else besides the drop target menu. Another alternative would of course 
be the edit menu. On second thought
this is even better, as the context menu should be reserved for 
frequently used things. I suspect that the reason
most new users look for it in the context menu is that they are used to 
windows, and they would probably
find it in the edit menu as well.

Regards
Uno Engborg
_______________________________________________
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]