June 19, 2007 at 7:06 am
· Filed under InvoiceSync
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.
Permalink
June 2, 2007 at 7:35 am
· Filed under InvoiceSync
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.
Permalink