The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Electronic forms for a customer?

So, have a client that needs some customers to fill out some forms (with additional pricing type information.)

Right now, they just email/send out a customer a excel template. When customer sends back the excel sheet, they then MANUALLY enter the data into a database. (gosh, how many times do we see this type of story!!).

So, I want to get rid of this MANUALLY part.

The ideal choice would be of course if they had the new SharePoint and forms server. This is a REAL slick system in which a very nice forms designer (InfoPath) can be used to create forms. These forms can then be *published* to your web site.

The forms are instant web enabled. The whole system is xml based (you can even email the forms in outlook – talk about a great survey system!!). Note that OTHER web browsers are even supported - Firefox, Safari, NetScape. (amazing!!).

The video demo is here:
http://office.microsoft.com/en-ca/formsserver/HA101672631033.aspx

Anyway, InfoPath + forms server is the new “ms-access for the web!

I can see a zillion uses for the above…

However, my client don’t have the budget for the above….which I think is a ideal solution.

So, choices:

** Create some PDF forms, send to clients, have them email them back, and then some software to pull out the data. I don’t have the adobe tools, but I think this is the *best* solution for them since they don’t have a web server, and PDF forms work when the user has the pdf reader (most likey).

** Do the same above idea as the PDF forms, but do this with the excel sheet they send out now (likely the cheapest/easy approach, but I can’t see how the data will be consistent with this approach).

** Build a SIMPLE web interface to accomplish this – the problem here becomes that you need a WHOLE SYSTEM for logons, admin of passwords/id etc. If we JUST had to fill out the form + submit, then a simple web page would be easy. However, the customers need to work on the form over a period of days (multiple sessions). That “logon” process, issuing of id’s etc is thus a problem….

So, if you don’t have InfoPath and the forms server…what do you folks use when a client needs electronic forms filling for their customers? Any other budget minded solutions?

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Friday, November 17, 2006
 
 
Can't you just attach to the excel spreadsheet using the OleDB database driver and extract your information? Then just write it to the database.

I would be really surprised if you couldn't just go directly from Excel to a database using a little .NET code. Microsoft is usually very consistent in providing you operability between its own products. Also, I've never used them but the Office Tools for Visual Studio may lend a hand.

Maybe someone else who has actually done some interop with Excel can give details.
anon
Friday, November 17, 2006
 
 
How expensive would that be?

Sharepoint is the cost of a Windows 2003 server

I don't know what the web enabled infopath is or will be (is it out yet?)  But it can't be that much to add to the price?

Compare that with custom written a webapp to do this?
Lee
Friday, November 17, 2006
 
 
Take a look at http://www.wufoo.com/. They provide a web-based form builder, host the forms, store the data, and manage security. The collected data can be sent to you in Excel format (among others) as well.

Disclaimer: I have not used the service, just taken a quick look at it, but it seems to meet your requirements.
Doug
Friday, November 17, 2006
 
 
>Can't you just attach to the excel spreadsheet using the OleDB database driver and extract your information? Then just write it to the database.

Yes, pretty much the plan right now. In fact I *prefer* the forms built in word, as those forms are FAR MORE unchanging / rigid.

The problem with this excel approach is that data can be messed up fairly easy. (I still debating even if I want to include macro code in the excel sheet).

However, from a KISS point of view (and budget), your approach is *likey* the one that we will use….

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Friday, November 17, 2006
 
 
Lock the Excel document so only certain fields can be changed by the user.  Lock the formulas and any static data, which should give you the same rigidity as a locked Word form.
Get me out of here Send private email
Friday, November 17, 2006
 
 
There are 2 types of pdf forms. The older technology that I am familiar with are called AcroForms (started back in Acrobat 4). The newer ones are made with LiveCycle Forms Designer (which needs 7 or later although some features work in 6). I believe that Adobe is trying to deprecate the AcroForms. LiveCycle can be very expensive, especially if you need DRM of any kind (think "nice car" ballpark).

