If you design or develop web apps…
… you have to read Getting Real.
Alex Hardy
Hello there!
- My name is Alex Hardy and I'm a web and multimedia developer based in Manchester, UK.
- This is my home on the web, where I keep my portfolio and have my say on whatever interests me.
- I do take on freelance projects, so if you like what you see here then get in touch!
-
Recent Posts RSS- Why CAPTCHAs suck
- Three design and marketing eBooks
- A friend in need
- Snow Leopard changes default gamma
- Charles meets Barack
- simpleContact Pro is available now
- simpleContact Pro is now in beta
- Dizzy Bee is the best game on the app store
- What if there were no stop signs…
- First impressions of the iPhone 3G
October 26th, 2006 at 2:09 pm
“Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong. ”
The guys are fucking idiots and that’s putting it mildly.
Abandon every cornerstone of n-tier and OOP development? You can tell they don’t do any ’serious’ development.
“While our products are mainly built for small businesses and individuals”
Well what a surprise. Take the project I’m currently on, a $1M project, the users have NO IDEA what they want from the interface, our design docs are STILL not signed off almost half way into the development stage … yeah best tell the team about ‘Getting Real’ and how it’ll revolutionise our development approach.
When was the last time you were on a project where the UI wasn’t changed right up to the last minute? What about all the non-interface related stuff, things like security and audit info, things that never HAVE an interface, how do you design them and ensure they fit into your framework if you use this approach?
This isn’t a guide to dev, it is just about emphasising the importance of their own products, nothing more. A nice bit of marketing if you will. If you disagree, I say try it. Next big project, design it from the interface down and see how well that goes.
October 26th, 2006 at 2:24 pm
I did say “read”, not “swallow whole.” Like any book, the purpose of the book is to sell copies of the book. There are a lot of ideas in there that I think are excellent.
You could easily argue that the interface is a primary consideration. Security and other developmental considerations are professional development practise, which is why they aren’t discussed. I expect they’re taken as a given.
I could think of several projects that have been worth a lot more than $1M, that have failed due to user abandonment.
In any case, they’re referring to development of products and services as your own business, where there is no “last minute”. The book has more to say about customer relationship management than nuts and bolts.
October 26th, 2006 at 3:41 pm
“You could easily argue that the interface is a primary consideration.”
From an application, business, project, user and monetary sense, the most important factor is the data structure and process flow.
Interface is tertiary, secondary at best. The whole *point* of modern, mobile, agile apps is that assumption that each deliverable platform is enabled to have a custom interface. How I my message board looks over WAP is different than over HTTP. The underlying fundamentals of how it works and the business logic, however, don’t change.
Then there’s the products themselves. A project managment system without workflow? It talks about the beauty of web apps being versatile and you can access it from any machine, but then it ties into iCal. Utterly useless if you ARE making use of the ability to hotdesk. Why not just throw that functionality into the app?
And the more I read the blog the more and more I dislike the company and those who work for it.
‘OMG HAHAHA a non-final build of Vista fucks up when I install an unsupported app. Yet when I install a supported app on the Mac, it just works’
So glad these guys are on the ball … o_O?
It is chumps like this that give software developers a bad name.
October 26th, 2006 at 4:04 pm
There are a million applications out there that are of no use to me. I don’t suppose that they’re of no use to anybody.
I wouldn’t use the iCal support either, but if their developmental approach is to be believed, the users of their product asked for it in enough numbers to justify its inclusion.
As it is, they’ve made a niche for themselves by coming up with products that, evidently, *somebody* is using and liking very much.
I’ve tried Backpack out. I can’t say I use it on a regular basis (the things I used it for I do with Google Docs at the moment) but I do find their design ethic interesting.
October 26th, 2006 at 4:25 pm
“As it is, they’ve made a niche for themselves by coming up with products that, evidently, *somebody* is using and liking very much.”
That’s really ironic, given their hatred of Microsoft.
In both cases, yes they can develop apps people use. Doesn’t make them robust, agile or mean they are built on good development practices, as we’re only too well aware.
October 26th, 2006 at 4:34 pm
Well, no. People using the apps is not indicator of how well they were put together. They may be held together with string.
I suspect though, at least in the case of these guys, since they have a well regarded development framework out there, they must give some consideration to their development practises.
Please let’s not have a discussion about the merits/failings of Ruby on Rails. I don’t really know what a framework *is*, so I can’t hold up my end of an intelligent discussion about things like that.
I’d rather have a well used app, than one that’s a structural marvel and unused. As usual, a desirable reality occupies a space somewhere in the middle.
If anything gives the typical software developer a bad name, it’s a refusal to accept that. A discussion of just about any development tool or methodology always dengerates into a tedious argument where each developer just wants to demonstrate that they’re most clever of all.
When I read forum threads like that, I’m reminded of a remark by Captain Jack:
“You need to find yourself a girl, mate.”
October 26th, 2006 at 5:57 pm
“well regarded development framework out there”
What, like third post on the blog is ‘wtf? that’ll never work in any large environment’ and the man makes good points. Especially about how critical it is to nail the framework, as changes to the framework have dramatic implications on an application and other systems. Interface changes happen in moments.
Their products are well regarded, but by design/UI folks, no-one talks of their framework and even the inexperienced internal techs here were able to identify the flaws in an interface-centric design principle.
One only has to look at the comments to realise the audience aren’t dev-aware.
“where each developer just wants to demonstrate that they’re most clever of all.”
Some designers do the same. But no good dev will make an app that is unusable, in much the same way good designers compromise what they do to take in the client’s own ideas and tastes.
“I’d rather have a well used app, than one that’s a structural marvel and unused. As usual, a desirable reality occupies a space somewhere in the middle.”
That’s a terrible excuse and one that relies on the mistaken assumption the two are mutually exclusive. They aren’t an anyone who says they are really should think about a career dishing out fries instead of development.
Also, aspiring to any ‘middle ground’ smacks of mediocrity. The framework to an app is one of the most important aspects of an application as it dictates how easy it is to maintain and support. The actual development process is a fraction of an application’s lifespan and any responsible dev knows this and as such ensures it recieves the required level of attention and detail.
What this interface-centric design principle focuses on is meeting the minimum requirements and pushing the product out of the door, without consideration for meeting longer term needs or requirements (after all we don’t even know what they are given we’ve opted not to do all that hated documentation).
I don’t believe that’s a responsible software development approach, nor are 37signals a responsible company for advocating it as a means to market their own products.
October 26th, 2006 at 6:53 pm
I refer to middle ground in a debate of technicalities, when there usually lots of ways of doing something. I don’t mean aspiring to mediocrity.