Make “upload” target bigger and don’t require drag-n-drop

[arrowtype]

Currently, the "drop font here" target is very small. This means, in part, that it's easy for new users to drop a font on the main white area, which does nothing but gives them a "download" (in Chrome).

It would be much nicer if this had a bigger drop area, more similar to existing UI patterns on sites like WakamaiFondue or other typical drag-n-drop upload screens:

Ideally, this has a few features:

1. Full-screen target: if a user drops a file anywhere in the viewport (even above the sidebar), the file should upload. They should be able to do this with their eyes closed.
2. Alternative option to click an "upload" link to open their system file explorer, to make this accessible via keyboard (good for users without mouse control, or anyone that just find it more convenient to not be managing multiple windows). 3: Visual cues: the "dashed border" is a common visual cue of a drag-n-drop target. You might use this to make the interaction more obvious.

Thanks for an awesome tool!

[Lorp]

Good proposal. Great point about “drop anywhere”.

[Lorp]

This is now working. Let me know if it works as expected.

I didn’t include the sidebar in the drop zone, but maybe I will later.

[Lorp]

Subsequent drag&drops are not intuitive, probably bringing up the original UI on a dragenter event.

Also, need to report if the font did not load for some reason (non-variable, CFF2) or if the file was not a font.

[arrowtype]

Nice update! The target is 100% more obvious, now. It works as expected on initial load in Chrome (with the exception that I think drag-and-drop should ideally be possible even onto the sidebar).

Subsequent drag&drops are not intuitive, probably bringing up the original UI on a dragenter event.

Yeah, I think that the nicest solution would be watching for users to drag & drop a new font at any time would be most intuitive. https://dinamodarkroom.com/gauntlet/ does a fairly nice job of this. As you say, though, bringing up the yellow overlay when a drag is detected might be ideal (similar to Font Gauntlet, but probably adding the original "Drop a variable font here" text would be a nice helpful user hint).

To make it more intuitive (and possible with keyboard-only use), maybe there could be some gray helper text in the bottom-right corner?

[arrowtype]

For what it’s worth, here's how I would imagine an ideal second drag and drop interaction might look:

The background would take over the whole screen, and be at maybe 80% opacity to make it obvious to the user that you have detected their new drag, but the UI is still there if they abandon.

[arrowtype]

Something that just occurred to me:

Potentially, it might make sense to just start with one of the "preloaded" fonts active by default. To make these obvious but also save UI real estate, these fonts could be put in a typical <select> list in a small section like "Current Font" above "Info".

By extension, instead of placing the "To inspect another font..." text in the bottom right corner, this direction could go directly under the font menu in that "Current Font" sidebar section. That way, new users can immediately click around, it's obvious that different fonts can be selected from a pre-populated list, and it's obvious that new ones can be uploaded. LTR language readers view webpages in an "F" shape, starting from top-left, so placing this font menu and upload direction in that spot will help make it immediately obvious what users can do.

I think the drag-anywhere overlay would still work well in this scenario, too. :)

[Lorp]

Thanks for these good ideas. I’m thinking of implementing a font menu the same way the right-hand font menu works in Axis-Praxis: an initial list of fonts, to which any drag-drop fonts are appended. Keeping that menu inside the same panel as Font info would work nicely.

Lorp commented 4 years ago

BTW the big drop area is implemented as a giant, transparent <input type="file"> element, which in all Mac browsers handles drop nicely, and of course handles the click as we want. So to extend it to the full screen, I’d also handle a normal drop event like the old days.

arrowtype commented 4 years ago

Nice, that all sounds good!

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[Lorp]

BTW the big drop area is implemented as a giant, transparent <input type="file"> element, which in all Mac browsers handles drop nicely, and of course handles the click as we want. So to extend it to the full screen, I’d also handle a normal drop event like the old days.

[arrowtype]

Nice, that all sounds good!