UI Feedback about androidaps

[MilosKozak]

A few comments from my side and what I've learned:

• you can never fulfill needs of all
• "Make it optional" is a way to hell. It will lead to xDrip syndrome. No one knows what all settings means. As a compromise I allowed layout selection where everyone can choose what fits best
• Increasing number of layouts is last resort. We already had it and maintain all layouts was a real pain
• I already tested BT status text in appearing/disappearing line and it's not possible to watch jumping screen as it's not once up and once disappear. And keeping it all the time is just wasting of space.
• Top menu has larger spacing if you don't choose short texts
• Notification has text button because there was/is a plan to have notification with more actions
• Shortening text with dots inside to fit text box would be really hard to implement
• Bottom buttons have text because quick wizard displays continuous result there
• I understand people like scrolling graph like in xdrip. But nobody thinks about the data. AAPS calculates data about 24h+ back. If you need more data back just try history browser to see how "realtime" calculation realy is ...
• Temp target dialog with buttons i find possible. But questions is if keep these options in popup menu and if these buttons should be single click like OK or just prefils of values

In general:

• i'd go way of reducing options in most used dialogs, screens etc. It makes it easier to use and reducing potential mistakes

What I'm missing in UI is a mark what is possible to click/long click. I'm not a designer and never be but still everything in AAPS has it's own reason ...

[osodebailar]

@Philoul I will have a look onto it tomorrow and see what’s the best to align icons vertical

[jamespaulley]

Sorry if you've already read this but these are my thoughts.

Menu. Whatever you think is best. Yes, on a small screen there should be the ability for the user to close the menu, whether that's a back button or a greyed-out area behind the menu.
TT Icons. Personally I feel like the iconography is getting too complex and confusing to look at. I think something like the icons below might be better. I think that 'cancel' should be first or last in the row, and should be a grey colour. I appreciate your take on the colours, but I think the colour theory throughout AAPS is a bit of a mess and as long as the colours of these new elements aren't immediately confusing I don't think we should worry about the consistency of the colours too much. I appreciate that the crosshairs icon is a bit aggressive, but I think it portrays 'target' more clearly than the waveform icon. I think the waveform icon is confusing as it looks like an audio waveform, and the straight lines look like basal rates.
Edit: Sorry, forgot the link:
https://imgur.com/HDyaGaE

[mistermintsgh]

Whilst I love 2.8 and the changes that have come with it (especially Omnipod implementation!) I must admit, I hate the new TT system and menu.

What is welcome, is moving it away from the long press menu (I can't tell you how many times my fat fingers had previously attempted to set an exercise target, accidentally hit eating soon target, and I've ended up with a reasonably large SMB being delivered which then scuppers my plan for exercise).

However, I don't like, once you're into the TT menu screen, that pressing one of the TT buttons just sets it. What I liked on the previous version was that by selecting the TT I wanted (after long press > Custom > select from dropdown) it would then auto fill in the target and duration boxes for me. Now, I don't always want to set a 90 minute Exercise TT, or a 60 minute Eating Soon TT, but by selecting those from the menu half the job was done and I just had to then set the duration if I wanted it to be different from my default for that TT. With the current implementation if I press a TT button, it sets it. If I try to select a TT option from the reason dropdown, all it does is put the reason in the box, but doesn't auto fill the target an duration boxes.

Unless this is a bug with 2.8, it feels like a step back if it has deliberately been designed this way.

And that's before I get started on "press OK to cancel" when there is also a Cancel button on that dialogue box!

[mistermintsgh]

I like these!

Can I also add to this list... I HATE the 3 dot menu in the top right hand corner. I have no mobility issues or anything like that described above, but I cannot tell you how often I go to press those 3 dots and end up somehow pulling down the notification/quick settings menu of my phone.

This happens all the time for me, but it is even more annoying in the middle of the night when I'm still half asleep and I get a pump disconnect alarm that can only be fixed by exiting AAPS and opening it up again. Its tough to be able to focus when you're half asleep, in the dark, trying to press the smallest of buttons on the menu to get your pump functioning again.

[Philoul]

@jamespaulley I think it is necessary for security reasons to avoid any single click without confirmation (I do not count the number of unwanted calls and even SMS sent by my pocket!)
=> unwanted several short presses everywhere on the screen are very frequent... The idea of setting a temporary profile with a single press on +10 and tempo is definitively too dangerous ...
=> I never had an unwanted "Long Press"

I understand that it can be difficult for shaky hand to long press on small zone on the top of the screen, but may be a good compromise could be:

• to keep the long press but to double the heigth of the zone to make it easier
• to replace the 2 menus (profile and targets) by temporary buttons with single press action (as you proposed) but only shown after the long press on upper zone... (according to zone you pressed you only show target buttons or profiles buttons)

@mistermintsgh For the three dot button, if it's only to have an easy way to restart AAPS, there are several devices that restart after a very long press on power button (phone, computers, ...)
=> If we keep this idea a "very long press" (about 5s for example) on the loop status zone (big zone just below profile and target buttons) could be used to show a popup to confirm or not a restart of AAPS...

[mistermintsgh]

@Philoul it's not just used to restart AAPS though, it's used to access any of these options

My point being that the button is tiny, and it's far too close to the notification bar to be able to bit with any kind of precision.

As I said above, I particularly struggle if I'm half asleep, but I also struggle sometimes in the middle of the day when I'm fully awake!

It just needs to be bigger, or in a better position

[swissalpine]

There are larger buttons for temp target and profile switch in the actions tab ... No need to put them on the Home tab. Afaik all preferences can be reached via the config builder.
And: If you enter the number directly in the dialogs, and not via the small +/- keys, the number keyboard will open. This one has quite large numbers ... Of course this is not the one click solution you have in mind - but beside that I don't see the problem.
And: On small devices isn't enough place to put additional buttons on the home screen without loosing the main graph.

[jamespaulley]

Okay great feedback guys thank you. A few things are being discussed now. I'll summarise everything below. Please also see the attached PDF for mockups and explanations of everything.

https://drive.google.com/file/d/1LD6uBF8oItpcF1L3NqemBBV_qnc9hl1N/view?usp=sharing

Spacing issues at top of Overview Screen

• The spacing is too tight at the top of the Overview screen. It’s hard to use. As mentioned by @mistermintsgh.
• There needs to be more space around the “...” menu.
• The tabs area needs more spacing top and bottom.

Concern regarding accidental single-clicks triggering dangerous action

As mentioned by @Philoul.

• We can forget the idea of having buttons that immediately trigger a profile change, I agree.
• I think immediate buttons for Temp Targets might still be useful, but I'm happy to drop that for now.

Long press throughout the UX

• I think long-press is bad UI/UX and we should have the option of not using it. People who want it can keep it, but I don't think users should be forced to use it.

Buttons on Overview screen

• I think we should have the option of placing Profile Switch and Temp Target buttons on overview screen.
• Two rows of buttons would be nice, for people with large screens. People with smaller screens can choose to use only one row, and decide which buttons appear.
• I understand these buttons already exist on the Actions screen, as mentioned by @swissalpine , but it would be convenient to have the option of also placing them on the overview screen. It would reduce the number of swipes and clicks needed to access the features, that many people use very frequently.
• I realise you can long-press the text at the top to access these features, but that top area is very badly designed: the areas are too small to function nicely as buttons, and long-press is not good UI/ UX. It’s fine to have it as an option for those who like it, but I think there should definitely be the option of not using long-press, too.

Temporary Target Interface

• Have buttons that quickly populate the target field, similar to the buttons seen on the Carbs and Insulin interfaces.
• The current dropdown menu next to “Reason” is too small and fiddly to use.

Profile Switch Interface

Can we have the option of the “+/–” buttons next to “Percentage” go up and down in intervals of 10%, instead of 1%.

Loop Button long-press issue

• Can we have the option of the Loop button not being long-press. So it opens the loop menu immediately when pressed, like a normal button. In the same way that the IOB and Basal buttons work.
• Maybe we could have a preference toggle to enable/disable long-press, but I don’t think anyone should have to use long-press if they don’t want to.

[Philoul]

Thank's @jamespaulley for this detailled synthesis

• For Loop button, if we replace long press by a short one, I think it's necessary to add a confirmation popup because the area that can launch an action is too important (click a second time somewhere in half the screen is enough to disconnect, suspend or disable loop...)
  => All buttons with single press action are followed by a confirmation popup with a small zone (Ok / Cancel)
  => So if we modify this, we should replace a long press and a short press by 3 short presses (like it is done today for bottom buttons)