Toolkit (link to zip file near bottom):
http://www.adobe.com/devnet/acrobat/fdftoolkit.html
>Additionally, with this release, the Acrobat 8 SDK is available free of charge to all users, as well as previous versions of the Acrobat SDK and the FDF Toolkit.

It looks like all the sdks are back to being freely available (for the past 3 years, they used to require annual subscriptions for access, prior, they had been free).

One older link (see comments):
http://msmvps.com/blogs/williamryan/archive/2004/11/24/20575.aspx

The FDF isn't a full PDF, it instead refers to a PDF that has fields (the /F tag needs to have the full path/url to the document if it isn't in the same directory). And a field/value pair will be:

<<
/T (address)
/V (1600 Pensylvania Ave)
>>

You can do http posts from within the form, as the scripting language *inside* PDFs is javascript. This way, the client only needs Adobe Reader (the official name for the free product).

At a previous gig, I wrote a proposal to replace their html forms with AcroForms and even built a prototype for them. That place had been automating fannie mae/freddie mac forms for real estate. At that time, the html forms were usually around 400kb with about 200kb in validation javascript. Swtitching to FDF reduced the payload to about 10-20kb. This was in the days of dialup.

I've not had time to look into InfoPath at this time. I will also not be able to actually work with the workflow foundation at home until the new computer is finished (it cannot work with express versions of visual studio as the WWF designers are add-ins).

If you want another sample (a fill in time card), more ideas, I can zip up a no-longer-used aspx (.NET 2.0) page with pdf sample and email it to you. I guess I better sanitize it a bit.
Peter Send private email
Friday, November 17, 2006
 
 
This is a Delphi/VCL component that may be something like what you're looking for.  Maybe someone sells a similar component for ActiveX, .NET, or whatever tools you're using.

http://www.wpcubed.com/products/wpform/index.htm
Herbert Sitz Send private email
Friday, November 17, 2006
 
 
Peter is spot on.
LiveCycle is expensive.
Probably as expensive as Sharepoint, if you're not acquainted with using it.

Acroforms is good, since the delivery methods can be customized, roughly into 4 ways I think.
You can have them submit the forms electronically, or via snail mail, e-mail, and probably directly into a database (not sure about this, but I remember hearing this option somewhere).
If so, you might be interested in knowing about the Acrobat FDF toolkit - http://www.adobe.com/devnet/acrobat/fdftoolkit.html
Vineet Reynolds Send private email
Friday, November 17, 2006
 
 
Some nice stuff here!!

I did come across Arco forms in my goggling. They seem to have two versions, and one works with standard pdf, and the other requires some type of software to be installed on the clients machine (which I hoping to avoid).

As I originally said:

** Create some PDF forms -- I think this is the *best* solution **

The only issue here is that I don’t have the adobe tools to create forms. If I did, then at least the SDK kits are now free (thanks for that tip).  I like the pdf solution the most, and they also print very well locally. Also, the forms made in pdf tend to look REALLY nice.

However, I also plan to have *some* dynamic generating of the form before it is sent to the client (this ability would depend on the tools I use). I think excel will do the trick here (since they been using that anyway).

It just seems to me if I start spending $$ on the pdf tools, then I might well get budgets for SharePoint and the new forms system.

As always, the budgets for this task are too small to do it the “right” way. So, a few hours of my time..and excel likely is the winner.

As mentioned, a simple web based system would be the best, EXCEPT for that need to return to the form with data over time. (thus, the whole mess of logon, id, forgotten passwords. you know the drill) comes into play. However, once the client *is* done, then NO futher interact takes place with the form of data.

Looks like old excel going to win.  However, I keep thinking that I should setup a SharePoint and forms server for my customers. That way, I can charge them a monthly fee!!


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Friday, November 17, 2006
 
 
Or take the financial loss personally and purchase the Acrobat tools needed.

