Moving VB Screens to the Web
Now that 6.1A development is ramping up and we are on the journey, I thought I’d blog in a bit more detail on how we are moving the VB screens to the Web. In order to complete the Accpac journey from VB to the Web we have to convert thousands of screens. In order to do this we have developed a number of tools to help in the process. However in order to reach our usability and performance objectives, a certain amount of hand tuning is still required.
After the TPAC conference we had a developer open house, where third party developers could come visit with our developers and tour our facility. We provided a number of presentations including one on using our Porting tools and on our Porting process, including how we want to improve our usability. These tools are now in the SDK which is posted on the development partner Wiki and the various porting guidelines are being posted there as they become finalized.
Our Porting tool consists of two parts. The first is a Visual Basic plug-in. This plug-in takes a list of VB Projects, loads each one and then iterates through the various collections in the project and writes them out to an XML file. Below is the screen you get when you run the Porting Wizard from VB:
This tool needs valid Accpac Sign-on information since it actually loads and activates each UI. This allows it to load all the language specific strings so these can be ported as well. Basically when run it outputs all the information on the screens (including popups), all their controls, all language strings and their layouts. As a VB plug-in this tool can find and export any design time or runtime information from the VB projects.
The next step is to take this XML file and create a SWT (Sage Web Toolkit) project from it. Our tool for creating SWT projects is SwtUICreator. This tool can either be run command line or from an Eclipse plug-in. To convert UIs it needs to be run from the command line. Usually you would create a batch file to convert all your UIs. For instance the following will create a SWT project for Order Entry based on the OE1100AccpacCtlInfo.xml file generated by the VB Wizard mentioned above.
-copyright “2011 Sage Inc. All Rights Reserved”
This will then create a SWT project with the screen layout converted, SData resources defined and is ready to run.
The following screen shot is that A/R Customer UI straight from the porting tool. It should look somewhat familiar if you are used to the VB screen. Notice that it has converted the notebook tabs into disclosure panels and has changed the record navigation controls to upper right of the screen. We haven’t finished updating the Cascading Style Sheet (CSS) for this yet, so the look will change (and hopefully improve quite a lot).
There is quite a bit of room for tuning this UI to look much better. Developers now have as a starting point a screen that can navigate, create, update and delete records. All the fields are connected to datasource properties and all the translated strings have been moved from VB language DLLs to XML strings definition files.
After the Porting Tool produces the starting point, people start modifying the code to produce the final product. But what if we improve the porting tool? With-in the porting tool we are providing the facility to re-run it, but not to overwrite any changes made since last time. So we can start porting without worrying that we will have to start over. For instance we are planning to generate automated test scripts from the porting tool, but porting has already begun. So the porting tool will be able to add these automated tests to existing projects later.
The porting guidelines are basically a set of rules of how we want the various design patterns used in the VB screens to be converted to the Web.
The porting tools will try to apply as many of these as possible, but it can only work with what it has available in VB. So the next step is to apply any tweaks to the UI that are necessary in the SWT UI Designer to get the screen to follow the porting guidelines. For most simple screens, no work is necessary. But as screens get more complex then more hand tuning is required.
For the main document entry screen like Order Entry where we expect many users to spend the majority of their time, then there will be custom usability research applied to go beyond the straight porting process.
The developers take the screens output from the Porting Tool, make any necessary tweaks to follow the porting guidelines, then get a usability expert to sign off on the screen design. Then they write any necessary code.
Although the Porting Tool makes a good start, there is often much more to a UI than just basic CRUD operations on simple records. The developers now have to add code to support all the things that go beyond this. They need to hook up all the popup forms correctly. They need to ensure the right things happen on fields that have a lot of logic behind them, like entering a customer number in Order Entry. On simple setup screens there probably isn’t any coding required. But on complicated document entry screens, there is a lot of code going on behind the scenes.
If we just run the screens as produced directly from the porting tool then they are quite slow. This is because the porting tool ports all the VB datasource to SData datasources. But each SData datasource requires calls to the server to configure and get data. We don’t want multiple of these happening. Ideally each screen should use very few datasources (ideally one). If a VB UI requires something, it just asks for it, this is a problem on the web since we want to reduce the number of round trips to the server. Often a UI wants to look up ancillary helpful information to help users, which is good, but we don’t want a separate server request to do this. So we have to remove these extra datasources from the project and add this information to the main SData feed for the project. This is relatively easy since it’s just a matter of editing the XML definition for the main SData feed to define what extra information to include (like G/L Account descriptions).
From the A/R Customers screen above you can see that some of the controls like the record navigation control are still in the early stages. We are starting moving all the VB screens to the Web while still completing the framework so we can get feedback to ensure the SWT framework supports all the things we require. We made sure all the APIs were competed so we won’t have to keep making changes to the UIs as we finish the framework. We left some of the cosmetic affects and some of the usability tweaks to be completed later. This is to get as much feedback as possible as early as possible so we still have plenty of time to make adjustments.
The main benefit of this project is to move to the Web. To reduce TCO by removing the need for any sort of Workstation Setup on a computer that is using Accpac. As we move to 6.1 we are supporting the IE, Firefox, Safari and Chrome browsers. This means you can run Accpac from any device/computer that supports one of these Browsers. This includes regular PCs, Linux PCs, Macs, iPads and Android Tabs. Additionally smaller versions of the screens can run on devices like iPhones and Android phones.
As we move all the screens to the Web we are looking to improve usability and address various customer complaints about the screens. For instance people have complained about optional fields always being in popup forms. Now they are either in disclosure panels or are actually in the grid control as additional columns rather than requiring a popup. People have complained about the notebook tabbed panels we use in VB, that it is too time consuming switching between tabs and that you can’t see all your information at once. Now with disclosure panels you can leave them open or closed as you wish depending on what you want to see (and the state is remembered from use to user). When entering comment/instructions you had to enter several fixed length lines which made copy/paste difficult. Now these are a single field so you can easily cut and paste the data.
Another complaint is that when you open a report, it is model, so it’s hard to open different versions of a report with similar parameters. Now each report opens in a separate Portal panel and you can open as many as you want to compare data much easier.
Now that we are getting into full swing moving all our screens from Accpac to the Web, I hope this gives an idea of the process that we are following. As the various Accounting Modules start to come together we’ll post them on an externally facing Web server so people can see them and provide feedback as we develop them.