GSoC 2016 Project Idea Usability Suggestions

[Arnav Dhamija]

Again, thanks for the prompt reply! With regards to file navigation 
through the disjointed children directories of the parent, the only 
solution I can think of is some improved breadcrumb directory tree at 
the toolbar of the view. I was thinking of adding files only via drag 
and drop, context menu, toolbar button, or Ctrl+C/V into the panel area 
rather than just clicking to add a file (as this would limit drilling 
into the directory). I don't think that accidentally clicking a 
file/folder directly into the stashing area should be a particularly big 
problem as this can be easily addressed by a clear button or by simpling 
closing the panel.

The events which would cause the panel to close is a good question. I am 
of the opinion that the user should manually close the panel as they 
need to. An auto closing panel might be confusing for some users. 
Perhaps the split view should be disabled while this panel is open? 
After all, this panel is /also/ serving the purpose of the split view. 
As for searching, my idea is to have an option in this panel's toolbar 
to add the results of a search into the panel, so the search area can 
co-exist /with/ the panel and add to its functionality : ) This can 
still operate in the default 50-50 split.

Finally, my current plan calls for only one such session of the panel at 
a time to reduce complexity. However, I am considering to have tabs for 
this staging area and if this does improve user productivity, I will 
certainly look into it.

As such, I have made a feature list for this project - a list of minimum 
deliverables in the GSoC timeline and some features which I might 
incorporate later on if I can't finish it by the end of the GSoC period. 
I am happy to discuss this at any time on IRC (nick: stheory on #kde, 
#kde-devel).

On Sunday 27 December 2015 05:12 AM, Johan Ouwerkerk wrote:
> On Sat, Dec 26, 2015 at 7:24 PM, Arnav Dhamija <arnav.dhamija at gmail.com> wrote:
>
> In my opinion and personal experience, ctrl+click has always been a pretty
> unintuitive and unfriendly way of selecting non-contiguous subsets of files.
> It's stressful to keep one finger always on the ctrl key and the
> functionality is very limited as it only works for the current level of the
> directory. This idea does exactly that, it works on disjoint folder trees at
> the same time. Plus, there is no stress about accidentally lifting the
> finger from the ctrl key and losing the entire selection : )
>
> Oh I agree. I just wanted to know if this was going to be more than
> just a 'visual' UI to copy existing shortcut mechanisms.
> It seems that it will be, and particularly the capability to work with
> disjoint folder trees will make it rather more powerful/useful.
> Plus it's a really nice concept because you do not need to know about
> shortcuts, need less 'dexterity' or fine motor control and so on and
> in theory it would even translate fairly well to a touch interface I
> think.
> So props for the idea, it sounds like a winner if you get it to work!
>
>>> Does this mode have special provisions for navigating in the one panel
>>> so you can easily select file (sub)sets from disjoint directory trees
>>> without setting up the file view as an expanded tree view first?
>> I am not entirely sure if I have understood the question, but operations can
>> be performed on the File Tray view as well across multiple disjoint
>> directory trees. I'm not quite clear on the part of "setting up the file
>> view as an expanded tree view first" however.
>>
> Depending on the File View mode you may or may not be able to navigate
> between disjoint trees easily.
> For example if I have a directory tree like this:
>
> /A/B/C
> /A/B/D/E
> /A/B/D/F
> /A/G/H/I
> /A/J/K
>
> Suppose I am located in /A/B
>
> I decide I wish to archive contents of /A/B/C, /A/B/D/F and /A/J/K
>
> Furthermore, suppose I use a default of "small icons", so I only get
> to see a grid of icons and cannot expand folder trees to drill down to
> sub-hierarchies from within the file view itself.
>
> Then if I invoke the stashing mechanism for the selection from /A/B, I
> now have a problem: how to select /A/B/D/F without selecting /A/B/D/E
> ?
> How to select /A/J/K at all? Remember, from the file view I can
> neither drill down (because clicking a folder selects it, and I don't
> get the expanders from a tree view because I use the icon view mode)
> nor back up to /A.
>
> I can refine my selection from within the staging panel itself, of
> course, but if the file hierarchies are complex and/or happen to
> contain lots of files it can get visually "noisy", making it tedious
> to prune the selection down to what I'd actually want to include.
> Being able to limit the initial "rough cut" of the selection
> beforehand would help tremendously but requires a relative freedom to
> navigate around folders in Dolphin while setting up the staging area
> at the same time. Especially if you want to keep viewing the items
> that have been explicitly pruned from selection in the staging area so
> the user can undo/redo the pruning itself easily.
>
> Now, with normal shortcut behaviour (Ctrl + Click), if you were to
> navigate elsewhere, you'd lose your selection. You could avoid this
> for the stashing mechanism quite easily: simply do not behave like
> those shortcuts and keep the state around, but then you must address
> the problem of cancellation.
>
> Whatever the choice, I think the user must be able to explicitly
> cancel out of/close the stashing widget in case they entered it by
> mistake. With Ctrl+Click it basically amounts to, release Ctrl, click
> anywhere and your selection is reset to empty.
>
> Also, how do you want cancellation/closing to work generally: does the
> widget auto close itself and release the selection immediately when a
> context menu action is "completed"? Or is the widget and selection
> retained so the user may re-use the selection for other actions
> afterwards, and must therefore close the widget manually? What actions
> in Dolphin would cause the staging area and any selection within it to
> be dismissed?
> E.g. searching for files? Splitting the file view (to view multiple
> directories side by side)?
>
> Which reminds me: if split view is used or file search results are
> currently being displayed, should it be possible to summon the staging
> area then or not? In particular with split view: how does the staging
> area behave? Does it 'attach' to a particular 'side' of the view, and
> if so, is it possible to have multiple staging areas open at the same
> time, one for each visible directory tree in a split view?

-- 
arnav dhamija
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/visual-design/attachments/20151227/d46e3b52/attachment.html>