Different View of Your FreshBooks(tm) Account

For anyone looking for offline time tracking in timerSync, the new BETA available here supports it.

Few notes about this version. After installing, you’ll see new menu item in the systray popup menu: Online

After clicking that item you’ll see the following screen:

After clicking the Synchronize button the syncing will begin and after it finished you’ll see in the timerSync timer window new suffix to the title: offline

While in offline mode you can create new projects and tasks and log time same way as when in online mode. When you finish working in offline mode and you have internet connection, you can switch back to online by clicking the same menu item Online (only now there is no check mark next to it, meaning you are still offline).

Clicking the Online item will bring the Synchronize window again.

Pressing Synchronize button will start the sync process, and after successful end of it, you’ll be in online mode again and your new entries should be in your FreshBooks account.

If you need this functionality, please take a look at the beta.

Now when the new version of the FreshBooks API is out, I can’t wait to implement the Timer widget in invoiceSync. So, this is my No.1 priority now. I hope that couple of weeks is a realistic forecast for this task.

Well, I am glad “the famous” post about me the spammer is deleted from the FreshBooks forum. The user who created it has notified me that he has deleted it, on my big satisfaction. However, I guess the popular search engines will keep it in the search results for a little longer (I hope not forever). But at least the link is dead. So, this episode is finished. I don’t look back.

OK, my plans are again little twisted. I planned to inform and ask for opinions about invoiceSync some FreshBooks community users privately first, and when I would have collected some of their thoughts, I planned to make a separate post as announcement about invoiceSync. I though before I go public, it is better to get a feeling from few random users. And I picked this particular user because I thought that a user who is requesting a new feature in FreshBooks would be probably willing to see something new related to FreshBooks. What a mistake.

My attempt failed really catastrophic. I was accused that I am spamming the FreshBooks users for my business after my first email. And this ended up as a topic on the FreshBooks community site. Really unpleasant episode for me and invoiceSync. The post is here.

I guess the user I contacted has full rights to be upset, but I can’t believe that the few lines I sent him can be justified for the damage he probably did to invoiceSync with his public post about me as a spammer.

So, this is now ruined, I can’t contact any other users privately and I don’t plan to post an announcement post about invoiceSync, there would be no point in doing that now. However, I don’t feel that this is going to stop me making a real good product from invoiceSync. I believe in its potential and usefulness to many FreshBooks users. I would just have to find other means for promoting it.

I am so excited, after more than 6 months of playing with invoiceSync; I think I am ready for “The World”! The Windows Desktop Client for FreshBooks is here!

Uh, I had to yell this load. Ok, back to reality, it is not all that bright yet. I have to find FreshBooks users who would like to take a look at the BETA version and hopefully see the potential value of invoiceSync. Until now, the only place where invoiceSync successfully ran was my personal notebook. Few tries from the FreshBooks staff to have a look at invoiceSync had an inglorious end. Yeah, more I write, less reasons to yell load. Good I did it at the beginning.

So, invoiceSync BETA 1 is out, that for sure. You can download it here. Just be careful with your data, if you have a “Real Account” at FreshBooks with real Clients and Invoices, I recommend first to create a test account and check the basic functionality with the test account. Not that invoiceSync will mess your data, but again this is a BETA version, so extra caution is not a bad thing.

If you are a FreshBooks user and you ask yourself, why I would need this invoiceSync thing, here is a reason (one of many): Backup of Invoices and Clients easier then ever.

I guess you all somehow backup your data already in a way, throw XML probably. But, with invoiceSync you can just select your account and download all your data to your station (for now Clients, Invoices and Payments).

It’s been awhile since my last post. I knew there were still many things to do instead of bogging, so I’ve spent my time on more productive tasks. But now, after almost six months I see I am very close to release the first version of InvoiceSync. I also made a first version of the website (still offline), I need to put some descriptions yet, make the setup scripts, test it to see is it working also on new stations (I’ll have to find somebody with Vista to check is it running on Vista or not). Some features I was planning to have in 1.0 will have to wait at least until version 1.1, but I think I have a usable product already, so there are no reasons to wait any longer with the release. Roughly, I would say 2 weeks until I start the public beta.

It’s a pity I couldn’t finish integration with Blinksale on time, so for now I am going only with the Freshbooks integration. Later, if there are requests I could continue with Blinksale, but for now I am concentrating on Freshbooks only.

Let the countdown begin!

These days I started to consider the idea to put a website for the project I am working on, and I had second thoughts about the name I was using for it. I coined a word from sync and invoice and I ended with sInvoicer. I was pronouncing it as es-invoicer, but also it could be divided as sin-voicer, whatever it means. So, I put a question on this forum The Business of Software and my fears were reasonable because majority of the comments lead in that (wrong) direction. And after the suggestion from Nicholas Hebb that invoicesync.com is available, I decided to go with that name. Now it is clearer what the product is about, or at least it can not be confused with something that it is not.

Thank you Nicholas for helping me out and remember me to send you a free license when the product is released.