If you build a workable solution here, you can refactor for other businesses down the road.
*myName
Friday, November 17, 2006
 
 
Umm.. you need to have Acrobat Reader to read the Pdf forms at the client's place. That seems to be a small issue though.

I think you've confused this with the Livecycle Reader extensions which is required for reading the Xml forms (which are the  latest forms, the only difference in being that - you can use  any xml parser to read the form output, in contrast with the Pdf forms which requires the FDF toolkit at the server)
Vineet Reynolds Send private email
Friday, November 17, 2006
 
 
I forgot to mention an open source solution for creating the PDF forms - Scribus
http://www.scribus.net/
Vineet Reynolds Send private email
Friday, November 17, 2006
 
 
To build the PDF forms as AcroForms, you'll need the "for money" version of Acrobat (student versions of the Pro version run about $150 at campus bookstores). To build LiveCycle Forms takes a different authoring tool. To fill in either variety can be done with the free Reader.

If you have a "for money" version of Acrobat...
Look for the editing tool bar (I have version 5 on one of my laptops here, and version 6 at home), there will be an icon with a tooltip of "Form Tool." With that tool, you can place a form field on a PDF and enter properties for that form field (name, format etc).

If you have a need to repeatably create PDFs, it *is* possible to script the generation of them. At my last employer, who made and ran websites for mutual fund companies, NASD required the clients (mutual fund companies) to produce required monthly/quarterly documents in a certain period of time after the close of the quarter/month. We scripted Illustrator (for charts), InDesign and used that along with asp.net and an addin called Xpublisha (which appears to be no longer on the market) to extract data from the DB, process into XML, run thru an XSLT, flow into a document and publish as a PDF. This reduced a manual process that sometimes took up to 14 days (the NASD deadline) and reduced it to under an hour. While this process wasn't 100% automatic (closer to 80%), it reduced errors by more than 90% and time-to-publish by close to 99%.

There are a lot of cool things one can do with PDFs. But, like with Excel and Word, most people never do more than scratch the surface of what *can* be done.
Peter
Friday, November 17, 2006
 
 
If they won't pay for more than a few hours of your time, how can they expect more than what you can actually do in a few hours?  And learning new tools for a one-off job is silly - that's not trivial and it's probably not billable under their "few hours of work" budget.

It sounds odd that they have the database system and a need for the information, but would rather pay the data entry clerk (a recurring cost they already have) instead of automating the process. Honestly, unless it's a trivial number of forms being filled in (and thus automating it is retarded) it ought to pay for itself soon enough.


> However, I keep thinking that I should setup a SharePoint and forms server for my customers. That way, I can charge them a monthly fee!!

Would their budget pay for that for 10 years instead of just buying the damn thing themselves?  ;)    (I assume the SharePoint license would allow that, right?)

Sunday, November 19, 2006
 
 
>If they won't pay for more than a few hours of your time, how can they expect more than what you can actually do in a few hours?  And learning new tools for a one-off job is silly - that's not trivial and it's probably not billable under their "few hours of work" budget.

Yes you are reading my mind. I kind of wish that I did have a full set of pdf tools, and WAS up to speed. The problem is that I am not…

>It sounds odd that they have the database system and a need for the information, but would rather pay the data entry clerk (a recurring cost they already have) instead of automating the process.

Ah, the problem is more complex.  We are in the processing of submitting/building a web based system for this problem).  (but, many $1000’s to do this). In the *mean* time, we are proposing to automate the import of those excel sheets they now send out to clients. The problem here is that they are reluctant to spend money on this temporary solution to just throw it away when the web based system comes on line (if they can come up with the money, and approve the web based system in the first palce!!).

The Excel import  (and, more important, some really cool automaton code to actually *generate* the excel sheet customized based on existing customer data) can likely be done for about $600. Not a lot work. However, since they *are* considering a web based system for the future, then one can easily see the issue of hesitation for spending money on this temp solution (the employees can tuff it out until the better solution can be delivered - no skin off of the boss!).

