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

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.

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.

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!

Web Site Basics is aimed at the complete beginner. It answers the questions: “What makes up a web site?” and “How can I keep it up to date?”

How I do things is more News and Current Affairs in the Web Development world: One Web; Progressive Enhancement; Responsive Web Design; Mobile First / Content First. It’s a brief summary of the direction things are going and a round up of the thinking of a lot of smart cookies out there.

I’ve seen NeighborGoods pop up a few times recently, and I like the look of it.
Since it’s got a lot in common with My Project Without A Name, I had a poke around to see if I could use it instead of building something myself.
Neighborgoods is great and I really jive on their simple, clear, message: “Save money and resources by sharing stuff with your friends”.
It doesn’t quite align with what I’m looking for, though.

I’ve always been a fan of lean and mean. Work-wise I’m very much moving in the direction of Mobile First Responsive Web Design: everything should start lean and fast, and build up from there. (I’m sure I’ll also be re-reading Bagchecking in the Command Line once I get started on my project again.)
Applied to my loaning app, this would mean that at first there should be very little going on apart from the loaning and returning of items.
The target audience is groups of friends who already know and trust each other, so there’s no need for lots of personal information: just a name may be enough.
Items descriptions can be short too: price, condition, exact model number probably won’t be needed.
The focus is on the in and outs of of your stuff: showing what’s in and tracking what’s out.

One big item that I still need to work out is money.
If I manage to find the time to put it together and get it up and running, how do I keep it going and keep improving it?
Will Google ads, or sponsored ads, earn enough to keep it going? Perhaps, but I doubt it. Also, I really don’t like ads.
Do I charge a membership fee then? How much? Don’t Be A Free User on the Pinboard blog reminded me that it’s okay to charge money for providing a service. In fact, it’s often necessary.
I think that if I want to be able to offer a really good product, I have to fund it somehow.

Two great posts about this from a few days ago are Startups, lack of sleep, and finding better ways to do business by Rachael Andrew and on doing what you love, loving what you do, and not burning out along the way by Scott Anderson. Both sum up things more eloquently than I can, but I want to pick up on a few of the points that I feel quite strongly about.

I don’t shy away from working hard, or from putting in long hours when necessary. This has to be the exception rather than the rule, though. Working into the evening, or on weekends, quickly takes its toll on health and sanity. I’d much rather put in fewer, higher quality, hours than lots of hours at steadily declining quality and productivity. Extra coffee only helps up to a point!

I love my job, but my life outside of work is just as important to me. The balance and the contrast is what keeps me happy, healthy, and excited about the next project. And now is a very exciting time to be a web developer. (More on this soon.)

I think it would be a little melodramatic to say that Hardboiled Web Design by Andy Clarke changed my life, but it’s not that far from the truth. I bought the electronic version of the book on the day it came out from Five Simple Steps and raced through it. Something about the “no compromise” approach really resonated with me, and I became very excited about my work again. I was hungry to try new things and work even harder than before.
The worked examples of the various bits of HTML5 and CSS3 look beautiful (which I find is not always the case in web design books), but what really go me going was Part 1 of the book: the day to day practicalities, how do you sell this to clients, and so on.

I bought the paperback a short while after, and I’m glad I did: it’s a thing of beauty and a weighty tome forever. I find that paper books have a stronger visual memory hook for me. I find them easier to dive back into and flick through to find a particular technique or idea that I want to revisit.

This list from the end of the Workshop page sums up the Hardboiled approach quite nicely:

• Why web browsers don’t limit your creativity
• That websites shouldn’t look, or be experienced the same in every browser
• How to handle older, less capable browsers
• That browser differences are creative and business opportunities, not obstacles

A parting aside: Five Simple Steps has a small but strong catalogue and is well worth perusing. I’m particularly fond of Brian Suda’s Designing with Data. It tickles all my minimalism muscles, and he’s pleasingly rude about Chart Junk.

A first step would be to use add_image_size to generate the different image sizes.
One problem is deciding what set breakpoints to use.

Then, rather than using Craig’s getimage.php, a filter would be added to post_content, looking for WordPress images (maybe looking for .wp-post-image) and replacing them on the fly with the desired size.
If you wanted to do this just for featured images it would be very simple. You could write a tiny custom script to pick the right argument for the call to the_post_thumbnail().

I’m looking forward to experimenting with this on my next project to see how practical or fiddly it is.

via Jon Hicks on Twitter