The Quick & Dirty:

  • 9+ years in the biz, 10 messing around
  • All the latest in HTML, CSS, JS & PHP (Sorry, no .net or Ruby skills yet)
  • Cross-browser compatible code from Photoshop or Illustrator files.. or napkins!
  • Custom Specialities in Wordpress theming & plugins, Twitter & jQuery
  • Subversion, server-log analysis, and blocking hack-attempts (of late).
  • Data/Project Geek. I ♥ timelines.

I’ve compiled some handy PHP functions I’ve had to whip up. More extensive code-samples are also available.

Wordpress-from-Photoshop/Illustrator

Wordpress-from-static HTML

Wordpress-from-Photoshop

Trac

I love Trac. I hate Trac. Trac won’t take off until it starts looking prettier/simpler. A few sites try cosmetic fixes, but that’s just not enough.

Fact is, Trac is built with information as a FIRST priority.

This is good: Code Developers love information. We’ll take as much as anyone can give us, because almost always, no one gives US enough.
This is bad: The rest of the world is only concerned with a subset of the information we know, and gets overloaded with all that coders revel in.

To that end, I’ve been devin’ up a slightly better version of Trac for my company.

Here’s some ideas I’ve been on:

Ticketing

Start a New ticket:

Ticketing has got to be the heart-and-soul of Trac. Everything seems to revolve around it. A ticket can be for anything from “OMG! The program is crapping to pieces!” (from a client) to “Dude, what about this?”(brain-storming) to “You’ve got to fix these 9 little things, why do I have to keep typing in all this extra info over and over?”

Fact is, making a new ticket should be easy. Painless. (and powerful) Otherwise, it won’t be used. And besides, there’s plenty of other info that can be added on later.

newticketing

Ticket Viewing/Reports:

Just a simple point here: Why does this have to be a separate page? Why can’t these 8 or 9 reports be dumped into the subnav ( in place of ‘available reports’) while making either ‘Active tickets’ or ‘My tickets’(face it, we’re all about ourselves!) the default ‘View Tickets’ page?

reports

Ticket Follow-up:

Take a look at a default installation. One simple question: Why all the crap?

There’s 3 sections: Original Ticket, Comments, and Friggin-Complex-Info-you-must-type-in-before-you-can-even-think-about-pressing-submit-a-ticket!

Unnecessary. Especially since that “Change Properties” box at the bottom:
1) has nothing to do with commenting
2) has everything to do with the original ticket UP TOP!

So call me crazy, but why not something more like this:

trac ticket suggestion 0

ooh.. simple.. clean…

Notice:

1) Ticket changes are in parallel with the ticket.
2) Changes are minimized for those who feel like clicking ‘edit’ (to which the ticket then gets turned into a textarea, properties turn into editable select boxes.)
3) Commenting? Yup. All alone at the bottom after all the comments. Who knew?

Changelog:

changes

I like changelogs. But when a client uses the WebDAV interface, EACH FILE becomes a commit. This can lead to some VERY long changelogs. Notice those “16:32″‘s up there? Why not group them all under “Wiki Changes by trac @ 16:32″? And especially those “Autoversioned Commit” You can’t tell me that can’t be parsed! Just dump all these under a collapsable ul/li & call it a day.

Ok, that’s enough of my rant for now, I’m sure I’ll be back with more Trac fixes (and a code release!) soon.

Any other bright ideas out there?

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS
Posted in interaction design, svn, trac Tagged , , , , , , , , , Comments Off

Comments are closed.