TicketDesk FAQ
by: Stephen M. redd
TicketDesk is a super-simplified help desk issue tracking application. It is designed primarily for small to mid-sized organizations servicing internal users.
TicketDesk's mission is to enable nearly effortless issue submission and tracking, with as little overhead and complexity as possible.
TicketDesk is an open source project cross-hosted on GitHub and CodePlex. There have been three significant versions of the project so far:
- TicketDesk 2.5 is a re-write of the TicketDesk 2 application targeting newer .Net 4.5 web platform technologies; ASP.NET MVC 5, Entity Framework 6, ASP.NET Identity 2, and OWIN/Katana. This release keeps most of the UI behavior from previous versions, but re-implemented for compatibility with modern browsers and small screen devices.
- TicketDesk 2 is a C# web application written for the Microsoft ASP.NET MVC 2 platform. Other technologies involved include JQuery, .NET Framework 4.0. Entity Framework 4.0, LINQ to Entities, Managed Extensibility Framework, and SQL Server 2008/2005 (express or full).
- TicketDesk 2.1 upgraded the application to target .Net 4.5 and the MVC 4 platform, and verified compatibility with SQL 2012 (express, localdb, and full editions).
- TicketDesk 1.x was the original ASP.NET 2.x webforms application written in C# on the .NET 3.x framework. The application was written as a single .NET project using the AJAX Control Toolkit, LINQ to SQL, and SQL Server 2005 (express or full).
In over 20 years in the IT industry, I've been frustrated by issue trackers at companies of just about every size. Some were better than others, but even the best of them tend to be quite annoying. Often they seem to get in the way as much as they help.
Instead of making yet another help desk system that does what all the others do, I designed TicketDesk to challenge the fundamentals behind other help desk issue trackers.
The result is that TicketDesk embraces the true nature of how help desks really work, rather than trying to serve the needs of some idealized fiction of what a help desk should be.
The core principals behind TicketDesk are:
- Ticket submission should be super fast and simple; ask as few questions as possible then get out of the way!
- A ticket should evolve as a natural conversation between users and the help desk. The system must enable frictionless participation from all parties at all stages of the ticket's life-cycle.
- Help Desks have a lot to do. The issue tracker should require as little administrative overhead as possible and place as little burden on the help desk staff as it does the end-users.
- You shouldn't have to train people how to use an issue tracker. The entire workflow should be obvious, simple, and effective.
I have a lot of faith in TicketDesk, but I would not pretend it can meet everyone's needs. Part of it's success is in keeping a very narrow focus on just the pure issue tracking features. If your organization is large, services external users, or bills for services then you should really consider other options as well.
TicketDesk 1 was just a quick experimental project of mine. I needed to get some hands-on experience with new (at the time) Microsoft technologies like LINQ to SQL and the Ajax Control Toolkit. At the time of the original project, I only had about 4 hours a day for 10 days to spare for the project.
At the time, I was also quite frustrated with the issue tracker my company was using; a product called Census by MetaQuest. So an issue tracker seemed like a good experimental project. I didn't have to do much design for an issue tracker. I've had years and years of first-hand experience with dozens of horrible issue trackers, so I already had a good idea how it should work . All I had to do was avoid the mistakes that the other guys always seemed to make.
So, with only 40 hours and a spec that took about 10 minutes to slap together on a napkin, I set out to conquer some new technologies. I didn't actually expect to finish the whole project, I just figured I'd take it as far as I could then stop when I ran out of time.
By the end of the experiment though, I was surprised to find that I had a fully functional issue tracker, and that was also quite good. So I put another couple of weeks into polishing it up, documented it, then released it as an open source project on codeplex.
And that's how TicketDesk was born. My employer scrapped our old system, and we used TicketDesk happily for many years.
TicketDesk 1.x pretty good, but since it lacked a lot of up-front design it also had some architectural limitations. Additionally, it was based on the Ajax Control Toolkit, which turned out to be one of the worst technologies I've ever seen from Microsoft. I was able to work around the flaws and limitations enough for TicketDesk's immediate needs, but I was exceedingly unhappy with the toolkit.
I also needed to get my hands dirty with the next round of new Microsoft technologies; notably the Entity Framework and ASP.NET MVC 2. Upgrading TicketDesk as I learned my way around the new platforms just seemed like a natural thing to do.
Over the years, I've continued to occasionally invest time into upgrades for TicketDesk 2.x. While the overall design is still based on patterns common with ASP.NET MVC 2 and the classic ASP.NET view engine, it has been upgraded to run on newer .Net frameworks.
In 2014, I started seriously working on a full-rewrite to bring TicketDesk up to current standards. First I prototyped the application I wanted to build, TicketDesk 3. I spent several months learning my way around JavaScript MV* frameworks, new security and identity frameworks, and all the new Azure goodness. Eventually I decided to break the re-write into two parts.
First, TicketDesk 2.5 would re-write TD 2 on the latest ASP.NET MVC technology stack. This version would have most of the same features as TicketDesk 2.5, just newer and better. Once the system was modernized and the back-end revamped, I would then resume work on TicketDesk 3, which will have an entirely modern front-end UI, and tons of long-overdue new features.
copy right @ test