On Wed, May 13, 2015 at 2:19 PM, Ali Alabbas <a...@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 <jo...@sicking.cc> wrote:
>
>>On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas <a...@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
