This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

Opening and Importing Files with the Content Apps

Experiments to try to improve workflow for opening and viewing files, particularly documents and images.

Background

Currently the main default file handlers are:

Issues with this:

Goals

Try to:

Relevant Art

OS X

Preview app shows various content types when opened from Finder. Exists independently of Photos, iTunes.

Windows 10

Discussion

Some existing behaviors that are important for people using Files:

Tentative Designs

The approach is essentially the same for audio and video on the one hand and documents and images on the other (although the UI differs slightly for Music and Videos).

In each case, the content application only shows items from its respective XDG folder (and not ~/Downloads). Importing a file by pressing the "Add to" button moves the file to the appropriate XDG folder.

TODO: what about non-local storage?

Music

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/open-audio-with-music.png

Videos

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/open-video-with-videos.png

Documents & Images

Documents and images are similar enough that the same approach can be taken for both. There are currently two options here:

Approach 1

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/open-images-with-photos.png

Approach 2

Process for opening an image:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/open-images-with-image-viewer.png

Compare and contrast for the document and image viewers and the Documents and Photos apps:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/viewer-apps.png

Approach 3

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/content-apps/experiments/standalone-photos-window.png

Evaluation

Approach 1

Approach 2

Approach 3

+ Strong presence of the content apps throughout

/ Does advertise the content apps to an extent

+ Content apps have a strong presence

- Leaving an item open in a separate window is hard

+ Can easily leave files open to use later or act as a reminder

+ Can leave files open

? Could be slow

? More likely to be fast

? Hard to say

+ If an item belongs to the content app, it is always opened by it

? Item always opened in the viewer

+ Item is always opened by the content app

Preview happens in the content apps

Exposes file-related actions - makes the viewers an integrated part of the file management experience

Preview happens in the content apps

- Back buttons are a bit awkward - they go back to a place you didn't come from

- When switching to the content app, the viewer window needs to be automatically closed - otherwise you leave debris behind - this could be surprising though, and means there's no way back

+ Allows switching to the content app without needing to close the viewer window

Development Plan

If we were to go with approach three, a development plan could look something like:

  1. Preparatory UI work in documents and music - address Inconvenient scrolling / paging, better communicate what is the current playset

  2. Enable opening files with documents, photos, music (file import not necessary in the first implementation)
  3. Experiment with and implement file import
  4. Profit

Comments

See Also


2024-10-23 11:04