• For profile switch I think it's a very good idea and it is easy to modify (it's always possible to select field and manually enter another value)
• For Target popup, today the "menu" prefilled the values AND select the reason of the TT (with "Manual" reason as default), so if we replace selection menu, we have to add an additional information into the popup to show selected reason of the TT (I think it's a good idea too)
• Concerning resolution, we initialized a low res skin in dev, so it's possible to have a specific layout for these phones (ex Atom) with for example less buttons in overview than in high res phones. But I don't think it's a good idea to add additional settings to customize interface (long press or not, additionnal zone for buttons or not...), the more we add settings, the more it's complicated to setup preferences...
• On bottom buttons, we have 3 buttons that are close: Treatment, Insulin and Carbs. On my side I never show treatment button because it's not the equivalent of Insulin + Carbs buttons (with carb you can enter slow carbs, with insulin and Carbs you can select a reason, enter carbs/insulin in the past, you have increments buttons). If we make a complete "merge" of Carbs + Insulin popup in a new treatment popup with all functions, we can replace 2 or 3 buttons by only one (and remove settings in preferences or replace them by TT and Profile Switch buttons...)

[mistermintsgh]

Suggestion on the profile switch:

• Make it customisable

In the same way I can edit the quick bolus settings (I've edit the small bolus to be 0.25U, the medium bolus to be 1U, and the large bolus to be 2U) it would be could to be able to edit the +/- percentage too. Some might want 5%, some 10% some 20%. Let us choose, through the settings, which quick profile switch we want.

[jamespaulley]

Loop Button

I agree that short-presses with a confirmation dialogue would be preferable over the current long-press behaviour, as described by @Philoul. My personal opinion is that 3 short presses is safer than a long click followed by a single click, but I appreciate that others might feel differently. Some users might like the long-press behaviour, so ideally there would be a settings preference for this.

Profile Switch

Exactly, @Philoul. I also like @mistermintsgh's suggestion for customisation of the percentage intervals for the "+/–" buttons on the profile switch screen.

Temp Target Popup

Exactly as described by @Philoul. Alternatively, we could leave the drop-down in place and provide the buttons as well, as seen below.
https://i.imgur.com/Txph56A.png

Resolution and display density

@Philoul points out that if we add too many settings to configure the interface, it'll get too complicated. That's fair enough. I think having a low-density skin as mentioned is good, and it doesn't need to be over complicated with loads of config options. But I don't think users with normal screen sizes should be suffering with cramped UI.

• I think users with tiny screens could have the option to disable certain elements from the Overview Screen, if they want to, to create more space.
• I think small phone screens should utilise vertical scrolling, instead of cramping and squashing the elements to fit on screen all at once.
• Small phone users should utilise horizontal scrolling between the "tabs" to access functions.

Bottom Buttons

I agree with @Philoul that the current Treatment Button is scarcely useful and could probably go. I also think the button sizes could come down a touch and be graphics-only, to optimise space. The buttons shown should be selectable by the user. Example of how this could look:
https://i.imgur.com/wuDHBxb.png

Treatments UI

I like the idea of combining the Insulin and Carb UI into one screen. Suggestion below:
https://drive.google.com/file/d/1CVvChtSMW29Os_z1wUXM-1i-WSSPEOOd/view?usp=sharing

Popup appearance

I wonder if having the 50% transparent overlay around the popup windows for Bolus Calc, Carbs, Insulin, etc is a bit confusing. You can't actually click the transparency to close the popup, and it feels a bit messy. I think solid backgrounds and a back button would be cleaner, as seen in the above PDF.

Top Notification area and other UI tweaks

Few other UI suggestions, bulleted below and illustrated in the following PDF:
https://drive.google.com/file/d/1AinMDHXaWuca7ViQX6mOImkFnyoVjYsc/view?usp=sharing

• Top Status area.
  • The Profile and Target buttons/zones need to be larger, if they are to remain as clickable buttons. If these are nice, large, single-click buttons we might not need to create buttons for these functions at the bottom of the screen. If they don't need to be buttons and can be replaced with buttons at the bottom of the screen, they could remain fairly small.
  • The layout of the info to the right of the BG value needs tidying up
• Bluetooth status text
  • Currently the bluetooth status text obscures the Profile and Target buttons. This is bad UI. I suggest the bluetooth status simply pushes the Overview Screen down when it appears.
• In-app Notification
  • The in-app notification is a bit of a mess in how it behaves. I think the way it works in relation to the Android system notifications might need to be tweaked. But for now, I think it could at least look nicer, be larger and have an easier to press "close" button.

[guydavies]

I would prefer all.those changes to be optional. I like the system as it is.

…

On Tue, 17 Nov 2020, 12:10 jamespaulley, ***@***.***> wrote: *Loop Button* I agree that short-presses with a confirmation dialogue would be preferable over the current long-press behaviour, as described by @Philoul <https://github.com/Philoul>. My personal opinion is that 3 short presses is safer than a long click followed by a single click, but I appreciate that others might feel differently. Some users might like the long-press behaviour, so ideally there would be a settings preference for this. Profile Switch Exactly, @Philoul <https://github.com/Philoul>. I also like @mistermintsgh <https://github.com/mistermintsgh>'s suggestion for customisation of the percentage intervals for the "+/–" buttons on the profile switch screen. *Temp Target Popup* Exactly as described by @Philoul <https://github.com/Philoul>. Alternatively, we could leave the drop-down in place and provide the buttons as well, as seen below. https://i.imgur.com/Txph56A.png *Resolution and display density* @Philoul <https://github.com/Philoul> points out that if we add too many settings to configure the interface, it'll get too complicated. That's fair enough. I think having a low-density skin as mentioned is good, and it doesn't need to be over complicated with loads of config options. But I don't think users with normal screen sizes should be suffering with cramped UI. - I think users with tiny screens could have the option to disable certain elements from the Overview Screen, if they want to, to create more space. - I think small phone screens should utilise vertical scrolling, instead of cramping and squashing the elements to fit on screen all at once. - Small phone users should utilise horizontal scrolling between the "tabs" to access functions. *Bottom Buttons* I agree with @Philoul <https://github.com/Philoul> that the current Treatment Button is scarcely useful and could probably go. I also think the button sizes could come down a touch and be graphics-only, to optimise space. The buttons shown should be selectable by the user. Example of how this could look: https://i.imgur.com/wuDHBxb.png *Treatments UI* I like the idea of combining the Insulin and Carb UI into one screen. Suggestion below: https://drive.google.com/file/d/1CVvChtSMW29Os_z1wUXM-1i-WSSPEOOd/view?usp=sharing *Popup appearance* I wonder if having the 50% transparent overlay around the popup windows for Bolus Calc, Carbs, Insulin, etc is a bit confusing. You can't actually click the transparency to close the popup, and it feels a bit messy. I think solid backgrounds and a back button would be cleaner, as seen in the above PDF. *Top Notification area and other UI tweaks* Few other UI suggestions, bulleted below and illustrated in the following PDF: https://drive.google.com/file/d/1AinMDHXaWuca7ViQX6mOImkFnyoVjYsc/view?usp=sharing - *Top Status area.* - The Profile and Target buttons/zones need to be larger, if they are to remain as clickable buttons. If these are nice, large, single-click buttons we might not need to create buttons for these functions at the bottom of the screen. If they don't need to be buttons and can be replaced with buttons at the bottom of the screen, they could remain fairly small. - The layout of the info to the right of the BG value needs tidying up - *Bluetooth status text* - Currently the bluetooth status text obscures the Profile and Target buttons. This is bad UI. I suggest the bluetooth status simply pushes the Overview Screen down when it appears. - *In-app Notification* - The in-app notification is a bit of a mess in how it behaves. I think the way it works in relation to the Android system notifications might need to be tweaked. But for now, I think it could at least look nicer, be larger and have an easier to press "close" button. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAS7B3Q6EEXUDHVPYPI5RQTSQJK2VANCNFSM4TTONRAQ> .

[4RK4N]

personally i wouldnt need those buttons either. im fine with overview long presses or actions tab for that. actions tab does exactly that alrdy. just add it as tab and swipe right once u have ur buttons for profile change and temp target.
besides they, sry to say it that way, look like pure eye cancer. (means they are really ugly)
adding those button only makes the problem worse.

[Philoul]

@jamespaulley

Treatments UI
I like the idea of combining the Insulin and Carb UI into one screen. Suggestion below:
https://drive.google.com/file/d/1CVvChtSMW29Os_z1wUXM-1i-WSSPEOOd/view?usp=sharing

Main idea is here, but interface has to be a little bit different to manage correctly "Record Only" for insulin and "Event Time" (and "Activity", "Eating Soon" and "Hypo" selection should be hidden I think for "record only" events)

[swissalpine]

The proposal "Treatments UI" isn't possible on low res screens. Please let this untouched!
Here is the actual look on an Unihertz Atom:

[Philoul]

@swissalpine I understand that the merge of Carbs and Insulin layout isn't possible on atom, but we can keep the 2 buttons (Carbs and Insulin) seperatly for low res phone like atom.
What do you think concerning the other points discussed here with your Atom ? (difficulty for short press on 3 dots button, difficulty for long press on profile or Target buttons to show menu, proposal of increase the heights of these zones, remove text on bottom buttons...)
=> Can you share several screenshots of your main screen (max number of bottom buttons according to you, heigth of upper zones, loop button's menu after a long press...) (when I run emulator I don't have same size than in your phone, so it's difficult for me to simulate results...)
=> For layout organization (size of each zone,) it's some work, but quite easy to have a dedicated layout for low res phone (size of buttons, length of strings..), but I think it's better to have the same global strategy for all skins (long or short press on buttons...)

[swissalpine]

@MilosKozak Thank you for your clear statement, which I fully agree with, as far as I can judge.

@Philoul In the zip-file you will find the screenshots you want. They also show how difficult changes are when you want to have all possible displays in view ...
By the way, I made the following adjustments for the atom in the file SkinLowRes.kt (150 instead of 100, delete isSmallHeight9:

@Singleton
class SkinLowRes @Inject constructor(private val config: Config): SkinInterface {

    override val description: Int get() = R.string.lowres_description
    override val mainGraphHeight: Int get() = 200
    override val secondaryGraphHeight: Int get() = 150

    override fun overviewLayout(isLandscape: Boolean, isTablet: Boolean, isSmallHeight: Boolean): Int =
        when {
            config.NSCLIENT && isTablet  -> R.layout.overview_fragment_nsclient_tablet
            config.NSCLIENT              -> R.layout.overview_fragment_nsclient
            isLandscape                 -> R.layout.overview_fragment_landscape
            else                         -> R.layout.overview_fragment
        }
    override fun actionsLayout(isLandscape : Boolean, isSmallWidth : Boolean): Int =
        when {
            isLandscape || !isSmallWidth -> R.layout.actions_fragment
            else                         -> R.layout.actions_fragment_lowres
        }
}

Profile and Target Buttons have an extra padding and a bigger font size..

[jamespaulley]

personally i wouldnt need those buttons either. im fine with overview long presses or actions tab for that. actions tab does exactly that alrdy. just add it as tab and swipe right once u have ur buttons for profile change and temp target.
besides they, sry to say it that way, look like pure eye cancer.
adding those button only makes the problem worse.

Thanks for the input. It is understood that many users are happy with using the Actions page as you describe, but some users will want faster access to certain functions on the Overview screen, so this is about whether we can build this optionality in to AAPS without creating complexity. Just to be clear, what are you saying looks like "pure eye cancer"? Please keep your language professional, by the way.

@jamespaulley

Treatments UI
I like the idea of combining the Insulin and Carb UI into one screen. Suggestion below:
https://drive.google.com/file/d/1CVvChtSMW29Os_z1wUXM-1i-WSSPEOOd/view?usp=sharing

Main idea is here, but interface has to be a little bit different to manage correctly "Record Only" for insulin and "Event Time" (and "Activity", "Eating Soon" and "Hypo" selection should be hidden I think for "record only" events)

Yes this is just a very quick mockup and more consideration would have to go in to any final design, should this idea be explored further.

The proposal "Treatments UI" isn't possible on low res screens. Please let this untouched!
Here is the actual look on an Unihertz Atom:

It's really important that we cater for users of small screens and make sure any designs collapse/adapt responsively to small screen sizes. But we should also cater to larger screen sizes too. Any changes made to the interface should accommodate all screen sizes. So for example, if we did create a unified treatment screen, it could be an optional screen, that users of small screens could simply choose not to enable or use, as mentioned by @Philoul. The trick is balancing this optionality whilst not creating overly complex settings for the user. Also, I personally feel that the combined treatments UI is not a particularly important change, so I'm not pushing that hard for it, but people do seem interested in the idea.

@MilosKozak thank you for all your points. I'll expand on a few of them below.

• "Make it optional" is a way to hell. It will lead to xDrip syndrome. No one knows what all settings means. As a compromise I allowed layout selection where everyone can choose what fits best

Absolutely. We should be careful to not create too much complexity. I think simple options, such as how we can currently choose which "buttons" appear on the Overview Screen should be fine. I think instead of trying to create multiple designs or skins for different phone sizes, we should have a single design that reacts responsively to different screen sizes. Instead of giving users many options to change the look and sizing of the layout, the user should have simple options to choose how many elements and buttons to include on the Overview screen, similar to how the user can currently choose which plugins to display via the Config Builder. Essentially the user just chooses how many things appear on their interface. I think having one simple "Compact Layout" or "Standard Layout" setting is a reasonable compromise, similar to the display density setting in Gmail, for example. The "compact" layout would essentially have less padding around elements and slightly smaller UI elements throughout.

• I already tested BT status text in appearing/disappearing line and it's not possible to watch jumping screen as it's not once up and once disappear. And keeping it all the time is just wasting of space.

Noted. Suggestions: Place text at bottom of Overview Screen. Or relocate it to Loop menu. Examples shown here:
https://drive.google.com/file/d/1AinMDHXaWuca7ViQX6mOImkFnyoVjYsc/view?usp=sharing

• Notification has text button because there was/is a plan to have notification with more actions

Okay, no problem. I think the button just needs more padding and spacing.

• Temp target dialog with buttons i find possible. But questions is if keep these options in popup menu and if these buttons should be single click like OK or just prefils of values

Yeah good questions. Personally I would replace the drop down menu. I would also have the buttons immediately enact the Temp Target and open an "OK/CANCEL" dialogue.

What I'm missing in UI is a mark what is possible to click/long click. I'm not a designer and never be but still everything in AAPS has it's own reason ...

Essentially, long press is like right-click on a desktop. So it's additional and secondary functionality hidden behind a single-press button. Nothing should be primarily long-press. From Googles guidelines, "long presses can reveal additional modes and features, but are not easily discoverable". More on that here:
https://material.io/design/interaction/gestures.html#types-of-gestures

[Philoul]

Essentially, long press is like right-click on a desktop. So it's additional and secondary functionality hidden behind a single-press button. Nothing should be primarily long-press. From Googles guidelines, "long presses can reveal additional modes and features, but are not easily discoverable". More on that here:
https://material.io/design/interaction/gestures.html#types-of-gestures

Interresting link, thank's
We have an illustration of the "Swipe / Don't section" in AAPS interface with Automation screen (Swipe between screens and delete a rule)

Don't
Avoid situations where a single gesture might produce two different results.
https://kstatic.googleusercontent.com/files/d2d7b6dce2efa234cb0b51a0576fb7cfef2a80b0cacc7bb6a23f10537924575a5a03aaed0f0ec143d91ae1c15c3a15fc7e0704ca0c7826fa231ded1e87aa09c0

@MilosKozak what was the reason of this modification ? (in previous versions there was a dedicated button to delete a rule in automation layout...)

@swissalpine I don't find your zip with screenshots. I read (but I can't remember where) that in some plugin screens, we could have buttons unreachable on low res phone because outside of the screen, If you have this kind of issue can you include screenshots too, that way I will be able to propose update for low res skin in parallel of this discussion...) (Can you update dev-mod5 branch too with your latest modification please, it's easier for me to find all modifications done on your side...)

[swissalpine]

@Philoul No, I don't have this issue (unreachable buttons) but I'm not shure if I have done some fixes. Important was to change the font sizes from sp to dp because the Android text size settings crashes the layout.
Sorry for the missing zip-file ... If you need more screenshots, please tell me.
My repo will be updated soon.
atom-screenshots.zip

[MilosKozak]

@MilosKozak what was the reason of this modification ? (in previous versions there was a dedicated button to delete a rule in automation layout...)

they were too close, hard to click one

[guydavies]

I have to admit that the swipe to delete is *really* annoying when you have swipe to move page left/right in all other pages (and on any empty space at the bottom of this page). I think that the button (even if small) was the better option.

…

On 19 Nov 2020, at 13:39, Milos Kozak ***@***.***> wrote: @MilosKozak <https://github.com/MilosKozak> what was the reason of this modification ? (in previous versions there was a dedicated button to delete a rule in automation layout...) they were too close, hard to click one — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAS7B3WFX7P3CCN6FXAORMTSQUGY7ANCNFSM4TTONRAQ>.

[Philoul]

@swissalpine very interesting your note concerning text size:

Important was to change the font sizes from sp to dp because the Android text size settings crashes the layout.

The recommendation is to use sp for text and dp for everything else, but this recommendation is to adjust text size according to android text size selection. This is important when you have a lot of text to read but could have side effects for "dense" layouts with lots of icons, graphs and text built and adjusted with default font size (see screenshot below, with default font size on the left and min/max selection on my phone).
Even on small resolution screen, @swissalpine probably increased text size in android settings but prefer dp to avoid side effects on its layout...

I think we can keep sp for tablet's layout (big size and it might be worth to reduce text size to avoid huge text in interface) but use dp in all other layouts to be sure to keep layout as it was designed whatever text size selection in device.
(On my side I confirm this side effect on watchfaces too if you increase default text size in watch...)
Most of users that don't change android default settings won't see any changes, but it could improve interface for those who change it...

[osodebailar]

Have you test icon texts in other languages ?
Too much word wrapping in button text , maybe in other languages , is not very useful for a good UI Design. If you have not enough space it is better to see no text.
Or place the buttons in 2 rows.

[Philoul]

@osodebailar in proposed PR, labels are only in Landscape and Tablet mode, I removed labels for standard portrait layout.
But I think we could add "Short Label" strings for low res
Can you help me to solve default in screenshot below (when we have quickwizard, with a label, bottom margin of left icon is too important and icons of other buttons are aligned top and I don't know how to keep every icons vertical align center)

[osodebailar]

@Philoul the best way to center icon in layout_no_label is to use an Imagebutton.
The disadvantage is you need a seperate SingleClickButton (SingleClickButtonImage) ansd seperate code parts.

[jamespaulley]

@Philoul the best way to center icon in layout_no_label is to use an Imagebutton.
The disadvantage is you need a seperate SingleClickButton (SingleClickButtonImage) ansd seperate code parts.

What is being discussed here, sorry? Is it how to handle the design of the text in the Quick Bolus button?

[Philoul]

@jamespaulley no, it's the other buttons with no labels.
=> I removed label, so we can add one or two additional buttons easily.
It's ok when quickwizard is not shown but when we have it, the icon on other icons is not centered vertically (see in screenshot insulin or carb icons).
@osodebailar thank's, I'll try to do that.

[jamespaulley]

@Philoul Suggestion: Get rid of the pretzel icon in the Quickwizard button? Then everything can be centred?

[Philoul]

@jamespaulley I think it's better to keep quickwizard icon (I reduced it's size). Vertical alignment is now corrected see #76 (comment), thank's @osodebailar , it works, can you verify if you think it's "clean" for code maintainability?

@MilosKozak or @osodebailar In my PR I added an OK/CANCEL popup for testing overview layout with only a "short click" to display Loop or Profile/TT menus, but I don't know how to replace the current "Long Press" by a "Short Press"... Can you help me ?

[mistermintsgh]

Another thought, this time for the calculator. I believe the iOS app Loop has a Pizza button, and I think something similar would be useful in AAPS.

What got me thinking about this was a post in the FB group today where someone has set their dose to be 60% via Plugin Preferences > Advanced Settings.

Someway to have a screen that allows me to enter bolus, carb amount, carb duration, and an upfront bolus as a percentage would be useful.

It may already exist, and I'm just doing things wrong, but as I see it at the moment I need to manually workout split dose percentages, flip to another screen/button to add extra carbs or carb duration and so on. Why not have a calculator that allows me to enter all carbs, and split them to extend, and split the bolus with a percentage up front and so on. Why add the complexity of working out what X% of Y grams is to bolus for, and then an extra step to extend carbs over several hours?

[Philoul]

Hi all,
I have finished to worki on this PR #76 (not all but most of above proposals are included)
I would appreciate comments and feedbacks
Thank's

[Philoul]

@jamespaulley I think most of proposals discussed here are now included in dev branch.
Do you think it's necessary to keep it open ?

[jamespaulley]

@Philoul sorry for being away. Just replied in the other thread.

[MilosKozak]

Another thought, this time for the calculator. I believe the iOS app Loop has a Pizza button, and I think something similar would be useful in AAPS.

What got me thinking about this was a post in the FB group today where someone has set their dose to be 60% via Plugin Preferences > Advanced Settings.

Someway to have a screen that allows me to enter bolus, carb amount, carb duration, and an upfront bolus as a percentage would be useful.

It may already exist, and I'm just doing things wrong, but as I see it at the moment I need to manually workout split dose percentages, flip to another screen/button to add extra carbs or carb duration and so on. Why not have a calculator that allows me to enter all carbs, and split them to extend, and split the bolus with a percentage up front and so on. Why add the complexity of working out what X% of Y grams is to bolus for, and then an extra step to extend carbs over several hours?

this is against how OpenAPS works

[mistermintsgh]

Another thought, this time for the calculator. I believe the iOS app Loop has a Pizza button, and I think something similar would be useful in AAPS.
What got me thinking about this was a post in the FB group today where someone has set their dose to be 60% via Plugin Preferences > Advanced Settings.
Someway to have a screen that allows me to enter bolus, carb amount, carb duration, and an upfront bolus as a percentage would be useful.
It may already exist, and I'm just doing things wrong, but as I see it at the moment I need to manually workout split dose percentages, flip to another screen/button to add extra carbs or carb duration and so on. Why not have a calculator that allows me to enter all carbs, and split them to extend, and split the bolus with a percentage up front and so on. Why add the complexity of working out what X% of Y grams is to bolus for, and then an extra step to extend carbs over several hours?

this is against how OpenAPS works

If it's against how OpenAPS works, why can't OpenAPS be changed? That response just sounds like "it doesn't work that way, I don't want to explain why it doesn't work that way, and no changes will be made".

Why can't user assistance functions be added, regardless of whether this is how OpenAPS works or not? The system should be as easy to use as possible for the end user, and Loops gets a lot of praise for this and its UI, whereas AAPS, to be honest, looks very complicated and dated.

[jamespaulley]

@mistermintsgh When Milos gives a short reply, it's only because he is extremely busy and can't spare the time to go in to details. That's where other users can step in to help :) I think I understand your suggestion regarding the calculator. Send me a PM and we can iron out the details and then make a considered suggestion about the UI if needed.

As for the other issues, I haven't had a change to check out 2.8 yet, but will do soon and will come back on that.

[MilosKozak]

Whilst I love 2.8 and the changes that have come with it (especially Omnipod implementation!) I must admit, I hate the new TT system and menu.

What is welcome, is moving it away from the long press menu (I can't tell you how many times my fat fingers had previously attempted to set an exercise target, accidentally hit eating soon target, and I've ended up with a reasonably large SMB being delivered which then scuppers my plan for exercise).

However, I don't like, once you're into the TT menu screen, that pressing one of the TT buttons just sets it. What I liked on the previous version was that by selecting the TT I wanted (after long press > Custom > select from dropdown) it would then auto fill in the target and duration boxes for me. Now, I don't always want to set a 90 minute Exercise TT, or a 60 minute Eating Soon TT, but by selecting those from the menu half the job was done and I just had to then set the duration if I wanted it to be different from my default for that TT. With the current implementation if I press a TT button, it sets it. If I try to select a TT option from the reason dropdown, all it does is put the reason in the box, but doesn't auto fill the target an duration boxes.

Unless this is a bug with 2.8, it feels like a step back if it has deliberately been designed this way.

And that's before I get started on "press OK to cancel" when there is also a Cancel button on that dialogue box!

the idea is allow straitforward set of daily used things, save time and eliminate spinners which are hard to use
did you try longpress on icon in TT dialog?

[MilosKozak]

Another thought, this time for the calculator. I believe the iOS app Loop has a Pizza button, and I think something similar would be useful in AAPS.
What got me thinking about this was a post in the FB group today where someone has set their dose to be 60% via Plugin Preferences > Advanced Settings.
Someway to have a screen that allows me to enter bolus, carb amount, carb duration, and an upfront bolus as a percentage would be useful.
It may already exist, and I'm just doing things wrong, but as I see it at the moment I need to manually workout split dose percentages, flip to another screen/button to add extra carbs or carb duration and so on. Why not have a calculator that allows me to enter all carbs, and split them to extend, and split the bolus with a percentage up front and so on. Why add the complexity of working out what X% of Y grams is to bolus for, and then an extra step to extend carbs over several hours?

this is against how OpenAPS works

If it's against how OpenAPS works, why can't OpenAPS be changed? That response just sounds like "it doesn't work that way, I don't want to explain why it doesn't work that way, and no changes will be made".

Why can't user assistance functions be added, regardless of whether this is how OpenAPS works or not? The system should be as easy to use as possible for the end user, and Loops gets a lot of praise for this and its UI, whereas AAPS, to be honest, looks very complicated and dated.

We try to be alligned to OpenAPS algorithm. I'd recommed to you read how OpenAPS/AAPS calculates absorbed carbs. It's completly different to Loop (and smarter) so something you may find usefull for Loop simply doesn't work for OAPS

[Philoul]

@mistermintsgh see https://androidaps.readthedocs.io/en/latest/EN/Usage/temptarget.html#what-are-temp-targets-and-where-can-i-set-and-configure-them

I hate the new TT system and menu.
...
(I can't tell you how many times my fat fingers had previously attempted to set an exercise target, accidentally hit eating soon target, and I've ended up with a reasonably large SMB being delivered which then scuppers my plan for exercise)
...
What I liked on the previous version was that by selecting the TT I wanted (after long press > Custom > select from dropdown) it would then auto fill in the target and duration boxes for me.

=> Excuse me but I really don't understand... you didn't like selection in main TT menu but you liked selection in the small dropdown menu that was included in previous TT dialog ???
Now to do the same thing with new interface, you just have to short click on the target to open the dialog, then long click on the default temp target (eating soon, activity or hypo button are big enough) to adjust your values, or short click to direct launch (after confirmation) with default values...
Isn't it much easier?

And that's before I get started on "press OK to cancel" when there is also a Cancel button on that dialogue box!

All dialogs works the same way in AAPS, just take a look in Insulin, Carb, Calculator, Profile Switch... first Ok in dialog, then Confirm
=> previously, security for TT menu was provided by the long click that you didn't like...

[ArthurusDent]

I do like the new TT icons that jamespaulley suggested. I never look at the waveform anyway and it just feels a bit overburdened.

[jamespaulley]

I have some more things to contribute on this topic? Can I reopen this issue or shall I make a new one?

[Philoul]

I suggest a new one to focus on new subjects (most proposals of this issue are already included in master now, and there are many many posts here...).

[jamespaulley]

I suggest a new one to focus on new subjects (most proposals of this issue are already included in master now, and there are many many posts here...).

Thank you. I made a new one here:
#349

And thank you to everyone that worked on the issues raised in this thread, it all looks really fantastic.