New architecture for file system UI

[lavelle]

I've been thinking about some of the problems I'm having with the current overall design of the filesystem UI and I think it might be better to take a step back and consider other options before continuing with the current approach.

There are two main problems right now:

• Duplication. Every file system provider will need its own UI, and they will all be incredibly similar. There will be

  • A list of servers/buckets/repos etc in the left hand panel
  • A button to add a new one
  • A button to remove an existing one
  • Some text fields for editing them

  Even when using Polymer components, this is a lot of duplicated effort each time.

• Synchronisation. The list of mounted servers is essentially just a duplicate of the list that already exists in the sidebar of the Files app, and it's a lot of work to ensure that the two stay in sync across additions, edits and removals. This is an area where potential bugs can be introduced that could be easily avoided.

Therefore, I propose that it would be far better to integrate this into the Files app. Have a single, canonical list of mounted file systems on the left sidebar of the file browser as we do already. Then, simply add a button to the file browser (either on the main UI or in the settings) for adding a new provider. Clicking this would bring up a provider-defined HTML page with a single form for entering the required details (bucket and region for S3, URL for WevDAV, etc). These credentials would then be passed into a mount method registered by the provider. Unmounting could then be done as it is already with a button that appears when you hover over a file system in the list, and editing could simply be done inline from the file browser with one more button.

To implement a UI all a provider would need to do is provide the HTML page for entering the configuration and a callback function for responding to a mount request. This is significantly less work than is required with the current setup, and would speed up development for this and all future providers.

This would take a bit longer initially because it would require coordinating with the team that develops Files.app to integrate this, but it would be worth it in the long run, by reducing code duplication, reducing potential areas for bugs, and improving user experience.

[lavelle]

@jmuk, @mtomasz-chromium, what do you think?

[lavelle]

I'm happy to take responsibility for drafting a specification for the HTML page and the callback, and for proposing the idea to the Files.app team and liaising with them on integrating the new system.

[mtomasz-chromium]

The idea is interesting. Let me share some of my concerns, though.

First of all, we are thinking about enabling File System Provider API on operating systems other than Chrome OS, where Files app is not available. If we put more responsibilities on Files app, then it would make the migration more difficult.

Secondly, if a provider wants to have some kind of UI, eg. for extra configuration options, then it may make users confused how to set up things - via the launcher or via Files app? There is also Settings page by the way. Also, I'm curious how many providers will really support more than once instance of a file system. So far we don't have much data.

As for synchronization, there is a crbug.com/393156 filed to add a method to get a list of mounted file systems. This may make things a little bit easier to keep in sync.

[jmuk]

For the number of file systems from an app: I expect usually an app will create multiple filesystems.
I'm thinking that an app will implement certain protocol, such like webdav, ftp, sftp, samba, or something like that. These apps will create a filesystem per remote host or configuration. Indeed some apps, like dropbox, will be single file system per user, but I think that is rather minority.

[jmuk]

The original proposal is interesting. I'm supportive but we need to consider the API more meticulously. What type of events will be emitted to the app, and what kind of data the app will provide?

[mtomasz-chromium]

Yeah, that's right. Especially for ftp, sftp/scp we should be able to create more instances. I still think, that before proceeding we should think carefully how this change would affect other operating systems, and how can we solve it.

[lavelle]

That API for getting the list of mounted providers looks useful, if we end up going with the current approach we should definitely use that instead of keeping track of the state manually.

I agree with Jun that the majority of providers will support multiple instances (even Dropbox could have two users sharing a Chromebook).

I didn't know there was a plan to add the FSP to Chrome on other OSs. That makes things more complicated. One solution would be to create a separate extension with a UI that shows the list of mounted filesystems, that can then be used as a replacement for the Files.app sidebar in the architecture I originally outlined on other OSs. This separation of concerns between the roles of displaying the list of filesystems and mounting new ones would allow us to keep duplication low and still have it work across platforms. I could even use the UI I've already created as the basis for such an extension. This would also allow work to begin immediately on this idea without waiting for updates to Files.app

Settings is another important consideration. I guess my initial idea would be to have an app present all its possible options in the HTML page that is displayed (obviously some fields can be optional if appropriate). If the user wants to change anything later, that same UI with all the options would then be shown again. Whether this edit UI is triggered by the chrome://extensions options button, the app launcher icon, the Files.app sidebar, or some combination of the above is a decision that can be made later - it's a 1-line change to switch the event handler. I personally have no preference there.

[jmuk]

Thinking this a bit more.

I think the problem of configuration UI is, the app needs to manage the list of filesystems. If the app doesn't have to, things will become simple -- the app simply shows the setup dialog (with a few text fields). The setup dialog contents is really app specific, it won't be covered by the API.

The reason why the app needs to manage the list is that the user wants to manage it. The reason why the user wants to manage the list is, sometimes the user wants to remove a filesystem permanently, but sometimes wants to disable it temporarily.

So, why don't we have the reason as a field of UnmountOption? Then, the settings list UI is unnecessary at all.
Of course Files app (or other platform's driver) needs to provide the UI of choosing the unmount reason, which could be hard from the UI perspective.

[mtomasz-chromium]

Avoiding duplication sounds basically good, but we have to be careful not to make things more complicated for users. If I had to choose code duplication or good UX experience, I'd go with the second one. Currently, to configure a provider we have to click on it in the launcher. This is very simple, petty intuitive and nothing should go wrong. It is also portable.

I'm not really convinced about creating a separate extension for managing provided file systems. To configure an app I expect to do it by launching it, to configure an extension, via chrome://extensions, to configure Chrome, then via chrome://settings. Having another separate tool for configuring part of Chrome doesn't sound like a good idea.

I kind of like the idea of moving the provided file systems configuration to chrome://settings. However, we will still have an icon in the launcher, since apps must have an icon (except for internal apps), so what would we show after clicking on it? If we could remove the app icon from the launcher, then it would make sense. We have to think of edge cases.

As for Mukai-san's suggestion. How would we change settings of a mounted provided file system? Do we want to make them immutable after created? I'm wondering if we want to support unmounting temporarily. I can't think of use cases for that feature.

[jmuk]

I was thinking immutable. I'm wondering how often user wants to change settings once the filesystem is set up. Simply discarding/re-creating sounds good enough to me.

[lavelle]

Yeah, I agree they should be immutable. Modifying the configuration of a filesystem while it's mounted leads to all sorts of problems. The question then is whether we support a 'deactivated' filesystem, that can be modified and remounted, for when the user wants to make minor edits to the configuration such as changing a password, or simply force them to delete the current one and create a new one.

The latter is a much simpler design, and I think that users will be modifying filesystems infrequently enough for it to not be a great inconvenience to enter all the details from scratch.

[jmuk]

Adding a UI to chrome://settings is a choice. Think about input method apps. They doesn't appear in the app launcher at all (even though third party ones), and simply appears in the language settings. Doing similar could be great.

However, I expect adding a new UI to chrome://settings is a tough task, usually UX people want to keep it really simple.

[lavelle]

And yeah, having a separate extension to emulate the Files.app sidebar on other OSs is complicating things a bit. I personally don't think the file system providers should have icons in the launcher at all.

They're not really 'apps' as such, that you launch and use independently, more system-level plugins for another app. IMO, the best UX would be no launcher icon, and then configuring the providers from a configuration dialog, either in the chrome settings, the extensions page or the file browser.

Could you possibly update the FSP API to allow extensions to use it as well as packaged apps so a launcher icon isn't required?

[lavelle]

Regarding those three options:

• Files.app: this seems like the best choice to me, keeping all filesystem-related configuration in the app that displays filesystems. However, if the FSP API is going to platforms other than Chrome OS, there's no way to have this and a consistent experience across platforms.
• Extensions page options: second best. This is where I go when I want to configure per-extension settings, and were I would expect the settings for filesystems to be if they weren't in the file browser. This option does allow a consistent experience across platforms.
• chrome://settings: the worst of the three. I don't think extension-specific configuration should go here, and like Jun said, I'm sure there'll be people fighting against adding any clutter to this page.

[mtomasz-chromium]

@lavelle I agree. The main reason we use FSP API from apps is that only apps can create windows, for all kinds of dialogs, such as credential ones. Eg. my prototype cloud extension shows an authentication dialog if the credentials are rejected or are basically not set yet. Extensions can't show (nice) windows.

I really wanted to show a configuration window as soon as the provider is installed. If we switch to extensions, then we have to open a browser tab on install instead of a nice app window. I think it is acceptable. WDYT?

[lavelle]

Hmm, yeah I guess that is kind of a conflict there. Could FSP be enabled for both? Then the providers that needed dedicated windows for authentication like Dropbox could be apps, but the others like my two could be extensions.

[mtomasz-chromium]

As for that three options.

The question is what are we going to configure. I want to configure available providers in Chrome. So IMHO I'm configuring Chrome, not a specific extension. By the way, setting for enabling/disabling Drive is already there.

Note, that while chrome://settings is easily accessible on Chrome OS (Start -> Settings), settings of extensions are very hidden (Launch browser -> Wrench button -> More tools -> Extensions). I don't expect typical users to find it.

[mtomasz-chromium]

We can enable for both easily, but I don't want to end up on having configuration in two different places.

[lavelle]

No, I agree, we should still keep configuration in one place, wherever we decide that is. If we enabled it for both I think there would have to be some mention in the tutorial or whatever that custom windows should not be used for configuration.

Yeah, I guess the settings menu is easier to find (and I guess more consistent with Google Drive too). Reckon we can get a new section added there for custom filesystems?

[mtomasz-chromium]

It seems that we may be able to create nice windows from extensions. These aren't app windows, but may look similar. I'll do some experiments.

https://developer.chrome.com/extensions/windows#method-create

If so, then I'd suggest to disable File System Provider API for apps and make it available for extensions only.

As for getting a section in chrome://settings, I think it should be doable. We should prepare a doc with some mocks and get it approved.

[lavelle]

Okay I created a wiki page to formalise the specification: https://github.com/google/chromeos-filesystems/wiki/UI-architecture-specification

Something that occurred to me as I was writing it: Do we want to let providers define custom HTML pages for their options, or could we just generate them automatically from a JS configuration object? I was thinking it could be defined something like

chrome.fileSystemProvider.registerProvider({
  providerId: 's3fs',
  providerName: 'Amazon S3',
  configuration: {
    fields: [
      {
        name: 'url',
        required: true
      },
      {
        name: 'username',
        required: true,
        validation: /[a-z]{10,20}/
      }
    ]
  }
});

LMK your thoughts on this and the rest of the documents.

[lavelle]

This idea has been replaced by other approaches developed by other team members. For the immediate future, the two existing providers will use a simple HTML page with Polymer components that allows a single instance to be mounted.