Fast Food, Rapid Prototyping

A recent post from Gabriel Coch at the InfoPatterns blog steps through the use of Zoho Creator in conjunction with Toucan Navigate to show “the concentration of Fast Food Places along the I-95 corridor“:

My main objective was to accomplish this without a single line of code (no html, no javascript, no nothing) and yet provide enough functionality to answer some basic questions, hence making this potentially useful in the business world.

Zynd in the Clowns

Awhile back someone in the Zoho Creator forum asked how to best design a ZC application and I wrote back to the effect that since there isn’t much design involved, it’s best just to suffer through the documentation and play with the interface until you get something close to what you thought you wanted. I’ll now amend that sentiment slightly by stating that it can’t hurt at least to try and write Deluge code that does not induce nausea.

Version 0.01 of Zyndafeed used a kludgy series of shows and hides in conjunction with 50 statically defined form fields to support up to 50 photo uploads. This worked OK from the outside but the implementation is embarrassing and in any case prompting the user with the option to fill out up to 50 text fields on one page is probably ridiculous in the first place.

Version 0.02 takes a different approach (and reduces signficantly the size of our Deluge script) by providing a separate form devoted to image uploads. A one-listing-to-many-photos relationship is established by inserting a listing’s unique_id as a non-unique identifier for rows in the Photos table. When it comes time to generate the feed, any image in the Photos table with a listing id that matches a listing’s unique id gets appended as a a child node. With this change not only are we providing Ted and the BuggyRocket customers with more flexibility (remember that we need to support at least 25 uploads per listing) but we’re also adhering closer to the DRY principle.

Design considerations when hacking out a Zoho application? It can’t hurt. In any case we’ll see what Mark thinks of this new version when he gets a chance to try it out and reply. Some ideas for more features include a monolithic view of listing data instead of views spread over 5 separate screens and some useful filters on whatever views are in place.

Zyndafeed Prototype

This incomplete version of Zyndafeed has some interesting characteristics, most of which aren’t particularly flattering, but at least we can fix the first two:

1. Photos in the wrong place (fix in next version)

Currently the form labeled New asks Ted how many photos he needs to upload (with a maximum of 50) and then dutifully renders only that number of upload fields for him to complete. Now that Mark has clarified the requirements to support a range beyond 25 photos, leaving them here is pretty ridiculous. In the next version we’ll break them out into their own form. We’ll also fix the 50 photo fields that are currently hindering attempts to edit the existing records in the Main view.

2. Photos published in XML feed (fix in next version)

We still need to render a new XML element for each photo before we have compliant custom XML feed. After we get #1 squared away this shouldn’t be a big deal.

3. Non-intuitive form behavior (won’t fix)

Even after we do make photos a separate part of the application, Ted may still suffer at the hands of some non-intuitive (albeit innocuous) application behavior — if he fills out a few photo fields at the bottom then later hides those fields, then submit the form, any data in those hidden image upload fields would still be sent.

4. Unfortunate code (won’t fix)

ZC’s simple back-end is sometimes a limitation. We’ve managed to commit more than a few unspeakable crimes against all that is holy in the land of law-abiding script writers:

1. The lack of dynamic field definition means that our only way of supporting up to 50 image upload fields is to statically define each field up front then show or hide the required number of fields as appropriate.
2. The lack of one-to-many relationships marches us down the ill-advised path of generating our own unique-ids.
3. Both the inability to add a new record from a script and the inability to update existing records (without also creating a new row) make our table “design” and the scripting required to maintain it unwieldy to the point where we hope we don’t have to maintain it too much. Oh well, at least part of any necessary maintenance can be done via the GUI and if it gets much more complicated we actually will check the source into Subversion.

I’ll update again when the next version is published; separate photo functionality and a complete XML feed should present something Ted could conceivably use to cover the listing entry duties of his job.

We’ll also take a look at how Zoho CRM might hook into the process Mark needs to enable.

ZC plus Oodle = Zoodle

This is the third post in a series detailing a real-world example of using Zoho Creator as a small business software platform. If you’re interested in catching up, here are the previous posts:

• In How Zoho Creator Can Help My On and Offline Business Pt.1 Mark Galloway detailed his hopes and expectations related to using Zoho Creator as a tool for his small business.
• In Ted vs. Zoho Creator, we introduced Ted the CSR, clarified our assumptions, and showed an unwieldy example form.
• In BuggyRocket Illustrated we sketched out an option for how the BuggyRocket customer service process might work from a high level.

False Assumptions

When we last left Ted, we said the next step was to publish a prototype that would let him enter a customer’s real estate listing and automatically post it to Google Base once it was ready. And a few days later in a tangentially related post about ZCrIS, I mentioned we’d be throwing ZCrIS into the mix of technologies for this case study. As it turns out both of those statements were lies, lies, lies.

We’re actually going to use Oodle instead of Google Base in our example because Oodle’s feed requirements are much simpler, allowing us keep our focus on Zoho Creator instead of Google Base’s API and relatively complex feed requirements. Furthermore we won’t need ZCrIS because as it turns out Oodle will actually come and get our XML feed from us (after we email them to tell them about it), instead of us having to submit it to them. It took a few iterations before this simple approach became apparent but our prototype in its current state is both fairly straightforward and entirely self-contained within a Zoho Creator application.

Meet Zoodle

The current prototype, nicknamed Zoodle, includes a couple unique features:

1. A multi-part form: We break up one long record of real estate listing data into four smaller forms. Contrast this approach with the proto-prototype that implemented one big form.
2. A custom XML feed: Oodle requires its users to submit a feed using its own custom format. We manage to export a feed that matches this format directly from Zoho Creator.

We provided a diagram depicting a high-level take on the BuggyRocket customer service process in an earlier post, but let’s look at a slightly modified version that shows how the Zoodle-to-Oodle interaction fits in:

Zoodle will let Ted enter the listing data he gets from a BuggyRocket customer as it becomes available and only publish it for Oodle to pick up once it’s complete. Other features include:

• Listing detail page: Although it’s not the slickest looking thing in the world, we do manage to provide a “detail page” served directly from Zoodle. We also provide an image URL in the same fashion.
• Private application with some public pages: Ted’s use of Zoodle requires his authentication but the detail page, image URL, and Oodle XML feed are all publicly available on the web.
• Gradual approach to form completion: Through the use of several forms that are attached to the main “Essentials” form, Ted can easily fill out the parts of a real estate listing that he currently has data for and come back to finish the rest at any time before publishing.
• Republishing: Data can be edited, overwritten, and republished at any time.

Given our current understanding of the business need, Zoodle is probably OK as a conversation starter for enabling BuggyRocket’s information system. But we can’t rest on our laurels, Zoodle is only intended as a prototype so Mark can check in with our efforts and see where we need to go from here. Look for Mark’s comments on this very subject in an upcoming post.

“Webification”, Brought to You by Open Source

Today LongJump Blog published two posts that together do a nice job of indirectly highlighting the subtle connection we have today between open source and situated web application platforms (SWAPs):

Is Open Source An Option for Small Business?

Because most open source applications are built by unpaid volunteers, bug fixes or complex features are sometimes not a priority. Most small business are better off using a reliable, world-class business application suite they can depend on

Webification and LongJump

…only recently have small businesses began to focus on leveraging web applications to take their business to the next level.

When I first read the post about open source my immediate reaction was to think blatant FUD but on close reading decided it’s a fairly accurate post, at least from the high level and brief attention with which it approaches the subject. Open source does often require relatively complex setup and will frequently exhibit bugs you can’t reliably expect to be fixed in the time you require. The resource limitations typical of small businesses can make these drawbacks particularly unattractive, even more unattractive today as we find more and more business software alternatives appearing in our web browsers.

The cool thing about this trend is that open source undergirds so many facets of the SWAP landscape we survey today. I can’t speak too much about the internal software choices of these companies of course but if you take a look at the web server identifiers of the software delivering your LongJump, Coghead, DabbleDB, and Zoho Creator content to your screen, you’ll see the word Apache staring back at you. And ZC in particular incorporates JFreeChart and javacc into its offering. Doubtless most companies offering a SWAP-like product are incorporating lots of open source software to deliver their functionality.

So while the direct employment of open source has definite drawbacks for small businesses trying to succeed with technology, as more of them gravitate to the applications implemented on a SWAP, they are unknowingly reliant on open source technology perhaps more than ever.