Thoughts on website ideas, PHP and other tech topics, plus going car-free
‘Buy Instead’ project proposal
Categories: Abandoned, Ideas

My recent customer complaint triggered an interesting idea for a website; since I don’t think it’s been done before, I thought I’d jot it down. I am inclined to build a prototype, since it seems quite simple.

OK, so here’s the pitch. After London Midland refused to refund an unused ticket, it so happened that I needed to travel to London again a couple of months after. Rather than use them during our ongoing dispute, I opted instead for a National Express coach from Birmingham Digbeth to London Victoria, costing £13 return. So, I’d like a website I can use to publicly record the things I’ve bought instead, totalling a company’s losses over time — so that mounting pressure is placed on them to resolve a dispute satisfactorily.

In my example, I’ve already not spent £26 with London Midland, and spent £13 elsewhere. If I do the same thing again for a year, they’d lose around £100+. Even better, it might encourage other people with other complaints to set up their own personal boycotts, and, importantly, to stick to them.

Here follow a few screens that a prototype might contain.



  • Form: email address
  • Validate: username uniqueness, email sensibility check
  • Submit: generate a password and send it to the email address, with a confirm link, in a text-based email

I’ve changed my mind here. I think it’s better to sign-up during the first complaint, removing a barrier to the user getting going. Stack Exchange use this approach, and it makes things very usable very quickly.


  • If a secret URI match is detected, enable the account, and redirect to a login screen
  • If a match is not detected, offer a link to sign up again


  • Enter email address and password to logon

Change profile/passsword

  • Change display name
  • Change email address
  • Change password

Browse/filter targets

  • Paged, sortable list of target firms
  • Free-text filter (LIKE search, or Zend Lucene)


Here’s a sketch of my initial ideas for the home page. The ‘New complaint’ widget expands a UI into this section (see later on).

Sketch of home page layout

Complaint list

The complaint list above might look a bit like this:

Complaints viewer sketch

The dotted message belongs to another screen – but is worth noting. Users may be inclined to exaggerate the products/services they’ve purchased elsewhere, but of course the value of the site is in a community that states things honestly. This way, if a profile says that company X has lost a few hundred pounds due to poor service, there is a shared confidence that this is reasonably accurate.

Add a complaint

This is a fairly busy UI, since there’s a lot of info to record. At the mo, I’m thinking it should go onto the home page into a click-to-expand JS device, so users can get started quickly.

The first section will contain the company that this campaign relates to, the product/service that gave rise to the dispute, and the cost. The next section will contain the alternatives purchased, who they were purchased from, their cost, and the date of purchase. Ideally we should also record the product we’ve avoided from the target company, since this may not be the same as the product that gave rise to the complaint.

Add boycott screen sketch

This UI device can be AJAX/JS heavy, since a separate (and much simplified) screen can be offered to mobile users. For desktop users, plenty of auto-complete and date-widget dialogues, for the Web 2.0 karma.


I’ve been playing around with HTML and jQuery to see how the add-complaint stuff might look, and decided on a small change of tack. My original intention was that each ‘campaign’ could be against more than one company (in the screen above, additional companies were to be added using ‘add another block’). This makes a great deal of sense in the real world: the consumer receives poor service from one company, moves to another, and then receives poor service again; they keep moving until they receive good service or they run out of choices!

This is easy to map in database terms: there would be a many:many relation between campaign and company. However, I’d like for a campaign page to be marked as resolved where the company in question has resolved the complaint satisfactorily, and this would be harder to make clear if there are multiple companies. In many cases, I suspect we’d have campaigns where there was one stubborn company that would always be unresolved, which rather spoils the ‘success’ of the overall page.

My new version has each campaign being related to just one company. This makes things much clearer, since the whole page can be unresolved or resolved. But, a user may purchase an item from one company in order to consciously avoid more than one bad firm – thankfully this can still be catered for. ‘Replacements’ switch from a 1:many relationship with campaign, to a many:many.

This is a sketch of the change:

Sketch of a change in some of the project's entity relations

For reference, a “diary” item is a note of something that has happened during the dispute, such as making a telephone call, or receiving a letter. I think this will always be a 1:many, since a note is unlikely to relate to more than one dispute. Meanwhile, a “replacement” is many:many, as noted above.

1 Comment to “‘Buy Instead’ project proposal”

  1. […] so I decided to build BuyInstead, mainly out of curiosity how quickly a web project can be put together. At the time of writing this […]

Leave a Reply