Mobile first user interface

[billybonks]

Hi, Thank you for all the effort in creating and maintaining this application.

I recently deployed it and started using it; while it has many useful functionalities, the mobile version of the UI could be more convenient.

My goal was to create a user interface for mobile that was clean, easy to use and optimised for data input while highlighting essential details on the dashboard and eventually turn it into a PWA so that it's almost like a mobile app on all platforms.

I did not want to deal with security concerns by coding it separately to the Django app. At the same time, I did not want to concentrate on making it compatible with the current desktop experience or focus on fighting Bootstrap, which is why I created brand new pages under the mobile namespace.

I am hoping to get some feedback while I continue developing the pages:

1. Would you be willing to accept changes in this direction
2. How best to integrate it ( I was hoping to build something lazy, so if the mobile page exists, use it otherwise, use desktop page)
3. Honestly, any other feedback? The work is a bit rough, and I am focused on ideation. I plan to deploy this to my server now and continue to iterate.

After running the app, visit

/mobile/children/{child-slug}/dashboard/ (the blue background might be poorly positioned it is just optimised for my cellphone)

I think you should look at it on your mobile; I have only developed the form for the diaper change model.

TODO

• only show child input if the user can make a selection
• Pass child slug as URL parameter https://github.com/billybonks/babybuddy/blame/mobile/mobile/templatetags/mobile-components.py#L36

[cdubz]

Hey! I haven't had time to look closey at this but to answer your Qs --

Would you be willing to accept changes in this direction

Yes! The frontend hasn't change since I started slinging code at this problem back in 2017. The screenshots here look like a promising direction.

How best to integrate it ( I was hoping to build something lazy, so if the mobile page exists, use it otherwise, use desktop page).

I think we'd want to put this behind a user setting toggle at least initially. Frankly I'm not opposed to reconsidering the overall approach to the desktop design as well... which could mean just incorporating this as part of a full redesign. But if we stick to just mobile yeah we'll need to work out particulars for how to put to use (I have no idea off the top of my head).

Honestly, any other feedback? The work is a bit rough, and I am focused on ideation. I plan to deploy this to my server now and continue to iterate.

Nothing yet but again the screenshots look like a great direction.

[MrApplejuice]

Hey, I maybe have some input from my side, the android-app dev is welcome?

First of all, I think that a mobile-first, too, design is probably the most sensible because it allows you to actually inspect the data on a proper data analysis machine. I personally suspect that this is a major feature of baby buddy to begin with.

For the web-interface: I kind of recognize that interface, and yours looks great, nice job! Anyway, for "my tips":

1. One goal I tried to achieve with the app was a slight annoyance with using babybuddy "while in the trenches", which was that sometimes it took 1-2 seconds to do data entry. This was mainly because of the delay incurred by the interface itself, loading a new page, a bad WiFi connection, what-have-you. I see that you are using separate views, for example, for diaper entries. If possible, I would suggest doing this all in one view but then using page updates. Frameworks like htmx or vue might be of particular use for this. I think this would make the utility of the mobile-first approach for this page really shine!

2. The other goal seems one you already seem to have very much in mind: Minimize all the button clicks, remove all required text edits. For example, for feeding-entries, I created a yet-to-be-redesigned button based entry method (see screenshot) which is easy to use on mobile. From what I understand, this is the most appreciated design feature of the app. "You open it press a few buttons and throw the phone in the corner after you are done."

Or the two tips in short:

• Eliminate wait times so that data entry can start quickly
• Eliminate cumbersome button presses during text entry

Take the tips or leave them... and copy designs you like from the Android app if you want (careful, the graphical assets are not free though)! If you have questions, I am happy to answer and help where possible...

(Edit) Short clarification: I kind of only wanted to share the user feedback I have gotten over time about the Android-app in case you were interested. This is only informative, design what you want!

[billybonks]

Thanks for the great feedback @MrApplejuice.

I am focusing on 2; the extra while-in-the-trenches feature that I will build Is PWA integration to look like an app on your phone instead of going to the browser and finding the correct tab.

I agree that a smoother interface could be built with a SPA; what prevented me from doing this is the amount of feature wealth already developed into the SSR version of the app notifications/forms/validations, etc. I will explore the performance and see if I can add notes on improving it.

@cdubz I have been thinking about how best to do this, within the allotted time i have for the contribution.

What I am thinking of build is

1. Child Dashboard
2. Create Forms for all activities
3. A way to switch between the two views
4. Basic PWA Feature setup
5. Explore improving timers.

a bit more detail

1. The bespoke homepage,
   a. used as a base to navigate to all other pages
   b. shows a daily summary of activities (at least ones important to me; more can be added as contributions)
   c. child picker on the home page

2. Optimise forms for mobile

   1. as @MrApplejuice mentioned, decrease the clicks required to do what you need, so the home page to form is one easy click. Take out critical choices into a one-click pill instead of a drop-down, and simplify the form like I did for bottle feeding.
   2. Build FieldSets concepts to support 1

3. A button to switch to new or old UI and save locally on the device what the choice was.

4. Saves site as an application with icon and splash screen.

5. the timers' experience is timer first, then activity. The cleaner experience is activity than a timer; for example, whenever I create a quick timer, I need to name it to sleep so I don't forget what it was for. It would be easier to add sleep and start the timer.

There is a timer context PR that I will explore finishing to support this improvement.

Final thoughts

This is what I can commit to doing at the moment. I explored making it change UI using responsive CSS, but I don't want to break the existing user experience, and this should stay on the side until it shines. Then, we can think about integrating the two views more interestingly.

The next steps would be to:

1. Support list pages
2. Support measurements
3. Support edit pages
4. Support timer pausing
5. Build proper breastfeeding input

Then it will be very on par with existing apps I found in the various app stores from a mobile experience point of view.