Mood Tracker project feedback

Hi :man_technologist:
I’ve been working on this project that tracks your mood throughout the year.
Basic functionality is working. I would appreciate feedback regarding the responsive layout, its my first time using skeleton boilerplate.
Next step with the project is to add a Random and Clear buttons that will fill the whole year with random moods, and in the second case, it will clear all the moods of the year.

Another interesting feature I would like to add in the future is storing the user’s input in either a cookie or localStorage, so when the user comes back, it will see the moods that were already entered.

Let me know what you think!

link to project
codepen here
Cheers :computer:


A few things:

  • I think you allow the months to get too squished together as you narrow the browser. You should always keep some side padding between the months. And the columns of days in each month are getting pretty tight too.
  • When I narrow my browser as far as it will go the days in the Sat column for each month jump to other days of the week.
  • It seems awkward to have some rows with just one or two months in them. A wide layout with three months per row should only have four rows. A layout with two months per row should only have six rows.
  • Text size responsiveness has some issues. When I increase the text size the days of the week start overlapping each other. Also the numbers start breaking out of their circular container.
1 Like

Thanks for the feedback.

There are many things to correct with regards to responsive design.

what would be the minimum device width we would actually make a site “readable” ?

Hi @eze,

I really like your idea. It would be nice if the 'select mood ’ options would be frozen in place when you scroll up and down. :slight_smile:

1 Like

I’ve made some changes to the original site.

I wouldn’t worry about specific widths. Narrow your browser as far as it will go (my Firefox goes to 450px). Use that as your starting point and style the page so everything looks good at this very narrow width. Once you have it looking good then slowly widen your browser until you feel you have enough room for the first layout change ( two months per row). Set your first break point there (using min-width) and then style for that width. After you are done with that, slowly widen the browser even more until you feel you have enough room for the final layout change (three months per row). Set your second break point there and style. Using this approach you are letting the content determine where the break points are.

Now the whole key to making this work with various widths and font sizes is to use em units for the break point instead of px. You can ballpark the em width by dividing the browser width (in pixels) for the break point by the default font size for your page (also in px). For example, if the default font size is 16px and you decide the first break point should be at 600px then 600/16 = 37.5 and you would set the break point to min-width: 37.5em. You can then test and adjust the em value until you get it right where you want it.

Using em units makes your page responsive to not only browser width changes but also changes in text size. Using the 600px example, let’s say you have your browser just slightly wider than 600px so that two months are showing per row. At a default font size (16px) this means that the width is just over 37.5em. But if you start increasing the text size (leaving the browser width the same) then the width in em’s starts to decrease and will fall under 37.5em which will trigger the page back to your narrow version (one month per row).

Now back to your original question about minimum device widths. First, instead of thinking of this in pixels you need to think of it in em’s. Thinking of the width in em’s basically translates to “how many characters of text can we fit horizontally on the page at the current text size?” Each device will have it’s own answer for that depending on what its device size and device pixel ratio is. But you don’t have to worry about all of that because you can use Chrome’s Responsive Design Mode in dev tools to narrow your page down as far as you want for testing. Choose ‘Responsive’ for the mobile device and narrow away. I think you’ll find that for the most part just designing the narrow view based on how far your browser can narrow is going to work just fine.

When you get down to very tiny devices there is always going to be a limit as to how far you can narrow the page before the dreaded horizontal scroll bar shows up. For example, I’m assuming you want to keep the months formatted as they are now (seven columns, one for each day of the week). So at some point that is going to break as you narrow closer to 0, especially if you are viewing with a bigger font size. At that point the user will just have to accept a horizontal scroll bar. But these situations are not that common. Just testing your page as it is now I can narrow down to under 200px and still have it looking nice.

1 Like

Thank you for your insight. I appreciate you taking the time.

I followed the instructions of your first paragraph and started working from small to big.
It seems to have worked and everything looks fine at least in my display.