Different View of Your FreshBooks(tm) Account

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.

Many things happen from my last post. Freshbooks released their new API version 2.0. I am so glad to see they are not forgetting about us, developers, and I feel more secure because I know I am investing my precious free time in an evolving project. I had to change again my plans, when I said I must first implement just one provider; I couldn’t resist the challenge to try the new API. And because Freshbooks requires usage of SSL, I had to finally sit down and integrate OpenSSL in sInvoicer. Connecting to Freshbooks was rather easy; I had just one problem that was actually my mistake and I solved it quickly with the great support from Ben Vinegar, the author of the API. Also I started with the local database implementation, because I got tired of entering the login info every time I start sInvoicer. And because to connect to a Freshbooks account you don’t use a password but big token, I added support for storing the login info in a secure (encrypted) form to the local database.

I am now in the process of creating the user interface for the Freshbooks Invoice window. I must say, the GUI is not my favorite part of the job, I am never satisfied with the results and I loose too much time on small details. But, this must be done and it is the most important part for the first impression of the potential customers about sInvoicer.

I am also very tight with my free time. My day job (also programming) is exhausting me a lot, and then my son Stefan (which is now almost a year old) is using quite effectively the rest of it. I must say, I like spending my free time with him, he is so full of energy, it is so active; but this is probably usual for a child with his age. Not to miss the point, I was hoping now when my wife and my son are in Krusevo, my wife born town, to work more on this project. But, actually I am missing them so much that I am loosing my concentration. I got used to be with my son all the time (because I am working from home and he is always somewhere around with my mother), and now I feel a little bit empty. I will join them for the weekend and then we’ll return back to Skopje on Monday. The last weekend we were at Ohrid’s lake, we spend some great time together. Stefan liked the water so much; it was pure joy watching him as he discovers the beauties of the lake. To get the picture, I’ll share some photos that I like so much. And I hope you’ll like them too.

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.

When I decided to go on with this project, I wanted from the start to put emphasis on the User Interface. I knew it is not enough just to have ‘some’ UI, it has to be modern and rich in features, professional, nice looking. I was sure I need to buy a good GUI library, but as my budget for this project at the moment is limited, I was just google-ing to find what my alternatives are when the time comes. As I was looking for a MFC based library the requirement filtered a lot of the possibilities and basically narrowed the results to Code Jock and Prof-UIS. I had some experience with Code Jock from my previous employment and was more familiar with it, so I decided to spend some time with the Prof-UIS and to see is it as good as the competition. I downloaded the trial and had no problems compiling everything and all the samples worked right away. I was really impressed from the look and feel of the samples. I returned to the site to investigate a bit more about licensing and pricing, to find what is suitable for me and something that I noticed down their main page astonished me. They were offering a free license for translating Prof-UIS to your native language if it is not already translated. And I couldn’t find Macedonian on that list. I wrote them a quick email and got fast response back with all the details. In 2-3 days all was finished and I got the full license for latest Prof-UIS! This was really amazing. As for a Macedonian these type of products are overpriced having in mind the average monthly salary in Macedonia (somewhere near $300), but this time I was lucky. And as I type this I went to the Prof-UIS site again to have a look at their offer (I wanted to quote it here), but guess what, they reorganized the site. I am not sure is this offer valid any more, I don’t see it on the main site. Ha, maybe now when they have Macedonian in the Languages list they don’t need more languages? But for me this was a great win.

As the wealth world is moving to Web 2.0 and Online Invoicing is getting more and more popular I saw (OK, I imagined) the demand (from users that are more comfortable with desktop application then a web browser) for a rich client application that will offer easier and more comfortable way to manipulate their online accounts. I my self am in the former group of users, maybe I am old school, but I still can’t get used to those web applications. I mean I use the web browser as a tool to explore the internet, to find the information I need, to pay some bills (yes that is even possible over here in Macedonia), to discuss on some forums and similar activities, but to work efficient with an application that is 100% in a web browser I still can’t manage. Chances that I am the only one in the world that feels that way are really small!

So, this is how I came to the idea to develop this application in the first place. Some short searches on Google didn’t return any relevant results for a similar program either made or in development. None, even not in the ads section. Oh my God, either I am the only one in the world that needs this application (I repeated it second time, I know) or there is a shortage on the market. Ha, what a great analyzer am I? I should repeat this one also later!

For me, web applications are still far beyond desktop applications. This waiting to refresh the page on every even small change is the main drawback. Even sites made with AJAX as gmail or their calendar, although very responsive are still not in the range of responsiveness as their desktop counterparts. Maybe I am so used to the desktop, I am programming for the desktop over 10 years now so maybe I am a bit subjective. I believe some younger programmers (not that I am old) that were starting with web programming opposite from my perspective find desktop applications as creatures from the past. Which I guess is normal. Different kind of people, different kind of programmers, different kind of users. All OK. As long I’m not the only one.

Now, is there a need for such a program on the market or not really doesn’t matter anymore because I already made-up my mind. I know it will not take me too much time to develop this program because I have most of the code spread around in classes (C++, if you wonder about the language) that are mainly easy to reuse, so why wait for somebody else to publish similar application before me? Ooo, if somebody else came to this same idea and is right now working on it, then definitely there are also users that are looking for this very same program, but can’t find it yet. Better I hurry up.

I already contacted Blinksale and Freshbooks support about their respective API. I wanted to make sure it is still valid and that they are working on it. They were both very supportive and answered all my questions and that added more fuel to the idea. While there is a difference in the approach how the requests should be send, both providers use XML to return back the results which is simplifying the things a lot. I am planning right from the start to support both of them and if another player comes around in the near future, I’ll consider adding it to my program as an add-on.

Here is a short initial list of what should be supported in version 1.

While offline/disconnected
• Creating new Invoice/Client with all the details and saving it locally
• Modifying Invoice/Client and saving the changes locally
• Marking Invoice/Client for deletion

When online/connected
• Synchronizing sending/receiving the changes made while offline
• Making real-time changes, new Invoice/Client, modifying/deleting

Of course, login/logout to account, stay logged in several accounts and alike, these are small things that are easy to implement and will benefit the users a lot.
Listing/organizing the Accounts/Invoices/Clients in a tree and basic search functionality.

This should be about everything for the beta and if there are no specific requests from some users for something else will stay that way for the first release.