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

List:       kde-usability
Subject:    Re: KDE improvement suggestions
From:       ra1n <pk20it () yahoo ! it>
Date:       2005-02-24 10:28:08
Message-ID: 421DBA22.7040307 () yahoo ! it
[Download RAW message or body]

Uno Engborg wrote:
> ziga wrote:
> 
>> Greetings!
>>
>> I am a long time KDE user and would like to thank everyone for
>> all the great work you are doing on the project.
>>
>> Many parts of KDE are currently used for our Slix project.
>> Slix is a LiveCD, aimed at nontechnical users. It involves a lot
>> of  testing with actual users, etc...
>>
>> Based on received feedback, we have compiled a list of small
>> improvement suggestions, which could help users a lot.
>> Some of the things are probably being done elsewere by other
>> people already. Some we will try to implement ourselves,
>> time permitting.
>>
>> The list is at
>>
>> https://wiki.ljudmila.org/index.php/KDE_improvement_suggestions
>>
>> Suggestions are most welcome.
>>
>> Žiga Kranjec,
>> Ljubljana Digital Media Lab - Ljudmila
>>
>> _______________________________________________
>> kde-usability mailing list
>> kde-usability@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-usability
>>
> 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).
> E.g. a normal user should not need to visit /etc, if he needs to fix 
> some setting he should be able to do that from some kind of control 
> panel. So /etc could just as well be hidden by default.
> 
> Nor will he need to visit /usr/bin /bin, /sbin or any other directory 
> with executable files. If he needs to run an app it should be available 
> from a program starter or from the K-menu. or he should find them in 
> applications:/  If we can find a reason why he can't do that, this is 
> the problem, not that he can't see /bin, ...
> 
> By not showing these directories by default the user doesn't need to 
> look for suitable GUI apps among the likes of grep, vi, man and other 
> things that run best from the command line, which he of course still 
> should be allowed to do.
> 
> He is not likely to need to double click something in /lib, /usr/lib, 
> either. So make it hidden by default.
> Similar lines of reasoning could probably be applied to some more 
> directories as well, but you should get the idea by now.
> 
> It should be possible for the sysadmin to control what directories that 
> was hidden for each user and group.
> 
> The directories hidden this way, should not appear in normal file 
> dialogs either.  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. The basic idea should be that the user 
> always should have access to the information he needs, but not more.
If I remember correctly MacOS X behaves like this, with the terminal you 
can see the whole filesystem, but finder only allow you to see the MacOs 
dirs (Apllication, Library etc etc)
> 
> 2)
> One thing that always get mentioned when Linux distros with KDE is 
> reviewed in the press is that it is hard to install applications.
> In kde we already have kpackage why not use some of that to make it 
> possible to drag & drop a package (rpm, apt or whatever the distro use)
> into the applications:/ folder to install an app.  Dependencys should be 
> resolved by downloading from a specified site on the Internet.
And if I want to install a library? This requires a lot of work, it's 
not so easy to manage packages, and keep in mind that kde work on other 
Unices too
> 
> 
> 3)
> This is more something for the HIG, than for any code changes. There 
> really should be some guidelines on how to select default backgrounds.
> All pattern details in a background image should be much larger than the 
> biggest application/folder icon in KDE.  That way it would be much
> less chance for icons to hide on the desktop. E.g. try to put a html 
> file from the standard KDE icon theme in between the gears of the standard
> KDE desktop image and you will see that it hides almost completely. Not 
> that the desktop is a good place to put files, but as long as we allow it
> we should make sure people can find their files easily.
agree on 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, and I really 
> don't think KDE needs any extra branding. The K-logo at the menu base 
> will be more than enough to tell people that they are running KDE.
agree with this too :-D
> 
> 5)
> Speaking of the K-menu,  Today it is divided into  a section for 
> actions, one section for runnable programs, and one section for 
> frequently used programs.
> To reach the frequently used programs section you have to move the mouse 
> so long that you just as well could have used the ordinary menu item.
> 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
> way we would need less mouse movement to start our programs.  But who 
> knows perhaps there won't be any K-menu as there have been some 
> discussions on having an application menu on top of the screen, and 
> perhaps the K-menu should be integrated in that somehow
This is something that I'm trying to do, an applet like gnome one, on 
kde-look.org there is already something, but it's far from being usable, 
nut I thing that something like this:

Applications  Actions

could be a good behaviour
> 
> 6)
> How about an improved in line editing of filenames. If you turn on in 
> line editing today it is very easy to change filenames by mistake.
> What if you only could change the filename if the file/folder icon 
> already was selected when you click on the filename. If the filename is
> clicked or selected the whole icon should be selected, but no editing 
> should be possible. This is how it works on windows and MacOS
> and so far I have not changed a filename by mistake in any of these 
> environments and it is still faster than selecting rename in the context
> menu for those who can't remember how to press F2.
> 
> 7)
> Pop up the right button context menu on mouse up instead of on mouse 
> down. That way it would be possible to use the right mouse button
> to move, copy, and link files by drag&drop much the way it is done with 
> the left button today (with pop up menu on drop target and all).
> The left menu button could be used for move only. For users with only 
> one mouse button control keys could be used. This is how it works
> in windows today.
> The advantage of this is that, move, and especially link is much less 
> frequently used than move. This means that in the current situation the
> users work flow is often unnecessarily interrupted.  This is especially 
> a problem for new users that doesn't know about modifier keys. E.g.
> 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.
> This still not solves the problem that there is no way to know how to 
> create a link in the current version. The user have actually do
> drag the file and drop it to find out how to do. This is different from 
> move and copy that could be carried out by cut&paste from
> the edit menu. So perhaps we could add a "paste as link" next to the 
> ordinary paste item in the edit menu.
I haven't completely understood this :-?
> 
> 8)
> Speaking of drag&drop. The current way of showing when a file is over 
> the drop target is a bit hard to see,  Perhaps we could stea... ehum
> borrow the gnome way of doing this.  In gnome the drop target is 
> darkened, and it is very easy to see.
Yes this is interesting, a little icon change (for example the target 
folder opens) could be nice too :-P
> 
> 9)
> Change the default order of  tool bar icons in konquerer, so that they 
> have the order left arrow, right-arrow,  followed by up arrow.
> Most browsers start with something similar to that order, so it would be 
> easier for users to switch between konquerer and other browsers.
> An other effect of this is that the up arrow will get closer to the 
> contents of a directory when used as a file browser.
Agree, another nice thing could be smart icon text, like explorer and 
the old nautilus, where icon text only appeared alongside important 
icons, like the back button, making it also a bigger target for the 
mouse pointer, speaking of toolbar icons text, it needs some attention 
too, it should be short, for example the home button has the label "home 
URL" why not only home? also in italian it gets translated into "URL 
della Home" try to put this text under a 32x32 icon, or the zoom icons 
button, that become "Aumenta la dimensione delle icone" and "Diminuisci 
la dimensione delle icone" damn!
Also toolbars must be dinamic, while browsing the up button it's not 
needed (or rarely needed)
> 
> 10)
> The action of adding buttons to kicker panels and to application tool 
> bars is a very similar process to the user. So the user interface for 
> doing it should
> be similar in both cases. Perhaps it could be done by drag and drop from 
> a panel containing all available alternatives a la Firefox.  That panel 
> could
> even have some kind of search or filter function to make it possible to 
> limit the alternatives.
Like gnome 2.8? :-P
Well, I don't agree completely, the drop down menu IMHO it's faster than 
  this, what the kicker lacks it's the ability to move applets between 
panels, so if you want to reorganize your panels, you need to remove/add 
  all applets everytime

11) An hide entry in the kicker menu, to automatically hide a panel, 
without opening panel configuration dialog

Cheers
Luca

_______________________________________________
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]