Trac UI re-design or update effort

[lkraav <leho@…>]

I've queried ​http://trac.edgewall.org/query?status=assigned&status=new&status=reopened&summary=~interface&order=priority now for "interface", "css" and I am not seeing any related tickets.

[imho=ON] This has been bugging me for a while. Trac's UI is so antiquated it hurts. So I've been thinking something like this ​http://wpthemes.jayj.dk/japibas/ and actually have a somewhat implemented ThemeEnginePlugin (screenshot attached, patch to follow). This idea came from seeing this originally Wordpress theme ported to a now-deceased Python blog engine Zine (Pocoo!).

Ignore the colorscheme for now (should be user-customizable anyway), but decent looking tabs, search box and human-readable font-size, please!

I think it is time to make an effort to get Trac UI from 2004 into 2011. This could easily be a step by step thing, as it's only the header that demands attention first and foremost. So 0.13 should be quite achievable.

[lkraav <leho@…>]

Trac13 theme initial mockup

[Christian Boos]

Here we go… colors and tastes…

But I agree that at least the navigation list should be fixed. We need to have the "tabs" wrap nicely, not something fixed like what seems to be the case for your model "japibas".

It seems osimons fixed that for his own Trac instances (​epicode). Any chance to adapt this to upstream, Simon?

[lkraav <leho@…>]

well I thought I wrote "colors are non-issue", but perhaps "colors and tastes" is just a figure of speech.

i like osimons' stuff. even colors, ha-ha! i just don't understand fascination with microfonts as default in this high resolution age.

who is able to or wants to read or aim for these small buttons every day when Trac is supposed to be a primary workflow tool?

stackoverflow just had a ​blogpost with some user screen size analytics. it should be a good enough userbase/type matching set. i happen to have a 3 monitor setup with 19" 1280x1024, laptop 17" 1680x1050 and portrait 23" 1080x1920. epicode's and trac's default navbar font (and epicode's) size becomes painful on anything greater than 1280x1024, which is pretty much on it's way out for coding. can this really be considered my-specific and subjective?

font/tab size does become a problem with trac's extensibility when you have lots of resource handlers that all want their own tab. from what i've seen with a large majority of "regular" projects, additional resource handlers are rarely installed. epicode's tab set is definitely above a regular installation.

which means if you can fit Trac's standard distribution set of handlers nicely with some space left over for a couple of more, you will satisfy almost everyone. edge cases already know what to do anyway to get their 20 buttons to fit.

i'll wait for a few more comments esp. from osimons, until i post a first patch.

[lkraav <leho@…>]

perhaps the question "who wants to" could be answered after a while with some sort of a poll. it'd be nice if the poll was embeddable from an external app inside ticket description, is it possible to do that on t.e.o?

[Christian Boos]

Replying to lkraav <leho@…>:

… just don't understand fascination with microfonts as default in this high resolution age.

Making easier to customize the fonts corresponds to #633.

… trac's default navbar font (and epicode's) size becomes painful on anything greater than 1280x1024, which is pretty much on it's way out for coding. can this really be considered my-specific and subjective?

That's quite subjective, yes. For example I have a 1920x1200 screen size and the font sizes seem to be just fine to me.

On the topic of big screens, note that the side-by-side edit mode for Wiki page was just designed for that ;-)

[osimons]

My changes are all done via css, plugins and site.html so there should be no reason why they should not be easily transferable to Trac source itself. Overriding is a lot harder than fixing the original source ;-)

Some things like tabs for menus is actually very easy, but other things like context menu, logo placing and general header flow was a lot harder. Some things like breadcrumbs and 'last-modified' information is put in place with millimeter-precision tied to Trac default design, and just proved to be more hassle than it was worth to re-style ({display: none} to the rescue…).

That said, making 'design' an important project goal in itself will no doubt lead to a lot more 'tweaks' that will provide harder to override by others and by themes. I'm all for redesigning parts of default Trac and making it a bit more fresh, but I wont be keen on changes that introduce lots of style directives for detailed placement.

The design needs to be fresh, but work to keep (and improve) a standard and straight forward flow of elements.

[Christian Boos]

Replying to osimons:

My changes are all done via css, plugins and site.html so there should be no reason why they should not be easily transferable to Trac source itself. Overriding is a lot harder than fixing the original source ;-)

So this means you're OK if we grab your CSS for tabs, for default Trac?

Some things like tabs for menus is actually very easy, but other things like context menu, logo placing and general header flow was a lot harder. Some things like breadcrumbs and 'last-modified' information is put in place with millimeter-precision tied to Trac default design, and just proved to be more hassle than it was worth to re-style ({display: none} to the rescue…).

Right, it's more complex than it should be, I'm all for simplifying it (which unfortunately probably means breaking existing customized layouts).

… I'm all for redesigning parts of default Trac and making it a bit more fresh, but I wont be keen on changes that introduce lots of style directives for detailed placement.

The design needs to be fresh, but work to keep (and improve) a standard and straight forward flow of elements.

Agreed.

[osimons]

Replying to cboos:

So this means you're OK if we grab your CSS for tabs, for default Trac?

Sure, no problem providing my changes as 'inspiration' - just don't force me to redesign to keep a distinct look ;-)

[Christian Boos]

Replying to osimons:

Replying to cboos:

So this means you're OK if we grab your CSS for tabs, for default Trac?

Sure, no problem providing my changes as 'inspiration' - just don't force me to redesign to keep a distinct look ;-)

No worries, I'm only interested in getting the nice tab wrap ;-)

[Christian Boos]

See also past discussion in TracProject/UiGuidelines.

[andhos@…]

