RE: RFC - file chooser dialog API for sandboxed apps

["Dodier-Lazaro, Steve" <s dodier-lazaro 12 ucl ac uk>]

Hello Allan,

A note on how people interact with UIs and the general direction taken by GTK to provide more touch-friendly 
UIs:

I think the current File Chooser Dialog (FCD) only fits well for heavy keyboard+mouse users, but not touch 
users at all. While that needs to be addressed, ideally a UI would be quick to use for both 
"keyboard-oriented" users and touch device users. It seems a bit of an obvious requirement but when looking 
at Content Selection Dialog (CSD) mockups it's somewhat hard to imagine what the kb interaction would look 
like and how it'd be on par with the current FCD.

I should always be able to type my filename with some degree of autocompletion, and to touch file/folder 
names on a tablet screen. However if individual content item icons are particularly large in a very populated 
folder, then I'd lose time when using a traditional mouse. One could make up test scenarios and measure times 
with cogtool with a handful of representative devices. It may be that customisation options will be 
significantly useful for some device types and if so they should be added to the existing UI mockup.



A couple of thoughts on CSD:

I prefer file systems as a primary method of storing and retrieving files because they're well understood by 
all current users, flexible enough to allow a per-activity organisation (in spite of their rigidity when 
you'd rather have several ways to index the same set of files/folders, to view a whole folder as a timeline, 
etc.), and they're rather raw structure, so that means users can appropriate themselves this structure in 
ways we hadn't anticipated. File systems also already sit in an existing ecology of tools readily available 
to organisations, so that means GNOME is also a workplace option. Providing per-app content selection as a 
primary means of interaction may create extra "noise" for organisational contexts where CISOs can't afford to 
let users rely on their apps to store and exchange data but would rather impose a contracted service provider.

Besides the local FS, files that are not saved on a filesystem yet could be kept in an app's "Staging Area". 
This would include all currently open content items in an application. (off-topic: having apps that are more 
conscious of this per-item organisation would allow for some sort of (voluntary e.g. a la Chrome) within-app 
sandboxing between the different contet items. GTK could ultimately provide a special tab API that would 
create autonomous mini-processes with callback functions that handle an item per tab, and rely on D&D 
handlers/the clipboard to allow users to exchange data across tabs, if necessary).

A staging area could also be part of a default interrupt handler on GNOME apps so that a user doesn't lose 
their progress immediately if they close the app by accident or if it crashes (and the staging area can be 
automatically cleared like a mailing app's drafts folder) -- most current devices' filesystems should allow 
for most apps to do that (well, maybe not a video editor on a tablet/phone). I would really rather make this 
staging area temporary, because ultimately users will be better served either by going all filesystem or all 
in-app storage, and... I prefer all-filesystem :) I think think a unique place to refer to makes it easier to 
re-find content, especially after a long time, as you re-learn your content organisation by browsing through 
one filesystem more easily than by having to explore several independant ones.

Besides that primary method to access content, apps could propose content that is not traditionally available 
as files (such as Facebook photo albums; Netflix movies in "Movies", if you have that; etc.). Exposing this 
content in a different way than the filesystem's totally makes sense to me. It could also be proposed as a 
specific folder on the filesystem (e.g. App Documents/MyApp/), in a complementary way, to allow users who 
already selected "Files" to have a way to reach this data without switching to another view/browsing logic. 
I'm not sure if that makes sense at all and I guess one would have to look at how people handle using 
different browsing logics in the same device -- I just remember Windows 8 was rather heavily criticised on 
the fact that one had to learn several different environments to know how to reach each feature of the system.

Remains the question of remote sources, e.g. cloud storages. I'm unaware of any research on how people cope 
with multiple file systems in terms of choosing how to organise their files, whether they prefer to mirror 
their remote file stores in their local file systems (and if so, how) or a specific, separate browsing 
location. I suppose again that one could propose "Local Files", "Cloud Foo", "Cloud Bar", "App Ter", etc. on 
the first page of the CSD and provide a default mirror on the local filesystem (like for mountpoints).

There could also be discussions as to how an app can indicate which sources are the most relevant (i.e. 
what's the best abstraction? Can they specify that they want certain types of external devices, or specific 
cloud shares e.g. SkyDrive for a Microsoft app, or MIME types that they handle to filter out stores and apps 
providing no compatible data). And finally, one could look into customisation options to further improve the 
experience of users in edge cases: do some users exclusively want their file systems because the content 
selection duplicates their company/personal approach? Do some users want to use per-app storage because they 
primarily use mobiles and are used to that? Etc.

Can one also provide automatic labels (or let users add labels) that indicate who a specific store/app's 
content is shared with or whether shared or not? I imagine that when you want to save a file, you would need 
to know/control the extent to which it is shared. For instance, my SkyDrive could say "Shared with research 
team" and my GDrive say "Shared with classmates; Association Foo; etc). There could also be a more permanent 
privacy indicator like on Facebook's pages when a simple hover tells you who an album is shared with -- so I 
would know which folder to pick for a specific file without having to switch to Google Drive's UI.



File saving:

I think one thing that remains on the "TODO list" is how to allow apps to save files? I really think apps 
should not choose arbitrary filenames and overwrite confirmation should be rethought, because otherwise they 
may erase users' content. I'd assume that you want to design a content storing concept a bit like content 
selection, maybe a bit more elaborated than Sharing, when a user wants to save a document they've been 
working on? Or would they go through the Sharing API? How would "Save as" behave in such a case? Would the OS 
remember where the file to "save as" comes from and re-display that information, would it ask the user to 
re-navigate straight from the start of the content storing dialog, would apps get to choose?

There's also the question of whether it's the app or the OS that opens and writes files to actual storage 
medium. I'd assume that some apps may come with built-in methods to store a file on the app's proprietary 
cloud so it may be something that can be exported to the "content selection/storing" UI by the app, and then 
the OS just tells the app which path it's allowed to read/write on which medium (and we resort to access 
control to allow the app to do the rw operations itself)? 

Cheers,
--
Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670