Thanks for your comments, I’ve found it a good option as well.
The thing I like is that the server can change its mind and process them one at a time.

I have designed a system that way before, and it works very well. To indicate a transaction is required across multiple messages you can easily include the details in a wrapper (or header). (Or to get something working quickly even just initially assume multiple messages === transaction).

From memory the design was based on the IBM IFW (Information Framework, a framework for financial services), which uses a similar architecture (multiple messages can be sent in one transaction).

Sly

Workflow-centric UI sounds good.

However, let me be very clear that technical jargon is virtually meaningless without the presence of examples (like the Amazon ones). I realize this is simply a blog, but the major failing of most blog entries on most blogs is a very dangerous myth: the myth that all programmers share the same psychology, when they do not.

Not only do programmers have different psychologies, but they also don’t share the same vocabulary.

Workflow-centric UIs are less common, in part because (a) you can’t simply use a code generation tool to build the UI for you (b) workflow is inherently hard to describe using human language, and as such there is no format for a compiler writer to use to help automate workflow-centric UI creation (c) workflows can often change, and so in workplaces where employee turnover is also high, human resources training officers have to work double duty to make sure people know what the hell their job is

With workflow UIs, you want to be sure that you only invest in them when you have a very stable description of the problem domain. If you properly design your application based on the real world, then any changes that occur in the real world should be not too dramatic, because people rarely dramatically change their workflow. Human beings, ya know, we’re risk adverse and don’t like change, and when we do change we tend to change in ways creating only subtle differences in the problem domain’s structure.

Re: “the UI *knows* what you need to do.”

Exactly.

If you can find a better term to describe this, giving it a good contrast from what I described as “grid-based UIs”, I’d be most happy to hear it.

I also think I can now better articulate what I am put-off by.

Sometimes users do need a “green screen terminal” do to their jobs well.

The scenarios you are talking about, with tasks like “Change XXX”, only make definitive sense when there is a service waiting on something. The service has a human dependency on XXX, and therefore the UI is Change XXX.

A good example is Amazon.com. Usually, they annoy me for two reasons.

1) A book I preordered has been delayed, and they want to confirm I am still interested.
2) A credit card I have on file with them is no longer valid, but my order has already taken place (but is now on lay-away until I change my CC#).

In both these scenarios, I get an email w/ a hyperlink to a secure URL (requiring login) that plants me on a page where I can take action to move the business process along. I don’t have to go looking for my order. They directly put the action item in front of me, and the screen tells me what my primary task is (”fix billing info” or “confirm you will wait until hell freezes over to get this book”).

I don’t like the phrase task-based UI here. Task-based UI means the user’s workspace is organized to improve completion of tasks, but doesn’t communicate the real usability concept: the UI *knows* what you need to do.

Also, what if the application doesn’t capture the business context. Instead, the business context is tied to a virtual event only known to complex event processing. Such is the case in a federated system controlled by messaging. You can see the messages flying back and forth, but without the ability to recognize events in a human understandable way, it’s just mud and you can’t actually see anything insightful.

The business context would be that there is a service waiting for a customer’s correct address.

So again, still I see a sort of strawman. Sorry.

Sorry for not defining it – I did make an assumption there about people understanding its intent.

A grid-based UI is one where the user performs most/all activities in the app through a grid – specifically editing data. In this kind of user interaction model, the intent captured is a fairly technical “I want to edit this entity”, without the business context of “why” – like Darrel’s comment above describes.

Relating to “she will be punching in numbers and names”, I’m not arguing that that occurs, but that having additional business context is invaluable.

Some systems really are pure data entry in that the system doesn’t really have any validating to do, as the data coming in is being typed from a file of sorts which is already the authoritative source of information – nothing really that a computer could refute.

Does that make more sense?

What is a grid-based UI?

Task-based UI – you give examples.

Grid-based UI – you throw in there like it is a common term.

Quite simply, Google Top 10 Search Results says the term is own you made up and didn’t define. I’d appreciate an explanation of what sort of symptoms Grid-based UIs have that you don’t like.

Look at it this way: You say, “let’s agree that if the UI was task based, it would be easy for the client side to activate the correct web service/method – seeing as there is a high correlation between the tasks and the service methods.”

This sets up a strawman for dismissing “Grid-based UI” (whatever that is). You actually never explain why Grid-based UI has a LOW correlation, or why correlation makes programmer’s life more difficult.

Also,

@Data entry is not interactive work, so grids might be more suitable there, although improvements in bulk-loading technology and OCR have decreased the amount of “plain” data entry that I’m encountering.

I don’t understand this, either. There is always a Suzy Creamcheese on the phone with a customer who needs to enter information somewhere about the call. Even if you have tasks that map to her cold and hot call scripts, at some point along the task she will be punching in numbers and names. If Suzy is a development personnel in a fundraising department working during a telethon, she needs a fast way to enter data.

At the very simplest level, when right-clicking a customer, one of the options available is “Customer Moved”.

If there are relatively few actions that could be done on customer, some kind of outlook 2003 bar could be used.