Please don't change the Trac design. It is very clean and good looking and one of the main reasons I chose to use Trac. As for customizeability i'm all for it, but keeping a default clean look is important for a first impression because different people have different taste. We can take for example epicode. It is not to my taste. no disrespect.

[Christian Boos]

Nothing like an overhaul, but I just committed two style enhancements (r10663 and r10664) taking benefit from a few CSS3 features that seem to be well supported now by all major browsers. I hope people will enjoy the change ;-)

[anonymous]

Replying to cboos:

I hope people will enjoy the change ;-)

Very good. If there was such shading also for the menu, it would be a pretty style.

[Christian Boos]

Replying to anonymous:

Replying to cboos:

I hope people will enjoy the change ;-)

Very good.

Thanks!

If there was such shading also for the menu, it would be a pretty style.

Actually that's what I have next in the pipeline (also #4926), but I had very little time for Trac lately so don't hold your breath ;-)

[anonymous]

Initial theme is nice and clean! I really hope that you do not change the UI toward what is proposed here, which I think is awkward and bloated.

[anonymous]

I really hope also that you do not change the UI toward what is proposed here, which I think is awkward and bloated. it's really not awful it fits exactly what it is a very often used TOOL in development and not a overdesigned website!

[Christian Boos]

Hm, am I the only one to suspect comment:14 & comment:15 to be trolling? Dear anonymous, be more specific and don't copy/paste your own message from one comment to the next, please. If you're not trolling, at the very least can you precise what you mean by "what is proposed here"? Do you have some specific proposition from the above comments in mind, or is it in general a stance against "any change", or do you simply refer to the current style of trac.edgewall.org?

[kblomqvist]

comment:14 and comment:15 are unique. I was the original poster of comment:14. By "what is proposed here", I mean the attached screenshot. I do not have any specific proposition in mind and I'm not generally against "any change", but why change the functional and clean theme to (refering to comment:15) overdesigned website. I really prefer the current style, so please do not overdesign it.

[Mikael Relbe]

Please have a look at the just-released ​th:WikiExtrasPlugin, which allows you to add styled boxes on a wiki page, where styling is in line with changes in [10663-10664].

[Xeross]

Even though Trac's design might not be "up-to-date" it's clean, and does what it has to do. I actually kind of like the current design.

[Ryan J Ollos <ryano@…>]

I like the larger tabs on the mainnav in the proposed theme. +1 for making the tabs and some selected text stand out, as the reporter has proposed.

[Christian Boos]

Mh, maybe it's time to post my work in progress (updated from time to time over the last month), for further discussion… Please have a look at demo-0.13, which today corresponds to [7672:7676/cboos].

[lkraav <leho@…>]

cboos, NICE. this fits totally with my own work in progress, gonna rebase and post it later tonight.

[Remy Blank]

Just a few quick comments (after 2 minutes of testing):

• On Firefox 3.6, the navbar doesn't extend to the edges of the page, and there's a missing right border.
• The tabs have the wrong orientation. The rounding should be at the top of the tab, not at the bottom.
• If find the shade around the main content distracting. I understand it separates the content from e.g. the links at the bottom of the page, but maybe there's a less visually-loaded way to do that.

[Christian Boos]

Replying to rblank:

Just a few quick comments (after 2 minutes of testing):

• On Firefox 3.6, the navbar doesn't extend to the edges of the page,

This is due to the usual body margins (i.e. it's the same in demo-0.12).

and there's a missing right border.

There's a small overlap of each tab to the right, I can counterbalance this with a #mainnav { margin-right: .1em } but I think it looks better without. Same with the #mainnav li { border-right: none } setting, it looks better with the right border disabled.

• The tabs have the wrong orientation. The rounding should be at the top of the tab, not at the bottom.

Well, that's intentional. I've tried several variants and this is the one which I find looks best, especially when the tabs wrap around with a narrow window size. The "flat" side must stand on something, and when the tabs wrap around you end up with no "support" if the rounding is at the top:

(the first also has border-right: none; disabled)

• I find the shade around the main content distracting. I understand it separates the content from e.g. the links at the bottom of the page, but maybe there's a less visually-loaded way to do that.

Right, maybe something like: #content { 0 .5em 3em #e4e4e4, 0 0 1px #666 inset; } which is a bit smoother.

But if you don't like at all the shade around the main content… well, give it a chance by trying to get used to it for a bit more time ;-)

[Remy Blank]

Replying to cboos:

This is due to the usual body margins (i.e. it's the same in demo-0.12).

No, the demo-0.12 instance looks fine, and the right border is fine, too.

Well, that's intentional. I've tried several variants and this is the one which I find looks best, especially when the tabs wrap around with a narrow window size. The "flat" side must stand on something, and when the tabs wrap around you end up with no "support" if the rounding is at the top:

It's not a question of look, it's a question of mental model. The tab is a model for physical tabs in e.g. a binder. The tabs stand on the page, and the rounding is opposite to the page. If you do the opposite, it looks confusing. Then you had better not use any rounding at all, so the user isn't reminded of the physical model.

Also, when putting the rounding at the top, you shouldn't have a shade below the tab, as that never happens with physical tabs. That's probably the reason why your first example looks weird.

But if you don't like at all the shade around the main content… well, give it a chance by trying to get used to it for a bit more time ;-)

It's not a question of getting used to a new look, it's a question of look vs. functionality. I'd rather not have any pure eye candy, as it just distracts from the real content. As I see it, the only function of the border is to separate the main content from the footer. There's probably a better way to achieve that (e.g. a simple separation at the bottom) than adding a full frame with shadow.

[Christian Boos]

Replying to rblank:

Replying to cboos:

This is due to the usual body margins (i.e. it's the same in demo-0.12).

No, the demo-0.12 instance looks fine, and the right border is fine, too.

Hm, then I don't see what you mean as for the demo-0.12, the navbar doesn't extend to the edges of the page either:

This is in Chrome, I don't have FF 3.6 anymore but in FF 5.0 it looks the same.

It's not a question of look, it's a question of mental model. The tab is a model for physical tabs in e.g. a binder. The tabs stand on the page, and the rounding is opposite to the page.

Well, that model doesn't stand when wrapping the tabs, as we don't reorder the tabs so that the currently selected one stays close to the page (and such a reordering would be highly confusing - Win95 did that a lot IIRC).

If you do the opposite, it looks confusing. Then you had better not use any rounding at all, so the user isn't reminded of the physical model.

Ok, I can live without the rounding, even if I still think it was a bit nicer and not confusing with it ;-)

Here's how it would look, on a wide and narrow page size:

It's now more a button than a tab, though, and I think having a shade below is perfectly fine in the examples above.

But if you don't like at all the shade around the main content… well, give it a chance by trying to get used to it for a bit more time ;-)

It's not a question of getting used to a new look, it's a question of look vs. functionality. I'd rather not have any pure eye candy, as it just distracts from the real content.

For me on the contrary it's a way to emphasize the actual content.

As I see it, the only function of the border is to separate the main content from the footer. There's probably a better way to achieve that (e.g. a simple separation at the bottom) than adding a full frame with shadow.

Not only with the footer, but also with the #pagepath and the #ctxnav, as you can see in the screenshots above. I even think we can move the Last change link back to the #ctxnav (yes I know, I kept changing this back and forth, #2635, #8488).

[Christian Boos]

The proposed #mainnav, with straight borders, on a single line

[Christian Boos]

The proposed #mainnav, with straight borders, on multiple lines

[Christian Boos]

The #mainnav in stock Trac 0.12

[Remy Blank]

FWIW, the current design on demo-0.13 is nice, and I'll get used to the frames around the main content (or deactivate it in my installations, shouldn't be too difficult). The only small thing I notice is that the background image on the navbar for inactive tabs looks weird in FF 3.6, somehow it doesn't seem to repeat vertically. Other than that, I would say it's good to go, and we can still tune on trunk if necessary.

[Christian Boos]

Testing a bit here before merging… For the #mainnav, it's slightly different from what you could see in a stock Trac (as in demo-0.13), as some adaptations were in order to better integrate with the overall look of edgewall.org sites (project013.css).

Feedback welcome, this is just a checkpoint.

[Remy Blank]

There's an issue here on t.e.o when displaying the properties of a changeset: the property names are pushed into the left border. See for example [10770]. It must be specific to this instance, as it doesn't happen on the demo-0.13 site.

[Christian Boos]

Replying to rblank:

… the property names are pushed into the left border.

I traced that down to the removal of position: relative on #content. I couldn't see why this setting was there, so I cleaned it up…

Note to self: I should one day read something about this position attribute (and CSS in general ;-) )

[anonymous]

The new mainnav doesn't look very different compared to the old one. I wish you took more courage for a stylish mainnav… :) as you did with the shaded buttons.

[Carsten Klein <carsten.klein@…>]

Definitely looks nice, great job. Except for the left, right + top border on the container of the main navigation tab bar. Removing these borders and combining this with the rounder upper corners would IMO do the trick.

[Carsten Klein <carsten.klein@…>]

Speaking of revamping this.

Please remove the outset borders on the comments and attachments in a ticket. They merely clutter up the view.

And, believe it or not, the outline borders of the content area on the ticket IMO could also be removed, leaving just the shadows, if any.

[Carsten Klein <carsten.klein@…>]

And while we're at it: why do embedded images like the above get rendered as tables? Wouldn't a div container and img suffice?

[franz.mayer@…]

I just updated our Trac instance to r10854 and got praise that "the new layout looks cool". Just wanted to extend the compliment to you.

[anonymous]

Why not let the main menu look like the tab page headers on ​http://trac.edgewall.org/prefs/advanced?

[anonymous]

May be need theme like - Lighthouse? ( ​http://userscripts.org/scripts/show/37887 )

in work: ​http://lighthouseapp.com/tour

The default theme is outdated. I believe that to promote the Trac need change the default theme.

[lkraav <leho@…>]

Tonight, @falkb mentioned #10012 on #trac and I put a couple of thoughts out there on top of that:

01:57       falkb I'm curious how "10012 Trac UI re-design or update effort" will be solved
01:58      rblank falkb: I don't know what else Christian has in mind, but I think most of it is
                  visible on t.e.o already (rounded boxes, shadows, and IIRC the nav bar wraps
                  correctly).
01:59      macmaN>falkb: what about it?
02:00       falkb>macmaN: What do you mean with "it"?
02:00      macmaN>falkb: my experience with working on #10012 type stuff commercially every day,
                  is you need a UX-experienced designer to draw some sketches for different views
02:00      macmaN>unfortunately that usually doesn't come for free
02:01      macmaN>nor cheap. unless the designer himself is a particularly big fan of trac.
02:01       falkb I very like the new shaded selection boxes, and was just hoping the mainnav
                  follows that style until #10012 closes
02:02      macmaN>until then, i have a few more simple ideas i will present in #10012 shortly
02:02      macmaN>but i dont expect miracles, i think it already achieved a few very nice things
02:06      macmaN>that being said, i might go ahead and order a view sketches from my designer
02:06      macmaN>i think it'll be a some hundred € well spent

Let's say hypothetically I get some price agreement with my designer. I would then give him some guidelines on what to focus on compared to the current UI. This means I could use some kind of poll-style input on what people here would like to see changed. Also the output needs to be somehow sanitized. I don't have comment editing privileges here, otherwise I could just dedicated a single comment to keeping track and editing that as new suggestions come in. So my question is how would you smart folks suggest I gather this info?

Do cboos or other core guys mind if users just jot stuff down in this ticket with comments? Or I open a new ticket? Use some external shared tool.. which would be what, suggestions?

Just to be clear, if I undertake the paid design project, I fully understand I take all the risks including none of it making it to the core etc. That's not the point. Point is to get something fresh visible for discussion and juices flowing in a timely fashion. At the end of the day, whatever my guy comes up with, in the worst case I can always theme just my own Trac instances with it.

[Christian Boos]

Sorry for the timely fashion side of things ;-)

I do have a few pending changes regarding the UI, and I'm getting to the point of reviving this branch, and then that branch will be on display on demo-0.13. Feedback and suggestions could be added here, or new tickets could be created for specific points (like e.g. #10592).

If there are really lots of things to present and discuss, a TracDev/ScratchPad/CommonUi page for example could be started.

I'm not sure anyone noticed yet, but since a few months the ticket descriptions are freely editable by everybody, so if you start a proposal in a ticket, its description can be amended and expanded over time.

But tweaking the .css is often a highly personal thing, and I'm glad that the current changes are relatively well perceived. More of them soon ;-)

[lkraav <leho@…>]

timely fashion was not at all aimed at this ticket's pace. More like money is very likely the quickest way for me to get anything new and worthwhile visible.

Yes, indeed, after getting some sleep, a wiki-page also popped into my mind as a good place to gather input. :)

[Christian Boos]

Btw, I'll start with an example: the annoying .closed {text-decoration: line-through}, which makes things unreadable. It's barely OK for numbers, but as soon as you have text, it's really bad. And crossing a milestone can make you think the milestone was cancelled or invalid, not "completed".

It signifies one of two meanings. In ink-written, typewritten, or other non-erasable text, the words are a mistake and not meant for inclusion. When used on a computer screen, however, it indicates recently deleted information. It can also be used deliberately to imply a change of thought — ​Wikipedia:Strikethrough

One could say that the convention closed→strikethrough is well established for ticket numbers, and maybe we should keep it just for this, but for other things even link to comments inside tickets, like ticket:525#comment:10, an alternative would be better.

Such an alternative could be a border (the text is en"closed"), compare the current: with:

[Christian Boos]

RoadMap@47 closed by a border

[Christian Boos]

RoadMap@47 current state

[Peter Suter]

How about something like .closed:after { content: "✓" }:

(or some other Unicode character like ☑ or maybe a custom designed icon.)

[Peter Suter]

RoadMap@47 closed by a Unicode checkmark character

[lkraav <leho@…>]

On topic of icons, this is what github recently came up with: ​a dedicated icon font

Side note: Trac's wiki syntax for URLs completely whips StackOverflow's. Raise your hand if you are ever able to remember what their ()[] crappy syntax is after using Trac.

[Peter Suter]

Also: ​Octicons (The icon font used on github itself)

[Christian Boos]

Replying to lkraav <leho@…>:

Side note: Trac's wiki syntax for URLs completely whips StackOverflow's. Raise your hand if you are ever able to remember what their ()[] crappy syntax is after using Trac.

… well, StackOverflow and GitHub are both supporting the MarkDown syntax for URLs, so I think you'll now probably find more people knowing the [target](url) Markdown syntax than people knowing MoinMoin / Trac's original one [url label] (though the new WikiCreole compatible one [[url|label]] is probably familiar to most as well, due to its use in MediaWiki). This means that at some point, it would be nice to also support [target](url) as well ;-)

[Christian Boos]

Replying to psuter:

How about something like .closed:after { content: "✓" }:

Looks even better I think!

The spacing is however a bit too narrow:

• #10012✓, #10734,#978✓,#31, #108

If we add a space, it's a bit too much (or is it?):

• #10012 ✓, #10734,#978 ✓,#31, #108

A different possibility would be to put it before:

• ✓#10012, #10734,✓#978,#31, #108

Or, as you suggested:

• ☑#10012, #10734,☑#978,#31, #108

(but that symbol is really too small)

No need for an icon, in this case, I think ✓ is plain clear and nice by itself (except in Opera, where it looks like it's a raster font).

Finally, if we go that way, we'll have to adapt again for copy/paste…

Ok, I think I found the winner ;-) :

• #10012 ✓, #10734,#978 ✓,#31, #108

'NARROW NO-BREAK SPACE' (U+202F)

[Ryan J Ollos <ryano@…>]

Replying to cboos:

Ok, I think I found the winner ;-) :

• #10012 ✓, #10734,#978 ✓,#31, #108

'NARROW NO-BREAK SPACE' (U+202F)

Looks really great, +1. I'd just note that the U+202F characters are displayed as narrow rectangular boxes in the email client and browser of my Android 2.3.5 phone. Finding something that displays nicely in every browser is probably impossible these days though.

[Christian Boos]

Replying to Ryan J Ollos <ryano@…>:

Replying to cboos:

… 'NARROW NO-BREAK SPACE' (U+202F)

… I'd just note that the U+202F characters are displayed as narrow rectangular boxes in the email client and browser of my Android 2.3.5 phone.

Oh, too bad. Then maybe a normal "&nbsp;" with a reduced font-size:

.closed:after { content: " ✓"; font-size: 90%; }

(BTW, I knew I should have created a new ticket ;-) )

[osimons]

Does it matter that 'closed' is not really the same as 'done' (as in typically 'fixed')? Tickets are closed for any number of reasons, and the checkmark does typically denote that work is completed. Are we just substituting one ambiguous style for another?

