Explore mobile support

[AustinGrey]

The experiments with Vue and a dedicated front end proved successful. The results showed improved usability. The next barrier is that of platform lock. Right now this frontend is very desktop centric, but it is likely that logging from a mobile device would be much more convenient than needing a complete desktop setup. The interface should be changed to either be a mobile friendly layout for both desktop and mobile, or completely different for the different platforms.

Current Challenges:

• [ ] Make all interfaces responsive, supporting 320 px to Inf px wide/tall screens.
  • [x] Everything except diary
  • [ ] diary
• [ ] Pick a color scheme that works on all devices
  • the current one is passable, but inconsistent with modern applications and doesn't use primary/secondary well.
  • Status: White and blue. The more blue the more suggested it is the user interacts with that element. Bland, but tried and true.
• [ ] Must find a way to condense information while maintaining readability
  • [x] Make units always visible so it is readily obvious what number should be input
  • [x] Strip unnecessary 0's from numbers
  • [ ] Organize input forms in a logical way (e.g. saturated fats should be clear it is describing a portion of fats, which is a total)
  • [ ] Organize input forms in a familiar way (e.g. perhaps making nutrition input form in the shape of a nutritional facts label)
  • [x] Explore better input field
  • Currrently
    • 
    • The float inputs were a fancy thing I put together when I tried to condense and grid up the input form for the ingredient. Their major benefit being they are self contained; the label and the input itself will always occupy the same space. This makes it possible for a grid of inputs to be consistent in overall look.
    • The major drawbacks are readability. As you can see the baseline of the input changes if the input is filled or not, making it hard to scan (see red line in the image). The label changes position, and input groups are not supported. Note how for (1) the unit appears as part of the label and so it's clear what the unit of the empty input would be. But in (2) the unit of the value then swooshes up into the floating label and thus is nowhere to be seen when trying to quickly scan. This design also leave absolutely 0 space for validation/help text
  • New idea
    • Some UX reading here and here make it clear that labels inside the input field are more trouble than they are worth, and that left and top aligned labels both are the best choices in certain situations. A replacement should be able to support left and top labels. Most likely it should not have a label at all, or support one or the other and allow turning it off so that a manually placed label can exist.
    • MUST have a consistent baseline and label font size. If this is in place, then help text can better exist and validation will be allowable.
    • Either embrace the whitespace or eliminate it. The gutters in input form field are distracting. This website advocates as much whitespace as possible, but seems that's more a marketing thing. This app is meant for getting in, putting in a diary entry asap, and getting out. This site shows that left aligned labels are actually the slowest forms to complete, and top aligned make the form much too long. For a mobile design it actually is looking more likely that right aligned labels could be the fastest, and if I can logically group the inputs using whitespace I can get them faster to fill.

[AustinGrey]

This issue will necessarily depend on #8 since that issue is currently being pulled into uipstream master with the na-vue-experiments branch

[dceliano]

+1 for mobile support being a necessary part of the UI - at least for the diary portion of the app. When I'm cooking or eating, it would be much more convenient to record data using a smartphone rather than typing into a desktop.

I got your Vue app up and running on my machine and I like how you can edit and view the data in a single view using it; this is much more usable than having the awkward Django /adminbackend split currently on the main branch.

I don't have much experience with Vue, but as you work on the mobile support I will try it out and can provide UI feedback/testing...it's of course better to keep this as a web app than a native smartphone app, especially since you probably want to be able to access the database from multiple devices.

[AustinGrey]

@dceliano At this point in the process broad feedback is welcome. I'm glad to hear you got it up and running. To be frank I wasn't sure how many if any people are using this app aside from Dylan and I personally am more diligent programming than I am logging my own nutrition through the app so feedback from more users at this stage could really change the course of the interface. Thanks for reaching out.

The plan is to keep everything in a webapp - that way the server can provide the app and the database if people want, and it's not difficult to use electron to target native applications.

[AustinGrey]

Here is the result of some experiments with condensing information:

https://user-images.githubusercontent.com/20841847/104403319-8640cd00-5515-11eb-9ec6-f2ecc2bb6d56.mp4

Notes from what I've learned:

• Sure having left side labels DOES make the form quicker to read, but it's also deeply unpleasant on mobile. If mobile is the target form factor, then having internal labels might actually be the choice. I can still get the benefits of validation text and more readable forms if I just put more whitespace around the elements. Possibly taking away the excess label animations from the float inputs, and placing the label on top on the outside of the input might be better.
• Reduction of elements is a must. In the attached movie, I've made the button to add a note to a component be the name of the component itself, and an asterisk appears when a note exists on that component. It save lots of space, and the button is now bigger! I've also hidden most inputs behind an 'advanced' toggle. The form is now so easy to fill out and very understandable with much less time. These principles could be applied to most areas of the website
• Lack of grid for buttons with shorter and more familiar copy. In the example above, instead of "Edit" I use "Save" and instead of "Create" I use "Save Copy" (and I debated using "Save As..." but since the name is already input that didn't make sense). The copy made the actions feel more natural, and NOT having all the buttons be the same width was so much better in helping me see which button to press.

[AustinGrey]

An improved look, using information condensing outlined in previous post, but with float labels that have had the labels popped out on top.

https://user-images.githubusercontent.com/20841847/104555870-d2663d00-55fb-11eb-9eff-422cde3709f0.mp4

1. This is subjectively better. Cleaner, simple. It does take up a LOT more vertical space... but I think I'm okay with that. Especially since most fields are hidden behind the "advanced" checkbox.
2. Validation text is now available, using it as a 'hint' right now in place of placeholders.
3. Aside from some bugs that will need to be ironed out. I'm moving forward with this design.

[dceliano]

I have some feedback from testing this on an actual smartphone vs. in the browser like your videos show. I set up an instance for testing at mail.domcc3.com:8000/frontend (entirely insecure, but only for testing) - feel free to browse to it to test things on your phone yourself. I will keep it up to date with your commits as best as possible.

1. When using a browser on Android (Firefox, Chrome) to visit the website, the bottom navigation bar is not always visible and is often covered by Firefox/Chrome's navigation bars. To compare, Youtube on a smartphone fixes this problem by making their bottom navigation bar float above the browser's navigation bar. It would be best to fix this, or alternatively use a "hamburger menu" at the top to navigate between the different pages.
2. There is no raw view of the diary or a summary view (as I'm sure you know). The "Daily Summary" page on the main website is useful, as it summarizes what you ate that day, how many calories you ate, etc. All I see in your frontend is the name of the meal (i.e. "Pasta with Tomato Sauce"). I would say this is the biggest priority to get working as the app is not very usable without it.
3. The ingredients page is slightly too wide for my smartphone (the width doesn't match exactly) - not sure why.
4. The ingredients/food pages always show a form with input fields. I understand it's probably easier to keep that form always present, but doing so makes the page very busy/less readable. Ideally, there would be "new item" and "edit item" buttons to click, and the form only pops up once those one of those buttons are clicked. Similarly, "Save Copy" vs. "Save" for ingredients is confusing. A user is either adding a new ingredient/recipe or editing a current ingredient/recipe.
5. The "Food" page should be labeled "Recipes" if you want to be more consistent/make the layout clearer.

[AustinGrey]

Thanks dceliano.

1. I can setup remote debugging on my phone and test this out in a chromium browser. It's less convenient but clearly needed before I request this merge upstream.
2. I'm having difficulty figuring out an interface for the diary. On one hand you should be able to quickly find a food (recipe, ingredient, or one off) and add it. On the other, you want to see a summary of what has already been added and how far along your goals you are. And on top of that, when adding a food, I want to see which food and how much will help me fulfill my targets. That's a lot of information, and it requires a lot of space. I tried to condense it with the reactive min/max bars on the diary page that tell you how much of each nutrient you are about to add. And if you click on a food in the "foods from the past 24 hours" section, it will highlight how much of your current targets came from that meal/food. But this could improve. I'll think on it more.
3. I'm unsure what could cause this, as I have no such issue on my smart phone. Mind telling me what model you have so I can look up the specs? Everything should fit down to 320px of width.
4. Noted, I'm a fan of 'commander' layouts where everything can always be seen, but I get the trade off of an extra click might be worth the cleaner look here. I'll test it out.
5. Part of me hates that ingredients and recipes are separate entities at all. You eat them, it shouldn't really matter that one can be composed and the other bought. But the backend uses different tables and therefore two separate api's. If there could be a unified food api, and as you said above the form doesn't need to show all the time, then it's logical that the ingredient and recipe pages should just become one page. I'm not sure how hard it would be to do this, but I'm experimenting with it.

[dceliano]

Regarding no. 4, the issue is not specific to my phone; you can use the Chromium developer tools' device toolbar to choose "Samsung Galaxy S5" and you will have the same behavior. It is like that on "Moto G4" and a few other models as well.

An idea for the diary page is to have a table with rows - one row per day - which shows a summary of that day's statistics. If you want to expand the details of a specific day, you can click the row and the individual entries will show up. Click the row again, and they will go away. The columns will be quite narrow since there are about 6 columns, but the values should still be visible on a smartphone. And then to add a new diary item, just put a "+" on one of the corners of the page.

Also, now that I've been using Django a bit more, the idea of "Save Copy" makes a more sense; Django calls it "Save as New" in their backend. A more intuitive word might be "Duplicate" or something of the sort.

[AustinGrey]

@dceliano I'm not sure I follow the proposed design for the diary page:

1. "Days" are indeterminate in PANTS, as it was a deliberate design choice by Dylan to support people for whom a 'day' starts not at midnight I'd like to keep that rolling. So instead I've decided to define intervals (although we can call them days as I'm sure for the average user their 'interval' would start at midnight and be 24 hours long)
2. For any given day, you may have any number of foods eaten so it would not make sense to show the eaten foods in the row, they would have to go into the 'details view' you mention.
3. Which nutrients are tracked can also fluctuate. Some individuals may care to track sugars and cost, while for another they may want to track the individual amino acid profiles of their chosen foods, for which there are more than 6 alone. The currently tracked nutrients are just hardcoded in - but it's obvious in the code that Dylan plans to make them more flexible. The front end should support this flexibility. So it wouldn't make sense to use the nutrients in the columns you mention either.

What I'm working toward now would look like:

1. A timeline of intervals (this could be in the form of a column with the days in it on the left, or a row with the days in it along the top for example) that can be navigated to the next/previous interval using a next previous button. The screen will show as many intervals as will fit so for phones you may only see today, but on a desktop likely a good portion of the week will fit.
2. Some way to visualize the statistics for an interval. I'm still shaky on this, but we could designate one interval as the 'main interval' and that interval would have it's statistics shown. Or we could show the statistics for all intervals in some condensed representation (e.g. if the timeline is a column on the left side of the screen, then we could show stats for each interval as a row off of it. Or if the timeline is a row on the top of the screen, we could show the stats in a column beneath each interval.)
3. And some way to show the create/edit form. This I'm the least sure on. Certainly we do want some sort of "+" button. In the bottom right corner of the page makes sense on a phone, but on a desktop that is completely unusable. I can put the button in the bottom right corner of each interval, and then since phones only show one interval, it will ultimately end up in the bottom right corner of the page if the timeline is shown at the bottom on phones. This means on desktop that there will be several plus buttons, but it would be obvious what each one would do. The other issue is where and when to show the form. If I click on an existing entry and start editing it, I would want to see the values I'm entering in the context of the stats for interval that entry falls into (e.g. if I edit or add an entry to an interval and type that it cost 10$, I want to know that that would put me over my cost target).

The devils in the details so I might hit a snag, but this seems to be the most workable solution to hit all the goals I mentioned last month.

[AustinGrey]

Here is a preview of the work done on a more mobile friendly version of the diary. Instead of using ag-grid, I just have a list that appears on search. And the form for adding a new entry appears as part of the rows listed for the interval.

https://user-images.githubusercontent.com/20841847/107997367-d4773f00-6f9f-11eb-9c4a-d68de3c85b21.mp4

It's ugly, but the functionality is much more intuitive, you don't need to think about recipes or ingredients. This required writing a completely custom View in django to merge the two models while still allowing sort/search. I can certainly improve the look on the front end though. You could image that for portrait mobile screens, we stack the stats on the top of the page with a maximum height, and then have the interval on the bottom as thats closer to the thumbs for interaction.

[dceliano]

Yes, I agree this diary view is more intuitive and looks better than the old one. I especially like the date picker on the top of the screen (or on the bottom) allowing you to easily go forward/backward days and the fact that there is a summary view for each day. 2 ideas come to mind upon using it: 1.) add a cancel button for if the user clicks the "+" button then changes their mind and wants to go back quickly 2.) Allow a user to click a diary entry and view more details about that entry and edit the entry.

There are still ways to make improve this design (make sure you test changes with multiple mobile devices in the Chrome developer tools), but I think this is a good step forward.

On another note, I get the following backend error:

File "./pants/recipes/serializers.py", line 128, in class FoodRepresentationQuerySet: File "./pants/recipes/serializers.py", line 134, in FoodRepresentationQuerySet def init(self, querysets: list[QuerySet]): TypeError: 'type' object is not subscriptable

I think you can fix it by making the following change on line 134: def init(self, querysets: list[QuerySet]): to def init(self, querysets):

I'm not sure what you were intending to do there, but if you ever need to convert a queryset to a Python list, I've found the syntax list(queryset.values()) is an easy way to do it.