1. Option for managing groups is in an unexpected place

The option to edit (add, delete) groups is not where all the other settings in KGet are, but under “Downloads”. Most users wouldn’t expect this and would rather look for it right in context, where the groups themselves are visible. If not there they would probably look for it where other settings are made, like changing default folders.

Suggestion: We already have a faint idea for a new layout for groups. This would include a new and better place for this option (putting it in context with the groups themselves). But until we have worked out our idea in a more detailed way, you could do the following: Move the “Edit Groups” option to the Settings menu or even into the “Configure KGet” dialog.

Fixed: The Groups Editor can now be found in the second page of the settings dialog.

2. Error message when default group is about to be deleted

In “Edit Groups”, the default group can’t be deleted, although the delete button is active. If users try to delete this group, they are told it can’t be done.

Suggestion: To make the interface consistent, it would be best if all groups could be deleted. But if you really absolutely want to prevent users from being able to delete the default group: grey out the delete button if something is selected that can’t be deleted (the default group).

Fixed: The default group can’t be deleted anymore, the delete entries aren’t shown then.

3. Simplify download target dialog by not showing the folder tree by default

KGet always asks for a target folder location if no default folder is set up in the config dialog. This can become very repetitive and tiresome when downloading several, especially for users who don’t know that it’s possible to set a default. (And only those who have been to the config dialog before will know.)

Suggestion: An idea would be to still pop up a dialog like the one we have now. But instead of setting the folder, we could simply display where the file will be downloaded to (by default). The user then only has to confirm he wants it to go there. If he wishes to change this folder, he can do so in this dialog as well, but it is one step farther away, in a kind of foldout. An example for this: is this dialog - click on Options to toggle the foldout. Folded, the dialog could say “Download to _ _ _ _ _ _” (with text entry box prefilled with the default folder). Unfolded, it could additionally show the whole dialog that appears right now, but embedded. This widget will possibly be part of kdelibs, see this discussion on kde-core-devel. Also, rename the title of the dialog from “Select Folder” to “Select Download Folder” to make it clear what can be done here.

Fixed:The new download dialog offers a simple dropdown with the most recent download locations. A button next to it pops up the old tree view that lets users choose a different location.

4. Allow setting default folder when adding a download

When adding a download, in the target folder dialog (folder tree view), it would fit into the user’s workflow to be able to set a new default folder right away. Right now, users have to go to the preferences to set the default, instead of doing it when they are reminded of the default folder, in the selection process of a new download.

Suggestion: Keep the default folder selection in the preferences, but add an option in the “Select Folder” dialog to do it there, too. Maybe with a check box or button that users can check when they have selected a folder.

5. Setting for different download folders per file type hard to find because of gray text

The option to setting up “auto-foldering”(placing different file types in specific folders) is quite hidden from users. Even when looking at the correct preferences tab, it is hard to see and read because the relevant text is grayed out by default. The default option (#8220;always ask for every file”) in this radio-buttoned option combination is the culprit: it causes most explanatory text pertaining to the auto-foldering by extension to be completely gray and thus nearly unfindable. Only if users change the default they will notice they have the option at all. Only the most basic info about the option is not gray, but it doesn’t make quite clear how much is really possible - putting files in several different folders by extension. This very useful functionality should be more visible! There is another problem: as it looks now, only two alternatives are possible: 1. ask every time (= no default folder), 2. one generic catchall default folder and possibly several others for select file types. There is no easy way to have specific file types put into different folders but still be asked for all other files (not putting them into the catchall main default folder).

Suggestion: The following mockup shows our idea. The two main options - always ask or always put into a folder - are decoupled from the option to specify download folders by file extension for some file types. Users can now either be always asked, but still specify some file types where they won’t be asked because they go to specified folders. Or they can define one catchall default folder, and still at the same time specify some file types that go to different folders. The checkbox label (always black) now makes it clear that KGet can handle user-specified file types separately. At the same time, the extension setup is grayed out when the checkbox is unchecked to spare the user the complexity when he doesn’t need it.

6. Extension formatting unclear

When setting up different default folders by file extension, it is not clear to the user in what format the extension should be entered. Possibilities include: with a preceding dot (“.png”), with a “*.” (like “*.png”), or simply the bare extension (“png”). They shouldn’t have to guess and use trial and error.

Suggestion: Give an example somewhere nearby on how the user can format the extension or simply explain it in very few words. In addition accept all possible entry formats and reformat them automatically to the one used by KGet. This solves two things: Users who want to do it right and actively look for an extension format will find a hint. At the same time users, who don’t care about the extension format (or don’t see the hint), can use any format they are used to.

Fixed:A short note explaining the format has been added. Reformatting is not possible because it would interfere with the regex functionality.

7. Faciliate adding entries to the default download folders list

The workflow of adding rules feels a little counterintuitive - define a rule, then afterwards add it. It would be better and more natural if users could decide to add a rule and only then go on to defining it.

Suggestion: Allow users to click “add” first, then add an (empty) rule that they can edit inline in the list. Give focus to the Extensions attribute of the entry, so that after adding they can type in the extension right away. <TAB> then moves to the Download Folder attribute where users can type in the download folder. An “open folder” button should be added there, too. Inline editing would also solve the problem that when changing a rule, users have to go way down to the edit box, then apply their changes and then back up to see what they changed in the rules list. The editing takes place too far away from the displaying of the end result.

8. Inconsistent settings labels and dialog layout

Descriptions on the single settings pages are inconsistent, both within KGet and compared to other KDE applications. The layout doesn’t honour current design guidelines. Users should be offerd with a similar dialog layout to quickly find their way in the sttings hierarchy.

Suggestion: Follow http://wiki.kde.org/tiki-index.php?page=Checklist+1%3A+Configuration+Dialogs to ensure consistency.

Example:

1. On the Appearance page, rename “Look and Feel” to “Change appearance settings” (pending)
2. Group “Show main window at startup” and “Show splashscreen” under a “Startup” group
3. Group “Sow drop target” and connected “Enable animations” under a “Drop Target” group