Accpac 6.1 Development Kick-off
On to 6.1A
Last month we shipped Sage ERP Accpac 6.0A and started working on Sage ERP Accpac 6.1A. Accpac 6.0 introduced our new Web Based technologies with the new Portal, Dashboards, Inquiry tool and Quote to Orders. With Accpac 6.1 we are now looking to fill out the main Accounting functionality by offering Web versions of G/L, A/R, A/P, I/C, O/E, P/O, Bank and Tax (i.e. everything except Payroll, PJC and some options products). This blog posting will fill in a few more details of the plan that was outlined in the Product Roadmap posting.
There will be additional features beyond moving all the screens to the Web, but we’ll talk about those in other blog postings. This posting is going to concentrate on the logistics and process we will be taking to move all these Accounting screens to the Web. One of the other features we will be adding is support for additional Browsers including Chrome, Firefox and Safari. Below is a picture of Edmund Tong and Accpac Jack with the Portal running on an iPad in Safari and on a Galaxy Tab in Chrome.
Edmund is a key Accpac development manager and will be demoing these at the Sage Insights conference in South Africa in a couple of weeks. If you happen to be in the Drakensberg then, be sure to check out his sessions.
Remember that as we move these screens to the Web, we will leave the current VB screens in place. As the new screens are developed we will switch to running these from the new Web based Portal. But you will still be able to run the older Windows based Accpac Desktop like you did in 5.6A and run the familiar screens from there.
How to Move Thousands of Screens to the Web
The challenge we have is to move over one thousand screens to the Web quickly, but we want to do a better job than just moving all the VB screens unmodified. We want to add definite learnability and productivity enhancements in the process.
Many screens are already very simple to use, and many others are used very infrequently or are only setup by Business Partners once. We don’t want to spend much time on these screens but concentrate our effort on the screens the customers work with the most. So a lot of work has gone into categorizing screens and determining how much effort we need to put into them.
UCD Porting Guidelines
We have developed a set of User Interface guidelines that categorize our User Interface forms into a number of categories like: Setup Screens, Printing and Processing Screens, Inquiry Screens and Document Entry Screens. Then we have a set of guidelines for each type and a set of instructions on how they look currently in VB and how we want them to look in the Web.
Below is an example showing how some elements look currently and then how we want them to look now. Along with some instructions. Below is one of these from the rather long porting guidelines on our development Wiki.
We have also developed a “porting tool” which will read VB projects and interpret their screen layouts and then generate an Accpac 6 declarative layout based on the original VB screen, but trying to follow as many of the porting guidelines from the UCD document as possible.
This was a fairly challenging tool to write. Forms in VB are laid out using (x,y) co-ordinates; whereas, in the Web everything is laid out using layout managers. Plus we wanted to do transformations like from notebook tabs to disclosure panels. But the tool was quite successful and saves us a lot of work creating the starting forms with all the controls bound to the fields in the SData feeds. We are just in the process of adding this to the SDK so ISVs can make use of the tool to start converting their VB based forms to the Web in the same way.
We aren’t going to port all the screens in this way. We will select specific high usage screens where we want to target greater productivity and learnability and for these we will apply specific UCD treatments to work to improve these screens more than the others. Below is an early prototype of A/R Invoice entry that we are now using for user testing.
We will sit users down in front of this and observe them entering Invoices to see where they have trouble so we can tweak the design to smooth these out. Performing this sort of User Centered Design can be quite time consuming since we have to go through several rounds of this testing/refining before we get a design our users are most happy with.
We are starting to move all the forms for A/R and O/E first. Although we won’t be releasing the product until all the modules are done, we will be demoing and beta’ing the applications as they are completed so we can get early feedback from partners and customers early in the development cycle so in can still incorporate all good feedback into the product before it ships.
The development team is extremely excited with building on the results of 6.0A and now running with it to move all of Accpac to the Web. We are looking forward to an exciting and rewarding development cycle for 6.1A.
Accpac development is performed by teams at several locations, but the largest is the Richmond R&D Team: