Sage 300 ERP Web UIs and CSS

Introduction

Last week I blogged about using MVC to program the new Sage 300 Web UIs, this week is an update on how we lay out the forms for the new UIs. I blogged on the previously here; but, this article is quite outdated now, everything mentioned will still work, it just isn’t the preferred way of doing things. This week’s post is an update on how we are now laying out forms and applying CSS to best effect.

In the early days of the Web there was only HTML. HTML was designed to structure content, mostly for scientific papers. Over the years, HTML was extended to allow more content types and to add tags for formatting. HTML has always had a set of table tags which were intended to display tables of numbers, usually produced by various scientific experiments. Clever web designers then figured out how to layout quite sophisticated layouts by using these table tags, by putting tables inside other tables and such. These ideas were extended for a while until it was finally realized that HTML was getting over-burdened and that we really needed to separate the content from the formatting. This was when Cascading Style Sheets (CSS) were introduced.

The intent with CSS was that people would stop using various formatting tags in HTML (like the font tag) and would instead do all their formatting in the CSS. Then in HTML tags would only be used to specify content like paragraphs, sections, copyrights, etc. Then tables would only be used to represent proper tables again. However for compatibility all the old HTML tags had to be left in place, so now we have a situation where you have to know which tags in HTML to use and which not to use, because you should use CSS. If you want to layout your pages using CSS then you need to use the HTML div and span tags which don’t do anything except give CSS a way to control your layout, then you want to avoid the older layout tags like the table ones.

CSS is used both for layout and for controlling the detailed look of content elements. This blog posting is concerned with the CSS features to do with layout and not the features to control things like color and font style. That would be a large blog posting in its own right.

GWT provides access to both the HTML way of formatting and laying out pages as well as the CSS method of laying out pages. Some GWT layout controls like the grid, horizontal panel and vertical panel wrap HTML table tags. Some GWT layout controls like the flow panel and simple panel wrap HTML div tags. This can be tricky since the GWT documentation isn’t always clear on what DOM elements are being created by a given control. But generally if you aren’t laying out the form via CSS then use all the panels, if you are using CSS then you will only use a couple of GWT’s layout panels.

CSS lets you control layout in a liquid or flowing manner, or control the layout by using fixed absolute placements and sizes (usually in pixels). Generally we want a liquid layout, so that our pages can be resizable and automatically adapt to different screen resolutions and still look good as various parts are hidden or shown depending on application options.

If you read a book on CSS (and there are many excellent examples), you quickly notice that all the terminology is from typography and magazine layout. Sometimes it takes a bit of getting used to this, so you can see past the terminology and apply the ideas to the layout of your form. This just takes a bit of patience and time to get used to.

How Sage 300 Uses CSS for Layout

The main way that you control form layouts with CSS is through controlling things in HTML div tags. These were designed to have CSS attached to them and then you move them by floating them around and controlling their size and dimensions. First let’s consider a simple form with labels, textboxes and sometimes a menu icon to the right of the text box. Since we want to control the placement of each control we wrap it in a Simple Panel and place them in flow panel’s as the diagram below indicates:

We then build up rows of the controls we want. Then to break each row we have a simple panel with the clear style which then acts as a line break. As you can see from the diagram this leads to a fairly simple setup, but it doesn’t look like it will lead to much of a page. But this is how we lay it out in HTML, and then we will leave it to CSS to make this look pretty.

To build up more complicated layouts we nest these. So for instance if we want a two column display then we put two flow panels side by side and then build the above idea in each one. The below diagram shows how this level is setup:

The labels in the diagram are the styles applied to these flow panels. Now you might think that we are just doing what we did with HTML tables at this point, having to nest them in complicated ways to get our effect.  This is true to some degree, but we have more control. For instance in a table control if you want to hide one cell, then the cells below will not move up to fill it, because this is a logical table. Cells only move up if you hide an entire row of cells. In the CSS scheme things will move up whenever there is room (unless you tell them not to), so this keeps forms much cleaner looking when parts are removed.

Another thing that controls layout is the CSS box model. This is the mechanism where you can put margin, padding and border around any element that you apply CSS to.

These elements give you a lot of control around how you position elements on the page. If you make the left padding of a flow panel large then you push the things contained in it right, etc. How to really control the fine details of layout using the box model can be a bit confusing at first, but it is easy to look for examples on the web that show all the tricks.

In the Sage 300 ERP SDK we provide a SwtDefault.css that contains all the styles you need. Then if you create your declarative layouts as we indicate and follow our style guidelines, you should get nice looking adaptable screens fairly easily. So basically it contains a lot of styles that are intended to be applied to simple and flow panels. These are intended to setup various page design patterns that we document in our UI guidelines. They then have the various floats to format the rows and to setup multi-column displays. They also include all the correct settings for the box model so that everything is spaced and sized correctly. This gave our interface designers a very fine grained level of control over the look and placement of all the controls.

Summary

Hopefully this gives you a flavor for how we are using CSS to layout our forms. CSS is a large topic, but for an application developer it’s really a matter of having a basic understanding so you can use the palette of styles that are provided by default effectively. If you are really advanced you can change the CSS files to completely change the way Sage 300 screens look.