I managed to sample a screen shot from the early draft version of sInvoicer. It is far from finished, but it contains the majority of the elements that are used in a Blinksale Invoice and they are functional. Don’t look at the toolbar, it is the default one, it will sustain thorough change. I just played with the size of the buttons; I think it would be better to have bigger icons there.

At the moment the Client info is missing from the Invoice screen, I am still considering the option to put it at the same place as in the original Blinksale invoice. The Accounts Pane will have the option of choosing between Blinksale and Local store (and hopefully Freshbooks later). Then the Treeview will list the hierarchy structure of the specified account. Opening and accessing multiple Invoices should be easy over the Tab bar.

I invite you to take a look at the screenshot and comment or email me if you have suggestions.

I am very pleased to say that I have the vast majority of the Blinksale DLL functionality implemented. To admit, these are all reading functions, but I am excited that all went without any troubles. I expect that writing the changes back to Blinksale would also be as easy as getting the data from there. As for now I connect only through HTTP, but I downloaded already OpenSSL and from the examples I saw, there would be no troubles to switch to HTTPS. Anyway, my testing account doesn’t allow me to use HTTPS yet, but it should not be a problem to switch for a month to a paying account when I am ready. I know that without HTTPS I would not get any real testers, nobody would expose his/her private date to public internet just to try this program, so this is number one open point to finish before moving to public.

At the moment I am straggling, should I design the dialogs just by copying the layout from the Blinksale site, that is for example creating/editing Invoice, Client etc., or maybe it is better to stick to a design more common to a desktop application. Pros for copy/paste is that the user will be very familiar with the layout immediately from the start, there would be zero learning time for existing Blinksale users. On the other hand, this would probably result in a ‘not so’ common desktop application design, because web and desktop applications are without doubt different. This and similar GUI issues are my main concern at the moment.

To be honest, I am leaning toward the copy/paste solution because that is also leaving space for the second provider I’ll implement later (Freshbooks) to have it’s own design. I wouldn’t have to worry then about matching the fields from Blinksale and Freshbooks Invoice type to a common Invoice type. I would just keep 2 separate designs independent from each other. This contradicts a little bit with one statement from my previous post where I say that the main EXE will only know what a Client is (in this case Invoice). I would rephrase it as “It would only know what a Blinksale’s Invoice/Client is, but it won’t know where it goes to read the Invoice/Client info, or how it writes the changes.”. This is still quite isolating the Provider’s specific logic to its own DLL, but it leaves space for customizing any Provider’s specific dependencies separately.

Initially I was about to complain that although having a library as Prof-UIS is a bless, it can also slow you down quite a bit. If I would do my GUI with plain MFC, I would have finished it at least 50% by now. This way, I always get some “fantastic” ideas that I later fight for days how to implement. But, the results are not comparable at the end.

After few days spent on researching the API of Blinksale and Freshbooks, I am certain I’ll have to choose only one of them for the first implementation of sInvoicer. This is because I would move more slowly if I would try to do both in parallel. And because I would have to write something like a Proxy Server to support Freshbooks, Blinksale seems to be easier choice. I would need to use something like proxy for Freshbooks because they require a static IP address for every account that has API enabled. That means that I would have to transfer all requests from clients using sInvoicer over my server to Freshbooks and then other way around; from the Freshbooks server over my server to the clients. This is even not so bad because I would be able to track the usage of sInvoicer. If in the requests from the clients I add also my license key, I would have exact info and much more control over licensing. I would know exactly if a license that has only one client is trying to connect twice in the same time from 2 clients and prevent that. But, as for the first version this seems like overkill.

So, my decision now is, I will go first with Blinksale implementation. I will try to make it public as soon as possible, and if there is interest at all, I will start on Freshbooks version. Then I will be able to redo also the Blinksale protocol to go over my own server, so I’ll have more control over the licensing. But, as I said already, I’ll leave this for later.

Now, little bit from the technical perspective. I plan to make separate DLLs for every such provider, and keep the implementation details in there. I am thinking on a model where the main EXE file will know only about the raw interface of the underling protocol. I will use something like Factory in COM for creating the actual objects. I don’t have this 100% cleared, but I am sure I’ll have in the main EXE as little specific dependencies as possible. Let’s say, the code in the EXE will know what a Client is, but it won’t know where it goes to read the Client info, or how it writes the changes. I’ll do this by instantiating the specific object (Client, Invoice etc) in the specific DLL from a raw interface known to the EXE. As an example, to download all Clients from a Blinksale account and store them in the local database, I would instantiate a read protocol for Blinksale and write protocol for local database. That way, code in the main EXE will collect all Clients with a single method, and than calling Save in a loop for all Clients. Other way around will push the local changes to the specific Blinksale account. Of course, this is too simplified; I will have to resolve all synchronization issues that may arise, but one at a time.

I was also thinking on putting some draft versions available for download as soon as I have something usable, so I can get feedback from potential users early in the development phase. But, I am not yet sure is this a good idea. Anyway, I don’t have anything ready yet, so decision can wait a bit.