A Better Insurance Company

I bought a new car recently. I kept the old car for a few days while I decided how to get rid of it. Good grief, car insurance in the UK is a mess. Various cancellations, new contracts, payments and refunds – not to mention about eight different letters, and we’re finally sorted. This got me thinking about my ideal insurance company, and what I’d expect from it:

  1. Absolute clarity on premiums. Everything is rationalised and explained to the customer. Getting this car will cost you £x more. Driving an extra 5,000 miles per year will cost you £y. Probably need to work on a fixed profit margin, but you’re a business (maybe a co-operative?) and I accept that. Seems to work for the utility companies.
  2. Allow instant feedback, so the customer can make decisions. The car will cost £x more? Okay, I’m willing to accept that but I’ll keep my mileage down and take the train more often.
  3. No charges for changing details. Ever. It’s a penalty on the facts of life – worse, I’m willing to believe otherwise honest people are discouraged from keeping their records true and up-to-date because of this.
  4. On the same basis, and to keep those admin costs down: everything updated online (and, per point 1, the interactive estimator is online as well).
  5. Get rid of this stupid policy of rewarding new customers and screwing loyalty. I get a premium increase next year but Joe Bloggs joins and gets 10% off?
  6. Make it absolutely clear what effect No Claims Discount has on the price. Insurance companies in other countries have clear rules on what percentage discount is applied with NCDs. Ours are smoke and mirrors.
  7. Make the idea that “to get a good deal, you need to shop around” redundant. See point 5. Many people I know shop around each year to renegotiate their insurance.  I’d rather not be in a position where this is necessary, and it shows how little importance companies seem to put on loyalty. Give me your best price first time, every time. Stop the rigmarole of phoning around every year.
  8. Remove the fear from claiming. I’m not sure how to tackle this but there is an implicit problem when people avoid claiming because they can’t be sure what effect it’ll have on their premiums. Even if you have protected NCD, can you be sure they won’t increase your premiums for the next few years (points 1 and 6 may help…). I dread to think how many people resolve their issues with cash rather than going the “proper” way, simply because of this fear and the associated hassle.

Case in point: To change my existing insurance was going to cost a lot more (20%+); to cancel then start a brand new policy (with the same company) turned out to be much less. I don’t care much for the whys and hows … this is a ridiculous, time-consuming and unpleasant way of doing business.

Over-familiarity

Reading through this article on the BBC about over-familiar websites, I was reminded about how there appears to be an increasing over-familiarity in communication in general.

One business colleague in particular grew quite annoyed at the widespread use of “Hi” at the start of (business) emails, and I have developed a tendency to agree. In client-supplier emails, for instance, the use of such relaxed greeting is (in my mind) both inappropriate and unprofessional.

My mobile provider, for instance, routinely sends out emails: “Hi Sven, we thought we’d just let you know your bill is available.” Great! You want to go for a beer this evening? Play a few games of pool?

Of course, it’s not even a human at the other end. The company probably send out thousands of these messages each day; the idea of familiarity is entirely fabricated.

Even the supermarkets are at it. My local supermarket clearly went through a stage of instructing its cashier staff to ask “how is your day?” as if they would be genuinely interested to hear a cheerful itinerary of my most recent activities. Of course not, and for all the time they’re asking the question behind fake smiles and feigned interest, I can’t help but imagine some marketing person thought this was actually a good idea, and that we enjoy being forced into conversation with somebody we’re never likely to meet again.

Of course, I take the negative view on this stuff. Maybe most people do enjoy the little artificial contact from the otherwise faceless corporations, which would explain why I ended up in a rather awkward conversation the other day when calling up a service provider. The person at the other end cheerfully spoke, “Hi Sven. Hope you’re having a good day. Can I call you Sven?” to which I rather bluntly replied, “No, I prefer Mr Latham.” I don’t think he was expecting somebody to actually object to that cosy relationship, and it put a bit of a downer on the rest of the conversation.

I wonder if he put the phone down at the end and genuinely despaired about losing a friend, but I doubt it.  I  never knew him before – he never knew me and we’ll probably never speak again.

Templating in HTML

Ongoing thoughts…

A fairly common scenario, particularly with dynamic page rendering, is the need for templates. Specifically, when loading data asynchronously we might want to define a template for each element in that data set.

For example, say I have three rows of data coming from JSON:

[{ 'name': 'John Doe', 'birthyear': 1981 }, { 'name': 'Jane Smith', 'birthyear': 1985 }, { 'name': 'Alice Bobbington', 'birthyear': 1987 }]

For interest, let’s say that both fields will be editable in the table from the outset. We’re aiming to produce something like this:

<table>
<thead>
<tr><th>Name</th><th>Birth Year</th></tr>
</thead>
<tbody>
<tr><td><input type="text" name="name_1" value="John Doe"></td><td><input type="text" name="birthyear_1" value="1981"></td></tr>
<tr><td><input type="text" name="name_2" value="Jane Smith"></td><td><input type="text" name="birthyear_2" value="1985"></td></tr>
<tr><td><input type="text" name="name_3" value="Alice Bobbington"></td><td><input type="text" name="birthyear_3" value="1987"></td></tr>
</tbody>
</table>

Please assume validation, correct HTML5 input tags and proper IDs & row references would be settled for the real thing … 🙂

There are several options to populate this in a HTML table.

  1. Start with a blank table body. Use DOM manipulation to add rows and columns in Javascript.
  2. Create a dummy row, hide it with CSS. Clone the row node in the table and populate each clone with each successive row of data.
  3. Create the HTML for each row in the Javascript (as a string) and use that to set the innerHTML of the table.
  4. Use something like JsRender, where the source template is defined in a script tag and we duplicate the template for each row.

There are pros and cons to each.

If we want to take the pure Javascript approach, (1) is the likely best option. No string manipulation, no messy fragments of HTML, but it’s verbose. Start taking this approach in a data-heavy page and you might want to rethink it.

If you’re using a decent editor with good syntax highlighting and completion tools, option (2) might be better. By revealing the rows through CSS, you can also preview how the row will look once complete (since it exists in the table). However, this places an extra row in the table which means you have to be careful when manipulating the table that you don’t include the template row (or, that you do where necessary).

Option (3) seems to be a fairly popular choice, but it leaves me with the awful aftertaste of string escaping and evals (to clarify – I treat innerHTML with the same caution I do with eval … i.e. only ever use them if I’ve exhausted all other options).

Option (4) looks promising, although I am uncomfortable with the idea of HTML markup inside a script tag … it’s (AFAIK) legitimate, but most parsers and editors won’t acknowledge this, and has the same bitter eval taste as Option 3.

Right now I favour the approach of (2), whereby a hidden row is defined in the source HTML, and is duplicated & modified according to each received row. The issues described above could be reduced by placing the template in its own TBODY.