Closed Bug 1846095 Opened 2 years ago Closed 1 year ago

Misaligned icon and stretched in "show events of the selected day" button

Categories

(Calendar :: Calendar Frontend, defect)

Thunderbird 117
Unspecified
Windows
defect

Tracking

(thunderbird_esr115 wontfix, thunderbird125 fixed)

RESOLVED FIXED
126 Branch
Tracking Status
thunderbird_esr115 --- wontfix
thunderbird125 --- fixed

People

(Reporter: narhhj, Assigned: Paenglab)

Details

(Whiteboard: [TM 115.10.+])

Attachments

(7 files)

Attached image notaligned.png β€”

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.82

Steps to reproduce:

  • Open thunderbird (all supernova versions, daily, beta or stable are affected)
  • see the very right side of the UI in the event section
  • there are 4 buttons : left pointing arrow for previous day, circle for today, right pointing arrow for next day, and down pointing arrow for "show events of the selected day"

Actual results:

  • the three first buttons are all square and their icons are center-aligned
  • The fourth button (down arrow) is vertically stretched compared to the rest and its icon is right aligned and touching the edge of the screen. (see attached screenshot)

Expected results:

The button icon should be in the center of the button and the button should not be stretched and be more cohesive with the 3 other buttons.

Component: Theme → Calendar Frontend
Product: Thunderbird → Calendar
Assignee: nobody → richard.marti
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9394926 - Attachment description: Bug 1846095 - Windows: remove t !important from the toolbarbutton-menu-dropmarker rule. r=#thunderbird-front-end-reviewers → Bug 1846095 - Windows: Remove the !important from the toolbarbutton-menu-dropmarker rule. r=#thunderbird-front-end-reviewers
OS: Unspecified → Windows
Target Milestone: --- → 126 Branch

Pushed by martin@humanoids.be:
https://hg.mozilla.org/comm-central/rev/8a0705cef75c
Windows: Remove the !important from the toolbarbutton-menu-dropmarker rule. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Comment on attachment 9394926 [details]
Bug 1846095 - Windows: Remove the !important from the toolbarbutton-menu-dropmarker rule. r=#thunderbird-front-end-reviewers

[Approval Request Comment]
User impact if declined: not centred dropmarker icon in today pane
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Attachment #9394926 - Flags: approval-comm-beta?

[Approval Request Comment]
User impact if declined: not centred dropmarker icon in today pane
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Attachment #9395253 - Flags: approval-comm-esr115?

Comment on attachment 9394926 [details]
Bug 1846095 - Windows: Remove the !important from the toolbarbutton-menu-dropmarker rule. r=#thunderbird-front-end-reviewers

[Triage Comment]
Approved for beta

Attachment #9394926 - Flags: approval-comm-beta? → approval-comm-beta+
Whiteboard: [TM 115.10.+]
Attachment #9395253 - Flags: approval-comm-esr115? → approval-comm-esr115-

This has been closed as fixed from version 125, but in fact is still not fixed in any of the daily and beta channel (full reinstall), and in the latest daily (129.0a1) and beta channel (full reinstall). In the attachements are the actual visual and what I think is the expected visual for this.

Status: RESOLVED → REOPENED
Flags: needinfo?(vseerror)
Resolution: FIXED → ---
Attached image Expected.png β€”
Attached image Actual.png β€”

I agree in the current nightly this is not fixed. Was it fixed three months ago and regressed?

Flags: needinfo?(vseerror) → needinfo?(richard.marti)
Attached image image.png β€”

This never regressed. When you look at the whole widget you see that the dropdown doesn't correlate to the other buttons but to the widget to show the minimonth.

Flags: needinfo?(richard.marti)
Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED

(In reply to Richard Marti (:Paenglab) from comment #12)

Created attachment 9409343 [details]
image.png

When you look at the whole widget you see that the dropdown doesn't correlate to the other buttons but to the widget to show the minimonth.

I won't reopen the issue as of now, but this is worth of a discussion here I believe.

I would like to argue against the statemet above statement, and do still believe this is a bug. First of all, correct me if I am wrong but this statement, to me, is more related to the structure within the code for these elements, and if so, should really not dictate the layout in terms of what's logical, on-screen in term of UX/UI.

My view in regard to this come specifically from where the project should be leading: the supernova rework. I am aware that Supernova is not just a UI redesign, but one of the main goals of this rework is to create a more user-friendly, logical design and layout.

Thunderbird previous versions had an uncohesive UI with elements randomly placed, exactly because the decisions were mostly coming from what was easy and/or fast to code for individual code contributors or what "made sense" in the term of coding layout in the codebase that existed. But in the end, this method just ended up making it difficult to understand and use or just unpleasant for end users. In my view, the logic behind the statement above, is returning to that instead of focusing on the general picture in the sense of UX/UI of Supernova and would in the long end us up with the same disjointed UX/UI that Supernova aimed to fix in the first place.

That is because, if we put aside how they are layed-out in the code, the buttons '<', 'o', '>', and 'v', in the user perspective, and actual use, all have the same function: let the user change the shown date within that panel.

Specifically: '<' move the user to the previous date from the shown date, 'o' change the current date to the current day, '>' moves to the next date from the currently shown date, and 'v' allows for selecting a specific date. From a UX perspective, from the user perspective, they are a "whole one", a bloc/group of helper buttons to use for achieving the same basic specific task. They mostly follow the same design language (except for this odd one) and iconography and logic (including this odd one), and they share the same visual space. Yet the 'v' icon is the only one that is stretched, for not particular reason, creating visual noise and disrupting cohesiveness.

The fact that it is a dropdown should not affect in any way this reasoning. Just as an example, if we look a little bit just above it, in windows, we would have the Menu button (which is a dropdown), next to the minimize button, the window resize button (which is also a dropdown in windows 11) and the close button. 3 out of the 4 share the same task (modifying the window state in some way) and are consistent in design, regardless of having dropdown or not.

But you would also notice, that even the 4th (the menu button) is properly aligned, properly sized, and consistent with the 3 next to it. And neither the Menu button, nor the resize button are stretched just because they are dropdown, that's not a good reasoning for this. The reason why all 4 are consistent instead of just the 3 of the same group is also because they share the same visual space so they need at least some form of relative consistency (alignment, size, ...), if you hover on them, they are slightly different, but at first glance, they should not create visual noise that take attention and disrupt the user.

But let's assume those are not relevant since all OSes thunderbird run on are not windows, let's have a look into Thundebird itself. There are many other interactive elements (textbox, buttons, toggles, dropdown buttons, ...) in the new UI, right from the top at the toolbar sections, to the quick filter, to the calendar, and on and on, and they all, for what I have found, maintain relative consistency (size, alignement and such) to their neighboring elements in term of visual space, regardless of what they are, or whatever else. And they do share absolute consistency with buttons that share the same basic function as them within that same visual space.

They also maintain consistency to the overall design language of the new Supernova interface, and just most modern user friendly applications really. In the sense that they all visually seems to follow these principles :

  • squarish if containing just a single iconography
  • or stretched to the average bounding box of the elements inside if containing a mix of multiple elements : text or other icons.
  • in short, they avoid odd shapes and just wrap around what they contains in a consistent logical way.
  • The other important thing to notice being that for all buttons within a same visual space is that, all sides have visually consistent paddings inside based on the elements within them (icons, texts) from all sides top to bottom to left to right.

In all of this, only this very particular button, does not follow these principles at all, where the padding on the top to the bottom is just overly stretched for no reason, and it's the only single one sticking out being misaligned to the others within that same visual space, despite it actually fulfilling the same function as its neighbors. I really have yet to find any other button(s) in the redesign, dropdown or not, that have this kind of odd stretch and misalignment, anywhere else.

So really, to me, this is a bug. I am even more convinced because this is originally not the only issue I have reported for this particular button in this post, and this particular view is more filled with bugs than most of thunderbird in my extensive use (scrolling issues tied to this specific view amongs other things,already reported in other issues but that's beside the point here), therefore, assuming implementation errors have been here resulting in this, is not far stretched and more believable to me than this just being the way things have been designed and implemented considering how other parts of the new design work, are consistently designed, and are mostly bug free.

In the case that it is in fact, really not an error which I really don't believe, I would still argue this is not right because of the elements I have already exposed above on how only this element is overly deviant from the design system of all other elements in the new thunderbird, to which I would ask, why so? Honestly, if continuing this way, as more and more elements like this one creeps in without being addressed because they structurally make sense in the code, in a few years from now, the project will just be back to the pre-Supernova era where everything is just all over the place and nothing make sense for the end user.

Flags: needinfo?(richard.marti)

Alex, what do you think about this button?

Flags: needinfo?(richard.marti) → needinfo?(alessandro)

That whole section is a UI/UX nightmare and we will rebuild it from scratch in the next ESR cycle.
There's no point in tweaking it now as it will be entirely replace soon.
We will share mock-ups and visual prototypes around September.

Flags: needinfo?(alessandro)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: