Automatic bulk flashing

[skullydazed]

There should be a special mode that can be enabled that flashes as soon as a the DFU bootloader is detected.

Suggested by IBNobody over on Reddit.

[skullydazed]

Over in #16 @NoahAndrews and I have been talking about how to best implement this. One of the (until now) undocumented intents of this issue was to make bulk flashing easier. We should be able to enable this, plug in a keyboard, have it enter DFU mode, automatically flash, unplug, plug in another keyboard, enter dfu mode, automatically flash, etc.

[skullydazed]

An interesting edge case I ran into with the new button: I had a keyboard already in DFU mode plugged in, I started the app, and then loaded the flash. Realizing I wanted to try "Flash When Ready" I unplugged the keyboard. After Flash Keyboard became disabled the Flash When Ready button did not show up. I had to Choose .hex again to have that appear.

[NoahAndrews]

I'll work on that edge case. Should be easy.

As I explained in the other thread, I don't like the idea of showing the FWR button before the hex file is loaded to our typical user. Your use-case, while valid, is certainly very exotic, and the typical user experience shouldn't be compromised to make it work. If we can agree on that, the question becomes how to present a bulk-flashing option to the user. Maybe a "Flash this file to every keyboard I plug in" button, worded better.

[skullydazed]

I agree with hiding complexity from the typical user. But what value is that button adding now? You don't save any clicks, you simply change whether you click a button before or after pressing reset.

[NoahAndrews]

From the other thread, buried in a huge post:

Also, IMO the main reason we need a flash-when-ready button is because it can take a while for Windows to detect the device, install the driver, and then for our app to detect the device. We don't want to make the user hold their finger over the button while all of that happens.

[skullydazed]

If that's the only use case you want to support why not fold it into the flash button?

In any case, that means we still need to build a mechanism to support the bulk loading use case. What's your suggestion to handle that?

[NoahAndrews]

That's a fair question. We should probably do that.

I'm thinking an "Advanced" button, that pops up either another (smaller) window with the bulk loading option or a menu with the option. Any thoughts on that?

[skullydazed]

That's one possibility. I'm not sure if that fits with the design paradigm we're using so far. I was considering the possibility of introducing bootstrap tabs and having an "Advanced" tab the user could flip over to.

I'm a little hesitant to implement this feature in a way that hides the fact it's enabled. That's part of why I like how the teensy loader has implemented it. I think having a toolbar across the top with one of the buttons being "Flash when ready" (teensy calls this "Auto" which is nice and concise) may be a good direction to move in. This is part of what I hinted at in the other thread when I said it may require waiting for more features to be implemented. Having a toolbar with one button seems somehow sub-optimal.

[NoahAndrews]

My thought was that the advanced button would go in the bottom left corner, in line with the others. ~Would that fix your concern?~ I like the tabs idea too, though I think it would perhaps add too much visual bulk.

Edit: I mistakenly thought your "having a toolbar with one button" statement applied to my advanced button at first. In what way do you think an advanced button doesn't fit with our design? It's less intrusive than adding a tab bar.

I'm a little hesitant to implement this feature in a way that hides the fact it's enabled.

You're referring to the bulk-flash feature here, right? I definitely agree. Maybe a slim banner across the top after each flash, saying something like "To flash another keyboard with this hex file, put it in dfu mode now."

The toolbar across the top of an advanced tab sounds good to me, aside from feeling mixed about a tab bar. What other buttons do you think belong there?

[NoahAndrews]

Haha, whoops. Let's reopen this issue, and rename it to "Bulk flashing mode"

[skullydazed]

Go github! :)

[skullydazed]

I apologize, I didn't do a particularly great job of maintaining separation between different ideas. My comment about not fitting into our current design paradigm relates to making a button pop up a window to enable it. That feels very "old school" to me and (as much as possible in a cross-platform toolkit) I'd like it to feel something like a native app on each platform. On the mac, clicking a button to open a preference window (rather that putting that into the QMK Firmware Flasher -> Preferences menu) would feel very odd.

I don't think we should mix tabs and a toolbar. I think it should be one or the other. I have been giving thought to both as a possibility.

For the toolbar, I envision possibilities like "erase", getting/setting fuses, and perhaps even displaying info provided through various dfu-programmer get commands. Perhaps one day in the future we even hide the large status window behind one of those buttons and make the UI more simple and less intimidating to non-technical users.

For tabs, we could have a Fuses tab, an Advanced tab, an Info tab, maybe even an Auto tab. You would pick the tab that matched how you needed the tool to operate that day. Perhaps the default tab is a very simple UI, but the Advanced tab lets you flash with all sorts of options like the auto mode.

[NoahAndrews]

Yeah, I think I agree with that. I think a dropdown menu from an advanced button (rather like Chrome's menu) would be a decent design though.

I think the advanced functionality like what you're saying would be in the toolbar should be hidden, so I'm not liking the idea of putting that toolbar on the main page. On the other hand, we could have a "show advanced toolbar" option in our advanced menu dropdown. ;)

I don't like the idea of a Fuses tab and an Advanced tab. If there's an advanced tab, that kind of implies that the other tabs aren't advanced, which a Fuses tab certainly would be.

I'm kind of starting to lean toward having the advanced menu with an "enable advanced mode" option. The bulk flash could also live in the menu, since it could be useful to someone who shouldn't be messing with all of the advanced options and doesn't want the full advanced mode. The advanced menu could also have an option to show the full status window, like we have now. I like the idea of the full advanced mode having tabs, but I'm undecided.

Sorry if I seem stuck on the advanced menu. I haven't seen another proposal that keeps the main page as clean as possible by default.

Edit: I think the "advanced mode" would be better called "Expert mode". It better says "Only go here if you know what you're doing" and it differentiates itself from the non-dangerous options in the advanced menu.

[skullydazed]

The particular collection of tabs can be changed. Likewise the particular collection of toolbar buttons. I think the bigger question to answer right now is whether one of those is the direction we want to move in.

I think figuring out what kind of user we're targeting will help a lot. The least technical user will never flash their keyboard. I hope they'll find this tool simple enough to use, but the chances they will even try are small. The most technical user will probably be using "make dfu" to flash their keyboard. That means we're targeting a goldilox zone of power users who are technical but probably aren't comfortable with the CLI.

I'm a big fan of discoverability. I'm also a fan of not using platform specific techniques if I can avoid it. When those two intersect, as they do here, I'm inclined to find the path that works for all platforms. Right now I'm leaning towards tabs as the right balance to satisfy both. We can change what these tabs are, even in the future, but here's another stab at what they might be:

• Flash - The default tab, what users see and the natural tab to click on if they accidentally click on another tab.
• Fuse - I think getting and setting fuses requires its own UI
• Expert - Auto mode, status box, etc, all available here

[NoahAndrews]

The particular collection of tabs can be changed... I think the bigger question to answer right now is...

Yeah, sorry. I was on a robotics team in high school, and I heard similar phrases fairly often. :P

I think figuring out what kind of user we're targeting will help a lot.

Agreed.

The most technical user will probably be using "make dfu" to flash their keyboard.

At least at this point in time, there are actually a lot of command-line-comfortable users using this tool because of the build and flashing situation on Windows. I'm one of them. The readme currently recommends to Windows 10 users that you build the hex file using the Windows Subsystem for Linux command line, and flash it using this tool.

That means we're targeting a goldilox zone of power users who are technical but probably aren't comfortable with the CLI.

In the future, this zone will presumably expand to include less technical users, if we add Teensy support (allows us to support Ergodox EZ users who are using this tool) and whenever you finish your own configuration tool. If you and Jack want to sell more keyboards, I suggest we focus on making keyboard customization as easy as possible, and that includes flashing. That's why I'm so resistant to making the advanced stuff too easy to get to. And it's not like a big button that says "Advanced" is hard to discover. We can also make it so that when the user switches to expert mode, that preference gets saved, eliminating the extra step in the future.

I'm still pushing for a simple mode that doesn't have tabs, but I do like tabs for showing the advanced stuff.

[skullydazed]

One of the reasons I started working on this tool was so that users of my (in progress) web GUI could flash their keyboards. I'm very sympathetic to the "keep it simple" argument. I also think that giving users discoverable hooks into your more advanced features, so that they know they exist when they're ready to try them, is important.

That's why I think it's important that it be easy to get back to the simple mode if you've accidentally clicked into the advanced mode. Tabs are a well known and cross-platform UI method that non-technical users are highly likely to be familiar with. If you accidentally click on Advanced, there's the Basic tab right there that they can find. You will always have some confused users, but I submit that tabs will confuse the fewest.

[NoahAndrews]

I hadn't brought it up, but the whole time I was thinking of a confirmation popup before the user would be allowed into expert mode. It could also inform them of an easily-visible button to bring them back to the standard interface.

Your arguments do make sense, and I'll accept tabs if I have to. It's just that I love the elegance of the current design, and I feel tabs would do a lot to make it uglier. Plus it reduces the chance of messing with dangerous options.

[skullydazed]

I just created #24 as a demonstration of the tabs interface. I think you'll find it's really quite simple, and that non-technical users shouldn't find it too difficult to figure out.

[NoahAndrews]

I do like that better than what I was envisioning (more like a browser tab). :)

I do have another suggestion though. If we're going with the tabs-up-front approach, I think we should try to keep it to just simple and expert. Maybe instead of a fuses tab, we have a "Configure fuses" button, that brings up a configuration interface, maybe in a modal. Any thoughts there?

[skullydazed]

This has been implemented in #36.