Stephen Smith's Blog

In a previous posting (http://smist08.wordpress.com/2010/03/19/sage-erp-accpac-6-x-mobility/), I talked about our mobile strategy of using HTML and JavaScript screens to run on mobile devices. But how exactly will that work? Mobile phones like the iPhone allow you to run web sites in the same manner you run native applications. So you can add an icon to the phone’s home page and then run your web based application. But does it look like a true iPhone or Android native application? Well it does with a little help. There are now several JavaScript libraries that reproduce the look and feel of native phone applications. In the screens below, I used the JQTouch (http://www.jqtouch.com/) library to easily construct some menus to act as an “Accpac Mobile Desktop” to launch our various data portlets (http://smist08.wordpress.com/2009/12/24/sage-erp-accpac-6-0-data-portlets/). This lets a user see various dashboards in real time from their phone.

In this picture we have a basic iPhone with some home page icons, including one for Accpac.

When you select the Accpac icon you then go to a set of menus for Accpac. Notice that even though this is a web page, it looks just like any other iPhone application. There isn’t any sign of the Safari browser, everything is nicely hidden.

The menus have nice animated transitions, so when you select them they slide to the side. Clicking on Payables yields:

Then if we click on Aged Payables we get to our regular Aged Payables snapshot that we normally see in the new portal/desktop. At this point our portlet isn’t styled to fit into the iPhone and there are a few style sheet bugs. But otherwise it does nicely display your aged payables.

Actually it looks a little better in landscape:

To use Apple’s iPhone SDK and iPhone emulator you need a Mac computer. I don’t own an iPhone, an Android phone nor a Mac. To test for the iPhone I used the MobiOne Test Center (http://www.genuitec.com/mobile/). For Android, I used the emulator in the Android SDK (http://developer.android.com/sdk/index.html).

Same sort of thing in Android:

Since we have made all our screens with standard HTML and JavaScript we will work on all modern devices. Plus as HTML5 is rolled out over the next few years we will pick up all the advances there as well.

Although we aren’t targeting mobile clients for our first couple of releases, we are architecting the Accpac 6.x series with mobility in mind. This blog posting isn’t meant to layout a roadmap for our mobility support, but to talk about what we are doing to support mobile clients and why. Mobile devices are proliferating. By mobile device, I mean anything you can carry around with you and stay connected to the Internet, from cell phones to iPads to netbooks. Typically these devices are connected to the Internet via cell phone carriers, or through WiFi hotspots.

The first key to our mobility support is Internet Browser independence. On regular PCs, most people run Internet Explorer. On mobile devices, almost no one uses IE. The most common mobile browser engine is WebKit an open source technology that is at the heart of the Apple Safari, Google Chrome and RIM browsers. Other popular contenders are mobile optimized versions of Firefox and Opera. For Accpac we need to ensure we work well in all these environments.

Generally we are taking the approach of running well in a mobile browser rather than developing mobile applications for each platform. If we were to do this we would need a version of Accpac for the Apple iPhone, iPad and iPod; Microsoft Windows Mobile; Google Android and ChromeOS; RIM Blackberry; Palm OS; Nokia Symbian, etc. This proliferation of mobile platforms has led to fierce competition and moved the technology ahead in leaps and bounds. But it makes it hard for software vendors to natively support them all. Plus there is the added complexity of dealing with all the separate application stores and all their rules and regulations. For us its way easier to be a well behaved Web Application that runs well in each device’s native browser.

The first thing is to handle hugely varying screen sizes. You can get racks that hold 6 large screen monitors and hook them up to your PC to get a tiled giant high resolution display, then at the other end of the spectrum, there are cell phones with huge computing power, but tiny low resolution screens. We certainly don’t want to optimize all our screens for 320×120 resolution and have a postage stamp sized screen on a big screen regular PC monitor. Our regular screens actually work fine on devices like the Google Android, but you have to scroll around quite a lot to get to all parts of the screen. In the Accpac 6 architecture the screen layouts are contained in separate XML files, unlike our previous VB6 technology where the screen layout was part of the program file. This allows us to maintain a repository of different XML files on the server and have some intelligence to serve up the correct layout based on the circumstances. It then becomes much easier to have minimal low resolution versions of the screens along with the regular ones. Plus all these can be customized. It might even eventually be necessary to produce medium resolution version for devices like the Apple iPad. On the other hand, the screens on these devices are getting better and better, but there are limits to what the human eye can discern. After all no one wants a giant cell phone, the smaller the better, so at some point improving the resolution doesn’t help.

We also need a minimal version of our main program Portal. Probably something with just a few big buttons to run a handful of screens, then when pressed each one takes up the whole screen with no Portal frame around it. Mobile users might even just run the screens directly in their Browser from their favorites menu.

Another difference in the mobile market are the input devices. No mouse and you are lucky if you have a qwerty keyboard. Touch screens aren’t as precise as a mouse and we have to have bigger buttons and controls or the user can’t select or manipulate them. New input devices like motion censors are present. What does it mean to Order Entry if someone shakes the iPhone? Does this mean clear the order and start over? Basically to work well on these devices we need to figure out what all these new metaphors mean to our Accounting Applications.

When we architected Accpc 6 to run in any Browser, the goal wasn’t so much being able to run in Firefox on Windows, it was more about extending the reach of where you can run Accpac screens, including PCs like Macs or Linux Netbooks, tablets like the iPad, or all the small cell phone based devices like the Apple iPhone and Google Android.