Further clouding the issue is that I can deliver this excel solution and interface it to the software in the next day or so!!

*-- So, more time, more money, more waiting = better web based solution (and, more money = more difficult approval process for the software).

*-- Quick and dirty = can deliver in less then two days right now. Allows them to WAIT LONGER for web solution. Also,  less money for them spend and approve right now.

So, you are 100% correct, I really don’t have time/budgets to learn the pdf tools. However, as a few suggested, if I can use these solutions for *other* clients, then the investment is worth it (and, by the way, I *can* use the pdf solutions for other clients!!...this make my decision even MORE complex!).

-- worse, is that I want a nice soltion for my software in terms of forms being filled out. Again, integrating sharepoint + forms (for customers that don't have share point) is also another idea I can considering.

Anyway, we likely do the quick $600 solution.  Thus, they will be up and running in the next day. And, with holidays, and things being busy for eveyone right now, it likely best to just "GET ER DONE" (if you been to a Rodeo…you will often hear the saying “get er done” -- it means exaclty what it means!!).

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Monday, November 20, 2006
 
 
I am developing something that might be interesting to this group. Would appreciate any input in defining Business Needs you are encountering.

I have created a framework for rapidly creating intelligent Forms directly from Schema and WSDL definitions. Based on industry standards XML, XSD, XSLT, and XMLHTTP these clients are deployable to all modern browsers.

Easy to Use: Interactive interface for creating valid xml as a user navigates through the document.
No  XML knowledge required by end-users. The XML document is automatically rendered as a form. All of the details regarding structure are created directly from schema and WSDL definitions.
Auto-validating.

The Smart client is auto-validating and highlights any erroneous input immediately. Ensures only data valid to the customers schema is created.
Based on standards: XML, XML Schema,XMLHTTP & XPath.
 

Business Orchestration
Smart Clients can be used to run complex business processes across many Web Services seamlessly sending and receiving data.  The SOA Client provides users and interactive and intelligent interface, hiding the complexities of SOAP, and WSDL.
 
Reduced Server Load
By insuring up-to-date, complete and valid xml content you not only simplify the middleware dramatically, you also reduce the number of application sessions that you need to be maintained, cutting down the load on the application servers.

Offline Capabilities
Smart clients solves one of the more troubling aspects of web applications - mobile users can download documents, work on them off-line, then post the results to the server automatically once a connection is re-established.
Edward Kepler Send private email
Monday, November 20, 2006
 
 
Edward, is not what you describe much the same idea as the SharePoint + forms server?

Did you take a look at that demo link I posted above?

http://office.microsoft.com/en-ca/formsserver/HA101672631033.aspx

(notice that there is outlook support for the forms emailed – this means off line, or “whenever” the user can respond/fill out the form). So, those forms can be offline or “online”.

InfoPath forms supports field verification, and that data can be from a server, or not.

Away, it sounds a bit like you much identified a need. Note that much of office has been re-engineered (including ms-access) to support forms that are mailed out..and filled in, and retuned (via sharepoint).

Google does turn up lots and lots of solutions. For sure, a whole industry been built around the pdf forms ability. After all, this kinds of forms stuff is a meat and potato kind of thing for just about any business.

However, what coding language, what scripting, what format….what server…the list is long!!!

The sharepoint + infopath + forms server is a huge deal because it becomes a *instant* standard. One that *many* developers can adopt. Lots of the forms don’t need any code, and be designed by anyone who can figure out how to use desktop publishing, or any kind of forms designer (infopath).

MORE importantly, these types of SharePoint services will eventually be extended to work *BETWEEN* business that adopt those systems.

I just so busy right now, that I just run out of time to look any further beyond what as discussed here. Besides, my solution is simply waiting approval, and is nearly done anyway.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Wednesday, November 22, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz