Edgewall Software
Modify

Opened 4 years ago

Closed 2 years ago

Last modified 12 months ago

#10012 closed enhancement (fixed)

Trac UI re-design or update effort

Reported by: lkraav <leho@…> Owned by: cboos
Priority: high Milestone: 1.0
Component: web frontend Version: 0.13dev
Severity: major Keywords: css
Cc: osimons
Release Notes:

Refresh the default theme to take advantage of a few CSS3 features.

API Changes:

Description

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.

Attachments (16)

Trac13 Theme Development.png (126.4 KB) - added by lkraav <leho@…> 4 years ago.
Trac13 theme initial mockup
Trac 0.13 Demo Project - tabs rounded bottom.png (22.6 KB) - added by cboos 3 years ago.
Trac 0.13 Demo Project - tabs rounded top.png (22.7 KB) - added by cboos 3 years ago.
Trac 0.13 Demo Project - mainnav - wide.png (55.9 KB) - added by cboos 3 years ago.
The proposed #mainnav, with straight borders, on a single line
Trac 0.13 Demo Project - mainnav - narrow.png (36.9 KB) - added by cboos 3 years ago.
The proposed #mainnav, with straight borders, on multiple lines
Trac 0.12 Demo Project.png (17.1 KB) - added by cboos 3 years ago.
The #mainnav in stock Trac 0.12
closed-milestones.png (9.1 KB) - added by cboos 2 years ago.
RoadMap@47 closed by a border
closed-milestones-strikethrough.png (8.4 KB) - added by cboos 2 years ago.
RoadMap@47 current state
closed-milestones-checkmark.png (10.6 KB) - added by psuter 2 years ago.
RoadMap@47 closed by a Unicode checkmark character
t10012-drop-double-borders-from-ticket-box.jpg.png.jpg (182.1 KB) - added by lkraav <leho@…> 2 years ago.
ManagePlugins.png (18.0 KB) - added by Ryan J Ollos <ryano@…> 2 years ago.
symbolic-reply-edit-delete.png (30.7 KB) - added by cboos 2 years ago.
more compact comment actions
wiki-side-by-side-edit.png (87.3 KB) - added by cboos 2 years ago.
nicer wiki editing…
report-ui.use_symbols-false.png (12.3 KB) - added by cboos 2 years ago.
report list with [795df252/cboos.git] showing buttons with symbol + text
report-ui.use_symbols-true.png (12.1 KB) - added by cboos 2 years ago.
report list with [795df252/cboos.git] showing buttons with symbol only
strange-border.png (3.4 KB) - added by anonymous 2 years ago.

Download all attachments as: .zip

Change History (127)

Changed 4 years ago by lkraav <leho@…>

Trac13 theme initial mockup

comment:1 follow-up: Changed 4 years ago by 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?

comment:2 follow-up: Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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?

comment:4 in reply to: ↑ 2 Changed 4 years ago by cboos

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 ;-)

comment:5 follow-up: Changed 4 years ago by osimons

  • Cc osimons added

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.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by cboos

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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 4 years ago by 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 ;-)

comment:8 in reply to: ↑ 7 Changed 4 years ago by cboos

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 ;-)

comment:9 Changed 4 years ago by cboos

See also past discussion in TracProject/UiGuidelines.

comment:10 Changed 4 years ago by 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.

comment:11 follow-up: Changed 3 years ago by cboos

  • Owner set to cboos
  • Status changed from new to assigned

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 ;-)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 3 years ago by 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.

comment:13 in reply to: ↑ 12 Changed 3 years ago by cboos

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 ;-)

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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!

comment:16 Changed 3 years ago by cboos

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?

comment:17 Changed 3 years ago by 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.

comment:18 Changed 3 years ago by mrelbe

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].

comment:19 Changed 3 years ago by 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.

comment:20 Changed 3 years ago by 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.

comment:21 Changed 3 years ago by cboos

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].

comment:22 Changed 3 years ago by lkraav <leho@…>

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

comment:23 follow-up: Changed 3 years ago by 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, 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.

comment:24 in reply to: ↑ 23 ; follow-up: Changed 3 years ago by cboos

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 ;-)

comment:25 in reply to: ↑ 24 ; follow-up: Changed 3 years ago by 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.

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.

comment:26 in reply to: ↑ 25 Changed 3 years ago by cboos

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:

The #mainnav in stock Trac 0.12

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:

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

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).

Last edited 3 years ago by cboos (previous) (diff)

Changed 3 years ago by cboos

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

Changed 3 years ago by cboos

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

Changed 3 years ago by cboos

The #mainnav in stock Trac 0.12

comment:27 Changed 3 years ago by rblank

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.

comment:28 Changed 3 years ago by Ryan J Ollos <ryano@…>

  • Cc ryano@… added

comment:29 Changed 3 years ago by cboos

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.

comment:30 follow-up: Changed 3 years ago by rblank

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.

comment:31 in reply to: ↑ 30 Changed 3 years ago by cboos

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 ;-) )

comment:32 Changed 3 years ago by 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.

comment:33 Changed 3 years ago by 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.

comment:34 Changed 3 years ago by 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.

comment:35 Changed 3 years ago by 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?

comment:36 Changed 3 years ago by 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.

comment:37 Changed 3 years ago by anonymous

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

comment:38 Changed 2 years ago by 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.

comment:39 Changed 2 years ago by 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.

comment:40 Changed 2 years ago by cboos

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 ;-)

comment:41 Changed 2 years ago by 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. :)

comment:42 Changed 2 years ago by cboos

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 thoughtWikipedia: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: RoadMap@47 current state with:

RoadMap@47 closed by a border

Changed 2 years ago by cboos

RoadMap@47 closed by a border

Changed 2 years ago by cboos

RoadMap@47 current state

comment:43 follow-up: Changed 2 years ago by psuter

How about something like .closed:after { content: "✓" }: RoadMap@47 closed by a Unicode checkmark character

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

Changed 2 years ago by psuter

RoadMap@47 closed by a Unicode checkmark character

comment:44 follow-up: Changed 2 years ago by 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.

comment:45 Changed 2 years ago by psuter

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

comment:46 in reply to: ↑ 44 Changed 2 years ago by cboos

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 ;-)

comment:47 in reply to: ↑ 43 ; follow-up: Changed 2 years ago by cboos

Replying to psuter:

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

Looks even better I think!

The spacing is however a bit too narrow:

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

A different possibility would be to put it before:

Or, as you suggested:

(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 ;-) :

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

comment:48 in reply to: ↑ 47 ; follow-up: Changed 2 years ago by Ryan J Ollos <ryano@…>

Replying to cboos:

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

'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.

comment:49 in reply to: ↑ 48 Changed 2 years ago by cboos

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 ;-) )

comment:50 follow-up: Changed 2 years ago by 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?

comment:51 in reply to: ↑ 50 Changed 2 years ago by cboos

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.

comment:52 follow-ups: Changed 2 years ago by 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 ;-)

comment:53 follow-up: Changed 2 years ago by rblank

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.

comment:54 in reply to: ↑ 52 Changed 2 years ago by 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 :/

comment:55 follow-up: Changed 2 years ago by lkraav <leho@…>

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

comment:56 in reply to: ↑ 52 ; follow-up: Changed 2 years ago by 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.

comment:57 in reply to: ↑ 53 ; follow-up: Changed 2 years ago by cboos

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.

comment:58 in reply to: ↑ 57 Changed 2 years ago by 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

comment:59 in reply to: ↑ 55 Changed 2 years ago by cboos

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)

Last edited 2 years ago by cboos (previous) (diff)

comment:60 in reply to: ↑ 56 Changed 2 years ago by cboos

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.

comment:61 follow-up: Changed 2 years ago by cboos

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:

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

comment:62 in reply to: ↑ 61 Changed 2 years ago by cboos

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].

comment:63 follow-ups: Changed 2 years ago by 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.

comment:64 follow-up: Changed 2 years ago by lkraav <leho@…>

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

comment:65 in reply to: ↑ 64 Changed 2 years ago by cboos

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 ;-)

comment:66 in reply to: ↑ 63 Changed 2 years ago by 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!

comment:67 in reply to: ↑ 63 ; follow-ups: Changed 2 years ago by 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.

Changed 2 years ago by lkraav <leho@…>

comment:68 in reply to: ↑ 67 Changed 2 years ago by cboos

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.

comment:69 in reply to: ↑ 67 Changed 2 years ago by rblank

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?

Changed 2 years ago by Ryan J Ollos <ryano@…>

comment:70 follow-up: Changed 2 years ago by 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).

comment:71 follow-up: Changed 2 years ago by rblank

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.

comment:72 in reply to: ↑ 71 ; follow-up: Changed 2 years ago by cboos

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 ;-) ).

comment:73 Changed 2 years ago by cboos

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

more compact comment actions

nicer wiki editing…

Last edited 2 years ago by cboos (previous) (diff)

Changed 2 years ago by cboos

more compact comment actions

Changed 2 years ago by cboos

nicer wiki editing…

comment:75 Changed 2 years ago by 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.

comment:76 in reply to: ↑ 72 Changed 2 years ago by rblank

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.

comment:77 follow-up: Changed 2 years ago by 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.

comment:78 in reply to: ↑ 77 Changed 2 years ago by cboos

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.

comment:79 Changed 2 years ago by cboos

Pushed my recent changes:

Slowly getting there…

comment:80 in reply to: ↑ 70 Changed 2 years ago by cboos

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].

comment:81 follow-ups: Changed 2 years ago by 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?

comment:82 in reply to: ↑ 81 ; follow-ups: Changed 2 years ago by cboos

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.

comment:83 in reply to: ↑ 82 Changed 2 years ago by rblank

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.

comment:84 Changed 2 years ago by 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.

comment:85 Changed 2 years ago by cboos

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

New since last time:

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

  • default buttons: report list with [795df252/cboos.git] showing buttons with symbol + text
  • buttons with only the symbols: report list with [795df252/cboos.git] showing buttons with symbol only
Last edited 2 years ago by cboos (previous) (diff)

Changed 2 years ago by cboos

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

Changed 2 years ago by cboos

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

comment:86 Changed 2 years ago by rblank

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

comment:87 Changed 2 years ago by cboos

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

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).

comment:88 Changed 2 years ago by cboos

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 ;-)

comment:89 follow-up: Changed 2 years ago by 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:

Changed 2 years ago by anonymous

comment:90 in reply to: ↑ 89 Changed 2 years ago by cboos

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).

Last edited 2 years ago by cboos (previous) (diff)

comment:91 follow-up: Changed 2 years ago by anonymous

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

comment:92 in reply to: ↑ 91 Changed 2 years ago by cboos

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)

Last edited 2 years ago by cboos (previous) (diff)

comment:93 follow-up: Changed 2 years ago by anonymous

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

comment:94 in reply to: ↑ 93 ; follow-up: Changed 2 years ago by cboos

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!

comment:95 in reply to: ↑ 94 Changed 2 years ago by 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.

comment:96 follow-up: Changed 2 years ago by 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.

comment:97 follow-up: Changed 2 years ago by djc

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

comment:98 Changed 2 years ago by cboos

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

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.

comment:99 in reply to: ↑ 97 Changed 2 years ago by cboos

Replying to djc:

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

Done in r11131.

comment:100 in reply to: ↑ 96 Changed 2 years ago by cboos

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.

comment:101 Changed 2 years ago by cboos

  • Resolution set to fixed
  • Status changed from assigned to closed

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)

comment:102 follow-up: Changed 2 years ago by 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.

comment:103 in reply to: ↑ 102 Changed 2 years ago by cboos

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 ;-)

comment:104 in reply to: ↑ 81 Changed 2 years ago by 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.

comment:105 follow-up: Changed 2 years ago by 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…. :(

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

    diff --git a/trac/htdocs/css/trac.css b/trac/htdocs/css/trac.css
    index b5946b7..0356d45 100644
    a b span:target { 
    8383/* Forms */ 
    8484input, textarea, select { margin: 2px } 
    8585input, select { vertical-align: middle } 
     86input, select, button { 
     87 font-family: Arial,Verdana,'Bitstream Vera Sans',Helvetica,sans-serif; 
     88} 
    8689input[type=button], input[type=submit], input[type=reset] { 
    8790 background: #eee; 
    8891 color: #222; 

comment:106 in reply to: ↑ 105 Changed 2 years ago by cboos

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.

comment:107 in reply to: ↑ 82 ; follow-up: Changed 2 years ago by cboos

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!

comment:108 Changed 2 years ago by cboos

  • Release Notes modified (diff)
  • Severity changed from normal to major

comment:109 in reply to: ↑ 107 Changed 16 months ago by 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.

comment:110 in reply to: ↑ 1 Changed 12 months ago by 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?

Last edited 12 months ago by rjollos (previous) (diff)

comment:111 Changed 12 months ago by rjollos

  • Cc ryano@… removed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain cboos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from cboos to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.