Archive for 2005
I just had a nice discussion with Daniel Webb about iBiz and Studiometry. He originally used Studiometry, but abandoned it for iBiz and didn’t want me to make the same mistake. This initially was kind of confusing to me because I thought my mistake was using iBiz.
Mr. Webb had used Studiometry for several years, and remarked that he was initially a huge fan of it. However, he noted in his comment on my post, Studiometry began to slow down as clients were added. So much that he recalled it taking 8 minutes to launch. This has been echoed by other users at MacUpdate and Version Tracker. He also pointed out that the networking, doesn’t always work right either, something that iBiz has gotten right for the most part. None of this comes as a big surprise to me given the amount of bugs I’ve logged in the past few weeks while trying to set up Studiometry. I’ve felt like more of a beta tester then an actual end user. It puts a whole new meaning on term Trial Software.
I’m not willing to hand over more money to a program I can’t be certain about. It’s not like I’m unwilling to work through the resolution of certain flaws, that is if the developer is willing to help. It doesn’t seem that way with Studiometry. My tickets often get closed with no resolution posted, or just completely unanswered. Here are some of them: 1,2,3,4,5,6,7,8,9,10,11,12.
iBiz, as I’ve noted in length, has a great number of bugs, but there is something to be said for at least knowing what they are. So as Mr. Webb pointed out to me, iBiz, when treated gingerly, can be used to accomplish something. A lot of my gripes have stemmed from the limited representation of unique employees and how it seems to butcher my invoices.
I attempted to use job event groups (folders) to represent employees, which as Mr. Webb pointed out, is a feature, but not one that should be used. What I’ve noticed is that when they are collapsed the invoices are incorrectly generated. I’m still unsure why a visual representation can create this sort of problem.
Supposedly if I create expense types for each employee I can get pseudo employee level tracking. This is something I had resisted because it clutters up the expense types. If it dissolves my reliance on job event groups, then I might just be able to get out accurate invoices and reporting. The only issue that remains is the event timers being inaccurate. To work around this Mr. Webb uses a 3rd party application, but I think I may try to see if the developer is willing to improve the implementation in iBiz.
In The End
It’s really a case of choosing the lesser of two evils. Studiometry could be a more accurate, but it hasn’t inspired any confidence and who wants to march into uncharted territory. Now that I know some ways to work around the inherent problems in iBiz, I should be better equipped at using it until something better comes along or the developer gets through a laundry list of issues.
Suggestions are welcome.
Christmas came and went, and with it a strange toy. I received a Nabaztag (WiFi Rabbit) from my girlfriend. She knew I was a sucker for things that light up, and in this case resemble a bunny. As excited as I was to see it work, I had to wait till Monday to be able to buy an adapter for the French plug.
Once plugged in and registered, I quickly realized that without paying for a subscription my Bunny would be seriously crippled. Not that they don’t offer some basic services, but most of them didn’t apply to me. Of the 10 offered, two applied specifically to Paris, one to people that have multiple Nabaztags, and so on. The weather and clock service seemed like it could be of some use, but the weather report is only broadcast two times a day, and tends not to match other weather services. The clock only presents a chime on the hour, and can come up to 10 minutes late.
Needless to say this gift was going back. I wasn’t going to pay for a subscription just so people could send messages to it without being charged, and I wasn’t going to settle for it’s limited functionality. However, the 15 day return period had since passed and this bunny wasn’t going anywhere.
Thankfully an API is available… in French. I don’t know any French. Actually most of the documentation only exists in French, and every so often the website drops from English to French. With the help of translation services, and my girlfriend (who speaks French), I’ve been able to assemble bits and pieces of the API.
This is the result. I’ve begun to develop a site, in English, that will let people control these things using the published API. As I learn more, I plan to expand the site to add new functionality. It’s rather basic but it sure beats paying 3.9 to 5.9 euros a month.
If you have any information about Nabaztag, or have no clue how it works, feel free to comment on this post and I’ll try to respond where necessary.
Update: The links have been corrected. Thanks Jomy.
I was biking to work this morning along Madison Ave., and passed a Ralph Lauren store actually handing out free coffee. I think if I was walking I probably would have picked some up. Nevertheless it was surprising to see, that and the street nearly devoid of cars.
So yeah, they decided to strike according to NY 1. Here I am, still at work. Haven’t slept yet. It’s probably a two hour walk home.
At least I can make some coffee.
P.S. I’ll take pictures of the mess in the streets if I get a chance.
So they may have a transit strike. So what, I’m working all night anyway. Ha, that will teach them.
P.S. For those who depend on mass transit, which I normally do, please consider demanding that “Union Square” be renamed “Right To Work Square.”
Needless to say things do not look so well with our new friend Studiometry.
We use Surpass Hosting incase you want to join the fray, or complain to them. I hope it’s the latter.
I’ve been waiting to take the plunge and switch to Studiometry from iBiz, but a few things have been holding me back. So far my use of Studiometry has been on very basic level. It’s not the easiest thing to pick up because it appears to have a ton of functionality. Its interface is a concise but achieves this by using a layered approach. I think there is some HCI rule against hiding things from the user, but then again a main window can only be so large. Given it’s complexity I’ve been reduced to reading the help pages just so I don’t gloss over less then obvious features. So far it looks like it can do some really useful stuff.
It’s when I began trying out some of these nifty features that I started seeing some bugs. If I remember correctly I was supposed to be getting away from this by getting rid of iBiz. So far I’ve found a few issues with the Apple Address Book synchronization. After watching it wipe out the notes I had in some of my contact cards, I decided that it is best to avoid this functionality all together. Then I found a crasher when trying to use the “Time Sheet Entry” option without any projects created. That was unnerving. As clarified by their tech support, I was trying to use that feature in an unusual way. Unusual or not, it still crashed.
I would like to wait till the issues I noticed are resolved, but as long as the software doesn’t loose data and make awful mistakes it’s better then what I’m working with now. The most important stuff is the core functionality, hopefully I won’t find any quirks there.
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.
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.
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 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 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.
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.
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.
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.