# Why we use single-click
There are a lot of good reasons for defaulting to single-click:
- New user friendliness: double-click must be learned
- Accessibility for children, the elderly, people with shaky hands, laptop users, and those with poor mouse skills
- Consistency with mobile and the web, where there is no double-click
- Predictability: no question regarding what needs to be single-clicked and what needs to be double-clicked (we've all known people who double-click everything)
# Problems with single-click
Nevertheless, single-click has one big Achilles Heel: selecting items. Right now, there are three flawed methods:
**Click the selection marker in the corner that appears on mouse hover**
- Requires precision mousing skills
- Easy to destroy your selection with a mis-click
- Unusable on touch since there is no concept of hover, and the click target is too small anyway
- Inconsistent UI; Dolphin and Folder View display a green emblem in the corner, while Gwenview displays a square button along with other contextual hover buttons
- Selection marker doesn't even appear in `KDirOperator` views used by open/save dialogs and many app sidebars (https://bugs.kde.org/show_bug.cgi?id=185793)
**Ctrl+click on individual items**
- Not discoverable; even some experts and longtime users don't know about it, as revealed in VDG chat this morning
- No good for touch; ctrl key is unavailable for tablets and phones, and awkwardly far away for convertible laptops
**Click-and-drag to make a rubber-band selection**
- Can only be easily used to select a line or box of items; must combine with ctrl+click in a multi-step operation to select arbitrary items
- Impossible on touch, where empty areas of a scrollable view will scroll the view if you touch-and-drag
Difficulty selecting items extends to difficulty doing things to items that do not involve opening them (i.e. renaming, deleting, copying and pasting, etc). With double-click, a common workflow is: {nav click item to select it > choose action with main menu or a keyboard shortcut}. But with single-click, selecting items is difficult, so using a keyboard shortcut or main menu to act on a selected item is more rare. Instead, the typical UX is to right-click on the item and choose an action from the context menu. But this is problematic because there is no right-click on touch, and anyway, a lot of people don't right-click very much using their desktops and laptops. With laptops in particular, right-clicking is often awkward, difficult, and non-discoverable.
# Proposed solution
I'd like to propose a new UI that will address the selection problem: a dedicated "selection mode" wherein single-clicking on items will select them. This is a very common and user-friendly pattern on mobile. Here is an example taken from a GNOME Photos mockup I saw a while back:
{F5754301}
And here's how it worked with a very old version of iOS:
{F6337130}
Adopting such a thing would be really nice for us too, as it would not only improve the selection situation for single-click, but also allow seamless touch support. The whole item plus its background in the grid becomes a click target, so it's very very fast to select a bunch of icons this way--much faster than using the selection marker, and even a bit faster than ctrl+clicking on icons. We could also allow click-and-drag to do rubber-band selection for bulk selection.
This mode would be activated by clicking on a visible button marked {nav Select items} or by using a keyboard accelerator--perhaps the {key ctrl} key, or even the spacebar.
Next, we can add a contextual action bar full of items that can act on the selected items--or even when there's no selection. Basically the idea is to replicate the features available via the right-click context menu, but without the need to right-click. Here are some rough mockups for how it might look in Dolphin (thanks @broulik!):
{F6337145}
{F6337146}
All of this probably relies on first unifying the icon/folder views: {T9226}