One of the core principles of software usability is that an application must behave consistently. Otherwise the application can lead users into making errors. Something as simple as arranging buttons in a different order on different windows can cause confusion and frustration. So, if we xTuple developers know about the dangers of inconsistencies, why do they exist and why don't we fix them all?

Usually they're there for a good reason. Those reasons fall into 4 major categories:  Feature Requests, Experiments, Deadlines, History

I'll address each of these, followed by some thoughts on configurability and a request for your help.

Feature Requests

One example of an xTuple ERP inconsistency is the difference in behavior between the Save buttons on line items windows and the rest of the application. When you click the Save button on most windows in xTuple ERP, the data are saved and the window closes. However, on the Sales Order Item and Purchase Order Item windows, the line item gets saved and the window is cleared to enter another line item. Why are these windows different from most of the others?

A long-time xTuple user with a high volume of orders specifically requested that these windows in particular remain open after clicking the Save button. This allows for faster data entry. The savings in data entry time makes the loss of consistency worthwhile.

A few years later, the same user sponsored the Purchase Order quick entry feature, again to speed up data entry. Why not add this everywhere? Because writing it took a lot of time and none of the result can be reused in other parts of the application. Transfer orders (in the Standard and Manufacturing editions) also have quick entry but inherited it through code duplication and not by true reuse.

Why not just buckle down and do the work anyway? Because this could double the size of the application and would definitely make it extremely susceptible to bugs. We learned from the initial Purchase Order work and the subsequent Transfer Order changes that the first internal design could be made functional but was not a viable long-term strategy.

Experiments

The External Shipping List window (Inventory -> Utilities -> Maintain External Shipping Records...) window doesn't sort, doesn't display numbers or dates using your locale definition, left-justifies everything, and uses a different font size to display its data on Macs. Why is it so different? Because we're testing the feasibility of a new internal design that could solve a number of problems if it works:

• Quick entry everywhere
• Smarter quick entry than we have on the Purchase Order and Transfer Order windows
• Fewer orphaned records (line items without parent orders)
• More right-click menu options available

If (and that's a big "if":-) this particular approach works, the application could be made much smaller, adding new features would take less time, and the same benefits would be extended to script developers.

"Quick entry?" you ask? "External Shipping List doesn't have a Quick Entry option!" It doesn't now but it did when we wrote it. Adding that back is trivial - one click on a checkbox. The problem is that the window wouldn't have the nice display properties and data validation everyone expects. This window and the tools behind it are works in progress. If we can make the infrastructure work, we'll be able to put quick entry editors everywhere in the application and make the overall application much smaller and simpler; we don't yet know all of the trade-offs but the Purchase and Transfer Orders showed us that the wrong approaches get really messy really fast.

Even when we do get this to work, you might not notice for a while. With an application the size of xTuple ERP, it takes time to propagate a change. For example, a few windows appeared in the 3.0.0 release with localized date and numeric formats and the rest showed up in 3.1. Once the infrastructure was in place and tested in a few windows (3.0.0), it took weeks of dedicated time from multiple developers to make the requisite changes everywhere else.

Deadlines

In general it's good practice to get something working and then refine it. Sometimes deadlines fall between those two stages. That's what happened with one piece of the 3.3.0 EDI feature in the xtbatch package. This feature lets you email or ftp certain types of document. When you request printing a particular Invoice (or Sales Order or Quote or ...) and there is an appropriate EDI Profile, the package presents you with a window to review the EDI before it gets sent. Now for the inconsistent part:

When you select the generic Send Electronic Invoice ... menu option, the EDI window appears and you get a Search or List window to choose your invoice. The same is true for sending Sales Orders, Quotes, Purchase Orders, etc. In similar situations, most other windows open up empty and position you on a field where you can either type a document number, click the ellipsis button, type Ctrl-L for a List window, or type Ctrl-S for a Search window.

What does this have to do with deadlines? The 'get it working phase' had this novel interface but wasn't finished until shortly before the 3.3.0 Release Candidate went to QA. Fixing it won't be hard but is akin to shuffling a deck of cards - the existing pieces need to be rearranged but not substantially changed. The risk of breaking EDI entirely was too great given how little time was left for testing before the release. This will be fixed soon but not in 3.3.0.

History

"If it ain't broke, don't fix it!" Sometimes different developers have different opinions about how something should be done. Neither is necessarily right or wrong; the crux of the matter is that the results sometimes behave differently. We address many of these when we find them but sometimes it's hard to justify the effort because that part of the application works and users are familiar with it.

Why not make these things configurable?

Ahh... the silver bullet... the magic answer... Make it configurable!

Theoretically, every inconsistency could be eliminated and those who like things one way or the other could flip a switch to express their preference. Practically, the story is very different. Every switch needs

1. Code to flip it.
2. Code to enforce it.
3. An interface to set it - it needs to show up on a screen somewhere.
4. Documentation of what it does and where.

Every line of code is an opportunity to introduce another bug, so the less code the better. Every button on a screen is another potential source of confusion. Every switch is something that needs to be tested, both in isolation and in conjunction with other settings. The fewer configuration options, within limits, the better off we all will be.

At xTuple we try to make it as easy as possible to maintain ERP. One advantage we have over our competitors is that it's easier to get up and running quickly. We've all heard stories of extended and failed ERP implementations. Many of the delays and failures occur because there are too many decisions to make and too many switches to set before you can even start using the system, very few of which are critical to your business in the long run.

How you can help

When you see something in the application that doesn't look or behave the same as everything else, let us know what you think. If you like it, let us know. If you don't like it, let us know. That's what the Current Functionality forum is for.

Sometimes it'll be a bug and sometimes it'll be a feature that we're actively working on. Sometimes what appears at first to be a bug will turn out to be a useful feature. We won't know that unless you tell us. Different isn't necessarily bad. For example, now that I've used it a few times, I sort of like the EDI popup document selection - the application tells me what it needs instead of sitting there making me guess. If you agree and tell us, we'll know to leave it in and possibly change other parts of the application to do the same thing.

Even better, you could submit your contributions to improve consistency. That's one of the advantages of using Open Source Software - if you see something that can be improved, you can help improve it. Just enter an issue, attach a diff of your changes, and mark the issue as a patch. Someone will evaluate your contribution for inclusion in the core product.