Re: Directory Upload Proposal

On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas <alia@microsoft.com> wrote:
> I recommend that we change the "dir" attribute to "directories" and keep "directory" the same as it is now to avoid clashing with the existing "dir" attribute on the HTMLInputElement. All in favor?

There's no current "directory" attribute, and the current "dir"
attribute stands for "direction" and not "directory", so I'm not sure
which clash you are worried about?

But I'm definitely fine with "directories". I've used that in the
examples below.

> As for the behavior of setting the "directories" attribute on a file input, we have the following options:
>
> 1) Expose two buttons in a file input ("choose files" and "choose directory") (see Mozilla's proposal [1])
> - To activate the "choose directory" behavior of invoking the directory picker there would need to be a method on the HTMLInputElement e.g. chooseDirectory()
> - To activate the "choose files" behavior of invoking the files picker, we continue to use click() on the file input
>
> 2) Expose two buttons in file input for Windows/Linux ("choose files" and "choose directory") and one button for Mac OS X ("choose files and directories")
> - Allows users of Mac OS X to use its unified File/Directory picker
> - Allows users of Windows/Linux to specify if they want to pick files or a directory
> - However, there would still need to be a method to activate the "choose directory" button's behavior of invoking the directory picker (e.g. chooseDirectory() on the HTMLInputElement)
> - This results in two different experiences depending on the OS
>
> 3) Expose only one button; Windows/Linux ("choose directory") and Mac OS X ("choose files and directories")
> - Allows users of Mac OS X to use its unified File/Directory picker
> - Windows/Linux users are only able to select a directory
> - click() is used to activate these default behaviors (no need for an extra method such as chooseDirectory() on the HTMLInputElement interface)
> - For Windows/Linux, in order to have access to a file picker, app/site developers would need to create another file input without setting the "directories" attribute
> - Can have something like isFileAndDirectorySupported so that developers can feature detect and decide if they need to have two different file inputs for their app/site (on Windows/Linux) or if they just need one (on Mac OS X) that can allow both files and directories
>
> 4) Expose only one button ("choose directory")
> - User must select a directory regardless of OS or browser (this normalizes the user experience and the developer design paradigm)
> - To make users pick files rather than directories, the developer simply does not set the "directories" attribute which would show the default file input
> - Developers that want to allow users the option to select directory or files need to provide two different inputs regardless of OS or browser

Hi Ali,

I think the only really strong requirement that I have is that I'd
like to enable the platform widget on OSX which allows picking a file
or a directory. This might also be useful in the future on other
platforms if they grow such a widget.

I understand that this will mean extra work on the part of the
developer, especially in the case when the developer render their own
UI. However authors generally tend to prefer to optimize a good UI
experience over saving a few lines of code. This seems especially true
in this case given that the author has chosen to provide their own UI
rather than use the browser-provided one.

So that leaves us with options 2 and 3.

I think both of these are options that I can live with. And for
authors that render their own UI the difference is only one of syntax.
And most likely authors will wrap our API in a library since none of
the APIs here are particularly nice.

However I do think that 3 has some disadvantages for authors that *do*
use the browser provided UI.

The main one being that the UI gets kind of awkward when rendering one
<input type=file (multiple)> and one <input type=file directories>.
>From a user point of view, it ends up being sort of half-way between a
UI where you select one "thing", and a UI where you can add as many
files/directories as you want. Specifically the user can select no
more than 2 things, but require that one and only one is a directory.

So the double-<input> UI ends up neither being a good UI to allow the
user to select one "thing", nor to allow the user to select an
arbitrary number of "things".

The other downside with 3 when used with the browser-provided UI is
that the website will still have to use javascript to dynamically
generate one or two <input>s. This is needed in order to avoid having
two exactly alike UI widgets on old browsers or browsers which doesn't
have a separate directory picker.

That said, 2 definitely has the disadvantage that it'll force us to
cram two buttons into the small layout size that is used by a <input
type=file>. But I think this is solvable. One simple solution is to
initially render two buttons, but once a selection is made, replace
the two buttons with the text "N files attached" or "File foo.jpg
attached" or "Directory bar attached" as well as a [x] button to clear
the selection.

This is certainly not a great UI, but it seems like a better UI than
the resulting UI from using two <input>s. And of course the author
always has the option to render their own UI, in which case 2 and 3
are pretty much equivalent.

Let me know what you think?

/ Jonas

Received on Friday, 8 May 2015 22:30:14 UTC