[Christian Boos]

Replying to osimons:

Most importantly, we're aiming at substituting it to a readable style. I agree we trade the somewhat negative tone brought by strikethrough ("deleted") with the positive one of the checkmark ("ok"). We could use another mark for indicating this negative tone again when needed (presumably ✗, 'BALLOT X' (U+2717)).

For example:

• ticket closed as fixed/worksforme: ✓, otherwise: ✗
• milestone completed: ✓, cancelled: ✗

Creating a dedicated ticket for this topic: #10741.

[Christian Boos]

So I converted my Mercurial branch 10012-css to git in repos:cboos.git:ticket10012/from-hg, then rebased it: repos:cboos.git:ticket10012/from-hg.2. It's part of log:cboos.git@+testing, which is on display on demo-0.13 and soon here if no one shrieks ;-)

[Remy Blank]

Eeeek! ;)

No, actually I quite like the look. I may remove the border and shadow around the content area in my own installations (and I assume this can be easily done with a CSS rule), but I'm fine with it by default.

There's a small glitch on the ticket page, the "Properties" box overflows the content border and shadow, probably because I have set larger fonts. Yes, it doesn't do that in Chrome, so that's the reason. I wonder if it would be possible to set the size of <textarea> fields (and possibly also the "Summary") to always be the full width of the content by default, independent of the font size?

So yes, please commit! I enabled tracopt.versioncontrol.svn.* on the demo site so we can look at the repository views, too.

[lkraav <leho@…>]

Replying to cboos:

So I converted my Mercurial branch 10012-css to git in repos:cboos.git:ticket10012/from-hg, then rebased it: repos:cboos.git:ticket10012/from-hg.2. It's part of log:cboos.git@+testing, which is on display on demo-0.13 and soon here if no one shrieks ;-)

So when I'm looking at ​http://trac.edgewall.org/browser or ​http://trac.edgewall.org/browser/cboos.git there is no indication about what the actual repo address is for cloning :/

[lkraav <leho@…>]

Right, found the info from TracTeam/Repositories, but I'm pretty sure this info should be visible in Browser.

[lkraav <leho@…>]

Replying to cboos:

So I converted my Mercurial branch 10012-css to git in repos:cboos.git:ticket10012/from-hg, then rebased it: repos:cboos.git:ticket10012/from-hg.2. It's part of log:cboos.git@+testing, which is on display on demo-0.13 and soon here if no one shrieks ;-)

Overall great job, cboos. Only Ticket view caught my eye as over-framed. I'd say lose the extra internal solid frames in favor of just having the new-style shadows.

What's your guys stance on 100% min-height pages? It would keep the footer from jumping up and down as you navigate between vertically challenged pages like Prefs and Search, giving the whole thing a more solid app'ish feeling. I could hack up a demo of that.

[Christian Boos]

Replying to rblank:

Eeeek! ;)

No, actually I quite like the look.

Argh! You got me ;-) For half a second ;-)

I may remove the border and shadow around the content area in my own installations (and I assume this can be easily done with a CSS rule), but I'm fine with it by default.

If only we had a decent up-to-date FAQ, it could be just an entry: "Q: How do I get rid of the content border & shadow in 1.0?" "A: add the following rule to your site.css: …" ;-)

There's a small glitch on the ticket page, the "Properties" box overflows the content border and shadow, probably because I have set larger fonts.

Right, I've seen that as well yesterday evening, so it's not just the fonts. I think it was not there originally (i.e. already almost one year ago, when I first wrote the changes).

There are a few other glitches. The major one is #4926.

So yes, please commit!

Perfect, I'll look into doing that later today.

[lkraav <leho@…>]

Replying to cboos:

Replying to rblank:

There's a small glitch on the ticket page, the "Properties" box overflows the content border and shadow, probably because I have set larger fonts.

Right, I've seen that as well yesterday evening, so it's not just the fonts. I think it was not there originally (i.e. already almost one year ago, when I first wrote the changes).

This happens due to #properties { white-space:nowrap; }

There's simply not enough space inside width:58em

[Christian Boos]

Replying to lkraav <leho@…>:

Right, found the info from TracTeam/Repositories, but I'm pretty sure this info should be visible in Browser.

I've set the url property for them, so now you'll find the Repository URL context link there.

(following the link in the browser won't work, it's just meant to be used for git clone and such)

[Christian Boos]

Replying to lkraav <leho@…>:

Replying to cboos:

So I converted my Mercurial branch 10012-css to git in repos:cboos.git:ticket10012/from-hg, then rebased it: repos:cboos.git:ticket10012/from-hg.2. It's part of log:cboos.git@+testing, which is on display on demo-0.13 and soon here if no one shrieks ;-)

Overall great job, cboos. Only Ticket view caught my eye as over-framed. I'd say lose the extra internal solid frames in favor of just having the new-style shadows.

Yes, I tend to agree. I experimented yesterday with removing them. Of course, if someone then also removes the content border, then it's going to be completely frameless…

What's your guys stance on 100% min-height pages? It would keep the footer from jumping up and down as you navigate between vertically challenged pages like Prefs and Search, giving the whole thing a more solid app'ish feeling. I could hack up a demo of that.

Yes, that could be interesting.

[Christian Boos]

Ok, so I've committed the repos:cboos.git:ticket10012/from-hg.2 changes in r11097, and I'll update t.e.o to it in a moment.

There's another set of changes cooking, repos:cboos.git:ticket10012/more-good-stuff:

• [b8df7c83/cboos.git] #10012: added box shadow for h2 sections in timeline, roadmap and query groups.
• [cb2d4052/cboos.git] #10012: in ticket view, reduce usage of internal frames
• [dc9eb175/cboos.git] #10012: fancier boxes for comment threading
• [22bb4686/cboos.git] #10012: now we're having a real wiki…

This is already in +testing and visible on demo-0.13.

[Christian Boos]

Replying to cboos:

… I'll update t.e.o to it in a moment.

Note however that here the #content border is disabled, so if you don't see it, it's normal ;-)

We might re-enable after [cb2d4052/cboos.git].

[lkraav <leho@…>]

Reviewed and +1-ing mostly everything. Still not convinced with the #ticket double border look. Try merging this and see if we can get this down to a single border:

#ticket {
  border-top: 1px solid rgb(221, 221, 153);
  border-right: none;
  border-bottom: 1px solid rgb(221, 221, 153);
  border-left: none;
  margin: 1em -1em 0 -1em;
  padding: 0.5em 2em; /* or 0.5em 1em */
}

I would probably do the same for the properties box down below.

Since #content wants to have its 1em by default, which I think makes sense, we can do -1em on boxes we want to expand to container size.

[lkraav <leho@…>]

Live WikiProcessor preview worked for the CSS above. That was simply awesome.

[Christian Boos]

Replying to lkraav <leho@…>:

Live WikiProcessor preview worked for the CSS above. That was simply awesome.

Heh, not because we fixed anything, but because of comment:49 ;-)

[Ryan J Ollos <ryano@…>]

Replying to lkraav <leho@…>:

Still not convinced with the #ticket double border look.

It does look a bit busy. It might look less cluttered if the two borders had a greater separation on the L and R sides.

The wiki looks really great with the new section headings!

[lkraav <leho@…>]

Replying to lkraav <leho@…>:

#ticket {
  border-top: 1px solid rgb(221, 221, 153);
  ...
}

Not sure why I didn't post a screenshot before. Attaching now.

[Christian Boos]

Replying to lkraav <leho@…>:

Not sure why I didn't post a screenshot before. Attaching now.

jpg or png? ;-) Yes, this is interesting. Probably worth combining with #7197.

[Remy Blank]

Replying to lkraav <leho@…>:

Not sure why I didn't post a screenshot before. Attaching now.

That looks pretty neat. How does this apply to the preview at the bottom?

[Ryan J Ollos <ryano@…>]

Minor detail is that the text runs into the foldable area on the admin plugins panel (image capture from Firefox 13 on Debian 6).

[Remy Blank]

Yes, I'm not a fan of the frames around the foldable section headings either (not only in the plugins admin panel). I would prefer we removed them. They don't add much, and look out of place.

[Christian Boos]

Replying to rblank:

Yes, I'm not a fan of the frames around the foldable section headings either (not only in the plugins admin panel).

