Better Bangle.js dialogs?

[gfwilliams]

One of the things that hasn't been updated on Bangle.js is the dialogs - they're pretty much the same as they were on the first Bangle.js 1 and are looking quite dated:

It feels like it's high time they had a change. Obviously the fonts could do with improving, but does anyone have any ideas/suggestions for improvements? Screenshots/pictures would be great

My initial thoughts would be:

• 1 button: use bottom 1/3 of screen as a button
• 2 button: use bottom 1/3, split in 2
• 3-4 buttons: use bottom 1/2, split 2x2

[thyttan]

All for bigger buttons and I think your ideas sound good! :)

[WhelanB]

Great idea on improving the dialog! I wonder if moving away from buttons towards swiping gestures could be a way to reduce the chances of fat-fingering an option especially as the number of options increases?

I'm thinking of along the lines of how the messages app handles dismissing or acknowledging/replying to messages, so made some quick mockups to show my thoughts

Two options - swipe left/right to choose:

Three or more options - maybe swipe to choose between options, tap to accept?
Horizontal swipes:

Vertical swipes:

Horizontal swipes where you can see the next and previous options greyed out:

As the number of options increases beyond a certain size, it could even be possible to bring up a showMenu style option with choices to select, though that makes it tricky to have the dialog title/message and options all on-screen at the same time

Also, some more "Pebble-y" styles, but which don't necessarily fit with existing Bangle UI:

[gfwilliams]

Thanks! I'm in two minds about the swipe - it could definitely make sense in the 2 option case, but it might mean we're forced into using a smaller font for the buttons than we might have if we'd just had big buttons.

But yes, for greater than two options it feels like having it scroll would make a lot of sense (as long as it was clear to the user that more options were available offscreen)

[thyttan]

I'm more inclined towards the original proposal with buttons.

When there'd be more than 4 options I see three solutions:

• the 4th button says "More..." revealing additional options.
• maybe a showMenu call makes more sense?
• or we introduce scrollable buttons if more than 4 options?
  • I imagine horizontal scrolling in a 2-by-X grid or vertical scrolling in a Y-by-2 grid, with buttons roughly the same size as the 2-by-2 grid, but the off-screen buttons showing just slightly to indicate they are there.
  • If vertical scrolling is implemented the message on the top part of the screen could be scrolled up along with the buttons leaving more room for them.

(reposted outside of sub-thread...)

[WhelanB]

I did some toying around in the IDE and I'm inclined to agree that the visual of a button is a bit more obvious (when there are more than 2 options) that the user needs to tap on the button to make a selection over swiping and tapping. I wonder how often dialogs have more than 1-2 buttons and what kind prompts they ask.

I find the direct scrolling on the Bangle a bit annoying compared to the way Desktop Launcher or ClockInfos navigate, where a swipe immediately switches to the next "Page" or "Item" rather than freescrolling - it just feels a bit more finicky to me when I'm trying to use the watch on my wrist to have to keep dragging to move along the list.

Here's another little experiment, where there are buttons with the ability to move left/right to navigate them. I liked this, but it also felt like a lot of swipes to get along the list compared to having multiple buttons on screen at one time, especially if the buttons were bigger and evenly sized/spaced unlike the current dialog. Throwing it here just to spark some thoughts 😄

I also think it could be interesting to consider what customising the buttons (rounded, colours, icons?) could do, without packing too many features into the dialog - for example:

[thyttan]

I find the direct scrolling on the Bangle a bit annoying compared to the way Desktop Launcher or ClockInfos navigate, where a swipe immediately switches to the next "Page" or "Item" rather than freescrolling - it just feels a bit more finicky to me when I'm trying to use the watch on my wrist to have to keep dragging to move along the list.

I held this sentiment as well and that's why I made Swipe Menus which changes scrollers to jump discrete steps on swipes much like desktop launcher. I've since started using Kinetic Scroll instead though. Maybe you'd find one of those useful.

[gfwilliams]

Hi,

I've been having a play around too, using the 2 wide buttons idea:

Personally, I think this looks quite promising. I feel like swiping between >2 options is a no-go - compared to actually seeing everything on the screen, having to swipe multiple times to see all the options before you select one seems needlessly painful.

The custom buttons is an interesting idea. Right now, with the existing showPrompt implementation you can supply 'inline images' for buttons:

E.showPrompt("Image Test", {
  buttons : { "\0\x18\x18\x81\0\0\0\0\0\0\0\0\x18\0\x0E\x18p\f<0\x18\xFF\x18\x19\xFF\x981\xFF\x8C3\xFF\xCC3\xFF\xCC\3\xFF\xC0\3\xFF\xC0\3\xFF\xC0\3\xFF\xC0\3\xFF\xC0\3\xFF\xC0\7\xFF\xE0\x0F\xFF\xF0\x0F\xFF\xF0\0\0\0\0<\0\0\x18\0\0\0\0\0\0\0 Alarm!" : 1}
});

So I feel like that works well where needed - I guess we could have an option not to paint in the button surround, or maybe for a custom renderer function?

... but I think it's probably not really needed - it seems there's be very few uses of this - if most people want something custom they'd just write their own function to draw the screen.

[gfwilliams]

I've just pushed some changes, which you can now try out in Bangle.js builds.

I've added 4 new fonts based on the https://github.com/pebble-dev/renaissance, much like in espruino/BangleApps#3109

.. but I've also added a built in 'g.findFont' function which finds the best font to go in a certain area, and have updated showPrompt/showAlert/showMessage/showMenu to use it, so you should see a pretty big improvement in things like the Setting menu right away.

I'd hoped that it could be somehow done in JS like @Chriz76 did so it was easy to have different font packs but I think the speed hit is just too high.

I'd be interested to hear thought on this... I still need to do a bit of work on vertical alignment of the fonts I think - it's definitely not perfect by any means.

[retcurve]

I think it looks great, particularly with the new fonts. Personally I don't think that trying to support more than 4 buttons is something that needs to be handled in a dialog because by that point a menu or layout should really be used.

The only app I've been able to find that uses more than 3 buttons is sleeplog, which has 5 buttons that in the previous firmware just about manage to squeeze in along the bottom of the screen and clicking the buttons updates the prompt text to select a day. In the new firmware the prompt text will be completely covered making date picking impossible. This is something that would be better suited to a layout rather than a prompt but I can see why it's been done as a prompt for simplicity.

[gfwilliams]

Thanks for looking into the usage of showPrompt. I think as a fallback showPrompt calling into showMenu is probably pretty sensible - I'll get that put in. For sleeplog the buttons are small enough that I guess it could be implemented as 3x2 buttons in showPrompt, but that does feel like a bit of a special case that maybe we shouldn't handle...

[thyttan]

I agree with @retcurve - looks great! And it feels like scrollers are snappier with the new fonts?

If I'd have one suggestion, it's I notice I'd probably prefer even slightly higher buttons. At least if there's only one row, i.e. one or two buttons. Just to make it feel like I nearly don't need any precision at all when hitting a button. But I realize it's a trade-off with the header and body font sizes also.

[gfwilliams]

Thanks - yes, that makes sense, I'll bump the size a bit. One thing I did do with the buttons is make sure that a tap right on the bottom triggers them, so at least when it's only 2 buttons you can be pretty sure of hitting them just by tapping on the bottom left or right.

[gfwilliams]

Just pushed a change - and I've made it handle 3x2 buttons for those rare cases now, just so sleeplog is ok.
It's possible it is marginally faster as now native code can handle the font selection, but the more characters the slower it'll be as it's having to try out multiple different fonts all the way down until something fits.