|
Limiting the user experience
There've been a couple of threads recently on "why web apps?", with the consensus seeming to be that the biggest argument against web apps is the poor quality of the interface. Maximus gave, as an example, how quick and easy it is to let a user edit a table by connecting components.
This horrified me. Most of our design at work goes towards shaping the user's experience so that they have a limited set of the correct/allowable choices at any given moment, and no more. This has paid off a lot in fewer errors in the data. Our Customer Information Sheet system covers six different tables that are considered part of the core of the whole system. Until we unified them in a web app with severely restricted interface, there were a constant stream of errors and missing data that rippled throughout the company. "Oops, someone forgot to enter the customer's SKU for that item, now we have to rework two truckloads of product before we can ship it this afternoon." As a bonus, it was easy to add a review/authorization layer where all changes are approved or disapproved by senior management (making them directly responsible for errors that slip through, disallowing the "clerical error" excuse). Little features like email notification of changes and such were also quick and fast. Now, there's also no difference between using it in the office or over VPN.
In short, the dumbed-down, more structured interface of the web app has been a great improvement, operationally. Given the comments I've seen so far, it seems like developers are viewing this as a step backward. Why?
[The app I mentioned above was implemented in ASP, with SQL Server 2000 on the backend].
Justin Johnson
Wednesday, November 19, 2003
I disagree. A restricted interface almost always is a good thing, but a native application with a more complete interface should be better in all cases. You just have more tools to check the validity of input in such type of applications (the SKU example you gave sounds just as lazy programming error to me.)
Regards,
Leonardo Herrera
Wednesday, November 19, 2003
The SKU example has nothing to do with code, it's a policy thing. Not all items require a customer SKU label, so it's not a required field.
Justin Johnson
Wednesday, November 19, 2003
Are there no rules governing when it is required and when it is not?
A limiting UI is probably a good thing for some kinds of applications. Data entry seems like one of these. Can you imagine, though, if you had to author your applications using a wizard for each system that forced you to enter the class names, then for each class enter the variables followed by the methods, etc?
busted hip
Wednesday, November 19, 2003
One of the best interfaces for protecting the user from themselves is the dumb terminal. A VT100 has no knobs to twiddle (ok, contrast!) and nothing to play with and only accepts what you want it to. We have a terminal mode in our business software and it isn't suprising to us any more how many people opt for it for factory, retail and basic data input tasks (the dumb screens are connected to the network, but the user can't tell!)
Most web interfaces are a variation on dumb screen ones due to the difficuties of implementation and design. It is possible to use Java applets or asp forms or something but then the native RAD tools start to look just as good.
Dominic Fitzpatrick
Wednesday, November 19, 2003
"Are there no rules governing when it is required and when it is not?"
For much of the information, no. A customer is complicated data entity in our system, covering a lot of information, and our customers are not in any sense consistent in their requirements, their structure, or what we want to track in order to serve them well. We're a manufacturer, so we're talking about the organizational differences between Wal-mart, Target, Office Max, Costco, and Bed, Bath & Beyond. The data model of a customer has to be something of a superset of the fields for each customer.
A lot of effort has gone into shortening the distance that data travels--the salesmen themselves are responsible for entering much of the information now. There's also the fact that data isn't ever known all at once--first the customer is set up, later the items they'll purchase are entered (which changes annually or semi-annually), their shipping requirements change, their program changes every year, and then we have large customers who change from drop-point shipping to DCs. Lacking well-behaved data, simplifying and restricting the interface has done a lot to improve consistency and make gaps obvious.
Justin Johnson
Wednesday, November 19, 2003
It all depends on your users.
If you are developing an app that you expect users will visit only rarely, then you could say that your users will remain newbies forever. With that in mind it might then be correct to implement an app that holds their hands all the time.
However, no one wants to be a newbie. Most users will quickly do one of two things: they'll either never use your app again, or they'll become familiar with it and graduate to experience users. Some will move on to "power" users.
At that point, hand holding starts to get in the way and becomes an annoyance. To me, this is where the limitations of web based interfaces begin to show up.
Just my opinion.
anon
Wednesday, November 19, 2003
I am thinking apples and oranges (I have a healthy appetite).
I may have skimmed the articles too quickly, but I get the distinct impression that it is more about bad interaction design than about the tools used to implement it.
I thought I saw a pussicat, sorry, people arguing limited options versus virtually unlimited, and the dangers of data being incomplete.
But neither a native or a web interface forces you to do one or the other. They make certain implementations more difficult than others, though.
So which part exactly did I misunderstand?
Practical Geezer
Wednesday, November 19, 2003
I don't think you misunderstood. I was presenting the case for a web app because of all the anti-web app posts in the other threads, making the point that there's a good fit between a restricted interface and web apps.
Justin Johnson
Wednesday, November 19, 2003
But I am not quite sure I understand.
I understand you might need restrictions on what a user can do using your UI.
So what exactly do you mean by a web interface and how is it more suited?
As the designer and builder of the interface, don't you have the freedom to restrict as much as you need, regardless of the tool you use to build it?
Practical Geezer
Thursday, November 20, 2003
So what exactly do you mean by a web interface and how is it more suited?
As the designer and builder of the interface, don't you have the freedom to restrict as much as you need, regardless of the tool you use to build it?
As someone observed above, when the task is largely about data entry, a web interface, meaning a web page in xhtml, with some javascript for form verification perhaps, is appropriately simple.
You're right, the builder can restrict as much as she wants, regardless of the tool. Since HTML is more restricted to start with, it's faster to build a simple, restrictive interface than in VB (or an Access form). It also has advantages in the architecture, like centralized maintenance and agnosticism about the client platform. I'm not arguing that you can't build things with VB/C#/Winforms that you can with a web app; I'm arguing that a web app is more than sufficient for a large number of business tasks, and is more appropriate. I'm arguing against those who think that web apps are a poor interface because of their poverty of interface tools and tricks.
Really, I'm saying that less is more in the vast majority of business systems.
Anon said above "no one wants to be a newbie". I disagree. In a business, almost everyone learns to use their computers and software only as much as their job requires, and no more. I mean both $12/hr clerks and $100K/year salesmen; the majority of our tech support is reminding our users how to use the basic functions of the systems we built. It's from that experience that I changed my opinion about how simple an interface should be.
Justin Johnson
Thursday, November 20, 2003
But won't you introduce a whole new set of problems to solve because of the web browser part of the interface?
Just to name a few:
- people pressing cancel while loading the page
- people closing a page before committing data
- people moving to a different page, or even site while in the middle of a transaction
All kinds of side effects from using such a tool.
Of course you can probably mitigate most, if not all, of them.
I assume you have considered this all, so is it safe to say that on balance using a web browser is still less work than using VB, for instance?
Practical Geezer
Thursday, November 20, 2003
"I assume you have considered this all, so is it safe to say that on balance using a web browser is still less work than using VB, for instance?"
Overall, yes, in my opinion.
The problems you mention aren't trivial, but they're not killers, either. Web apps need to be designed for stateless reliability--the server has to check that a form submission is complete, for example, and ignore transmissions that aren't.
On the client side, if they navigate away, or freeze their computer, or hit cancel, they lose whatever they entered--so you have to break up tasks into smaller chunks that require incremental saves. Really, the same problem we have now with VB based systems where the program crashes or Windows 98 freezes.
But again, there are better opportunities here if statefulness is limited to the server--logging, server-level hardware, etc.
Justin Johnson
Thursday, November 20, 2003
 Recent Topics
Fog Creek Home
|