They look like "buttons", actionable items. I think it's good to be consistent with this. I don't want them removed for now (notice that the content border was removed yesterday, so it's not like I never change my mind ;-) ).

[Christian Boos]

Talking about the changes I did yesterday, there are two groups:

• Small rounded buttons:
  • [0c268fc1/cboos.git] #10012: rework rounded add/remove buttons in custom query.
  • [fbecb272/cboos.git] #10012: quick buttons for reply/edit/delete in tickets.
  • [161d1b6d/cboos.git] #10012: in deleter.py fix copy/paste error for unicode character BALLOT X

• Border not around the whole #content, rather focused on the actual "text" content (.trac-content):
  • [b61e5326/cboos.git] #10012: reworked wiki view, no content border
  • [da852fb0/cboos.git] #10012: move the wiki header underline to wiki.css
  • [6c1cf9b7/cboos.git] #10012: distinctive look for fieldsets
  • [bb7e07dc/cboos.git] #10012: streamline wiki edit mode

[Christian Boos]

more compact comment actions

[Christian Boos]

nicer wiki editing…

[Christian Boos]

symbolic-reply-edit-delete.png​ above corresponds to [711f795e/cboos.git].

[lkraav <leho@…>]

I'm pretty sure the symbolic icons need to be uniform-size and the X needs to be less artsy i.e. leaning somewhere. Delete button also very likely benefits from red color. That being said, I have always enjoyed the full text labels on the mini-buttons. I would also surely enjoy "icon + text". For icon-alone strategies there's always the mental learning and remembering curve. This is mainly problematic for users who have important roles but need to use Trac fairly rarely.

[Remy Blank]

Replying to cboos:

They look like "buttons", actionable items. I think it's good to be consistent with this.

Consistency is quite relative in this case. You could also argue that each link should have a border, because it's an actionable item. Most of the other buttons trigger a server-side action (except for the ticket query), which isn't the case for these headings. I see them more as links (and technically, that's what they are, but that's irrelevant to the user).

But no worries, I can remove the borders here.

[AdrianFritz]

Is it possible to have more columns (like 3, instead of 2) to show ticket property fields?

Use case

1. nowadays, screens uses to come on widescreen format (commonly 16:9 ratio). Then, the way tickets are now shown, requires more scrolling to see whole content than if ticket information were spread horizontally.

[Christian Boos]

Replying to AdrianFritz:

Is it possible to have more columns (like 3, instead of 2) to show ticket property fields?

Definitely not for 1.0, but I think that's a worthwhile goal for later improvements, as well as the degraded case of a single column for narrow displays.

Use case

1. nowadays, screens uses to come on widescreen format (commonly 16:9 ratio). Then, the way tickets are now shown, requires more scrolling to see whole content than if ticket information were spread horizontally.

As for wide-screen, I have in mind a side-by-side edit mode similar to the Wiki side-by-side, but again, not for 1.0.

[Christian Boos]

Pushed my recent changes:

• [fa5c0249/cboos.git] #10012: restyle the wiki h2 and h3 underline
• [9503ad9d/cboos.git] #10592: highlight inline code (<tt> elements)
• [0e3c1da6/cboos.git] #10012: for the ticket/comment delete buttons, use another 'x' symbol and color it in red.
• [bee77a2d/cboos.git] #10012: ticket/comment delete buttons, use '-' symbol and fix the height (helps for FF)
• [bf5ce6b2/cboos.git] #7197: continue to improve the "Yellow Ticket Box"
• [61e49d7d/cboos.git] #10012: tweak change headings in ticket change history
• [364183e4/cboos.git] #10012: deal with admonitions, using a 'x' symbol for closing.
• [a49bcfbc/cboos.git] #10012: admin #tabs menu in the style of #prefs
• [2467733e/cboos.git] #10012: buttons "sink" slightly when pushed (effect works best for Chrome and FF)
• [deafb215/cboos.git] #10012: better contrast for foldable fieldsets
• [1ccb255d/cboos.git] #10012: fix admin panel for plugins (summaries don't collide anymore)

Slowly getting there…

[Christian Boos]

Replying to Ryan J Ollos <ryano@…>:

Minor detail is that the text runs into the foldable area on the admin plugins panel

Fixed in [1ccb255d/cboos.git].

[lkraav <leho@…>]

Mmmmkay. One of the thoughts I had for ticket comment meta boxes was something like "is this getting over-boxshadowed". With a screenful of comments I think the extra chrome might just become too distracting. If ticket comments would stay 0.12 style, I wouldn't mind at all.

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/. It's one of the top-watched libraries on github, which to me says this is a real pain point for a large amount of people and that Chosen is a quality solution. Looking at the amount of select controls in ticket properties (for just one example), I think Chosen could be quite useful in Trac, esp. for projects of almost any non-trivial size. Those select boxes fill up quickly with components, milestones and whatnot. Any arguments against including it in core?

[Christian Boos]

Replying to lkraav <leho@…>:

Mmmmkay. One of the thoughts I had for ticket comment meta boxes was something like "is this getting over-boxshadowed". With a screenful of comments I think the extra chrome might just become too distracting.

You're referring to the underline of comment headings ([61e49d7d/cboos.git])? Well, I don't think so, it's in line with what I picked for the Wiki h2 and is there to give the impression that the separators are slightly "above" the content. But I'm not yet done, I'm still going to change the display of threaded comments, and more.

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/ …

Wow, impressive! Yes, looks like it's a must have. Not sure for 1.0 though, but definitely a good pick for 1.1dev.

Any arguments against including it in core?

Not from my side.

[Remy Blank]

Replying to cboos:

Replying to lkraav <leho@…>:

Any arguments against including it in core?

Not from my side.

Not from mine either, it definitely looks nice. But please not for 1.0, it's high time we wrap it up.

[lkraav <leho@…>]

1.1dev is fine with me, I'm living in trunk anyway.

Probably makes sense for me to open a separate ticket for it.

[Christian Boos]

I rebased the branch on top of r11112: repos:cboos.git:ticket10012/more-good-stuff-r11112-ticket-revert

New since last time:

• [54e24dc5/cboos.git] #10012: threaded ticket comments have again only a left border
• [f7f6ca23/cboos.git] #10012: oops, fixing Emacs coding: directive
• [927c3fc1/cboos.git] #10012: printer-friendly CSS (i.e. no shadows)
• [091f9177/cboos.git] #10012: introduce new preferences for controlling the verbosity of the UI
• [795df252/cboos.git] #10012: convert remaining inline buttons to captioned quick buttons

Of particular interest is the new preference tab for selecting a less verbose user interface.

• default buttons:
• buttons with only the symbols:

[Christian Boos]

report list with [795df252/cboos.git] showing buttons with symbol + text

[Christian Boos]

report list with [795df252/cboos.git] showing buttons with symbol only

[Remy Blank]

Oh, come on, enough previews. Just commit already! :)

[Christian Boos]

Ok, so it looks like we're getting to an end. Two more little changes:

• [7a780725/cboos.git] #10012: adapt report list to the .wikipage h2/h3 styles.
• [c15c93e6/cboos.git] #10012: use same border-radius for div.code and pre.wiki

I plan to commit the branch tomorrow (as I already made too many mistakes at this late time!).

This will hopefully conclude this topic… hope the changes were enough to qualify for a decent "update effort", but I realize we're not even close to a re-design attempt…

I hope I'll still have time to finish #8866 before the beta, as well as adding the "resource path" briefly presented in ticket:7197#comment:10 (i.e. ticket:xyz on the upper left, similar to the wiki:page / path).

[Christian Boos]

I was about to commit repos:cboos.git:ticket10012/final-on-r11128 when I noticed that I actually have a bunch of validation errors… not so final, after all ;-)

[anonymous]

strange thing: Since some days and from time to time I notice a strange dotted border around the projectplan menu entry on t.e.o. site. Seen with Windows Firefox 13.0.1 and now 14.0.1:

[Christian Boos]

Replying to anonymous:

strange thing: Since some days and from time to time I notice a strange dotted border around the projectplan menu entry on t.e.o. site. Seen with Windows Firefox 13.0.1 and now 14.0.1:

Could be fixed by:

#mainnav li:focus {
  outline: none;
}

(from ​SO:71074)

