Why Smart Clients?

... or “Why is my client so fat?”

InfoPath is really cool. To some degree, it actually delivers on the ancient promise of “productivity without programmers.” Fundamentally, it's a form design and publication tool - end users can design forms and publish them to a server where the people who need to fill out the form can access it, fill in the data, and submit the data to a predefined data store.

When combined with SharePoint, there is generally no reason a developer needs to be involved at all - users can lay out forms, create lookups, create *cascading* lookups, add validation, and so on. If the data is simply to be aggregated in a SharePoint forms library, the whole thing is automagical and can be queried directly at the end.

I think it's a wonderful thing for developers because personally I find building generic forms for standard business data collection somewhat, uh, tedious. I'd much rather be solving larger business problems and inventing the next bread slicer.

“But Philo,” you ask, “what does this have to do with fat, er, smart clients?”

Simple - the #1 question regarding InfoPath is “does everyone need InfoPath on the desktop to use an InfoPath form?”

The answer is “it depends.”

Since InfoPath is all XML based (the form definitions are saved in a cab file, but fundamentally they're an XML Schema; the form data is an XML document with a pointer to the XSD), then no - you could easily write an ASP.Net page or a Windows forms client that uses the form XSD to generate the form data in a properly-formatted XML document. But that's not really what the questioner is asking - they want to know “can people without InfoPath on their desktop use the InfoPath forms with no additional coding?”

Think about it - boil that question down and it's “can we get all the InfoPath functionality without InfoPath?” To which the polite answer is “no.”

Why not?

Anyone who's done web development has faced this question: “Can we have spell checking in this data entry form?” Often this happens on a contract where one delivery requirement is for complete client-side validation. Well, in essence this means that every time someone downloads the form, they need to download a dictionary as well. Rich text formatting, validation, spell-checking - these are all requirements we've faced, and we've either bought tools or coded them ourselves.

This means:

• Additional development cost
• Additional testing cost
• For web-based clients, additional download sizes (often massive ones)

InfoPath offers a rich platform for end users to create forms on that provides the full power of the Word libraries (spell checking, grammar checking, rich formatting), a solid client-side validation model, .Net-based code behind (in SP1, download the preview), and offline capability. That's right - a web-aware solution that works in an offline mode, no additional code on your part necessary.

[One caveat in here is where the data goes. As I mentioned above, if the data is going into SharePoint, the end user can build the whole thing. If it needs to go into a business system, the IT Department may have to get involved to provide the data consumer. InfoPath consumes web services very nicely, in keeping with a service-oriented architecture.]

Web-based solutions definitely have a place, and the open architecture of InfoPath forms even allows web-enabling data entry and/or display of the form itself. But when you're talking about robust data entry requirements, web-based solutions generally run out of steam quickly. The client wants a form with spell-checking, client-side validation, offline capability, etc, etc, etc. You can build it, but it's going to be pricy, and it only solves one problem.

InfoPath gives developers the ability to let clients create their own forms with little or no developer intervention, and allows developers to move on to solving bigger and better problems. So you have to ask yourself how you'd rather spend your day: “Hey John, can you move these three fields five pixels to the right?” or “We need someone to build a proof of concept for the new smart phone client the Operations Department needs” ?

Learn more about how developers can add value to InfoPath solutions with the InfoPath Developer Resources Kit

Philo

Comments

• Anonymous
  March 17, 2004
  I would appreciate any information regarding the merits of SmartClient development using VB.NET/VC#.NET vs. InfoPath. Which scenarios are better suited to each tool?