Skip to content

[frio] Various UX improvements (mostly larger clickable areas)#12699

Merged
MrPetovan merged 17 commits intofriendica:developfrom
damianwajer:frio-ux-improvements
Jan 19, 2023
Merged

[frio] Various UX improvements (mostly larger clickable areas)#12699
MrPetovan merged 17 commits intofriendica:developfrom
damianwajer:frio-ux-improvements

Conversation

@damianwajer
Copy link
Copy Markdown

Hi. This is my first contribution to the Friendica project, so please be understanding :)

I noticed some elements in the Frio theme have small clickable areas, small font sizes, small buttons, etc. It's not very convenient and can cause misclicks, especially on mobile. My main goal in this PR is to improve the UX of such elements by making them larger (sometimes only in terms of clickable area, but sometimes also in actual size, which I considered a readability improvement, e.g. comments font size).

I think most of the changes are quick wins, but some may be a little opinionated, e.g. more clean design for responses actions. I needed small redesign to increase clickable area without making the icons too prominent or risking that icons will break into two lines (nested comments and all icons visible with dislike and share via…).

In the PR review, please check if everything is ok or if I haven't broken anything. Of course, I tested these changes before opening the PR, but maybe I left some parts of the system that I don't use or know (like optional settings etc.). To be honest, there are places where CSS has a lot of nesting, overrides or general elements, and can be unpredictable at times. We may consider using BEM methodology in the future.

Most of the commit messages should be self-explanatory, and I think they can act as a changelog. If I should provide more information or context, please let me know.

I hope you'll like the changes!

Here are the most notable before/after examples.

Larger clickable area

accordion

Name Before After
Dropdown dropdown-01 dropdown-02
'' tabs-click-area-01 tabs-click-area-02
Batch actions batch-actions-01 batch-actions-02
Aside links aside-01 aside-02
'' aside-settings-01 aside-settings-02
Action buttons comment-textarea-01 comment-textarea-02
Comment text size comment-01 comment-02
Responses actions (clickable area, spacing) responses-00 responses-01
'' responses-example-01 responses-example-02
Responses desktop (spacing) responses-desktop-00 responses-desktop-01
User menu user-menu-01 user-menu-02
Visibility and larger clickable area for top-right icons larger-contact-action-clickable-area-01 larger-contact-action-clickable-area-02

Enable user menu scrolling for low screen sizes:

user-menu-scroll

Icon hover style on button hover instead of whole item area hover:

Example 1 Example 2
icon-hover-instead-of-item-hover icon-on-hover-instead-of-item

@MrPetovan
Copy link
Copy Markdown
Collaborator

Everything looks good to me, except maybe the font size for comments, which I believe should remain slightly smaller than the top-level post to highlight it. If the absolute font size of comments is too small, maybe increase the top-level post font size instead?

@AlfredSK
Copy link
Copy Markdown

...except maybe the font size for comments, which I believe should remain slightly smaller...

Looks very well for me, too. But I have a different opinion about the font size of comments. ☺️ I have really bad eyes. And that tiny font in comments always bothered me. Sometimes I thought it is a bug that the font is smaller than in top level posts. 😉

...maybe increase the top-level post font size instead?

Could be a solution. Question is how the larger font in top level post would visually match the rest of the UI.

@MrPetovan
Copy link
Copy Markdown
Collaborator

MrPetovan commented Jan 19, 2023

Is this enough for you, Opa? 😄

Screen Shot 2023-01-19 at 16 37 39

@damianwajer
Copy link
Copy Markdown
Author

(…) the font size for comments, which I believe should remain slightly smaller than the top-level post to highlight it

Could you please elaborate what is the reasoning behind this?

Personally I don't see the benefit of such approach. I know Mastodon and Twitter do it, but their thread system works differently than Friendica.

In terms of highlighting:

  • the first message in the thread is always at the top, so IMO it don't need additional highlighting
  • comments are always indented, so that's one more indicator for the first-to-others relation
  • if you open the comment with a permalink, the background of current comment changes, so another indicator of "current item"

If there are any good reasons to differentiate the size, I strongly recommend increasing the main comment font instead of decreasing other comments.

I think, from the user perspective, if base font is ok in the thread system like Friendica, then smaller comments may be harder to read or look a bit odd. My vote goes for consistency, therefore the same font-size for comments.