… but I'm not sure it's a good idea. This outline is useful for accessibility. Only FF seems to have trouble sizing it exactly on the <li>, Chrome and IE do it right (Safari and Opera don't bother moving the focus there).

[anonymous]

Also if you shrink the browser window width, the floating panel of checkboxes covers the current 97% a bit. Seen here: roadmap

[Christian Boos]

Replying to anonymous:

Also if you shrink the browser window width, the floating panel of checkboxes covers the current 97% a bit. Seen here: roadmap

DONE could be fixed by moving the #prefs above the h1 (r11130)

[anonymous]

Anyway, good work. Like the shaded 3D effects. Maybe let a shade also fall from the main menu. —Sven

[Christian Boos]

Replying to anonymous:

Anyway, good work. Like the shaded 3D effects. Maybe let a shade also fall from the main menu. —Sven

I see from the screenshot you're looking at t.e.o which as of now has only half of the changes… please have a look at demo-0.13 instead!

[anonymous]

Replying to cboos:

I see from the screenshot you're looking at t.e.o which as of now has only half of the changes… please have a look at demo-0.13 instead!

Looks even stylisher, like it too. The TODOs from above remain there as well. The focus problem can be hit quite fast; just click through a few things then go back and forth by using the browser's back and forth buttons left to the URL input field.

[djc]

Can I request that the current mainnav item text not be bold? That way, the menu items left of it won't move around as you click through menu items.

Similarly, it would be great if there was some CSS to force the vertical scrollbar always on, making it not appear and disappear depending on the page height.

[djc]

Also, it would be nice if the cursor changed to a hand when hovering over a button.

[Christian Boos]

So I made the following last two changes on the branch:

• [cbde5705/cboos.git] #10012: a bunch of XHTML validation fixes, functional tests pass again.
• [6323f280/cboos.git] #10012: merge .trac-quickbutton into .inlinebuttons, as we really need the wrapper div.

In particular, the last one consisted of several svn revert ..., as I had to go back to wrapping the <input> elements into <div>s (for the sake of XHTML validation). The .trac-quickbutton class introduced during work on the branch is now gone and instead .inlinebuttons got the new rounded button style.

The whole of repos:cboos.git:ticket10012/final-on-r11128 was committed as r11129.

[Christian Boos]

Replying to djc:

Also, it would be nice if the cursor changed to a hand when hovering over a button.

Done in r11131.

[Christian Boos]

Replying to djc:

Can I request that the current mainnav item text not be bold? That way, the menu items left of it won't move around as you click through menu items.

I use text-shadow instead, to "simulate" bold at constant width.

Similarly, it would be great if there was some CSS to force the vertical scrollbar always on, making it not appear and disappear depending on the page height.

Also in r11132.

[Christian Boos]

Ok, with r11133, this concludes this ticket… but certainly not the effort to improve the user interface in future releases!

Follow-up ideas and suggestions are welcome, either in tickets directly or more informally in TracIdeas/DefaultTheme.

(please leave this ticket closed, it's already long enough)

[Ryan J Ollos <ryano@…>]

Should related minor defects be mentioned here or in new tickets? I may have discovered a one last evening, but need to retest with the latest code.

[Christian Boos]

Replying to Ryan J Ollos <ryano@…>:

Should related minor defects be mentioned here or in new tickets?

I should have said in comment:101, follow-ups ideas, suggestions and related defects in new tickets directly or more informally in TracIdeas/DefaultTheme ;-)

[lkraav <leho@…>]

Replying to lkraav <leho@…>:

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/. It's one

Discovered an interesting plugin today ​th:SubcomponentsPlugin, immediately thought of Chosen, filed ​th:#10170. Just a note to keep track.

[Jun Omae]

If a user agent is Firefox on Windows, the form elements is shown with the system font, not font of body. It is uncool in especially Windows Japanese Edition…. :(

I would like to apply font-family for input, select, button. (except textarea, which is shown with the browser's settings for monospace.)

trac/htdocs/css/trac.css

@@ -83 +83 @@
 /* Forms */
 input, textarea, select { margin: 2px }
 input, select { vertical-align: middle }
+input, select, button {
+ font-family: Arial,Verdana,'Bitstream Vera Sans',Helvetica,sans-serif;
+}
 input[type=button], input[type=submit], input[type=reset] {
  background: #eee;
  color: #222;

[Christian Boos]

Replying to jomae:

If a user agent is Firefox on Windows, the form elements is shown with the system font, not font of body. It is uncool in especially Windows Japanese Edition…

Fine for me.

[Christian Boos]

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/ …

Wow, impressive! Yes, looks like it's a must have. Not sure for 1.0 though, but definitely a good pick for 1.1dev.

Any arguments against including it in core?

Not from my side.

In fact, there's something that speaks against it: there's already something similar in jQueryUI (​http://jqueryui.com/demos/autocomplete/), so we already bundle something very similar!

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to cboos:

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/ …

In fact, there's something that speaks against it: there's already something similar in jQueryUI (​http://jqueryui.com/demos/autocomplete/), so we already bundle something very similar!

A relatively new Trac plugin, ​th:MultiSelectFieldPlugin, uses Chosen to implement a multi-select.

[anonymous]

Replying to cboos:

Here we go… colors and tastes…

But I agree that at least the navigation list should be fixed. We need to have the "tabs" wrap nicely, not something fixed like what seems to be the case for your model "japibas".

It seems osimons fixed that for his own Trac instances (​epicode). Any chance to adapt this to upstream, Simon?

Who is Simon?

[Ryan J Ollos]

Replying to Christian Boos:

About select boxes:

Another interesting library I recently discovered is ​http://harvesthq.github.com/chosen/ …

In fact, there's something that speaks against it: there's already something similar in jQueryUI (​http://jqueryui.com/demos/autocomplete/), so we already bundle something very similar!

It needs to be studied further, but looking at ​jQuery combobox, a substantial amount of implementation code is needed when compared to chosen and ​select2.