Opened 5 years ago
Last modified 9 months ago
#4917 reviewing defect (bug)
Trac needs more responsive styles
Reported by: | sumitsingh | Owned by: | dd32 |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Trac | Keywords: | needs-design-feedback has-patch has-screenshots |
Cc: |
Description
Hi,
I have found desing the issue on Moto E4 plus in chrome browser in below mentioned link.
https://core.trac.wordpress.org/ticket/48997
Thanks
Attachments (25)
Change History (60)
#1
follow-up:
↓ 6
@
5 years ago
- Keywords needs-patch added
- Priority changed from normal to lowest
Unfortunately Trac isn't designed for mobile usage and these are only two minor examples of where the styling breaks down.
Attachment Screenshot_20191217-232159.png
I can't duplicate that on any mobile devices I have, but I can reproduce it on Chrome at screen resolutions <450px, unfortunately I can't find the CSS that's doing it.
Removing all instances of min-width:
fixes it, but makes trac less usable on larger tablet resolutions. In this case, it's the presence of min-width
that's breaking it, I can't explain why and I can't find any combination of styles that are colluding to make it happen.
Attachment Screenshot_20191218-091019.png
Reports in general aren't usable on mobile anyway.
The standard experience for reports is the header/intro being ~33% of the viewport due to the extra-wide ticket table below it.
IMHO this ticket is a wontfix
unless anyone feels strong enough to redo quite a lot of CSS to make Trac usable on all mobile resolutions. The current experience of having to zoom on most pages is reasonably usable given the content being worked with. I'm marking this as needing a patch, and low priority due to the above.
#2
@
5 years ago
- Summary changed from Desing issue in Mobile device to Trac needs more responsive styles
#4
@
4 years ago
- Keywords needs-design-feedback added
- Priority changed from lowest to high
@dd32 I worked on a simple fix and got the result below:
Before:
https://prnt.sc/tg3dmc
After:
https://prnt.sc/tg3dde
I think this ticket should not be low priority, as it is related to accessibility. What do you think?
How can I send a patch with the fix?
In case someone wants to make the patch, the basic CSS I used is this:
@media (max-width:550px) { #ticket .ticket-star { font-size: 25px; width: 25px; } #ticket > h2 .trac-id { font-size: 100%; } #ticket table.properties > tbody > tr { border-bottom: none; } #ticket table.properties > tbody > tr > td { border-top: 1px dotted #eed; width: 42%; float: left; } #ticket table.properties > tbody > tr > th { border-top: 1px dotted #eed; width: 42%; float: left; } #ticket table.properties > tbody > tr > th#h_focuses { border-bottom: 1px dotted #eed; } }
This ticket was mentioned in Slack in #meta by marcosalexandre. View the logs.
4 years ago
#6
in reply to:
↑ 1
;
follow-up:
↓ 8
@
4 years ago
- Priority changed from high to normal
Replying to dd32:
IMHO this ticket is a
wontfix
unless anyone feels strong enough to redo quite a lot of CSS to make Trac usable on all mobile resolutions.
I partially agree for the Good First Bugs page - you don't go on that page from mobile. On the other hand, the single view of a ticket is more and more accessed from a mobile device - just wanting to check a ticket. So, IMHO, that needs a patch.
Explored solutions:
word-wrap: break-all;
will result in ugly incomplete names & keywords- Creating 2 columns of properties + attributes instead of 4 is possible, but still looks crowdy on mobile and needs different HTML output, not only CSS rules.
- Creating 1 column of properties + attributes looks elegant on mobile. (see 4917.patch)
@MarcosAlexandre I wasn't able to replicate your results with your proposed CSS snippet. If you have any suggestions about my proposed patch, please let me know.
Maybe step by step we'll make trac fully responsive, who knows!?
#8
in reply to:
↑ 6
;
follow-up:
↓ 9
@
4 years ago
Replying to vladytimy:
On the other hand, the single view of a ticket is more and more accessed from a mobile device - just wanting to check a ticket. So, IMHO, that needs a patch.
Agreed! The changes in 4917.patch seem straight forward enough, if it works like the screenshots here, that's a good step towards more usable Trac.
Explored solutions:
Thank you for explaining what you've tried! it makes it much easier to just trust the patch as-is without questioning the why's and how's of it, as long as the styles look reasonable on other sizes once applied I'll push it out today!
#9
in reply to:
↑ 8
;
follow-up:
↓ 10
@
4 years ago
Replying to dd32:
as long as the styles look reasonable on other sizes once applied
4917.patch only addresses styles in @media (max-width: 360px)
and @media (max-width: 550px)
.
There are 2 other styling issues on the single ticket view not introduced by this patch (see current design / screenshots):
- between 550px and 640px breakpoints both avatars float right (not ideal solution)
- between 640px and 770px breakpoints Reported by & Owned by: overlaps reporter's & owner's avatar (within this range, also the
#modify .trac-properties
table has styling issues)
Although IMO, these are less used sizes, since this ticket description is Trac needs more responsive styles I will propose an updated patch to address the above issues as well.
Thanks for making trac more responsive, even though most of the work here is not done on mobile.
#10
in reply to:
↑ 9
@
4 years ago
Solutions for this comment:
between 550px and 640px breakpoints both avatars float right
Here I have a dilemma. CSS comment says: img.avatar {float: right; /* move it to the right to help prevent collisions */}
but I can't reproduce any collisions without floating right even with longer names given that Reported by & Owned by are static length strings. (4917.2.patch removes floating - we either test it or let the floating right as it is currently)
between 640px and 770px breakpoints Reported by & Owned by: overlaps reporter's & owner's avatar
Explored solutions:
- Avatar floating right is not consistent with the design
- Changing margin-left from -60px to 0; moving rule from (max-width: 640px) to (max-width: 770px) (chosen approach)
between 640px and 770px breakpoints the
#modify .trac-properties
table has styling issues
Explored solutions:
- smaller width columns results in a crowded design and needs different HTML/selectors
- moving table rules from (max-width: 640px) to (max-width: 770px) creates one column, but intricates up Keywords and Focuses fields, making unclear what input is for what section. (see screenshot)
- reducing
#focuses
padding-right from 52px to 22px on this screen size - it aligns with above element. (chosen approach)
All these are small things, but make trac look better on medium screens.
#11
@
4 years ago
4917.2.patch now addresses @media (max-width: 360px)
, @media (max-width: 550px)
, @media (max-width: 640px)
and @media (max-width: 770px)
It definitely needs some testing. Thanks!
#14
@
4 years ago
Another mobile style breaking issue is when people (me included) use long attachments names or links.
.description
and .summary
already have word-break: break-word;
but .changes
and .attachments
don't.
Since we already use word-break (and not others such as: word-wrap or overflow-wrap), 4917.3.patch adds that rule to the above specified selectors. ( These rules don't need to be in a @media (max-width:550px)
CSS block, since they take action only when needed on smaller screens. )
With this, we'll have a fully responsive (meaning "no major style issues") single view of a ticket, the most accessed template on here. Thanks, @dd32 for taking time to test and implement these small changes.
This ticket was mentioned in Slack in #meta by sumitsingh. View the logs.
4 years ago
#17
@
4 years ago
The next step with responsive styles on Trac would be responsive Report view, as requested in these tickets, other than this ticket:
As Dion said, Trac is not designed for mobile and many things can't be implemented by CSS styles only. My reasons for trying to implement responsive styles are:
- it doesn't affect those that use wider screens
- it gives a slightly better user experience for those (maybe a few) that use it on mobile
- it might increase Trac usage if it has a better mobile interface
- even if it's not perfect, it's better
The Reports patch for mobile devices is split in 4 smaller parts:
- Overlapping report name with Max items per page
- Styling report Filters (mobile)
- Styling report Listing (mobile)
- Better accessibility for report listing (mobile)
#18
@
4 years ago
- Fixes overlapping report name with Max items per page (4917.reports.1.patch)
- adds padding-top to
#prefs
- no breaking point suggested, since the overlapping occurs for screens up to 900px (the patch doesn't break style for larger screens)
See before and after.
#19
@
4 years ago
- Styling report Filters (mobile) (4917.reports.2.patch)
- displays filters table as block
- corectly aligns labels
- increases size of labels
- adds padding between clauses
- breaking point:
<640px
( wider screens can display current design )
See before and after.
#20
@
4 years ago
- Styling report Listing (Mobile) (4917.reports.3.patch)
- displays listing table as block
- keeps table header containing labels as a row
- adds label before every item listed
.id
and.ticket
have the same label, because... Trac.date
has Date label - see below why- labels are bold, except Comments and Stars (not vital info)
- label Stars is, because not-logged users don't see the star icon
- Comments and Stars fields, in most cases, don't have their own row (space efficiency): they float right on the same row as the field they come before. (depends on the report field order)
- breaking point:
770px
- see below why
Reasons
- Choosing a breaking point for reports mobile styling.
Different reports need different breaking points based on the number of fields in the default query. Not wanting to affect smaller desktop sizes (extreme example: meta/report/5 needs a breaking point at 1550px - mobile style at that width is a no), the breaking point that works for most reports is 770px
. It is small enough not to affect any desktop views.
- Date label
The labels are inserted via CSS. eg: .summary::before { content: "Summary: ";}
The problem occurs with .date
class that is used both for Modified and Created fields because... Trac.
Core: 42 reports use Modified field only, 1 uses Created field only and 2 use them both
Meta: _5 reports use Modified field only, 9 uses Created field only and 0 use them both
Also, it's not possible to determine, based on the field order only, if the output should be Created or Modified since there are 17 combination of the fields used in the core reports and 14 combinations used for the meta reports. see this sheet pulled from Trac
Conclusion: I suggest using a generic field for both of them: Date.
It may make some wonder: Created date or modified date? (the answer: the type of date specified in the report table header) but it doesn't misinform by displaying wrong label.
See before and after ( the after includes 4917.reports.4.patch )
Note: the patch is a development of this proposed CSS snippet
#21
@
4 years ago
- Better accessibility for report listing (mobile) ( 4917.reports.4.patch )
- in order to have more contrast and better see when a ticket ends/starts, this sets border color ( for
.prio[3-6]
and.color[3-6]
) to the same color of the text (in most cases). - to be easier to read, this increase tickets attributes font size
- breaking point - same as 4917.reports.3.patch:
770px
Bug screenshot