UI ideas for remaining Files tasks

[Thomas Pfeiffer]

On Monday 19 November 2012 18:40:50 Marco Martin wrote:
> On Friday 02 November 2012, Aaron J. Seigo wrote:
> > Hi...
> > 
> > I sat with Marco today to work out task priorities. Since this is about
> > polishing, bugs get highest priority, UI polishing second and new but
> > necessary functionality third.
> > 
> > Within each of those categories we've prioritized in three priorities as
> 
> > follows:
> so, a bit of time passed,
> and some work happened in Files. To summarize,
> some visual issues have been fixed, and the underlying metadata model has
> been refactored.
> The last point is very important (even tough is of the type everything
> changed, but if all goes fine looks like nothing has changed) and sadly
> taken quite a lot of time.
> 
> now basically two important points remain to be done:
> * file rename/tag rename/tag deletion
> * type specific ui, that shows metadata only present in a particular
> resource type, such as filter by Author
> those still miss an UI design at all... any idea? ;)

That's where I come in, right? ;) Okay, here we go:

Tag rename, tag deletion: 
Here I'd go for our general context menu mechanism. Currently that is long-
tap, although I don't think this is ideal. Personally I'd prefer swipe up or 
down over the item so as to "slide the menu out of it" (including the 
corresponding animation), since that fits our general drawer metaphor pretty 
well. However this should only be done this way if we adjust the context menu 
mechanism for the icons on the Activity Screen as well. If the long-tap stays 
for the Activity screen, it should be used in Files as well for consistency. 
Whichever way we choose to invoke it, a context menu seems appropriate for 
this function to me.

File rename: 
I can imagine two ways which would not brake consistency:
a) Introduce a new drag target for rename so it works the same way as 
moving/deleting/tagging. I'm not sure about the placement yet, though
b) Add another button near SLC for misc actions. This could also hold 
functions like "delete" for people who don't like dragging. It may feel weird 
to do this, but I think that if we add a button with additional options for 
selected items, it should be here because SLC is also stuff you do with 
selected items.
In general, I do not recommend introducing another place where a button which 
does something with selected files is placed, since we already have three 
(toolbar, drawer, SLC), and I don't think the drawer is a good place, since 
it's more for things you can use to filter.

Type specific UI:
This should go into the Filters tab; because it changes with the selected file 
type, it should appear close to it. The only problem here would be "jumpiness" 
as is would push down the Activities as soon as a file type is selected.
On the other hand, I'm not too happy with the Activities resting with the 
other two filters anyway, because you can drag files onto Activities but not 
onto file types, ratings or the filetype-specific filters. Activities would also 
better be represented like tags (and it would also make sense to show how many 
files are connected to an Activity), but I know the current radio buttons were 
a temporary solution anyway. It should also be untangled from the file types 
once we turn filetype into an independent filter equal to the others (so one 
could say "give me all images connected to Activity X", not just either "give 
me all images" or "give me all files connected to Activity X", as it is now).

For representation, I'd suggest a list similar to the Information Panel in 
Dolphin but with "<all>" as default for each property, which is replaced the 
appropriate editing widget when tapped (displaying all the edit widgets by 
default would probably be too heavy).

Of course the problem is: Where do we put the Activities? I'd say a separate 
tab would be ideal (since the list can grow very long with many Activities 
created), but of course this would make the tab bar a bit cramped. Is there 
any way we could add another tab, or do they absolutely have to share an 
existing tab? If Activities have to share a tab, it should be Tags because 
that's what they have most in common with.


I hope you can imagine what I have in mind from my descriptions. If not, I'll 
have to create some mockups.
(Btw, I've started to teach myself QML, so expect to be bombarded with 
questions soon, and then hopefully with QML files of my ideas ;) )

---
Some time has to be reserved for the regressions in Files compared to PA3 as 
well:
https://bugs.kde.org/show_bug.cgi?id=309989
https://bugs.kde.org/show_bug.cgi?id=309991
but that will probably be done together with the other bugs marked as 
important, right?