Sage ERP Accpac 6 Competitive Advantages

Introduction

A key goal of the Sage ERP Accpac 6.x series is to completely revamp the Accpac User Interface technology. The goal is to transform Accpac into a technologically leading product again. We want to ensure that through this technology transformation we make Accpac an extremely competitive market leading product. This blog post will look at the technologies being incorporated into the Accpac 6.x platform and compares them to other technologies to highlight a few of the differentiators that set Accpac apart. We will also examine what we will be able to do with the building blocks being put in place.

This blog posting talks about the technologies being incorporated to make Accpac more competitive. However there is much more to competitiveness than the technology platform being used. We are also making changes to business models, marketing, product features, integrations, migrations, verticals, etc. All of these have just as big an impact on competitiveness as technology. All of these reflect that Accpac isn’t sitting still, but that all departments are moving ahead at a rapid pace to stay ahead of the constant change that we see in the market today. But I’ll leave those topics to other people’s blogs.

Usability

Besides advancing to more modern technologies and providing a platform for future development, we are taking the opportunity of a User Interface rewrite to give the product a usability rework in the process. The goal is to greatly improve the learnability of the product, and to greatly increase the productivity of customers. This is from performing extensive end user testing and from applying modern user interface design techniques. Typically applying advanced usability to an ERP product has been the domain of small business products like Simply Accounting or Peachtree. We are looking to bring the ease of use of a small business product to the mid-market space and to develop this into another competitive advantage. We are also looking to greatly improve our user assistance, for more see: https://smist08.wordpress.com/2010/06/19/sage-erp-accpac-6-user-assistance/.

Technology Direction

