Blog

WordPress Plugin: Gravity Forms and Solve360 CRM

Naga IT Services
Projects, WordPress

A lot of the work I do is WordPress-related, and a lot of that involves things that are either quite client-specific, or that can’t really be shared in a public forum. A job I’ve been working on recently, however, has given me the chance to make something that I can publish.

The site uses Gravity Forms extensively for contact forms, application forms, and so on. They use Solve360 for their CRM software and wanted a way to easily send the data gathered by the forms to it.

Since the site runs on WordPress, I put together a Plugin that loops through the forms and sends the data to Solve360, using their API.
Download the Plugin from the WordPress plugin directory.
[Added 23-02-12: Fork it on github.]
The only extra work required is adding labels to the Gravity Forms so that Solve360 can match up the form’s fields with its own. Details are in the Plugin’s readme file.

I wrote this to be used by developers, so the options are set in the code, rather than via the WordPress Dashboard. This is okay for now since the options won’t change often. Things that I intend to implement in a future version:

  1. Solve360 user details set in a WordPress options Page.
  2. debug mode and date overrides set in a WordPress options Page.
  3. To, From, CC, and BCC notification email set in a WordPress options Page.
  4. (added 21-02-12) Cronjob support

Mo’ devices, mo’ problems

Naga IT Services
Industry, Responsive

The number of internet-connected devices in the world is increasing at an alarming rate. There are about ten in my house of two people, and the devices have wildly varying degrees of connectivity, usefulness, and physical size. I think the future friendly folk have got it right when they say: disruption will only accelerate.

Ideally

In an ideal world, we would test on every device to see that everything works fine. Time and cost make this impractical, though.
(By testing on every device, I don’t mean matching up the design exactly or even providing an identical experience. Expecting a web site to look and feel identical on a smartphone and a television, for example, is somewhat like expecting a movie to look and feel the same watching it on a laptop on a plane as watching it in a crowded cinema. The two will be different experiences, but still essentially the same movie.)

Realistically

So, what can we do? Test as much as we can, on as many devices as we can.
We can’t pick up every problem and every error, but each one we do find helps us learn more about things to look out for, and help us build more robust sites.
There are a number of services like Perfecto Mobile that offer remote testing of a large bank of mobile devices. They’re not cheap, though, and I think that actual physical testing trumps remote testing.

Linky

Here are a few links to articles that make me think more about this.

  • An old-ish article, but still a good one is Peter-Paul Koch, “Smartphone Browser Landscape” on A List Apart.

    In this article, I’ll give you an overview of the mobile web market, as well as phone platforms and their browsers, so that you can decide which mobile devices to test on. Then, we’ll look at how to set up a mobile test bed.

  • A more recent article by Stephanie Rieger, “On designing content-out (a response to Zeldman and others)” reminds us that emulators and rough-and-ready browser resizing isn’t quite good enough:

    Testing on devices reveals all sorts of stuff that simply adjusting content never will, and that you won’t see by simply testing by resizing a desktop browser.

  • Finally, Brad Frost’s “test on real mobile devices without breaking the bank” gives some good, practical, real world advice on setting up a test suite.

    Mobile is the future of the web, so it’s time to start investing in some mobile devices. Testing on actual devices is now an absolutely essential part of web design.

Personally

I’m still reviewing my options. As a one man show, I don’t have a large budget to buy lots of devices just for testing purposes. I have to rely on emulators to some degree.
I don’t currently own any Android devices, or Nokia, or a Blackberry, but I’m looking at Pay As You Go options for getting more devices, and still having access to phone networks for testing.

I’d love to hear people’s thoughts on this. Sound off in the comments, or drop me a mail.

One Version Manifesto

Naga IT Services
Industry, Reading

Two interesting articles came up on .net magazine yesterday: “My websites will only support the latest browser versions” by Aral Balkan and a counter piece “Develop for as many users as possible” by John Allsopp.

Balkan makes a fairly convincing argument about the ease and automation of upgrading browsers, but focuses on designing/developing for browsers. I’m more convinced, and agree, with Allsopp that sites are for people, not for browsers. I think he nails it with:

And however ideal it might be that our users use only the most up to date version of a browser, it simply isn’t, and never will be, a practical reality.

Some users don’t, can’t, or won’t upgrade their browser. Some aren’t aware that there’s a choice available.

Balkan’s article also seems to be fairly desktop-focused. Mobile access via feature phones in Africa is booming. These users certainly aren’t using the latest and greatest browsers, but that doesn’t mean we shouldn’t consider them in the design and development of our sites.

A lot like building a house

Naga IT Services
Industry, Reading

Aaron Gustafson wrote a well-reasoned post about Progressive Enhancement vs. Hardboiled Design yesterday. In it he describes Progressive Enhancement more eloquently than I can (although he also uses a house analogy), and explains how it’s not at odds with the “Use the latest and greatest technology right now” approach that Hardboiled Web Design champions. Being a big fan of both approaches, this made me very happy. There’s no reason not to use the latest tech, as long as it’s applied in a stepped, responsible, manner.

Progressive Enhancement is all the more important in the industry at the moment because of the meteoric rise of Mobile First Responsive Design. Applying Progressive Enhancement in this context means starting with a small screen, low capability device, and adding features as screen size and device capability increases.

Aaron’s post jumped off from A plea for progressive enhancement, which reminded me to hit up Yiibu’s excellent Slideshare page. I’ve grabbed copies of the most recent three, which I somehow missed, and have them lined up for reading matter when I travel later this week.

Adaptive Web Design (Aaron’s book) is an excellent read, and I highly recommend it. It’s clear, concise, and offers excellent practical advice. I find that it goes very well with Filament Group’s Designing with Progressive Enhancement. Adaptive Web Design was quite a fast read, but great at getting the ideas across and making them stick. Designing with Progressive Enhancement is dense and a bit heavy going at times, but is an excellent resource and is jam-packed with fully worked examples. I would call both required reading!