Kenneth's Picnic

1) I expect you to manage my files. Maintain a list of my purchased files and let me download them whenever I want. Why am I expected to keep backups? It’s just weird.

2) I expect you to allow me to deauthorize a computer remotely. For example, I’ve just lost my hard disc. How do I deauthorize it? You tell me I’ve got 5 out of my 5 computers authorized. Ok, which ones? Unlike 1975, five is not a big number of computers. How about automatically deauthorizing a computer after 12 months?

3) I expect you to tell me that I can’t play HD films on a non-approved TV BEFORE I buy it. Or, to be honest, never. I’ve never heard of such ridiculous bullshit. I’m not about to go and buy a new TV, just because it doesn’t have your DRM built in.
The discussion here has 8 pages, and the last one says “Apple Support has no idea this problem exists.”
http://discussions.apple.com/thread.jspa?messageID=8472731

4) If I tell you I own an MP3 I expect you to trust me. Allow me to copy and transfer it like any other file.

We like our iPods, we love our iPhones, and when our wives aren’t looking, we might secretly give our MacBooks a cuddle. But no-one likes iTunes. And not because it’s a bad idea. It’s just clunky and unusable.

If I were the EU, I would consider Apple bundling iTunes in the same light as Windows bundling Internet Explorer. Let’s start the fine running at €1m/day and start talking openness.

Ok, so the headline of this article is probably a little OTT. But I’ve just had one of the most annoying, and expensive, experiences working with Amazon’s hosting.

Actually, it’s really only annoying because it was expensive.

What happened was this: I moved a sizeable set of sites over from my previous standard hosting to the Amazon EC2 set. It was LAMP based, but I’m not going to tell you which site, because it was built a long time ago and hasn’t had enough TLC recently.

The site was suffering from some pretty terrible response times. Using a top to find the slow process seemed to give me no clues at all, and yet the cloudwatch service was showing consistently high CPU usage.

The site is database driven, and that work is quite intensive. Each page on the site executes several queries, and there is a chatroom which drums the database on a regular basis. But the site doesn’t do much else. And so my culprit was obvious: the database.

I’d read about Amazon RDS and it seemed the perfect solution. There’s no denying that my database is relational, it’s almost the textbook relational example, and so RDS beat Simple DB any day of the week. It was cool to have my own EC2 instance running MySQL, but really, Amazon can be a bit complicated with backups and storage. The thought of carefree backups, and a consistent long-running database as I toggled between application servers definitely appealed. I have a new site to roll out? Easy. I run a new server in parallel, and switch the IP across when it’s tested. Dream scenario, right?

And so it seemed. The cost seemed a little high, but I had high hopes for the performance, and it was still less than our (3 year old) prior hosting. I followed the Amazon online setup guide together with someone’s step-by-step tutorial (since sadly the console did not support RDS yet).

Except that it wasn’t much faster. “Shit”, I thought. That was a waste of time. But that’s ok – I now can toggle between different instances of application server, and figure out the problem there without worrying about the database at all. The site was fast enough to leave it running for a week to “bed in”.

One week later, a spring in my step, time to get working on the application. This is working out well. Database still intact, Cloudwatch says CPU load still high, so the blame must be with the PHP not the MySQL. Ok, fair enough. And a quick check of the running costs, gives me $400, not bad for the …

No, wait, go back to that bit again.

Four hundred dollars? A WEEK?

WHAT. THE. DUCK.

That’s over twenty grand a year. Sucre.
My fingers have rarely moved as fast as they did to get that server switched back.

So what happened?
It turned out that I’d been charged for the bandwidth between the app server and the database. And in that week, I’d racked up a terabyte of data. That sounds like a lot, but like I say, this was a DB-heavy site. And actually, you never really look at the bandwidth to your DB do you? It’s not what I would consider “external bandwidth”, which is what Amazon charge for.

After a very stressful couple of hours, I had a medium size instance (high cpu) running, with a clean Ubuntu install and Apache PHP MySQL on top. Performance was back to proper levels (so the PHP just needed another processor), and the costs were back down.

I sent a message to Amazon asking what had happened, and whether I could have my money back. Answer: not on your nelly. You used the bandwidth, you pay the price.

I protest. “Come on”, I say, “I’m not sure what happened here”. I’m a loyal customer and they could at least be generous on this. A bit of faith in the newly-subscribed. Better than that, I paid up and reserved an instance to demostrate my commitment. Just drop the week’s charges, I asked.

My question was passed to management. Not on your nelly, they said. You used the bandwidth, you pay the price. Your bandwidth was cross continent, they say.

AHHHHHHHHH.

Now I get it. My servers were naturally in Europe. Obviously I’d omitted the step of putting my RDS instance in Europe too, and it had defaulted to the US. Bollocks. I moved 1TB of data across the ocean because of a silly oversight.

Of course, it would’ve been nice if the setup commands had mentioned this.
It would’ve been nice if they had added RDS to the console, so I could see this (seriously, they can develop a distributed database system, but haven’t got the time for a bit of HTML?)
It would’ve been much better if they’d alerted me as I switched from a $1,000 setup to a $20,000 setup.
Not much to ask.

And really, it’s not much to ask for my $400 back. Ok, so I got it wrong. But where’s the love?

Thankyou isn’t a word.

I was taught this in English class, and it’s official.  It’s not in dictionaries, and Google doesn’t recognise it.

Correctly, it should be two words.  ”Thank” and “you”.

