xTuple Web Client: It's not just for mobile devices

One of the great misunderstandings about the new xTuple web client is that its primary purpose in life is to provide an interface for mobile devices. This may surprise people, but that was never the primary reason for its creation. In fact, we expect more people to use it on laptop and PC environments than on mobile devices. It has been labeled the “Mobile” client entirely for marketing reasons to differentiate it from the Qt based “Desktop” client. There were actually several goals we were attempting to achieve in development by creating this technology including:

• A user interface that could run in any modern browser.
• Cloud-ready architecture.
• An object oriented paradigm for defining business objects and their corresponding functions.
• Improved performance on large data sets.
• Unit of Work commit transactions.
• Inline editing.
• System wide support for locking.
• More consistent user interface.
• More modular design.
• Web services support for easier system to system integration.
• Native support for column and row level security.
• Mobile ready interface that will work on any device including touch devices such as tablets and phones.

That's a lot of goals! Some of them may not make sense to you, so I will describe each of them in more depth.

A user interface that can run in any browser

The benefits of this are probably among the most obvious. The main idea here is system administrators do not have to deploy and update client software on local devices. Users can log in from anywhere using any device with a modern browser.

Cloud ready architecture

I know, I know. The use of the term “cloud” is such an over-hyped and misused buzz word that it causes as much eye rolling as it does excitement. What this really means to us is that we can deploy the software as a service in a way that can scale economically as the user footprint grows, and that works well over the internet where connectivity and bandwidth are often spotty and unpredictable.

An object oriented paradigm for defining business objects and their corresponding functions

I debate whether I should list this item as third, because in my mind it is the most important attribute of the new architecture because object oriented programming (OOP) enables just about everything else on this list. Basically we have introduced a core notion of a model based business object that defines the universal behavior of all objects in the system. This is a radical change from our Desktop client which uses scripting techniques and hand written SQL statements to drive all functionality. What this means is if we want to add a new system wide feature we only have to add the feature in one place and it becomes available everywhere. It also means it is much easier to extend the application with custom functionality, with a much lower probability of breaking the core on the next upgrade. I could write an entire book on this subject, but suffice it to say that many books have already been written on OOP and this is a sea change for xTuple.

Improved performance for large data sets and complex functions

The web client implements a technique known as “lazy loading” when presenting lists of data. What this means is when you bring up a list of what is potentially a million records, only the first few are actually loaded. As you scroll through the list, additional records are loaded a few more at a time in the background. In this way you don't burden either the client or the server with the complete request to query and process a million records.

Like all modern browser based applications, the new client also features ubiquitous use of asynchronous programming. What this means is when a user does something that requires a request to the server to get more information, the client allows the user continue navigating and doing other things until the answer is returned. This is vastly different from a single threaded application like the Desktop client which basically stops all further activity until it receives a response from the server.

Finally, the web client has been optimized to send as little information back and forth as possible. After the application is loaded in your browser, no further scripts or HTML are passed between the client and the server. Only business data is transmitted, and even then we cache and compress data when possible to ensure minimal chatter between the client and the server. These optimizations, coupled with asynchronous programming and lazy loading are reasons why the web client can run just as well from a server in Singapore to the United States as it can on a server in your local region.

Unit of Work Transactions

This is very closely related to object oriented programming, but what it means is when business objects or transactions are committed to the server, they are committed in their entirety. In the case of a complex object like Sales Order this means nothing goes to the server until you click “Save” and when you do the header, line items, comments and everything else gets committed all at once. By contrast in the Desktop client when you are working on a document you are committing bits and pieces to the server. This can lead to problems if you get abruptly disconnected server while working on an incomplete document. Unit of work also enables the next important feature:

Inline Editing

