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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
