I write occasional restaurant reviews on a group blog with friends: Salty Cracker club. We score each restaurant out of ten on a few categories: Atmosphere, Staff, Service, Food, Wine, Value for money.

I wanted to started marking these up as hReviews for better data richness and search engine listings, so I went searching in the WordPress Plugin repository. I didn’t find anything that quite matched my requirements, so I decided to write one myself.

Flexible hReview allows you to write multi-dimensional reviews attached to a Post, then display the review wherever you like using a php function, or a WordPress shortcode.

While testing the plugin with Google’s Rich Snippets Testing Tool (more on Reviews specifically) I discovered that only the first rating category (in Salty Cracker’s case, Atmosphere, not necessarily representative of the review as a whole) was picked up and used. To provide a more representative rating, I added an option in the plugin to automatically generate an overall score, and add that as the first rating. An example: using a search string mr chan cape town review shows the following at the bottom of the first page of results (at the time of writing):

Our 10-scale rating is converted to a standard 5, and is displayed as stars, giving a quick visual guide to the score.

The Flexible hReview plugin can be downloaded via the Plugins menu of the WordPress dashboard, or from either of the links below.
Download Flexible hReview from WordPress.org.
Download or Fork Flexible hReview from GitHub.

• Nielsen is wrong on mobile by Josh Clark;
• Designers respond to Nielsen on mobile;
• Nielsen responds to mobile criticism.

The gist of the replies / rebuttals are that Nielsen seems to be stuck in the old way of thinking, and isn’t embracing what is becoming the reality for web development today: the massive number of different devices being used to access the web means applying a robust, Progressive Enhancement-driven, Responsive approach is the way forward. It doesn’t make sense to assume user intent from device context, to give mobile (or tablet, or other) users less content, or to provide separate sites at separate URLs.

Related: Browser screen resolution stats rile devs.
These screen resolution trends are nice to look at for historical reference, but that’s about it. The relation between screen resolution, browser viewport, and physical size of the screen is becoming increasingly complicated. Smartphones have physically small screens, but often have a high resolution. TVs have physically huge screens, but can have resolutions of 1920×1080: the same as many laptops.

This line of work is getting more complicated and difficult; but more interesting because of it!

A word of warning, though: set aside at least half an hour for these. Good stuff, worth digesting, including the many, many, links contained therein.

Two posts that really caught my eye were more focused, though:
responsive navigation patterns by Brad Frost from a few days ago (a well thought out, well written, round up of responsive navigation patterns, with pros and cons for each.);
A Responsive Design Approach for Navigation, Part 1 by Filament Group from yesterday (a step by step guide to setting up a solid, progressively enhanced, responsive navigation).

Personally, I’m tending towards using a select for smaller screens: hooking into the native UI seems like a good thing. This could mean using JavaScript (something like Filament Group’s cunning testfit in their example above) to switch the select out for a ul for larger screens.
Relying on JavaScript for anything that basic makes me uncomfortable, though, even when it’s done progressively. I’ve been wondering about putting in both select and the ul as a starting point. (Loading extra stuff is bad, yes, but these would be tiny text snippets.) Then, using media queries or some cunning RESS action (see also Dave Olsen’s excellent article) to pluck out or hide the one that’s not needed.

Filing this under: Must Think More About It.

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.