Webware vs Software

23 April 2007

I recently found a couple of blogs that are pro and anti webware and it made me think about just how much webware has changed recently. Eighteen months ago the reasons I used for deciding whether to build webware (ie SaaS) or software (ie standalone app or a smart client) were basically: if the audience is the general public, then build webware. Otherwise, build software.

This was because software UI could be far more powerful than web UI, so you could build a lot more functionality with a lot higher usability for the same price. Of course this was also based on my preference for software, but I had the golden rules of UI design to back me up.

Now, with decent (or at least better) web browsers, AJAX, javascript and all those 2.0′s, webware can compete with the basic stuff that software has always been able to do. Its like Windows finally doing what Apple has been doing forever. Feedback and error handling can be handled live, controls can be interacted with and updated on-the-fly and users don’t have to wait for a server roundtrip after every click. On top of this, webware gives complete freedom to the user interaction gurus, so they can design an app with consistency, closure, keeping users in control and reducing memory load.

So, with webware and software pretty-much equal when it comes to UI and the cost of developing and deploying webware and software being very similar, its often not a technical decision anymore between building webware or software – its a business decision. Is the business model to license or subscribe? How will the software be sold and maintained? etc.

However, while webware technology has come a long way, there’s still a lot of work to do to achieve good UI and I’ve been very impressed at how the team at Xero have managed to build webware with better usability than any accounting software out there.

The golden rules …

1. Consistency
Software UI is well defined. It all looks the same. Menus, toolbars, shortcut bars, modal windows etc, its all boring and consistent and you don’t have to put any thought or time into how to make the windows and controls look – just copy Outlook. Of course, you can still screw up the consistency within your app, but software has a huge head start over webware when it comes to consistency.

2. Shortcuts
Frequent users need shortcuts, including right click menus, single vs double click, keyboard shortcuts and menu shortcuts. These are all taken for granted in software and users get pissed off when they’re missing, but they’re usually missing from webware and no-body notices because no-body expects them there because it takes time to add them, so most developers don’t.

3. Informative feedback
Good feedback should be fast and contextual, so having to make a round trip to the server, then reload a page just to validate a field, or confirm an action is poor. Handling feedback in software is a non-issue – you still need to provide good informative feedback, but its much easier to do it in software than in webware.

4. Closure
The user needs to know when they’ve completed an action. When using software, have you ever seen the message “Don’t click Save twice otherwise your order will be processed twice”? This is typical of webware because you click the button and wait and then you’re not sure whether you’ve just saved or lost your last 10 mins of form-filling, so you click it again. What happens when you go back, then forward, or refresh. Software doesn’t have these issues, so you don’t have to spend time building workarounds.

5. Error handling
Like providing good feedback, error handling should be instant, contextual and preventative where possible. Who wants to post a form, then receive a list of error messages that need to be matched back to each control? Error handling in software is easy, in webware its harder, so its usually not done well.

6. Undo
This is an area that most webware lacks in, but something that users expect.

7. Keep users in control
Happens by default with software and requires more thought, design and workarounds in webware.

8. Reduce short-term memory load
Not too long ago, updating info live on a webpage was not cross-browser, so webware was pretty poor at this, but to update information on a form in software is simple and you’ve got lots and lots of memory for storing the session info for just one user.

Leave a Comment » | SaaS, Software, Technology | Permalink
Posted by Andrew

En Avant

17 April 2007

Jim Donovan‘s new blog looks interesting. I look forward to his thoughts on business & technology.

Leave a Comment » | Business, Technology | Permalink
Posted by Andrew

High goals and high risk or low goals and low risk?

12 April 2007

I like setting high goals that are challenging and that I don’t know for sure if I can hit. It motivates me to work not just harder, but smarter and gives a lot more satisfaction when you do hit these goals.

I also know that over promising and under delivering is way too common with software development. To really provide top software & service, we need to over deliver on our promises so its tempting to set low goals that we know for sure we can hit, just to make sure that we can meet our promises to customers.

Setting challenging goals carries higher risk, setting easy goals carries lower risk. High risk = high reward, but also a higher chance of missing the goal and letting people down. So how risk adverse should we be when it comes to building software?

There are three types of goals:

  1. Business goals – what the business and customers are asking for and/or demanding
  2. Development goals – what the development team are striving to deliver
  3. Estimates - how long should it take to deliver

Often business goals are widely different from estimates and this leads to high risk of those business goals not being hit. Our development goals sit in the middle and should always be challenging the development team to deliver a better product and rewarding them accordingly.

We also can’t ignore business goals – if there’s a trade-show on a certain date, then the software has to be ready in time even if risk is high.

So, the goal is to set high development goals, but keep the risk between business goals and estimates low by:

1. Acknowledge business goals and organise milestone deadlines around these dates. Business goals may also drive the roadmap, so they may decide the priority of features – but not the complexity.

2. Identify what functionality and complexity can be delivered in time with low risk and promise this. Typically, this will be a cut down version of the feature, but allows you to promise the feature without going into detail.

3. Set goals that are a challenge, but achievable and will deliver much more than the low-risk functionality. Reward the team for hitting these goals. Make sure that the low-risk functionality is finished early and can be released independently of the higher goals, but focus the team on the higher goals.

Either way – don’t fall into the trap of pushing against business goals and setting easy to achieve development goals just so you can hit them every time and look good. It might feel like a win, but the dev team and the business will be the losers.

Leave a Comment » | Business, Software | Permalink
Posted by Andrew

Its about people, vision and fun

10 April 2007

Most things that are worthwhile are going to be hard at some point – if they weren’t, they wouldn’t be so rewarding – so hard is good, but there’s a point when hard becomes bad and usually you’re the last one who figures out when that point has long since past. How do you know that what you’re doing is worth pushing through the pain for? There are three things that I use to take an objective look at a situation and decide whether to persist, or call it a learning experience:

R: Business is about people.
I’ve had a number of people tell me, “its not personal, its business”, normally while they’re in the process of screwing you and want to feel better about it. Business is all about people. The people you work for. The people who work for you. The people you sell to. The people you buy from. These people are your stakeholders and as soon as its no longer about them, then its time to move on.

P: Know what your niche is and why it matters.
This is about two things: (1) what’s your elevator pitch? (2) So what?

Your elevator pitch is not about your ability to explain your product to someone within 30 seconds. Its about that person catching your vision within 30 seconds and going away and explaining your vision to other people, who explain it to other people etc.

This comes back to your vision. Why are you doing what you do? Is it your vision, or someone elses? Do you believe in the vision? Is it worth the pain? Does anyone care about it other than you?

J: Have fun
One necessary ingredient of hi-growth businesses is stress – you don’t get growth without stretching your existing capabilities – but there is good stress and bad stress – just like there’s good pain and bad pain. Good pain is when you’re running hard. Bad pain is when you sprain your ankle. To keep going through good pain is beneficial and gives you good rewards. To keep running through bad pain is just stupid and does more damage.

The same applies for problems. You will always have issues and problems – make sure the majority are good problems, not bad problems. For example – making source code maintainability a priority from day one means that down the track, you can focus your efforts on solving business problems – not on bug hunting and regression testing. When the majority of your problems are bad problems, then it stops being fun and its time to fix the big picture.

2 Comments | Business, Vision | Permalink
Posted by Andrew

Follow

Get every new post delivered to your Inbox.