One of the things that has dogged us the most over the years is the dearth of inline editing capability in the Desktop client, meaning that people want to edit lists such as Sales Order line items directly in the same form as the header. People don't like to have to open a new form every time they create a line item, enter a comment, or a characteristic. We've created work arounds for this in a few places, but by and large you can't do this across the board without an object oriented foundation that uses unit of work transactions described above. In the web client you will find that all business objects with line items allow direct inline entry on the main workspace for the document, and you can also edit other things like comments and characteristics inline.

System Wide Support for record locking

A classic problem in enterprise applications comes up when you have two people open the same record for editing. What happens when they both make changes and save? Without a record locking system, the second person's changes over-writes those of the first. The Desktop application has record locking on Sales Orders, Purchase Orders and Transfer Orders that disallows the second person from editing until the first person is done. The web client has this behavior on all business objects. This is only feasible with an object oriented architecture.

More consistent user interface

We've had complaints from time to time about some screens behaving different from others. For example on the Desktop client in the Sales Order screen when you click “Save” the screen saves and clears for a new record. In the Invoice screen when you click “Save” it saves and closes. In the web client all screens (called workspaces) have the same controls: “Refresh” requerys the data. “New” will save the current record and clear the screen for the next. “Apply” allows you to save and stay on the same record. “Save” will save the record and send you back to the previous screen in one click.

There other nice consistency improvements, like all lists having the same filtering and sorting mechanism, all layouts following the same style conventions and so forth.

More modular design

When you are dealing with an enterprise application like an ERP system modularity is critical because there is so much variation from business to business. Different businesses, and even different users within a business, need to be able to have the application do different things which usually means adding or removing large swaths of functionality for each implementation. It can also mean doing deep invasive customizations. This all needs to be able to happen in a way that is relatively easy to turn off and on, appears seamless to the end user, and allows the application to be upgradable in the future.

The web client is built as a modular application from the ground up, not as an after thought, and is designed to achieve all theses goals. For example in the web client you can completely turn off CRMat the user level so it does not appear at all. Once again object oriented design enables this capability.

Web services support for easier system to system integration

It's a no brainer these days that any ERP application worth its salt has a web services interface to integrate with other external systems. We have implemented a modern REST interface for just that purpose.

Native support for column and row level security

In the world of ERP security can be a huge issue. It's not unusual to want to disallow users from seeing not just application level functionality but very specific data such as cost data, or rows that don't “belong” to them. The web client was designed with this in mind so whereas in the Desktop client adding and enforcing these kinds of rules can be extremely difficult and painful, doing the same in the web client is trivial.

We haven't done much to implement row level security in the web client outside of what the Desktop client already does (namely “Personal” privileges), but the new eCommerce portal takes extensive advantage of this new capability by doing things like only allowing customers to access “their” Contacts, Orders, and Invoices. This is possible because the privilege rules are enforced at the user level all the way down to the aforementioned REST interface.

Mobile ready interface

Yes, though the purpose of this blog was to downplay this element, making our application mobile-ready was an important goal. Of course tablets and smart phones are ubiquitous now and people expect to be able to access their business system from these devices. Furthermore, they expect to be able to just pick up an iPad or ruggedized tablet and use it to perform inventory functions! This is a big shift from not too long ago when you had to expend huge amounts of money to purchase special software and hardware to implement a wireless inventory management system.

Note, however, one thing that makes xTuple different in this regard leads back to my early claim that we expect as many or more people to use the web client on laptops and desktop computers as we do mobile devices. Most companies write an entirely new native client for each mobile platform. This can lead to disarmingly different user interfaces moving from device to device. Because xTuple's interface is designed to work in all environments, there is no need to retrain people on how to use each device. Also, if you make a customization or add a new extension, that new functionality is available to all platforms and devices, which can be huge.

Conclusion

So there are a lot of great things to talk about on the new web architecture that go far beyond just mobile capability. The amazing thing is, this is just the tip of the iceberg! There's so much more to talk about, but you can only hold attention in a blog for so long. The best way to find out about other improvements is to read about and play with the software.

Read about how its put together on the xTuple's GitHub wiki

Play with it here