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.

Iced Out

I got an email from Mark this morning saying he was in his first ice storm and that there’s one branch “above the power line that I’m concerned could fall and leave us offline for awhile” so who knows when we might hear from him. Best of luck, Mark!

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.

Zoodle Rhymes with Poodle

- and you know what they say about Poodles…..? Well, you could say a lot of things about poodles, but specifically, I was referring to their finicky nature. As you’d imagine, we’ve discovered in trying to launch this nifty Zoodle prototype, that despite Pete’s five submissions of our feed, Oodle has not replied to our small potatoes endeavor. No worries, there are other dogs in the kennel, so to speak.

Fortunately, I have been working with a developer of a nice new real estate listing syndication site that will distribute our feed data to Oodle, Google Base, and a slew of other advertising mediums for us.  We’ll title our new prototype Zyndafeed.

The process of creating these CSR friendly tools forces one to really think about how an application is going to be used, and what’s going to matter to the telephone reps on the front line.

Ted may not like the fact that by using ZC to gather the essential data we need, we are practically forcing him to complete multiple forms. In other words, in order to complete the attributes section of the listing, he first has to complete the basic listing data - essentially we have multiple ZC forms within this one app, and this makes the process of submitting essential BuggyRocket listing data a multi-staged endeavor.

Though a multi-staged approach may seem clumsy to some, it also provides natural checks and balances so that Ted can’t skip ahead and neglect an important required data field. Not surprisingly, real estate sites like Zillow, Trulia, PropSmart and others have specific required fields that must be completed in order for the listing to be displayed. Our multi-stage approach helps minimize the likelihood that an important field is accidentally omitted.

But what if a customer calls Ted and isn’t ready to do business with BuggyRocket yet? Good question! - We’ve asked it too. Zoho has a nice little CRM app called, not surprisingly, ZohoCRM. It will allow Ted to capture a prospects contact info for brochure request purposes, as well as to schedule future marketing efforts and follow-up.

What is surprising is that there doesn’t appear to be a seamless integration available between Zoho Creator and ZohoCRM. Hmmm? How is that possible? Don’t know, but from an end-user perspective it seems a bit odd to not be able to unify the mighty possibilities of Zoho Creator with the simple, yet relatively elegant CRM software available under the same roof. (However, a separate account is required to use ZohoCRM and up to three users can use it for free.)

Aside from that grievance, I don’t have too many reservations about using ZC for our CSR users. After playing around with our prototype, the only other feature I would really like to see is dynamic image upload capabilities. It’s a bit cumbersome to have to to create a massive form simply because we need to upload more than a couple pictures. It’s not unlikely that we will need to upload 25 pictures or more. That could get rather bulky!

Next time we post, we hope to provide you with results from our new Zyndafeed app.

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.