Import/Export (or Save/Open) should be discoverable and consistent

[polina-c]

Problems:

1. It is now called Import/Export and should be Open/Save
2. Drag and drop for import is not discoverable
3. Memory page has different implementation

Mindy:
needs afforances for drag and drop and import button. "Export" might be the wrong word here if the main user journey is to save and reload states within the DevTools. "Save" and "Open" might be more appropriate. Even better if on save the user can name the file and the directory is shown so they know where to find it for sharing with others. -Mindy

Mindy / Polina (2022-10-21 11:39 GMT-7) at 4:15

[kenzieschmoll]

Switching to Open / Save SGTM. This should be a simple change, we already have the file selector plugin hooked up in other parts of DevTools.

[polina-c]

How about discoverability of 'Open' with drag and drop? Do we want to continue supporting it? If yes, we need to figure out how to make it discoverable.
But may be it will be better to reserve drag and drop for other more important future features that may take advantage of it?

[kenzieschmoll]

It doesn't cost us any overhead to leave the Drag and drop functionality there. We can leave it here for users who are used to it and would not like if it was ripped out, and we can point all new users to use the Save / Open buttons.

[polina-c]

And, we can suggest to drag and drop in the tooltip for the button 'Open'.

[bkonyi]

we already have the file selector plugin hooked up in other parts of DevTools.

I didn't think we had a file selector plugin that worked on web, or am I mistaken?

[polina-c]

We have it. See for example App Size > Import File

[polina-c]

The tooltips for the buttons can be:

• Save the screen state to the folder Download, to open or share later.
• Open a previously saved screen.

@melyndahoover
@MaryaBelanger

How does it look?

[MaryaBelanger]

Save the screen state to the folder Download, to open or share later.

Change to:

Save the screen state to the Downloads folder

Save's original is a little long for a tooltip. Plus the buttons are logically paired (and I'm assuming graphically paired as well), so Open's tooltip provides the same information

[melyndahoover]

Marya's suggestion for the save tooltip and Polina's suggestion for the open tooltip sound good to me.

[polina-c]

This is how return back to online mode is implemented in CPU Profiler.
All other screens disappear, but CPU Profiler, and there is button 'Exit offline mode'.

Is it how we want it to be implemented for memory screen?

[kenzieschmoll]

I would recommend to keep this consistent for all DevTools pages. This makes it clear that we are in offline mode, viewing a single set of data, and to return to the "live" view of DevTools, the user would need to exit the offline mode.

[kenzieschmoll]

Instead of having the import action be accessible from the toolbar at all times, in static mode we should have the pages that support loading offline data be present, and on those pages we should just show an action to load offline data. This will make it more clear which pages support loading data and what kind of data can be imported. When we are connected to an app, each screen should have its own import (or after renaming, 'open') button where a user can still access the offline viewing mode.