The general trend in technology is to go Web. The question isn’t whether, but how and when. A key trend driving this is that people just don’t want to install software anymore. It’s a pain. They want to just browse to a web site, possibly sign up, log on and work. People have many devices whether a PC or Mac, iPad, iPhone or Android. Ideally they would like to do their work from any of these and not have any hassles of downloading and installing applications. This trend on the front end is well underway without any resistance to adoption. On the back end many people are asking the same questions, why do we need to maintain all this server and network infrastructure? How do we reduce these costs and just have our applications work. This is driving SaaS (http://en.wikipedia.org/wiki/Software_as_a_service). This is still underway with many problems still being solved like protection and privacy of data, what happens if you SaaS application goes out of business, control, customizability, etc.

We are fully embracing the new Web based technologies. With our Accpac 5.x platform we were web deployed but relying on ActiveX controls and IE to provide the foundation. These caused problems with security, reliability, ease of use and performance. Learning from this lesson we have gone in the complete opposite direction, writing our new UIs in pure HTML/JavaScript and not relying on any ActiveX controls, Java Applets, Browser Plug-ins or anything else that can cause installation or usage roadblocks. All we require is a modern Browser that runs HTML and JavaScript well.

Many of our competitors continue to develop Windows desktop applications using technologies like .Net WinForms (http://en.wikipedia.org/wiki/Windows_Forms), Java Swing (http://en.wikipedia.org/wiki/Swing_(Java)) or WPF (http://en.wikipedia.org/wiki/Windows_Presentation_Foundation). These applications will only run on Windows, they will not run on mobile devices, Macs or Linux PCs. They are designed exclusively for PC sized monitors and will only run on Intel/AMD hardware. The claim is that they can give a richer user experience than Web based applications, which perhaps true ten years ago, is no longer true today. Currently applications written with HTML4 can easily match the richness while applications embracing HTML5 will exceed this richness of interaction, while remaining open and device/hardware/operating system independent. Typically such applications haven’t reached the ease of use level common in Web applications like Facebook or Gmail.

Many of our competitors still use ActiveX controls (http://en.wikipedia.org/wiki/ActiveX) and Java Applets (http://en.wikipedia.org/wiki/Java_applet). Again requiring special plug-ins or limiting browser and device choices. These are really just ways to start Windows applications from inside the Browser.

Many of our competitors have gone with Adobe Flex/Flash (http://en.wikipedia.org/wiki/Adobe_Flex) to create their Web Based UIs. The problem with these is that you require an Adobe plug-in for your browser for these to operate. This means they do not work on many phones and other devices like the iPad. They also sometimes don’t port to all platforms, so if you have 64-Bit Linux, you are out of luck.

Many of our competitors have embraced Microsoft Silverlight (http://en.wikipedia.org/wiki/Microsoft_Silverlight). This is worse than Flash, in that there are very limited choices for where it runs and you are really limited to only running on Windows PCs in IE or on Microsoft Phones which so far haven’t been very popular.

Again we chose HTML and JavaScript because we get full device and browser independence built on open industry standards. Our competitors will claim that they chose something proprietary to give a richer client experience. This may have been true five years ago, but today even with only HTML4, you can get just as rich an experience as these other technologies. And now with HTML5 and a whole host of newer more powerful Browsers coming to market, we can now exceed the rich client experience of these other technologies without losing TCO or locking in to proprietary platforms.

TCO

Reducing TCO is a key goal of Accpac 6. Initiatives here include requiring only a Server installation, no workstation setup, nothing else that needs to be installed on the individual workstations. Not requiring any special firewall or network setup, having everything use standard HTTP (or HTTPS). Making customizations upgrade safe, allowing you to upgrade and have customized reports and screens just work. For more details see:  https://smist08.wordpress.com/2010/03/12/on-total-cost-of-ownership/.

Customization

As we move forwards we want to provide a more powerful customization model. A powerful customization model and robust SDK has always been one of Accpac’s competitive advantages, and we want to extend that. Studying what people customize currently and seeing if we can incorporate this into the product as part of the UCD review process to eliminate the need for customization. But when customizations are required we want to:

• Make more customizations straight from forms without requiring code.
• Make customizations upgrade safe.
• Have many more customizations possible from the UI designer.
• When code is required, ensure we provide the power to do more than we can currently.

For more on customizations see: https://smist08.wordpress.com/2010/02/05/sage-erp-accpac-6-customization/.

Openness

With everything we do, we are trying to be more open. Using open standards like HTML, JavaScript, SData and XML. Any files that we save are now just XML text files that anyone can manipulate with any of the many XML tools out there (including notepad). We want to follow industry standards and best practices. We want to avoid single vendor lock in. We want to make sure we can play when the next disruptive technology comes along. We are avoiding binary file formats and binary network protocols. We are avoiding proprietary technologies developed by a single vendor. We are ensuring we can be as adaptable and open as possible. This also reduces TCO since we can leverage open source technologies like Apache Tomcat (http://en.wikipedia.org/wiki/Apache_Tomcat) and Eclipse (http://en.wikipedia.org/wiki/Eclipse_(software)) which are freely re-distributable.

Future Foundations

Many of the technology choices and architecture we chose was to provide a foundation for future innovations including:

• Browser Independence: Due to time constraints the first version will fully support only IE 7 and 8. But everything we have done is set to support Firefox, Safari and Chrome as well. This would include desktop and mobile versions of these Browsers.
• 64-Bit – All the new technologies are fully 64-bit compliant. You can run the 64-bit versions of the browsers.  Now we are set to compile our Views for 64 bit and to produce a 64 bit version of Accpac when needed. As we scale we will be able to take advantage of huge 64-Bit memory spaces.
• SaaS – Although we are shipping as an on-premise install to start, we have architected the system for SaaS deployment at a later version.
• Advanced end to end integrations enabled through SData. As other Sage applications like SageCRM move to the same platform, we have the opportunity to integrate much more closely. With common UI components and a common SData Web Services layer, we can provide much more cross application functionality in UIs, Reports and Workflows. For instance see: https://smist08.wordpress.com/2010/05/07/on-the-sage-gcrm-contract/.
• Performance/Scalability – With the adoption of SData Restful Web Services we can use advanced Web performance tools to test and expand the scalability/performance of Accpac from where it is today. See https://smist08.wordpress.com/2010/02/26/sage-erp-accpac-6-performance-testing/.
• Server Independence – All the technologies involved in the Accpac 6 platform are server operating system independent. So we can produce a Linux Web Server version easily if we choose to do so.
• Full Unicode Support – All the new technologies fully support Unicode, so this sets the stage for creating a full Unicode version of Accpac.
• Mobile – All the new screens are pure HTML/JavaScript and can run on iPhone, Android and Blackberry phones. Plus tablet devices like the iPad. See: https://smist08.wordpress.com/2010/06/25/accpac-on-the-iphone-and-android/.
• HTML5 – For our first version we are only using HTML4 features, but since we are built on the Google Web Toolkit (GWT) and Google is aggressively pursuing HTML5 we will automatically be getting HTML5 features as they become available in the various Browsers.
• Connected Cloud – As a Web Based application, built from the ground up on RESTful Web Services, we are ideally situated to integrate with other Web Based applications based on Web Services whether these are locally installed or cloud based. This can include common ERP services like sales tax calculation or government reporting, but also integration to other services like Social Networks or Web Based Office applications (like Google Docs). Our technology platform is ideal for both consuming and producing such services.

Summary

With the Sage ERP Accpac 6.0A platform we want to ensure that Accpac is a leader in Web Technologies, Usability, Customizability and TCO. Expect to see a progression of exciting releases kicking off with 6.0A later this year.

Update 2010/10/10: Forgot to mention competing against Web 1.0 companies. Many of our competitors went to the web early with technologies like ASP.Net. These are all Web 1.0 applications meaning that they aren’t a very rich user experience and often result in fairly major page refreshes as you work. These companies may claim to be Web 2.0, but usually they have only patched in a few specific cases for show and you soon realize it isn’t used in most of the product. Many of these companies were start ups and are still fleshing out full ERP functionality and so don’t have time to go back and do a major refactoring of their UIs. Accpac’s new Web interfaces are fully Web 2.0 which use Ajax everywhere. All server calls are asynchronous and we only update individual DOM elements, never doing a page refresh. Since Accpac has full ERP business functionality already, we aren’t still filling in missing pieces.