Electronic Forms for Today’s Web
What is Web 2.0?
Back in the ‘90s we had Web 1.0 – static HTML pages and client-server solutions. That was twenty years ago. Nowadays, the Web is more dynamic. Electronic forms push and pull data to and from multiple sources, and they must look good on mobile devices and work well offline. HTML was the standard for static Web 1.0 and XML is the standard for Web 2.0 because it enables offline document storage, and speaks the same language of the many Web services supporting the dynamic Web 2.0 world of today.
How do Smart Apps Integrate with Web 2.0?
Smart mobile and Web browser apps no longer rely on server-side validation to submit. Why is that?
- End users do not want to fill out a form and see an error on submit (it’s a disappointing user experience)
- Submit connection may be asynchronous which means the confirmation may not come for minutes
- The app client does not know how to act on the server’s error result (requires custom coding which creates a brittle tight coupling preventing quick change)
For those reasons, smart apps do validation before submitting. They ensure their data meets the requirements of an XML schema. Submits do not fail. This architecture is called a “loosely-coupling” architecture because there are no constraints on the server. The server simply extracts information in a passive way from the client. No errors. Of course, the app designer is responsible for creating a data source that matches the business process. The server is only responsible for storing the data and extracting details from it. This simplifies solution architectures while allowing change-management flexibility. Server logic goes away. When the app changes the server just updates the mapping it uses to extract data. No system downtime. XML is the key in enabling this loosely-coupled integration model because it provides client-side schemas. The NoSQL movement is a key in enabling the no-code server-side piece of this puzzle.
In spite of Microsoft’s recent deprecation, InfoPath is still the best technology to use for forms projects:
- Layout is industry standard (HTML) – good-looking, structured forms can be created
- Data format is open (XML) – supports loosely-coupled architecture and enables easy migration of data to new solutions down the road
- No code required – supports rich client-side validation with rules; Web service queries or submits can be done without code
- Mature, feature-rich technology – InfoPath handles millions of forms in production today
- Low Cost – no new software licenses needed for Microsoft SA customers
- Reliable Support – Microsoft will continue supporting the filler until 2023
Who is Qdabra?
Qdabra is a customer-focused company. We build electronic forms and have helped thousands. We are technology agnostic and we always listen to the unique needs of the business before proposing a solution. As a small boutique consulting services company, we specialize in electronic forms but we have also developed many tools to accelerate projects and empower our customers to get the most value out of their existing software investments. Qdabra’s Web Service Suite (DBXL) and qRules plugin are two of the many tools available from our web site.
What is DBXL?
Qdabra developed DBXL in 2004 to fill a glaring gap in the InfoPath and SharePoint landscape. Customers could not report on the repeating data in their forms and 95% of all business process eForms have repeating data. To solve this problem, DBXL supports submitting XML data to any SQL database. DBXL is a loosely-coupled Web service that enables other smart app scenarios. It is not specific to InfoPath and, in fact, can be used to reduce the development cost and improve the architecture for Web development (since it enables a loosely-coupled design). After 10 years of development, DBXL no exists a suite of Web services to reduce the cost of integrating apps with SQL. It provides both query and submit functionality and rich repertoire of tools to manipulate data. The main benefit of the DBXL is that it is a generic Web service and can be used for any number of forms. Instead of creating one Web service per form template, which causes deployment and migration cost, DBXL supports any number of form templates and that results in a huge cost savings since there is only one deployment and migration to a new server or SharePoint farm is easy. In the last few years, we have created cloud versions of DBXL for Amazon Web Services and Microsoft Azure. Visit our Web site for more details: http://www.qdabra.com/en/products/DBXL.aspx
What is qRules?
Qdabra launched our first community site, InfoPathDev.com, back in December of 2003. After a couple years, the InfoPathDev forum was the leading resource for InfoPath questions on the Web and we currently get between forty and fifty thousand unique visitors a month. The problem was that the questions always centered around the gaps in InfoPath. In other words, people were constantly hitting the same issues and we grew tired of responding to each post with the same code snippet. So, we developed a common library to give to people and that library became qRules. Today, qRules has over 150 functions not included in out-of-box InfoPath. The main benefit of qRules is that our customers don’t have to worry about writing code to fill the most common gaps in Microsoft’s InfoPath technology. Rather than hire a developer and have separate libraries for each InfoPath form, qRules provides a common library that can be injected into a form template and used to complete InfoPath filler forms as well as SharePoint browser forms. Recently, we have created a Microsoft Azure Web service for our Office365 cloud customers. Visit our Web site for more details: http://www.qdabra.com/en/products/qRules_new.aspx.
What about the Future?
Ten years ago SharePoint was barely breathing and ten years from now, SharePoint will likely be something entirely different. Technology changes very quickly, companies split apart and merge. Data formats change much slower than apps. I feel confident that HTML and XML will still be around in 2024. Forms technology that uses those formats today will easily migrate to new “apps” in the future. Qdabra is an “eForms” company. We think InfoPath is still the best technology around, but we are customer-focused. We are not technology centric. We’re here to create a solution for you. We have employees certified in K2 smart forms and Formotus mobile forms and we also are happy to implement ServBus or a PDF Share Form solution if you think it would be a better fit. We will happily look at Access or SharePoint list forms too, but they have serious limitations. We just completed a 12-part webinar series titled “After InfoPath” (click here) focusing on migration paths. We also have a matrix you can review to see some of the many forms alternatives. One of those alternatives is Qdabra’s own FormsViewer technology which we are committed to providing for free as open source software. The software currently works on SharePoint 2013 but we intend to provide it for people without SharePoint in the next year. FormsViewer will support both viewing and editing of data and it will use InfoPath XSN format. We hope this will provide an additional migration path for companies over the next few years and we intend to add features to it to extend the technology in the future. In other words, we will have API compatibility for a large percentage of existing InfoPath forms. InfoPath form services provides about 80% API compatibility for InfoPath filler API features. Formotus provides maybe 70% and FormsViewer will likely be in the same range. Certainly, we can design a form that will work on FormsViewer and InfoPath filler from the beginning too.