- air
- ajax
- algorithm
- apple
- bitbucket
- braintapper_exchange
- charts
- chumby
- codeigniter
- cognos
- complexity
- crashplan
- crosstab
- dash
- dashboard
- date
- dbvisualizer
- decisions
- dimension
- dogfood
- dona_wong
- dropbox
- edward_tufte
- extension
- feature_checklists
- feature_excellence
- filemaker
- firefox
- firewall
- flot
- flowing_data
- fogbugz
- football
- free
- freenas
- freshbooks
- git
- github
- gm
- google_charts
- iPad
- javascript
- jdbc
- jedox
- mac
- macbook
- maps
- marsedit
- mercurial
- metaweblog
- metrics
- microstrategy
- monowall
- moo
- nathan_yau
- news
- nosql
- open_source
- palo
- pentaho
- pfsense
- printing
- programmers_interfaces
- rapidweaver
- regex
- regexr
- rest
- safari
- smoothwall
- sony
- sqlpower
- stackoverflow
- statistics
- stephen_few
- svg
- tablet
- ticket_agent
- time_machine
- tip
- tm1
- transformer
- trick
- typographic grid
- usability
- visualization
- vmware
- w3c
- web
- wiki
- wikkawiki
- work_management
- wsj
So it's been a while since I've last posted. A long while. It's been intentional.
As some of you may know, I've been working on an app, tentatively called Ticket Agent. I'm hoping to make this a widely available SAAS (software as a service) application for work management.
I'm quite aware that the work/project management space is a crowded one in the SAAS area. The most dominant player is probably 37signals' BaseCamp. It's an excellent product. Ironically, listening to their audio version of their book Rework inspired me to build my application. It's been an application in my head since maybe 1998, and I never got around to building it.
Some history: Many, many years ago, I worked on a Web 1.0 product like Basecamp but a little too far ahead of its time. We released it as a free and rentable multi-tenant product, but this was in 1998, and the idea of SAAS barely had any traction. Needless to say, the product got killed, and that was the end of it.
So I've been fleshing together Ticket Agent over the past few months, and of course, there have been bumps along the road. It started off as a LAMP stack app (Linux/Apache/MySQL/PHP for those not in the know) and has evolved into a Ruby on Rails / NoSQL (MongoDB) app along the way.
The major platform pivot resulted in me wanting to take advantage of the cloud services available, and the change to a NoSQL database was driven by the idea that I didn't want to be saddled with database schema migrations every time the data model changed. Perhaps I'll talk in more detail about my database decision in a future blog post.
In any case, back to the app. The application is a "ticket" based application (hence the name). While most people will associate tickets with an issue or bug tracking app, I took the philosophical view that a ticket is the best way to assign a unit of work to a team member.
I mean what's the real difference between a ticket and a task other than the ticket number? Not much, really.
Being a ticket-based system, however, isn't the differentiator for the application. This application is designed to scratch an itch I've had working on and running projects. The primary problem I've had is status.
I hate compiling team member status reports into client status reports. I've used various systems, including BI tools like Cognos, but there was always just a little too much work involved with that. Add to the fact that most consultants hate doing status reports themselves. So then as a manager, you're stuck cracking that whip chasing people down for status reports and then spending time compiling them into reports that your clients can consume. Not fun at all.
But it's not just project status that's an issue. Here are some of the time consuming status items that a typical project manager needs to keep up on (in no particular order):
- Where are my team members today?
- What are my team members working on today?
- What is the progress of what my team members are working on?
- What are the upcoming deadlines (or milestones) for my company?
- What is the status of all of my active client projects?
- Which of my team members are best using the Ticket Agent application?
The last point is a little interesting. As with any application, end user adoption is an issue. You could have the most usable system, but people may still not use the system. I have a solution to help address this, but it's a "secret sauce" idea that I'll hold back until closer to release.
From a design perspective, my goal is to make the application feel more like a GTD (Getting Things Done) application than your typical project/task management solution.
Well that's all I have for now, but I'll finally start posting more regularly to let you know how development is going.
