The Problem with iBiz

I promised more work related posts, so here we go:

As everyone here knows we spend a significant amount of time interacting with iBiz. Let me explain what iBiz [Server] does. It's a time tracking and invoicing application for the Mac OS X platform. It supports multiple users in a local area network environment. It also integrates with several key OS X applications, such as Address Book, and iCal. All these great sounding features were factored in when I decided to purchase 3 copies of it in the beginning of September. After three months of daily use, and endless issues I can confidently say that iBiz sucks. In order to paint a more vivid picture, I'll attempt to accurate describe what would normally be the most compelling features of iBiz, and how perception differs from the grim reality.

Cross Application Integration
iBiz works with Address book, but in a really limited fashion. A separate group is automagically created in your Address Book called "iBiz Clients". In concept this is a really great idea, but in a networked environment only the server's Address Book is used. This makes changing client information nothing short of a hassle because it has to be done on the server itself. That's right, you can't actually edit the client inside iBiz, it has to be done in the associated Address Book. As [un]expected double clicking on a client's card from within iBiz client, even if I have the same exact one locally in my Address Book, brings up a cryptic error message. Thankfully for us client information doesn't change that often.

iCal integration isn't much better. You can publish events to and from iCal, but it has to be done manually, and the time spans are rarely accurate. Publishing to a new calendar requires that iBiz is relaunched after the calendar is created in iCal. As of this writing I can't even publish a project due date to the calendar without this error: "iCal got an error: NSContainerSpecifierError". I later discovered that this occurred because I failed to select a calendar in the project info window. So in essence I had to hunt around to find what the program should have already known was an obvious issue. Instead it probably tried to jam an event into an calendar called "NULL", causing iCal to get agitated. Events can also be imported from iCal but with questionable results, only across a single calendar and only manually. I had really hoped to be able to add events in iCal and have them appear in iBiz, but after some time I learned it wasn't going to happen. Needless to say we didn't end up using the calendar features much.

Networking
iBiz Server has seamless networking, within a local area network. The clients were able to connect to the server immediately, without the need for any configuration. However there is absolutely no feasible way to connect to it from outside of the local network. I even tried to VPN, which doesn't seem to carry Bonjour so well. There is no way to define what IP the client should connect to. So much for using it from home.

There is an option to check items out, because as soon as iBiz Client loses it's connection to the server all the client / project information disappears. This requires that specific objects be selected for check out. Upon doing so, unchecked items disappear. This initially freaked me out and I didn't have a clue how to get the missing information back. Thankfully I figured out that "Synchronize With Server" really means reconnect with server. I still can't understand why iBiz doesn't just maintain a local copy incase you need to disconnect from the network in a hurry or if the server goes down. We would occasionally lose connection to the server, which would stall our timers and clear our client lists until iBiz Client was relaunched.

Time Tracking
This part of iBiz is just a mess. I can't even come up with a crafty lead-in for this section. We have been reduced to manually correcting timers at the end of the week. Often they are just flat out wrong. From what it appears, using the same timer for more then one day, or adjusting the time of an event then starting a timer causes all sorts of trouble. Jon lost 10 or 15 hours just in 1 week of use. That's disgusting.

Invoicing
Invoicing is no better then time tracking. As other users have reported on Mac Update, we have generated the same invoice more then once and gotten completely different totals. I miss billed two clients. I don't even want to think how much money this might have cost me just in these few months.

Reporting
Reporting does exist, and it is really easy to run, but it isn't that flexible. We ran into a [major] issue with the fact that iBiz has NO WAY TO DIFFERENTIATE EMPLOYEES. None at all. We've worked around this by using event folders, one for each person. This really fowls up the reporting. I can't do something as simple as see how many recorded hours an employee worked over a given time period. Aniel had to sit with a stack of printouts one week to see where all our hours had gone. I'm not saying iBiz was responsible for the huge loss of billable time, but it didn't help in tracking the loss down.

Interface
I have to say that iBiz's interface is not so bad. It's very simple and that lends to a very small learning curve. Though I'm constantly rewarded by interface glitches. For example, the "Add" and "Insert" event buttons will be grayed out but still accessible. I'm not entirely sure what the difference is between adding and inserting an event. As far as I can tell they have almost the exact same function, except "Add" refuses to place an event in a job group, and insert event can put one inside or outside. Job event types are yet another thing that has to be entered in on the server. Those don't change too often, but that's just silly that I have to go to the server to do certain things. Speaking of the server, it runs as a faced application, which means OS X has to be logged in for it to run. Not the most ideal situation for a server environment.

General Madness
I have not kept track of how many full out bugs and interface glitches that we have reported to the developer. My logic for not keeping count was that we probably wouldn't find another and that keeping track would be a waste of time. After the 5th or 6th e-mail to the developer, I should have gotten the hint. It was a twice a week occurrence for a while. Last I looked I wasn't using Beta software.

I can't say I'm as bad off as some others. There are reports going around of data loss. Not that I'd know how to backup iBiz server, without doing some investigation. I certainly don't consider backing up folders in ~/Library manually an acceptable option for most users. Other applications, like Address Book or DevonNote provide concrete methods to backup their databases.

Final Thoughts
I feel like an idiot for using iBiz this long. It has probably cost us a ton of money in lost time, incorrect invoices, and in the hours wasted working around its flakiness. It's also embarrassing to explain to a client that our software messed up and miss-billed them. Those kind of mistakes don't help to build trust.

I think we're going to switch to Studiometry. From what I've read and observed from my limited use, it appears to have a much higher learning curve. I could care less. I just don't want it doing stupid shit. It's also a little more expensive, and I hope that's just because it's a more solidly written application. Hell, it's even dual platform, lets me define employees and even lets me specify the server's IP.

I hope I'm not going to be making the same type of mistake I made before with iBiz and not writing a similar entry three months later. I'll post updates on how the transition works out. I bet it's going to be ugly.