:: Markus Egger, in the latest Publisher's viewpoint, talks about how he sees a rebirth of the thick client, powerful desktop applications as opposed to lame feature-skimmed web clients.
I'm not sure I entirely agree, although when you read the entire column, you'll see that he is not advocating all and out thick clients. Yes, there will always be cases where the functionality on the desktop has to be there but I think design needs to be done to make an application treat its functionality as a service - available when needed and where possible.
To his credit, Markus notes that the Smart Client is really the technology that closes the gap and this is really where the power is needed. In response to his note: "Would you rather use Microsoft Outlook or Outlook Web Access? " My response is simply "it depends on where I am".
I want my information everywhere and I want tools that give it to me. Yes, if I'm doing heavy data entry, I don't want to be required to enter stuff on a web site but hey- WHY am I still doing data entry?
Technology was supposed to evolve to the point where I no longer have to do redundant input. No, we're not there yet but I would rather see developers concentrate on making the functionality accessible WHEREVER it is needed, rather than focus on building a "desktop" client.
Markus' point about the Tablet PC and ink-based interfaces is well placed. You don't want to be doing ink entry on a web-based interface but I also don't want to have to load an huge application to view my statistics. A CEO of a company shouldn't have to install software to see his company information and it's not similar to (as Markus puts it) - "public applications" or "occasionally used applications." Instead it's the "forest v. trees" scenario. He needs to see it on his home computer, his PDA, his pager - wherever he needs the information required to assign responsibility.
His non-scientific observations about web-based vs. Windows-based data entry (web IS going to be slower) are right on target (see page 2). But it also has to do with HOW the data is being put in. Hopefully, a company doesn't submit paperwork to a clerk who then orders books from Amazon. The purpose of the web-based interface is so that ANYONE (from the CEO to the clerk) can order books, as they need them.
I used to write trucking software and often heard demands for I want to dispatch over the web. Huh? Dispatching is the "art" of taking 1000 shipments and matching them with the 100 trucks that are best able to deliver the shipment. It is inherently, a visual and entry intensive operation and isn't well suited to web-based interfaces. Having someone book 100 orders that came in over fax is also not suited to a web-based interface but letting a customer submit their order or check the rates between one location and another, as they need it, IS.
Developers considering the service oriented architecture and smart clients should be very wary of making design decisions based on web vs. desktop clients. Web or WinForms is a USER interface choice - it shouldn't be the business or application architecture (if this is beginning to sound n-tier, that's because it is - nothing has really moved away from that concept).
The Service Oriented Architecture is aptly named. When you go to a restaurant, your server, the table, the background music is your UI. The actual work, interfacing with the food, is performed by the server, hopefully on demand. In the back, almost every restaurant works the same (and it isn't always pretty!), churning out the requests, presented on your behalf, by the server.
Take what you want your application to do and make sure it can be accessed on demand, as a service - then build the appropriate user interface, be it thick, thin, web, smart or dumb, for what is needed.
Now that's being Smart.
I'm not sure I entirely agree, although when you read the entire column, you'll see that he is not advocating all and out thick clients. Yes, there will always be cases where the functionality on the desktop has to be there but I think design needs to be done to make an application treat its functionality as a service - available when needed and where possible.
To his credit, Markus notes that the Smart Client is really the technology that closes the gap and this is really where the power is needed. In response to his note: "Would you rather use Microsoft Outlook or Outlook Web Access? " My response is simply "it depends on where I am".
I want my information everywhere and I want tools that give it to me. Yes, if I'm doing heavy data entry, I don't want to be required to enter stuff on a web site but hey- WHY am I still doing data entry?
Technology was supposed to evolve to the point where I no longer have to do redundant input. No, we're not there yet but I would rather see developers concentrate on making the functionality accessible WHEREVER it is needed, rather than focus on building a "desktop" client.
Markus' point about the Tablet PC and ink-based interfaces is well placed. You don't want to be doing ink entry on a web-based interface but I also don't want to have to load an huge application to view my statistics. A CEO of a company shouldn't have to install software to see his company information and it's not similar to (as Markus puts it) - "public applications" or "occasionally used applications." Instead it's the "forest v. trees" scenario. He needs to see it on his home computer, his PDA, his pager - wherever he needs the information required to assign responsibility.
His non-scientific observations about web-based vs. Windows-based data entry (web IS going to be slower) are right on target (see page 2). But it also has to do with HOW the data is being put in. Hopefully, a company doesn't submit paperwork to a clerk who then orders books from Amazon. The purpose of the web-based interface is so that ANYONE (from the CEO to the clerk) can order books, as they need them.
I used to write trucking software and often heard demands for I want to dispatch over the web. Huh? Dispatching is the "art" of taking 1000 shipments and matching them with the 100 trucks that are best able to deliver the shipment. It is inherently, a visual and entry intensive operation and isn't well suited to web-based interfaces. Having someone book 100 orders that came in over fax is also not suited to a web-based interface but letting a customer submit their order or check the rates between one location and another, as they need it, IS.
Developers considering the service oriented architecture and smart clients should be very wary of making design decisions based on web vs. desktop clients. Web or WinForms is a USER interface choice - it shouldn't be the business or application architecture (if this is beginning to sound n-tier, that's because it is - nothing has really moved away from that concept).
The Service Oriented Architecture is aptly named. When you go to a restaurant, your server, the table, the background music is your UI. The actual work, interfacing with the food, is performed by the server, hopefully on demand. In the back, almost every restaurant works the same (and it isn't always pretty!), churning out the requests, presented on your behalf, by the server.
Take what you want your application to do and make sure it can be accessed on demand, as a service - then build the appropriate user interface, be it thick, thin, web, smart or dumb, for what is needed.
Now that's being Smart.
Comments