As Ryan tweeted, this really is “condensed years of blog posts and project experiences into a 30-minute talk.”
So. Good.
What if we designed a new kind of “maker space” — a space that isn’t just for putting pieces together, but also for seeing and understanding a project’s behavior in powerful ways? — Bret Victor
Ryan Singer sums it up nicely. Some points I particularly liked:
The reason I am making a product is to give people capability they lack. That’s why they pay for it. The gap between the person’s current situation and the situation they want to be in defines value for them. They hire your product to do a job. The job is their definition of progress from here to there.
Some people think patterns are formal things written in a book or collection, but they aren’t like that. They are natural and spontaneous just like spoken language. We learn a language by hearing it and speaking it. Words, phrases, and constructions come to mind as if by magic.
This works against you when your work isn’t goal-directed. R&D projects and exploratory design don’t benefit from narrow problem definition. Platform and infrastructure projects are different in kind from product projects because the platform is meant to enable products on top of it, which are themselves targeted at specific situations.
I wanted to share five paragraphs of customer support conversation I’ve had with the rest of the team (two other guys). As I’ve IMed with one of the guys few minutes ago, I automatically went for the IM window. But first thing that stopped me was I remembered that sometimes the IM does not send longer messages. So I am thinking: “OK, there has to be some better way.”
Then it clicked: “Oh, wait, this is the sort of thing we have Basecamp account for!” And that led me to realizing one obvious disadvantage of abstract software.
Continue reading
Jason Fried writing for the Inc.
You don’t have to analyze the bottle like I just did to understand that it is well designed. You know it, because you can see the bottle, feel it, and use all of its features immediately. You can see where it starts and ends. It is not complicated. It is in balance with its purpose. Imagine a bottle without a spout or a bottle that was burning hot or a bottle that was as slippery as ice. Every reasonable person would know that wouldn’t work.Contrast that with software. What are the criteria for evaluating software? Software doesn’t have mass. It doesn’t have shape. It doesn’t cast shadows. It has no edges. It has no size. You can’t pick it up. You can’t feel it. It doesn’t obey the laws of physics. It’s not really even there. Nothing is pushing back, saying, “That’s a bad idea; that won’t work; that’s going to burn someone or hurt someone or make someone drop it or…” Almost none of the tools we’ve developed to evaluate physical objects apply to software.
This is why most software goes bad over time.
I can still remember some of those early meetings, with 3 or 4 of us in a locked room somewhere on Apple campus, with a lot of whiteboards, talking about what iMovie should be (and should not be). It was as pure as pure gets, in terms of building software. Steve would draw a quick vision on the whiteboard, we’d go work on it for a while, bring it back, find out the ways in which it sucked, and we’d iterate, again and again and again. That’s how it always went. Iteration. It’s the key to design, really. Just keep improving it until you have to ship it.
[…]
One of the things about designing products that can come up is Ego, or Being Right, or whatever that is called. I’m not sure how this evolved, but when I worked with Steve on product design, there was kind of an approach we took, unconsciously, which I characterize in my mind as a “cauldron”. There might be 3 or 4 or even 10 of us in the room, looking at, say, an iteration of iPhoto. Ideas would come forth, suggestions, observations, whatever. We would “throw them into the cauldron”, and stir it, and soon nobody remembered exactly whose ideas were which. This let us make a great soup, a great potion, without worrying about who had what idea. This was critically important, in retrospect, to decouple the CEO from the ideas.
Via @daringfireball
Article worth reading by Rob Banagale.
Positioning your HTML5 mobile web developer as the primary domestique (flanked by UX design and UI design) is the best way to cut through the “wind resistance” of developing for multiple mobile platforms.
As much as engineers like to joke about our counterparts in sales and marketing, the most successful sales and marketers think like engineers.
…
That’s when I realized – it’s not just that developers don’t see themselves as potentially amazing marketers. They might not even realize how deep and interesting of a field marketing is.
— Tal Raviv writes on his Customers over code blog
Mr. Matteo Spinelli created nice add-to-home-screen script that may be useful to you if you have a mobile web app and want to let your users know, they could add it to their home screens.
That then allows your app to look like native app from their point of view.
The application cache manifest (ACM) offers developers a way to make their apps work offline, reduce bandwidth consumption, and load pages much faster. Local storage and WebSQL databases are also great ways to cache data on the client side, and this post will talk about the pros and cons of using each.