UI ideas for remaining Files tasks

[Thomas Pfeiffer]

On 21.11.2012 11:09, Marco Martin wrote:
> On Monday 19 November 2012, Thomas Pfeiffer wrote:
>>
>> 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.
>
> yeah, this looks more a context menu linked to the specific icon rather than a
> slc thing.
> i like the concept of sliding the menu...
> only thing it would force to maintain a list that scroll horizontally, and i
> don't know, i'm liking that iphone-esque paged icon grid less and less...
>
> in general, the direction you slide dictates the direction you can scroll a
> view, not sure we want that

Yes, that's the biggest drawback I see in that solution as well.
On the other hand, maybe making scrolling direction consistent isn't 
such a bad idea anyway? I prefer vertical scrolling as well, so how 
about maybe changing all scrolling to vertical and making the menu slide 
out to the side? The tag list can only scroll horizontally anyway.

I agree that this is something that has to be carefully thought through, 
as indeed is may limit us later on. The long-tap context menu does work, 
I just think that sliding it out would feel more "fluid".

>> 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.
>
> the reason they are in the same tab as types right now is that choosing an
> activity shows files of all types, so is mututally exclusive with them.
>
> (if you have just a couple of files in an activity, if you have to guess the
> right type before being able to access it becomes not too useful)

Yes, that does make sense in the current situation, but as I wrote 
earlier, I sincerely hope this will change. It doesn't make sense form a 
user's perspective (Why do I have to select file type OR Activity?)
When we get to the point where filetype is not special or mandatory 
anymore but is just another filter which can be combined with others, 
they are not mutually exclusive anymore and that problem disappears.

So yes, removing the mutual exclusivity is a precondition for this 
solution, but I'd suggest not to create a workaround but only implement 
it when the precondition is satisfied.

>>
>> 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 ;) )
>
> nice, looking forward to that ;)

:)