Wednesday 30 January 2013

Real world Web browser development

Have just completed a small static Web browser application.  It is a bi-directional data capture application.  In my case it is a stock order system.  It works like this.  You fill out a single page order form (which is an HTML form with external CSS files and external Javascript files) and email it as an attachment to the wholesaler. The wholesaler opens the attachment and prints it off. They wander around their warehouse ticking off the stock items as they are picked.  When they are finished, they tick off the items on the HTML form, add any notes about the order (perhaps not all the stock is available and some of it has been placed on back order), regenerate the HTML form as text, which they cut and paste back into the email as a reply.  When the email reply is received, the recipient copies and pastes the email body back into an HTML file on their desktop and views the revised form. This process can be repeated as many times as necessary until the stock order is complete.

What have I found out?

1.    Javascript is so popular it's easy to find a solution to just about anything with a quick search on the Internet.  Due to the nature of the language the explanations and solutions are very straight forward and easy to understand.
2.    Using CSS for layout can be tricky.  Content boxes don't always do what you would expect.  I found myself using them on a trial and error basis most of the time.  After a while I began coding most things in pixel sizes and using id selectors for everything.  In Fox-Toolkit, text never exceeds it's content box boundary, but with CSS, sometimes it did.
3.    Having a separate external CSS file for printing was fantastic.  In every other software development environment I've used, with the exception of Microsoft Access, printing has always been a major problem.  With CSS all I had to do was create a new style sheet and make everything invisible except for the stock table.  It was done and dusted in 30 minutes.
4.    The DOM (document object model) is another great feature of Web browsers and Javascript.  It allowed me to easily create a dynamic table where new rows could be added and removed at run-time.
5.    JSON too proved to be huge time saver, serialising and deserialising my Javascript data storage array with a couple of functions.  In Classmaker, I had to write and debug my own lightweight tokenised string data structure (which by the way has been a wonderful thing - lightweight tokenised strings for data transport rock), which incidentally is very similar to JSON.  With JSON it was all done for me. As argued by the proponents of JSON, XML is just too markup heavy for decent data transport performance.
6.    My application has relied heavily on include files.  The core HTML file is as small as I could make it.  All the HTML markup code is located in an external Javascript file. With just 15 lines and 760 bytes in size, it is easy for core HTML file to be copied backwards and forwards as text in the email body.  All the include files which are doing the heavy lifting are located on a Web server. Without include files the HTML file would have been too large to copy around as text.

After reading this you might be asking why?  Why not create a spreadsheet and email that backwards and forwards?  I didn't choose the spreadsheet route for three reasons:

1.    I wanted the end users to have no software dependencies to worry about.  By using a Web browser that is avoided.  The only hiccup would be users who do not have Javascript enabled on their browser.  To be frank, they would be a rare breed these days.
2.    Printing was very important to me.  I needed to be certain that printing out to hard copy would be painless for users.
3.    I wanted the stock table rows to be created dynamically at run-time, with no opportunity for data to be loaded into unexpected places.

Thursday 3 January 2013

Have Web browser apps finally come of age?

In the past, I've evaluated Web apps and discarded them as being a waste of time for the following reasons:

1.    They are very slow.
2.    They were hard to print from.
3.    They didn't have adequate window controls.
4.    They didn't have an adequate window layout system.
5.    They mixed data and presentation together.
6.    The web browsers weren't standardised.
7.    They didn't have a powerful client side language.
8.    They didn't allow the use of include files.

All of these things, with the exception of slow response times are changing.

Web browsers today have:

1.    Fast rendering engines.
2.    Intelligent printing e.g. modern browsers will automatically split a print job across a table by splitting on the row and printing the table headers on the new page.  In the past a row would be chopped in half.  They also have useful options like page counters and date of the print job.  Firefox is leading the pack in the printing department.  I use it to print the invoices I generate from GNUCash (if you're looking for small business accounting software, check it out.  After evaluating a number of desktop and Internet based packages, I chose GNUCash, due to it's maturity and customisability.  It uses Scheme for it's embedded language).
3.    The introduction of tabs has been a major development, but they still don't have the sophisticated controls available to desktop developers.
4.    The introduction of Cascading Style Sheets is one of the main reasons I'm now looking more closely at Web development.  CSS means that a developer can now completely separate presentation from content.  Pages can now be coded up in basic XHTML with no formatting of any kind.  They will appear on the page sequentially.  With the liberal use of <div></div> content boxes and CSS the content can appear anywhere in the browser window. This still isn't as easy to do as it is in Fox-Toolkit, but it's getting close.
5.    Before CSS, web development was a mess.  HTML tags had to contain all sorts of markup for font-sizes, font-styles, dimensions for the control and colors just to mention a few.  Now all of this presentation markup can be removed and all presentation can be organised from the external style sheet.
6.    Web browsers weren't standardised and there were lots of different client-side binary formats competing for attention e.g. ActiveX, Java applets, Flash applets.  Thankfully, these have gone away and Javascript has largely won the battle for client-side control.
7.    As mentioned above Javascript has now been accepted as the default client-side scripting language.  It has come ahead in leaps and bounds.  Two areas in particular deserve mention, DOM and JSON.  DOM provides a reference for all elements on a web page using a tree structure.  The entire tree can be quickly navigated using Javascript to locate, add, delete and manipulate elements at run-time.  JSON is a text based data format, that naturally co-exists with Javascript.  It is a simple matter to create and parse JSON objects using Javascript.
8.    Web browsers can use include files as a matter of course.  Your web page can include any number of CSS and Javascript files.  Three advantages accrue from this remote coupling.
    a)    Web pages can be kept small.
    b)    Multiple CSS files enable presentation to be customised for different devices.
    c)    The Javascript code files which rarely change can be minified and cached locally by the Web browser.  This will speed up web applications substantially.