Make carb entry time configurable when entered via Watch (#608)

[mpangburn]

See #608
(Project will build with updated project.pbxproj)

[ps2]

Thanks @mpangburn!

The iPhone interface has some restrictions as to what times new carbs can be created. So we'd have to at minimum match those validation rules (or even make them tighter).

The UI has multiple buttons (one for changing day, one for changing minutes), and is more cluttered than it should be. I think we are really only interested in changing time (a few hours past or future) from the watch, and you only need one action to increment or decrement, with the crown being the most likely input mode.

Instead of a button labeled "Date & Time" in the carb screen, it could be titled with the current date, or the one changed by the UI

I'm not sure you need a whole new modal to enter date; the watchOS HIG is pretty clear: "Avoid displaying a second modal sheet from an existing modal sheet." https://developer.apple.com/watchos/human-interface-guidelines/app-architecture/modal-sheets/

Since changing date is a "pro feature" that the carb algorithm doesn't especially need, I'd leave it as more of a "pro experience" to use. Adding a date label with a little more padding where GRAMS is, and allowing it to be tapped to take over control of the crown (after tapping, change its background color or something to highlight) and allow tapping again to change focus back to changing the carb number.

Space is at a premium, so I'd recommend tapping on the carb number OR the date to do the same thing – switch the focus from one input to the other.

5 minutes as an increment isn't enough to "matter" to the algorithm; I'd recommend it be 10 or 15 minutes (though this is only for the +/- buttons; the crown input should move by single minutes so it feels fluid).

Also, the date/time formatters should be localized.

[mpangburn]

Thanks for your guidance @ps2! I've updated the UI to meet your suggestions:

• The date button on the carb entry screen now displays the current time (localized)
• Removed unnecessary modal sheet and InterfaceController
• Tapping on either the carb value or the date button will switch the focus from one to the other
• The focused button is indicated with the light green text color (with unfocused using white text)
• The digital crown will change the value of the focused button (carb or date)
• The +/- buttons only change the carb value (and are appropriately highlighted/unhighlighted with the carb value)--this felt appropriate given the layout, but if you'd like these buttons to change the date when it's selected I can make that little change

Re restrictions on new carb creation:

• Right now the time displayed will always be for the current day, i.e. if the user scrolls beyond midnight in either direction, it will use the displayed time, but still for the current day--but I don't think this is the ideal solution (see bullet 3)
• I originally had the date displayed to mimic the function of a UIDatePicker and cover the edge case of wanting to prebolus across midnight, but I agree with you that that design choice is cluttering
• Right now I'm thinking it might be best to have a time interval capping the date from changing too far in either direction (which would allow crossing over midnight if it's late enough), but I thought I'd check in with you as far as what that interval should be (3-4 hours?)

Let me know if you have any other suggestions. Thanks!

[ps2]

Thanks Michael I think this is a big step in the right direction.

The tap areas are a little too small. You can use a UITapGestureRecognizer for the whole area to act as a toggle. Tapping anywhere in the area would switch input mode.

Also the 'grams' label is causing clipping of some numbers. I'd vote for removing it in this context, and keeping the icons their full original size.

"The time displayed will always be for the current day, i.e. if the user scrolls beyond midnight in either direction, it will use the displayed time, but still for the current day". As you said, this isn't ideal. I think we have the current time restriction for the phone UI specified in LoopKit, so you could look it up there.

[mpangburn]

Per your suggestions:

• Tap gesture recognizer over the whole group now used for toggling input mode
• Grams label removed, restored size of buttons and carb label
• Updated UI to match your mockup (light gray text color for inactive label)

I somehow missed the carb entry date restrictions in CarbKit in my first revamp, but I caught them this time around. Aligning with carb entry via phone, users can enter a carb entry up to 4 hours in the future. There appears to be no restriction on past date in CarbKit, so I chose to use 8 hours for restricting entries in the past.

[ps2]

This is looking very close!

The 🍭, 🌮, and 🍕 buttons have their font size changed to 20/22. Please restore them to 25pt.

• Instead of creating a separate var activeValueLabel: WKInterfaceLabel! reference to keep track of which entry mode is active, it would be better code to define an actual enum, e.g.

enum InputMode {
        case value
        case date
}

Then you don't need default cases in your switch statements; your code is more readable due to your intent being clearer. Also, accessing activeValueLabel before func awake(withContext context: Any?) results in a crash.

• Minor question: is there any reason why the +/- buttons shouldn't also control the date when it is the current input mode? Some users may prefer on-screen buttons to the digital crown.

• Please revert the developer team changes

[mpangburn]

Sorry for my lag on finishing this up!
Should've looked at the project.pbxproj and storyboard diffs more closely--thanks for catching those pieces.

• Font size restored
• InputMode enum implemented
• +/- buttons can now be used to increment/decrement the date by 15 minutes (when the date was represented by a larger, separate button and the grams label was still there, using +/- to control the date felt unintuitive; this is no longer the case)
• Using guard in carbValue's didSet meant that it was possible to have a mismatch between the stored value and the value shown on the label if the user were to turn the crown fast enough; this has been corrected

Hopefully this just about does it!

[ps2]

Thanks! Looks great! I believe the build is just failing because TravisCI is still using Xcode 9.1 beta version.