Showing only time slots for scheduled dosis at Home tab

[rrodrigueznt]

Hi! When at Home tab, time is shown in hourly slots. Those slots are occupied when a dose is due at any of them, but free slots are also shown. Even though this could be useful as a measurement of time until the next dose, when you have several patients with several intake times each day, you much scroll longer to reach a given point, frequently through empty areas of the timeline.

Please, what do you think? Thanks!

[angelpinheiro]

Ok, I think we can add an option for show or hide the empty hour when the agenda is expanded. Thank you!

[rrodrigueznt]

Welcome! One more tip on this issue: when a given schedule is shown in a time slot, both appear, the dose and the free time slot. Does this make sense for you? Cheers!

[angelpinheiro]

That's because routines are not necessarily located at exact hours (9:00, 10:00,...), and in that case an exact hour label is useful. Thus, the implementation is easier the way it works now, because we avoid a lot of checks, but I also think that it seems a bit unusual when there is a routine at the same time, and we should remove the empty item.

[rrodrigueznt]

Hi! Still running Version 2.5-SNAPSHOT-2016.12.20 (29) here and for some reason, empty slots are no longer shown on my Calendula's Home tab! Any idea? Perhaps some changes in settings on my device, but I'm not able to figure out which changes could have affected Calendulas's behavior! Thanks!

[AlvaroBrey]

Hello @rrodrigueznt,
Perhaps you might have triggered the collapsed mode by accident? Please try to click the icon on the top right corner of the home tab of Calendula and see what happens.

[rrodrigueznt]

That's the point! Thanks! Thus, your comment raises another issue: the collapse icon has not a coherent behaviour here: with only one patient, it simply collapse the upper area of the tab, with several patients, it both collapses the upper area and hide free time slots. Could you reproduce this?

This could be somehow related with #66

[AlvaroBrey]

Sorry, but I cannot reproduce the problem on my end.
The expected behaviour (working correctly for me) is the following:

• The Home tab has two modes. One is a "quick overview" mode which shows the pending intakes for today only. The other is an "agenda view" which shows intakes from yesterday, today and tomorrow. This last mode is the one with the blank timeslots. Both modes show intakes for all patients.
• When clicking on the top right button, the mode is toggled. Additionally, the top toolbar is automatically collapsed when switching to agenda mode, and uncollapsed when switching to quick overview.

Can you please confirm if this is not the behaviour you're experimenting?

[rrodrigueznt]

Thanks! I think that this behaviour is true now, after including two patients, but the switch between "quick overview" and "agenda view" was not working correctly with only one patient. But this is only a feeling and I can't reproduce now what I think it was the original behaviour in my device by removing all but one patient.

Your explanation helped me to understand and I do hope to explain better what is weird for me in this behaviour. Again, related with #66...

• If I select "quick overview" mode at Home tab, I would like to stick to this state when navigation out to any other tab and back to it.

• When in the Home tab. I would like to be able to expand/collapse the upper zone showing all or only part of a picture both in "agenda view" or what now is called "quick overview". The collapsed upper zone won't ever show a background color assigned to a patient.

• When in "agenda view", present time will appear vertically centered in the available view area. I'll scroll up to find yesterday schedules and down to find tomorrow's ones. Now, I've to scroll down both to find yesterday and tomorrow's schedules.

Please, WDYT? Thanks!

[AlvaroBrey]

A small note on the second suggestion: you can definitely collapse/uncollapse the top section independently of the mode by sliding up/down (respectively). Perhaps it would be better to not link this behaviour to the mode change. We'll think about it!

The other two suggestions seem interesting enough to deserve a separate issue, which I'll create shortly. Thank you!