Fog Creek Software
Discussion Board

More features = more Training = less ease of use?

Should one resist the temptation to add more features to an application at the risk of increasing complexity and ruining ease of use? Can we always keep ease of use, but continue to add more features? I am worried that adding too many features might make the software require too much time to master?

Anyone have some profound “Joel” like thoughts on this issue?

Are wizards the answer?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. kallal
Wednesday, September 10, 2003

IF the customer requires the feature you need it in your software, why don't you have realses, where you have 10 features, give the customers some time to get familiar with it, then do the next release with more features, Repeat....


Prakash S
Wednesday, September 10, 2003

This is tricky for 'off the shelf' software, where you're trying to satisfy the needs of often very diverse clients who use different features.

Training is also not always the answer, because it either has to be very customized to a particular client's needs (and thus not training them on features they think they don't need right now and will thus never discover or use) or very general, which means they probably won't be able to use the features that they need :(

I like the old usability principle that says 'make the safe stuff easy to do and the dangerous stuff hard to do'. I also like a layered approach to features - if you enable box 'X', you get advanced toolbars / menu options that work with feature class X. Then you can write training material for feature class X, which can be ignores until such time as user needs that type of feature.

Wednesday, September 10, 2003

>> if you enable box 'X', you get advanced toolbars / menu options that work with feature class X.

Yes, that is kind of what I am aiming for....

In some cases, you can have tons complexity and keep loading up the application for years, and it is still easy to use. Ms-Word is a good example.

However, I dealing with problem where I need to have simple pricing of tours and complex pricing.

Often, a pricing model is something simple like a 1 day whitewater rafting trip. On the other hand, some situations require a complex hotel pricing system with seasonal rates that vary etc. (a lot of similar tour systems out there usually don’t do a lot of the pricing, you simply type in the cost of tour and sell it). My tour system is far more complex then that, and does a LOT more work. So, my complex hotel pricing engine does add to the amount of time to configure, and setup and use the application. However, once done, then each new tour created is FAR LESS work.

I am looking to actually REDUCE the pricing complexity in my case! I guess I might wind up splitting out the “type” of pricing required. I will have to figure out a way to NOT expose the complex hotel pricing system to simple tours. I already can handle a fair number of pricing systems (and even stuff like clothing can be priced from inventory to be included in a tour, or often things are included, but at no cost from inventory).

I simply don’t want to continue to add more features and options to the ONE pricing system/screen. I am thus working to build a pricing engine that allows a very simple to a very complex pricing scheme. The problem is then you are faced with giving the user two UI. (one for simple pricing, and one for complex pricing..or that additional screen called advanced options!). This results in spending more development dollars on building some UI.

I think all developers are faced with how you present complexity in a nice graduated series of steps for more and more advanced users. Simple pricing should be really easy, but then as more is wanted, then stuff like season rates, and cloting from inventory etc can be included.

As mentioned, I want a graduated series of steps.

I will just sleep on this!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. kallal
Wednesday, September 10, 2003

Here's a pricing model I was involved with that tried to cope with getting revenue from modules and features and keeping the user interface straightforward.

You buy the System module which gives you the security engine, the users, accounts, profiles and junk.  And that's licenced by the number of users.

Then the customer buys the modules they require, in the beginning the module price was fixed; later on it was made variable depending on the user licences.  Modules (this is an accounting system), are ledgers, and major functionality, Sales, Purchase, General Ledger, Sales Order Processing and so on.

Then the user (or more likely the dealer) can add features on top of those modules, say a Purchase Invoice Register on the Purchase Ledger or Serial number tracking in Stock.

The pricing of features was fixed and came out at around 10% of the module price.

However, the entire product with all modules and features is delivered, there is only one deliverable and the modules and features are turned on by some kind of activation key.

If a module or feature wasn't enabled then it was simply invisible, greyed out functionality being more irritating than its advertising value was worth.

Simon Lucy
Wednesday, September 10, 2003

Oh and to answer the question about how you can add functionality to something like a pricing engine whilst keeping the interface basically the same...

That same system allows developers, third party or not, to insert code into the flow of the system, most frequently in Order processing or Invoicing.

This meant the publisher could deliver a complex functional standard product and it could be extended and tailored for an individual solution.

One example of this was a pricing engine which handled things like multibuy discounting (buy N of some set of products and the price of all of them was reduced) and a dynamic price list (your invoice total comes to X pounds so you step up into a different price list which gives you a whole different set of prices per line).

There's no actual UI required for this, it involves reevaluating the whole document as it changes, but its still deterministic so given the basic engine it was reasonable to modify it.

When adding entirely new functionality, for instance adding Service Record entry when in the middle of a Sales Order it makes more sense to pull up a new form but keep it centred within the current form so that the user isn't distracted away from their basic focus.

Currently I try and avoid using things like multi-tab forms preferring instead to switch the new form content in context with where the user currently is on the basic form.  So if another form is needed for input the activation of that form (whether its a button or some kind of valid event from a field), is as close to the context that the user is in as possible, and after that form is finished with the user is returned to the next field in context with their original flow.

Sometimes its not a new form that's created but the current form is extended, this can be useful when moving from a header to transaction line entry kind of process.

Simon Lucy
Wednesday, September 10, 2003


Wednesday, September 10, 2003


Unfortunately, ease of use comes at a prices. More work happening in the back. Its the whole duck syndrome... looks good up top, but is paddling like mad beneath the water line.

I think ease of use comes with only seeking the barest minimum of information from the users.

Where you absolutely need the information, two things. One, where possible, use approximations, (high, low etc vs specific #). Where you absolutely need the figure, make it easy for users to enter.

Makers of install tools have somehow managed to crack this tool. Most will let you click next next next through the installation just based on the defaults.

Compare this to installing Oracle 8i on Linux. I found God through the process.

Now, the trick will be having the right defaults, and also knowing what to ask, when. Getting this right is the paddling going on below the surface.

Wednesday, September 10, 2003

"Anyone have some profound Joel like thoughts on this issue?"

No, but that won't stop me from commenting on your post.  :-)

"I am worried that adding too many features might make the software require too much time to master?...

... My tour system is far more complex then that...

... I simply don’t want to continue to add more features and options to the ONE pricing system/screen. I am thus working to build a pricing engine that allows a very simple to a very complex pricing scheme."

What kind of tour pricing software application/system are we talking about here?  Are you:

* Creating a custom in-house application that will be used by only one company?

* Trying to create some type of commercial application that you can sell to many customers (i.e. tour companies)?

* Trying to create a framework (i.e. a pricing engine), so that you can reduce the time and effort required to complete this type of work in the future should more of it come your way?

One Programmer's Opinion
Wednesday, September 10, 2003

On a simple level, I think that having a 'collapsable' form is much better than having 2 seperate forms (simple/advanced).

This seems to be the approach that Microsoft take.  For example, the simple search and dial up networking dialogs have a 'More' option that will then drop down the advanced features.

If you can break the advanced details into several 'folds' of this type then the complexity is effectivly hidden.

This can be improved further by remember the 'folds' for each record, so that a complex pricing option will display all the extra stuff by default and the simple will not.

I assume your working in Access.  I don't see that this would be too difficult, especially if you use that neat subform trick you wrote about.

Ged Byrne
Wednesday, September 10, 2003

"Are wizards the answer?"

If you need a wizard, your interface sucks.

Go back to the drawing board, and really think about how users approach your application.  And read the Macintosh Human Interface Guidelines.

Jim Rankin
Wednesday, September 10, 2003

About Wizards.

I think they are useful if you have a complex decision tree. Most wizards are about three steps and there is one straight path through them and a bunch of extra confirmation dialogs.

Wednesday, September 10, 2003

"I think they are useful if you have a complex decision tree."

But why is there a complex decision tree in your application?  Is it inherent to the task the user needs to accomplish or is there another way to structure the app?

Jim Rankin
Wednesday, September 10, 2003

The case that I was thinking of is in a database setup for an engineering application.

We could just forgo having a wizard and have the user hire a consultant to hand enter the information into the correct fields and add the right tables manually. It's not something that anyone except possibly a consultant is going to do very often, but it has to be done a certain way for the application to work.

Many of our users are in countries where we don't have good consultants, our consultants wouldn't want to go to, and/or exchange rates make it impossible to hire them anyway. I suppose we could just turn the feature off, but it wasn't that big of deal to have a wizard. I suppose we could have just documented the steps to take, but then we would have to provide debugging tools to figure out what the user screwed up.

Anyway, the whole topic of adding features means adding complexity is interesting. I think it takes a visionary to say, no, we aren't going to add that feature because it clutters up the UI for only one customer. However, at some point, you probably have to find a new way of representing the tasks.  The poster child for this is the idea of hierarchical directories in a command line environment vs folders inside folders. Not many people took to hierarchical directories until there was a graphical explorer like on the Mac/Windows Explorer/Xtree on DOS, etc.

Wednesday, September 10, 2003

>> Trying to create some type of commercial application that you can sell to many customers (i.e. tour companies)?

It is already the case now that  have a user base.

I am simply in the process of re-evaluating how I setup the pricing system.

I have clients that have actually used the Hotel Pricing system to sell coffee mugs!

So, I do have a lot of flexibility, but I don’t think the above type scenarios should be occurring! The coffee mugs should shave been added to the inventory, and then simply sold.

However, users don’t always use software the way we expect them to!

By using the Hotel pricing system, they are able to get better reports, and the screen comes up with better info as to who bought a mug! (they actually created a room called mugs!). It was one of those internal things where people in the office had to commit to purchasing a special mug (a cool mug with a light on the bottom).

So, in place of using Excel, they used my reservation software (they are a tour company).  The invoicing and making a printout of who bought a mug was much nicer using this approach. I mean, after all, the software does manage stuff like who wants what, and is it available?. That is the whole point of the system, and I guess it applies to tours, or selling some coffee mugs!

It is quite a warm feeling when users are willing to setup a whole tour just to sell coffee mugs. To me, this means I have a rather nice UI and ease of use.

I am just looking for more improvements, and am planning a incorporate even more flexibility in terms of pricing things. Based on feedback from the user base, there are some pricing scenarios that I still need to add.

I just don’t want to ruin what I have now! I also don’t think a tour should have been used to sell coffee mugs...but the client begs to differ!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. kallal
Friday, September 12, 2003

*  Recent Topics

*  Fog Creek Home