Re: Directory Upload Proposal

On Wed, May 13, 2015 at 2:19 PM, Ali Alabbas <alia@microsoft.com> wrote:
> Thank you for the feedback Jonas. After speaking to the OneDrive team at Microsoft, they let me know that their use case for this would involve hiding the file input and just spoofing a click to invoke the file/folder picker. This makes me believe that perhaps there should be less of an emphasis on UI and more on providing the functionality that developers need.

I do agree with you that most websites will likely want to hide the
browser-provided UI. And for those websites options 2 and 3 are pretty
much equivalent.

But my theory has been that some websites will want to use the
browser-provided UI. For those websites I think option 2 is
advantageous.

But I don't really have much data to go on, other than that I still do
see quite a few websites using the browser-provided UI for <input
type=file>.

> On that note, there is actually a 5th option that we can entertain. We could have three different kinds of file inputs: one type for files, another for directories, and yet another for handling both files and directories. This means that if a developer has a use case for only wanting a user to pick a directory (even on Mac OS X), they would have that option.

Like with options 2 and 3, I would definitely be ok with this option too.

It isn't clear to me though that there are actually use-cases for
enabling the user to *just* pick a directory, even on platforms where
the file-or-directory picker is available?

/ Jonas


> Thanks,
> Ali
>
> On Friday, May 8, 2015 at 3:29 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>>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 Thursday, 14 May 2015 06:40:06 UTC