But hold your horses there.  As I understand it, one of the key benefits of the English language is its flexibility.  The first Dictionary was, I believe, German, and it laid down exactly how all the words of the language should be.  The English huffed and puffed about this, and openly mocked the idea.  They then sat down in a library and formed the English language by reviewing every English word ever written.  They set out to be descriptive rather than prescriptive.

And our dictionary evolved.  The scholars in Oxford smugly release a new set of words every year, which they promise we’ll all be using a year from now.  Now they didn’t invent these words.  They acknowledged their use somewhere, and described them.

Ok, so I accept that another idea of a dictionary is to provide a single spelling for each word.  In a language with few rules, none of which are not broken, a defining way of spelling helps us all be understood.

But thankyou is a word.  It has become a word through common usage.  It has a specific meaning and use.
It has 12,500,000 matches on Google.

Let us not reject it.  Let us accept it.

Please sign my petition here:
http://tinypetition.com/thankyou

Thankyou.

Agile does not mean faster

If Agile meant faster, we would’ve called it Rapid.

The aim is to get a better result.

Obviously, getting a better result avoids the need for costly revising later.  That will save time.

You can’t switch to Agile because you’re behind

An Agile project needs regular input from key stakeholders on a project.  If you’re not getting that already, something is already wrong.

By going Agile, make sure you’re switching cost models to a time-based approach.  Otherwise you’re simply handing your client infinite inputs and revisions for no cost.

An Agile project is basically the repeated improvement of a prototype.  If you haven’t got a prototype ready, starting Agile might mean you have to step back in your project plan.

If you’ve been through a whole bunch of project definitions and deadlines which you have to stick to, then you have already missed the boat.

A meeting with the client every week is not Agile

I have seen people suggest that we “go Agile”, by having a weekly meeting.  This is not Agile.  This is a weekly meeting.  If you don’t understand a word, don’t use it.

If you can’t say no to your client already (which surely is a blog post in itself), then giving them extra input will increase your workload.

If your client is interfering rather than assisting, then maybe less input is what you need.  Maybe full definitions are needed to avoid scope creep.

Agile is not always better

“How much will it cost?” is the question ever-present in your client’s mind.  Unless you have built up the trust by delivering on projects and timelines already, or have wowed them with case studies on the concept, then your client is right to be suspicious.  What guarantee have they got that your Agile project will complete in budget?

A waterfall process can be slower because you have to continually define what you’re building.  But this definition should not be wasted.  Know the audience for your documents, and make sure they’re read.  Don’t complete documents just for process checklists.  Make them useful.  Make them short.

Then introduce Agile for your next project.  Make sure you know your stuff on this.  Go Agile early.  Make sure you can deliver to cost, and make sure you know who’s paying if you don’t.  A clue:  it’s your client. (extra flexibility costs money)

Agile will not save your life.  But it might just deliver your client a better result.

Use it wisely.

I can understand that when you’re designing a magazine page, a poster, an advert, a banner, or hell, even a letter to your granny, then the first thing you need to know is the size of the material you’re working with.

The challenge of the web is that your users’ monitors vary widely.

In the UK, we currently have the following breakdown:

1024×768 25.10%
1280×800 24.60%
1280×1024 13.38%
1440×900 10.23%
1680×1050 6.74%
1366×768 2.76%
1920×1200 2.32%
800×600 1.99%
320×396 1.55%

It’s good to see the 800×600s have dropped to under 2%. This has been a steady decline, and so we can politely ignore the size when building our sites.

We build to ensure that there is no horizontal scrollbar when viewed at 1024pixels across. This gives us a working width of 990px to allow for the scrollbar on the right.

Users on bigger screens simply see more space, but they are also likely to avoid maximizing their windows, so this usually doesn’t look too bad.

The big issue is the height of the screen. We cannot give a fixed working height, because we do not know the size of the titlebar and bookmark bars at the top, nor the height of any windows taskbar at the bottom. There is no “usual” size here, since inexperienced users commonly add bars, but do not know how to remove them.

Generally we work to a height of about 550px. It’s important for this part of the screen to convey the majority of useful information.
Users will need to see the following, before they scroll:

• Logo
• Navigation
• Current location in the navigation (highlighted nav or breadcrumbs)
• First header
• A description of what this page is about.

We refer to this area as “above the fold”.  This is a term acquired from newspapers, where only the information shown above the halfway fold is visible to the buyer, and so is the area most likely to influence your purchase.

Poor designers can be readily spotted here:  they see the above, and make designs of a fixed height.  This means that the page is built without any vertical scrolling.  This restricts the usable area for content, and usually means some sort of custom scrollbar needs to be used in little windows in the site.  It’s lazy.  It’s amateur.  It’s pathetic.

What I want to point out here is that scrolling is not bad.  People do know how to scroll.  People like to scroll.  It’s the most usable way to present content on the web.

So, please say NO to:

• fixed height layouts
• custom scrollers

Reasons you can give are:

• custom scrollers do not work on touchscreens (like iPhones)
• fixed height designs can’t flex to fit smaller screens (like iPhones)
• scrolling is still fine with high-resolution backgrounds.  Look at twitter, where the background is simply fixed.
• custom scrollers look ugly when javascript is disabled.

While mobile users and non-JS users are usually dismissed out of hand, there is evidence to show that this should not be so.  See the 1.5% of users above using a 320×396 display?  That’s mobile.  And yet the site I used to gather these stats is not even mobile friendly.  This is rising, and will continue to rise.

In Japan, mobile internet is used more than PC internet.

It’s time to embrace flexible layouts.

And to be fair, most of the Internet has.  But there are still a few designers out there who haven’t.  Wake up!