PS. I thought about increasing base font even more (15px or 16px - also for comments), but I didn't want to be too extreme and opinionated in my first PR. In terms of accessibility and web typography best practices, the good starting point is 16px. Whatever the choice is, website should support browser preference, which can be done by setting html { font-size: 100%; } and using relative units like em or rem in most places. I think that could be a topic for a another PR.

@MrPetovan
Copy link
Copy Markdown
Collaborator

You make very good points. I've been using the frio theme for 7 years now so I'm very used to its idiosyncrasies.

I do support your additional point about typography and letting web browsers handle the font size for maximum accessibility, but you're right, it's best enabled in another issue/PR.

@MrPetovan MrPetovan merged commit 208d6db into friendica:develop Jan 19, 2023
@Quix0r
Copy link
Copy Markdown

Quix0r commented Jan 20, 2023

I know it has been merged, still a few ideas of mine:

  • Too small font sizes can be overcome by using CTRL + mouse wheel (at least Firefox supports this)
  • The theme now has elements being more away from each other, people may prefer a compacted theme
  • The theme is responsive (a good thing, under Firefox you can try it with simply pressing CTRL+SHIFT+M), the side menu can be found over the top-left 3 dots but some tooltips may not hurt here (e.g. good for accessibility)

This is more a positive review than a negative one.

@AlfredSK
Copy link
Copy Markdown

Too small font sizes can be overcome by using CTRL + mouse wheel (at least Firefox supports this)

I can't find that "mouse wheel" thingy on my phone. 😉

The theme now has elements being more away from each other, people may prefer a compacted theme

Most of the time I hear that: my fingers are too big for that tiny buttons. 🙂 So I think the spacing is a good solution.

All in all those changes are looking good. It's a matter of taste, I guess.

@damianwajer
Copy link
Copy Markdown
Author

Thanks for the comments. I think taste is one thing, but general UX is another. Most of the research tends to conclude with bigger elements. Sometimes much bigger than Friendica has. Of course, it's a matter of habit too, and sometimes we can make a larger clickable area without visually increasing the element size.

In any case, good point with a desktop solution with a CTRL + mouse wheel (there is also CTRL + + or -), but I don't think most regular users know about such shortcuts or other browser settings regarding fonts or other accessibility features. I don't know the Friendica user base very well yet, but general good practice is to target the most people with the best possible defaults, not only power users, who can adjust all the settings for themselves.

Material Design is a good reference point in terms of touch target size: https://m2.material.io/design/usability/accessibility.html#layout-and-typography
It focuses on mobile, and the desktop most frequently has a mouse, which is much more precise, so elements can be a little denser. I'm a fan of the mobile-first approach, which most of the time works better than the other way around.

@Quix0r
Copy link
Copy Markdown

Quix0r commented Jan 21, 2023

You can put bigger font-size values in the @media (max-width: 600px) branch in the style.css file. Then it remains compacted on desktop systems (still CTRL+mouse wheel exist) and is better readable on smaller displays such as mobile devices. And yes @AlfredSK I know mobile devices don't have a mouse wheel yet still I believe that there is some equivalent to it, e.g. some button combinations.

Sorry, you may have to block some ad-servers there, but here is one I could find quickly:
https://www.technipages.com/firefox-for-android-how-to-force-enable-zooming

@damianwajer
Copy link
Copy Markdown
Author

Of course, I know about media queries, but many people also use laptops with touchpads, which are not as good as a mouse. There are solutions for that (media query again), but I don't think we're even close to saying that the elements are too big for most users. In general, it's a matter of principle and design system. There are no strict conventions in the Frio theme, so there can always be debate about such things. Anyway, I'm open to any suggestions, and thanks for the feedback.

@SpcCw
Copy link
Copy Markdown

SpcCw commented Jan 21, 2023

I like clicking space improvements (especially for mobile) but I am with @Quix0r on more compact layout being more useful on smaller screens when reading posts and comments. I get why more spacing and larger fonts can be great for people with higher resolutions and/or less sharp vision however I wish there was a switch between larger and compact (old) mode. Maybe we can have updated and compact Frio available so users can decide?

Also there seems to be a small bug on mobile - "share" icon is sometimes invisible unless something else is clicked:

image
image

@MrPetovan
Copy link
Copy Markdown
Collaborator

Also there seems to be a small bug on mobile - "share" icon is sometimes invisible unless something else is clicked:

Yes, but this has nothing to do with this PR, it's always been like this since I added the feature. The issue is that the button availability has to be checked in Javascript, but I haven't managed to fire this check on page load, however it correctly fires on post reload.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants