#18211 closed enhancement (fixed)
Paint the Tracshed
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | WordPress.org | Priority: | normal |
Severity: | normal | Version: | |
Component: | WordPress.org Site | Keywords: | |
Focuses: | Cc: |
Description
The new logo and accent color is nice, but it would be cool if a designer would be willing to do a sweep of our Trac design, perhaps turning the yellows into grays, and what not.
Both ocean90 and helenhousandi have expressed interest. I'd be curious to see what people come up with. CSS and screenshots would be great. (Can just paste the CSS into a comment, surrounded by {{{
and }}}
.)
My suggestions are cool colors, easy on the eyes, appropriate contrast... Nacin is getting old and going blind.
Attachments (11)
Change History (51)
#4
@
13 years ago
I like where @ocean90 went with the top nav, so I went with it: http://cl.ly/282Q2J0f1o1U03471P1L/o
What are thoughts on jumping to sans-serif with a nice line-height on Trac to match wp-admin? Or is that too hot pink, I don't know. Going with sans-serif as opposed to Verdana meant that I generally upped any percentage sizes by about 5, some/most of which I didn't include below.
Added some hits of WP orange, and link hovers would also be that orange without the gray background. Lots of other places to get rid of the yellow tinge (code, hovers in timeline, etc.), but I did give pre areas a little yellow. Can work on other views. Also added some padding and fixed some alignment issues under modify, especially the CC: checkbox that was floating out in the middle of nowhere, at least for me. Edit: And I forgot the attachments box. Oops.
Some of the CSS:
body, th, tr { font: 13px/1.5 sans-serif; } h1, h2, h3, h4 { font-family: sans-serif; } :link:hover, *:visited:hover { color: #D54E21; } input[type="button"], input[type="submit"], input[type="reset"] { background: #EEEEEE; border: 1px outset #CCCCCC; color: #222222; font-size: 0.9em; padding: 0.1em 0.5em; } input[type="button"]:hover, input[type="submit"]:hover, input[type="reset"]:hover { background: #CCCCCC; } input[type="text"]:focus, input.textwidget:focus, textarea:focus { border: 1px solid #888; } legend { color: #D54E21; font-size: 95%; font-weight: bold; padding: 0 0.25em; } #search input { font-size: 11px; } .nav ul { font-size: 11px; } #mainnav { background: #F9F9F9; border: 1px solid #CCC; font: 12px sans-serif; margin: 0.66em 0 0.33em; padding: 0.2em 0; } #mainnav *:link, #mainnav *:visited { border-left: 1px solid #CCC; border-right: 1px solid #FFF; } #mainnav .active *:link, #mainnav .active *:visited { background: #D54E21; border-right: 1px solid #D54E21; color: #F9F9F9; font-weight: bold; } #ticket { background: #F9F9F9; border: 1px solid #D7D7D7; } #ticket .date { color: #888888; font-size: 85%; } #ticket table.properties td, #ticket table.properties th { font-size: 85%; } #ticket table.properties th { color: #666666; } #ticket .description h3 { border-bottom: 1px solid #DDDDDD; color: #666666; } #ticket .description h3 .lastmod { font-size: 90%; } #action div { padding: 0.3em 0; } p.hint, span.hint { color: #666666; font-size: 90%; } #properties table td { padding: 0.4em; vertical-align: top; } #ticket table.properties td, #ticket table.properties th { font-size: 85%; } #properties .col2 #field-cc { width: 2em; }
#5
follow-up:
↓ 6
@
13 years ago
"WP orange" should be avoided if possible... it's a leftover from 2.5 that I've meant to eradicate from the admin but keeps cropping up.
#6
in reply to:
↑ 5
;
follow-up:
↓ 7
@
13 years ago
Replying to jane:
"WP orange" should be avoided if possible... it's a leftover from 2.5 that I've meant to eradicate from the admin but keeps cropping up.
Got it - didn't know. I should probably have called it "the orange from .org". Are there guidelines for a highlight color, or is sticking to blue/gray the way to go?
#7
in reply to:
↑ 6
@
13 years ago
Replying to helenyhou:
Got it - didn't know. I should probably have called it "the orange from .org". Are there guidelines for a highlight color, or is sticking to blue/gray the way to go?
We keep meaning to give wordpress.org a facelift but keep making software instead. :) I think there's room for suggestion on alternate highlight colors. For that matter, go ahead and use the orange, it can always get changed later.
#8
follow-up:
↓ 11
@
13 years ago
One oddity with Trac is the highlighting of tickets in reports. I've yet to determine why some tickets are highlighted yellow, some red, and others not. It doesn't seem to be related to ticket priority, ticket severity, or ticket keywords, but I could be wrong.
Anyone care to explain or improve the highlighting?
#9
@
13 years ago
I'd also love to know how exactly the highlighting is determined without digging into Trac (Python?!); it doesn't seem consistent at all. It's also a little confusing because there's some alternate row striping going on but when they don't really alternate it just looks like there are different colors.
My question would be who uses the highlighting as a visual cue and in what way? If people are used to it, it might not be worth changing, but if it could be more usable somehow, we should roll that in.
#10
@
13 years ago
Finally got around to a first real pass: http://cl.ly/1Y19392i0I3U3d3a3Z0U (zip file). Going to refine for mobile (maybe/maybe not actually responsive) in a bit.
The CSS from /chrome/common/css is in there; if I remember correctly, most files have at least something changed. There's an extra one that I called inline.css that contains what most views, if not all, had in the head with a couple of changes. Don't know why they're in the head if it's always the same, but I don't know much about Trac's inner workings.
It looks essentially like the screenshot I posted a couple months ago, with some light blue for th's in the diff and browser and pulling out a couple references to the orange. Can post more if you'd like to see. It's also totally possible that I've missed stuff in the admin, since I can't actually see it.
#11
in reply to:
↑ 8
@
13 years ago
Replying to johnbillion:
One oddity with Trac is the highlighting of tickets in reports. I've yet to determine why some tickets are highlighted yellow, some red, and others not. It doesn't seem to be related to ticket priority, ticket severity, or ticket keywords, but I could be wrong.
Anyone care to explain or improve the highlighting?
The highlighting is done by us in the report SQL. In some reports, they have to do with priority or severity (or both), in others, who knows. We can go through and clean those up or add keys to the report descriptions.
How it works: http://trac.edgewall.org/wiki/TracReports.
#12
follow-up:
↓ 13
@
13 years ago
I'll check out the latest patch from helenyhou. One thing though, for maintenance reasons it might be easier if we had a single CSS file of overrides (like a child theme first importing the parent theme's style.css). That way our Trac updates hypothetically go smoother, and maintenance/deployment is less crazy. I'll take a look at what it takes to just switch out the theme, though.
#13
in reply to:
↑ 12
@
13 years ago
Replying to nacin:
it might be easier if we had a single CSS file of overrides
I can definitely pull out the changes if that's the easiest/best way. Should really look at how Trac works one of these days...
#14
@
13 years ago
Uploaded a CSS file with mobile/responsive stuff in it. A couple of changes are needed in the usual CSS as well, so I will extract those changes and attach shortly.
Mobile devices need a viewport meta tag in the head:
<meta name="viewport" content="width=device-width, initial-scale=1">
#16
in reply to:
↑ 15
@
13 years ago
Replying to ocean90:
helenyhou, is it still the same screen from above?
More or less, yeah. Took out the orange for the fieldset legends and did a tiny bit of shuffling for the #mainnav so it works on mobile. Mobile-wise it looks essentially the same, just a few tweaks.
I'm pulling out all my changes into one override file now, so tweaking it should be easy :) Any suggestions?
#17
follow-up:
↓ 18
@
13 years ago
wptrac.css contains all of the CSS changes for the regular CSS files and also some changes/additions to that pesky internal/inline stylesheet. It needs to come before all internal/external stylesheets but before the mobile one.
If you make all rules important, you can also try it out as a user style. Just watch out for the one rule that is already important, and the second to last rule seems to do something different in a user style than it does otherwise.
#18
in reply to:
↑ 17
@
13 years ago
Replying to helenyhou:
wptrac.css contains all of the CSS changes for the regular CSS files and also some changes/additions to that pesky internal/inline stylesheet.
You can go ahead and pull all of those inline rules into this file. That was just us being lazy.
#19
@
13 years ago
Should be noted though that a touch of the inline rules are actually for the benefit of the bbPress and BuddyPress stylings:
.wp-notice { background: ${bg_color}; border: 2px solid ${accent_color} } . . . :link, :visited, dt em, .milestone .info h2 em, #content.build h2.config :link, #content.build h2.config :visited { color: ${accent_color}; }
Here's what we use in our templating file:
if project_slug == 'bbpress' : profile_link = 'http://bbpress.org/forums/profile/' support_link = 'http://bbpress.org/forums/' accent_color = '#080' bg_color = '#eaf9ed' elif project_slug == 'buddypress' : profile_link = 'http://buddypress.org/community/members/' support_link = 'http://buddypress.org/support/topics/' accent_color = '#d84800' bg_color = '#fff3ec' else : support_link = 'http://wordpress.org/support/' profile_link = 'http://profiles.wordpress.org/users/' accent_color = '#21759b' bg_color = '#eff6f9'
If there are any colors that should be tweaked across the different color schemes, we can continue to sprinkle in a few more inline styles.
#20
@
13 years ago
Oh, that said, I originally had code that simply gave a different body class to each project, so body.bbpress, body.buddypress, etc.
Since we're pulling this out into an external stylesheet (one we can put on s.wordpress.org as a static file), I'm fine with adding that back and pulling out the colors from the python above.
#21
@
13 years ago
Replying to nacin:
You can go ahead and pull all of those inline rules into this file. That was just us being lazy.
HA. Done. I combined some rules into other areas but a lot of it I just left as a little block of "Formerly internal" down at the bottom.
Replying to nacin:
I'm fine with adding that back and pulling out the colors from the python above.
I put the bbPress and BuddyPress stuff at the very bottom of wptrac.css. Take a look and let me know if I mixed it up or anything.
#22
follow-up:
↓ 23
@
13 years ago
I just downloaded wptrac.css
. Good job!
Some points:
- Still the "WP orange" in menu? on wp.org the color is only used for the download buttons, can be confusing.
- On timeline: If you hover of an item the icon on the left will be removed.
- Commit messages have a light grey background http://cl.ly/ARaB
- Do we need the hover background color for the properties?
- Changeset view: http://cl.ly/ASC7
#23
in reply to:
↑ 22
@
13 years ago
Replying to ocean90:
Thanks!
- Still the "WP orange" in menu? on wp.org the color is only used for the download buttons, can be confusing.
It can be blue instead, the more I look at it the less it seems to need to stand out as much. BuddyPress and bbPress Trac will also have their respective accent colors there as I have it, so it would make more sense for it to be blue, as BuddyPress uses a pretty similar orange.
- On timeline: If you hover of an item the icon on the left will be removed.
I actually see a different problem (it repeats instead, even worse), but I'll take a look at that.
- Commit messages have a light grey background http://cl.ly/ARaB
I don't see that - which view is this on?
- Do we need the hover background color for the properties?
This might be because of the !important in a user style if you're using it that way; when I have it linked as CSS it only does it to the links. I can make it more specific to be safe, though.
- Changeset view: http://cl.ly/ASC7
I see it, will work on it. Glad you looked :)
#24
follow-up:
↓ 25
@
13 years ago
Some of the stylesheets being overridden here are only loaded on specific pages.
Example, report.css has one selector: .tickets tbody tr:hover
, which then provides a background over the row. This selector also matches the ticket properties area on a ticket view. This is what ocean90 reported above.
Trac uses a class on div#content to provide context (among other things, I imagine). For example, div#content.report will limit it to reports. Or probably just div.report, etc.
Still going through the changes. Looks great so far. Commenting the intent of some tweaks would be helpful. (The inline CSS actually has comments in them, but they don't get printed here.)
The on-state for the menus is pretty useless. Even a gray is fine. I'd even consider killing orange for the link on states, and go back to the current hover state. It's easier on the eyes for someone who could easily spend five or six hours browsing Trac at a time.
#25
in reply to:
↑ 24
@
13 years ago
Replying to nacin:
Some of the stylesheets being overridden here are only loaded on specific pages.
I'd even consider killing orange for the link on states, and go back to the current hover state. It's easier on the eyes for someone who could easily spend five or six hours browsing Trac at a time.
Beat me to the punch - was fixing up specificity and took out the rest of the orange on a plane last night :P
Commenting the intent of some tweaks would be helpful.
Put some comments in. I guess you'd probably minimize the served version anyway.
Attaching a revised version that should address the issues and also puts the mobile/responsive stuff at the bottom. I made the nav menu on-state blue and then used the highlight color for BuddyPress and bbPress, but it'd also be fine as #333
for all of them instead. If you don't use the menu much, you/I can reduce or take out the vertical padding for the menu items in the responsive part to save some space.
#26
follow-up:
↓ 27
@
13 years ago
Looks much better now. But I think we have now too much blue on the timeline.
Has nothing to do with colors, but can we add
.comment img { max-width: 100%; }
to prevent overflowing, see ticket:18197#comment:74.
#27
in reply to:
↑ 26
@
13 years ago
Replying to ocean90:
Looks much better now. But I think we have now too much blue on the timeline.
Hmm, what else is blue besides the links? Maybe I'm not seeing something you are :)
Has nothing to do with colors, but can we add
.comment img { max-width: 100%; }
Definitely, that drives me nuts. I'll add that and update wptrac.2.css
.
#28
follow-up:
↓ 29
@
13 years ago
Hmm, what else is blue besides the links? Maybe I'm not seeing something you are :)
http://cl.ly/ARaf - The ticket title shouldn't be blue.
#29
in reply to:
↑ 28
@
13 years ago
Replying to ocean90:
The ticket title shouldn't be blue.
Huh. Are you doing this as a user style? I'm on a different machine right now and don't have that set up at the moment. When the link color rule is !important
it ends up overriding the black for the timeline dt
links but it doesn't do it when it's just a normally linked stylesheet.
#30
follow-up:
↓ 31
@
13 years ago
Sorry, yes. I was using the Chrome addon Stylebot. It uses !important. Tested again with Stylish and it looks good. :)
One thing, #field-cc is not always a checkbox. I have a text input there.
This should work:
#properties .col2 #field-cc[type="checkbox"] { width: 2em; /* fix the cc checkbox */ }
#31
in reply to:
↑ 30
@
13 years ago
Replying to ocean90:
One thing, #field-cc is not always a checkbox. I have a text input there.
I was wondering how some of you were CC-ed with your username and not email@. Will refresh wptrac.2.css
again with that. Does it look fine with the text input? The checkbox ends up outside of the #properties
box currently: http://cl.ly/2a0U1H0B1a320x1N263t
#33
@
13 years ago
For less shock to your eyes: wptrac.6.css takes out the font change.
#34
@
13 years ago
It's almost like a tracking ticket for myself... but wptrac.7.css adds the blue gradient from the uploader/pointers to the progress bars. And makes the header more compact for small screens.
Gradient screenshot: http://cl.ly/0n3j29163J2g370o3n08
#35
@
12 years ago
With the recent changes, the font of ticket properties became too small on Windows (18211.table-font.png, top).
Current font size is 80%, used to be 81%. Could we restore the previous value?
#ticket table.properties td, #ticket table.properties th { font-size: 81%; }
#36
@
12 years ago
Header image is larger now, so it collides at narrower screen sizes, and since it has a defined height, gets stretched. Perhaps as a quick fix for the 640px media query (would love to do something better because search looks ugly):
#header img { max-width: 40%; /* prevent the logo and search from colliding (to a point) */ height: auto; }
Screenshot: http://cl.ly/3k210u1d2M1Z2V0Q2P0R
CSS Code: