Go to file
Nate Graham b14f98de19 Make it more obvious that you can connect to servers on remote:/ page
Right now it is not super obvious how you connect to a remote server
in Dolphin when you already know the URL. Users will go to the
"Network" item in the Places panel, but from there it is not totally
clear. The "Add Network Folder" icon in the view opens a complicated
wizard and it's also a bit of an odd UX to have it living in the view as
opposed to being a toolbar button.

Old hands and developers know that the URL navigator is, well, a URL
navigator, and as such, it accepts arbitrary URLs from any view.
However this may not be obvious to other more casual users, for
two reasons:
1. The URL navigator is in breadcrumbs view nearly all of the time and
   by default, so may users may not know that it can accept text at all
2. Even when it's displaying URLs, they are almost always local paths,
   so users may not make the connection that it can accept remote URLs
   rather that just local paths

To improve the discoverability of this feature, this commit makes the
following change:

When the view is displaying the remote:/ ioslave (i.e. the "Networks"
place), the URL navigator is put into URL entry mode and given some
placeholder text that hints at what it can do. It reverts to breadcrumbs
mode when you leave.

BUG: 414670
FIXED-IN: 21.04
2020-12-27 17:38:55 +00:00
cmake Output of licensedigger + manual cleanup afterwards. 2020-08-25 17:07:38 +00:00
doc Add docs on the 'Date style' option 2020-12-24 10:05:46 +02:00
LICENSES Output of licensedigger + manual cleanup afterwards. 2020-08-25 17:07:38 +00:00
src Make it more obvious that you can connect to servers on remote:/ page 2020-12-27 17:38:55 +00:00
.arcconfig Revert "GIT_SILENT: we don't use phabricator now" 2020-05-23 23:35:22 +02:00
.gitignore GIT_SILENT: ignore .cmake generated by qtc 2020-03-28 15:32:08 +01:00
.gitlab-ci.yml Fix typo in gitlab-ci filename 2020-11-24 00:06:02 +01:00
AUTHORS updated to KDE 4 (the file was valid for Dolphin for KDE 3) 2008-07-07 09:18:51 +00:00
CMakeLists.txt GIT_SILENT Upgrade release service version to 20.12.0. 2020-12-02 22:48:44 +01:00
COPYING commited initial version of Dolphin 2006-11-21 06:02:05 +00:00
COPYING.DOC updates for new licence policy 2008-01-12 16:39:07 +00:00
dolphin.categories Autogenerate debug file + install debug categories file 2018-11-02 13:23:10 +01:00
DolphinVcsConfig.cmake.in Use CMakePackageConfigHelpers instead of the ECM variant 2017-12-01 19:27:57 +01:00
logo.png Add Dolphin icon as repository logo 2020-05-19 10:14:04 +03:00
plasma-dolphin.service.in D-Bus activation systemd service 2020-11-19 10:40:56 +01:00
README.md Update README.md to gitlab :D 2020-10-06 16:02:54 +00:00

User Documentation

See https://userbase.kde.org/Special:myLanguage/Dolphin

Development Information

Dolphin's source code can be found at https://invent.kde.org/system/dolphin/

To build Dolphin from source, see https://community.kde.org/Get_Involved/development#Applications

To submit a patch to Dolphin, use https://invent.kde.org/system/dolphin/-/merge_requests/.

Development Philosophy

Dolphin is a file manager focusing on usability. When reading the term Usability people often assume that the focus is on newbies and only basic features are offered. This is not the case; Dolphin is quite full-featured, but the features are carefully chosen so as to not impede any of the users in the target user groups.

Target User Groups

Focusing on usability means that features are discoverable and efficient to use. The feature set is defined indirectly by the target user group of Dolphin:

  • Lisa: Lisa has been familiar with computers for 10 years. From her job, she has experience with Word, Excel and Outlook. At home she mainly uses the computer for browsing the web and writing e-mails. She requires a file manager for managing photos from the camera, documents she gets via e-mail, or PDFs she downloads with a browser. Lisa knows concepts like folders and a file hierarchy, but she is not familiar with the file hierarchy of Linux.

  • Simon: Simon has been a developer at a software company for 8 years. At home he uses a file manager to maintain his large collection of photos and music. Additionally he owns a small homepage and needs to transfer updated files on the FTP server. Moving and copying files are regular tasks in Simon's workflow.

Not part of the target user group of Dolphin are Fred and Jeff:

  • Fred: Fred is 75 years old and is able to write e-mails and browsing the web. He is not familiar with file hierarchies and stores all his documents on the desktop.

  • Jeff: Jeff is Linux-freak since the age of 16 a few years ago. He is a developer and in his spare time he acts as administrator for a small company. Jeff has two monitors to keep the overview about his huge number of opened applications.

This does not mean that Fred or Jeff cannot work with Dolphin. But there might be features and concepts of Dolphin that overburden Fred. Also Jeff might miss some features which are a must-have for his daily work. This is acceptable; there are other tools that cater specifically to their needs.

Non-Intrusive Features

Before a feature is added in Dolphin, check whether the feature is mandatory for the target user group. If this is not the case, then this does not mean that the feature cannot be added; first it must be clarified whether the feature might be non-intrusive, so that it adds value for users outside the primary target user group of Dolphin. The term "non-intrusive" is mainly related to the user interface. A feature that adds a lot of clutter to the main menu, context menus or toolbar might harm the target user group. In this case the feature should not be added.

A good example of a feature that is non-intrusive is the embedded terminal in Dolphin. It only requires one entry inside a sub-menu, but adds great value for Jeff, who is not part of the target user group.

Options

Options are mandatory as the "average Joe" user does not exist. Still it is not the goal of Dolphin to offer options for all kind of things. Again the focus is on the possible needs of the target user group. Each additional option makes it harder finding other options, so the same rules for features are applied to options too.