-
"Unlike other video platforms, Panda is not just a service for encoding your videos for the web; Panda handles the whole process. From the upload form to streaming, Panda takes control." Open source, Merb-based video platform that anyone can use – runs on top of Amazon EC2, S3, and SimpleDB.
-
"These concepts are not complicated by Cern standards. We are entering a zone which is weaponised to boggle."
-
Simple, straightforward, pretty much correct.
-
Yes, this is going to come in handy.
-
"This javascript function can then read in the current content of the text area, format it using a trimmed down version of textile, and then set the content of a DIV with the resulting HTML. The end result of all this is live comment preview, with textile formatting." Live textile preview functionality.
-
"Trying to over-explain the cause of a disaster often detracts from its more tangible impact. … Instead, Faliszek says, it is more effective to create resonant gameplay experiences that players will remember, particularly if the setting in question, such as a zombie invasion (or a tornado outbreak, for that matter) is already familiar." Why games don't always need tangible villains.
-
A nice approach to doing some of the typical monitoring you'd want to do with Google Analytics, eg monitoring PDF downloads. I'm not totally convinced by some of his syntax, but the functionality is good, and the regex trick is nice.
-
"It's just an Nintendo in a toaster, but I like it."
-
"I don't begrudge Blow an attempt at addressing important historical events, but the weight of the atomic age seems too much to address with a few lines of text that feel incongruous with the rest of the production." This is, I think, a worthwhile point. I'll be returning to the whole "atomic bomb" question in a blogpost soon, I hope.
-
"Given that Valve is being forced to charge for the update, they wanted to ensure that 360 owners were getting their money's worth." Such a shame they have to charge for it – but still, more TF2 on 360, and that's a good thing from my perspective.
-
A nice simple explanation of what using Git is really like.
-
"What the hell is wrong with me? There are a lot of ways to win at Civilization Revolution that do not involve taking a happy, peaceful city and reducing it to a smoldering gravesite filled with radioactive trinitite." Clive Thompson on a case of Walter Mitty syndrome.
-
"Keldon Jones has published an artificial intelligence opponent for the game Blue Moon with an user interface written with GTK+ toolkit. This is a native Mac OS 10.5 version of the game written with Cocoa, so there's no need to install X11 and GTK+ libraries. It runs straight out of the box (on Leopard)." Heck yes.
-
"This is a write-up of my diploma project in interaction design from the Oslo School of Architecture and Design. The project is entitled ‘Adventures in Urban Computing’ and this weblog post contains a brief project description and a pdf of the diploma report." Well worth a read, and beautifully presented. I need to chew over this more.
-
"It's a shame to me that a game with Braid's narrative, artistic, and aesthetic aspirations is inaccessible to so many people hungry for exactly those things." Yes. Much as I adore it, Braid can be awful hard at times. A smart game for smart gamers, alas.
-
"A popular misconception about agile is that it doesn’t allow for plans. This isn’t true. Agile focuses on the activity of planning rather than focusing on a fixed plan."
-
WikkaWiki is a flexible, standards-compliant and lightweight wiki engine∞ written in PHP, which uses MySQL to store pages. Forked from WakkaWiki. Designed for speed, extensibility, and security. Released under the GPL license.
-
"The Morning After is a magazine-style theme for WordPress created by Arun Kale. The theme was created based on a brief survey on the WordPress forums about what people would want to see in a unique magazine-style theme." Looks great.
-
Now that's what I call a UI. Nice idea!
-
"Are you tired of browser-based games that are thinly veiled interfaces for databases? Finally, there's a game that just is a database!" This looks awesome.
-
"A simple pocket knife can be more appealing and usable than a bristling Victorinox, and a dedicated little games machine like the DS can engage us far more than the sleek power of the PSP. You can feel admiration and even awe for the big power boxes, but for the DS you feel affection – and that, in marketing terms, is worth a whole heap more." I love Stephen Fry.
-
"…for software developers, it's moronic. Your software isn't being released in theaters, it's available over the Web. You don't have to worry about the theater no longer showing after week one; you can keep pushing it for years, growing your userbase."
-
"The result of the workshop is Dear Lulu, a fantastic and imaginative resource that puts digital printing to the test through a Do-It-Yourself presentation." Testing digital printing by creating a book that's full of metrics and challenges.
-
"The application works by assuming a constant viewing angle (35-45 degrees), typical for when the device is placed on a tabletop. The 3d scene’s perspective is warped using anamorphosis…" Awesome.
-
"OmniDiskSweeper is a utility for quickly finding and deleting big, useless files and thus making space on your hard disks."
-
"Mockups feels like you are drawing, but it's digital, so you can tweak and rearrange controls easily, and the end result is much cleaner." Interesting-looking prototyping/wireframing tool.
-
"The Tinkering School offers an exploratory curriculum designed to help kids – ages 7 to 17 – learn how to build things. By providing a collaborative environment in which to explore basic and advanced building techniques and principles, we strive to create a school where we all learn by fooling around. All activities are hands-on, supervised, and at least partly improvisational." Sounds fantastic.
-
"What do we sing about, when we sing about the body?" Lovely infographic, ever-so mildly NSFW. Hint: hip-hop talks a lot about bottom.
A while back I mentioned that the iPhone App Store was a place where we could see people paying for interface alone, regardless of functionality.
This is a useful segue into Daniel Jalkut’s commentary on the nature of independent software development, and, specifically, whether small-software should be free-as-in-beer software. Jalkut makes the point, as an independent developer, that you should support the software you like, regardless of how slight it is. The example he refers to is Pukka, a nice little tool for posting to delicious from OSX. Pukka is nice because it’s always available and it’s very Mac-like in its behaviour. It’s pretty cheap at $12.95.
Jalkut takes exception to Leo Laporte’s commentary in a MacBreak Weekly podcast, where he suggests (as he tells us how much he loves Pukka) that it should be free.
Why did he suggest this? The answer, simply, is that Pukka is an interface to someone else’s functionality rather than a tool in its own right.
To wit: Pukka interfaces to delicious through the delicious API. Most of the hard work of social bookmarking has already been implemented by the delicious time. All Pukka does is talk to the API – it’s a menubar item, an interface, and a window that sends data to the API. Not a product on its own. Of course, if you know anything about development, you’ll know that building things that talk to APIs – on the desktop, on the web, wherever – isn’t always as easy as it sounds. $14.95 seems reasonably to pay for an app that does this well, especially if you use delicious as much as (eg) I do.
Jalkut’s own MarsEdit (which I’m using a licensed copy of to write this) is similar. It’s a $29.95 weblog editor, that interfaces with most popular blogs, and lets me write posts on my Mac desktop. It’s not that I couldn’t write blogposts before; I can always log into WordPress to do that. No, the reason I bought this is because of the convenience and quality. I rather like posting from this fluid, offline interface, rather than having to type into a box in Safari, for various reasons – the quality and speed of preview, the simplicity of media integration, and the multi-blog (and API) support – I use MarsEdit to post to both WordPress and LiveJournal. If I couldn’t spare $30, I could always just blog from the existing admin screens, but I felt the product was so good I should be it.
Sometimes, it’s hard to express to people the value of a product that does something you could already do. A product that does something new, or which is an essential tool, is much easier to justify. Many Mac owners I know didn’t hesitate to pay the €39 for TextMate, because text editing is so fundamental to our work. But $30 on a blogposting client? That one requires more thought, and isn’t such a no-brainer.
I’m not sure what the solution is. It’s a shame that it’s harder to express the value of “service” applications; I think the iPhone might have it better off here, simply because the device itself is so unlike traditional clients that it makes sense to redesign interfaces to services for it. In the meantime, it’s worth remembering that a quality interface to an existing product might still be worth something, however small, and it’s for that reason that developers like Jalkut should be rewarded for their work.
Jens Alfke writes about the beauty of the $0.99 iPhone Application. I think he makes a reasonable point: when somebody else is taking care of a lot of the overheads of both distribution and payment processing, there are no compelling negatives to developing micro-priced software applications.
You find where download mp3 music on player, You need mp3 music download from online mp3 archive
What kind of application are you going to sell for $0.99? It doesn’t seem like a lot of revenue for something that you might call “useful” – but I don’t think there’s a lasting market for one-dollar “toy” applications.
I think the interesting market that becomes opened when you apply this kind of thinking to a particular platform – namely, the iPhone/Touch interface – is one of selling interface.
A good way of explaining this is with a currency or unit converter application (bear with me).
As it stands, if you want to convert from, say, imperial weight to metric, you can just fire up the iPhone’s built in Calculator application and bang out some arithmetic – as long as you can remember the conversion ratio.
If you don’t know the conversion ratio, you can go online – for free, because you’ve got an airtime contract, or pervasive wifi – and look it up, perhaps even finding a nifty Javascript conversion tool. But that’s a long way round for such a simple task.
Or, I can sell you my $2 weights-and-measures converter. It doesn’t do anything fancy, because we’ve already established that the maths isn’t beyond any potential iPhone user. So the single thing I can sell you on – and the single reason you’d buy my app over the long way around described above – is because of its interface. How easy is it to use? How satisfying? Does it simply a complex task?
The iPhone exposes “interface” as an obvious criteria for purchasing things. Because the interface is so hands-on, so direct, users can easily spot when an interface stinks, or when it’s as easy to use as Apple’s own applications. Given that: let’s make an application where the interface is the primary feature, and the functionality is essentially trivial.
Here’s what my hypothetical weights-and-measures conversion application might look like. You choose what you want to convert to and from via a pair of drop-down boxes at the top of the screen. The drop-down highlights which things on the right-hand side are similar types of measurement to those on the left – so that when you select “metres” on the left-hand side, the units of length on the right-hand side are highlighted. And then, underneath, are two vertical, gradated rules – much like on a slide rule. Above them is the exact value readout; at the centre of the screen is a red marker line. You flick one “ruler” up and down with your thumb, and the other moves in accordance to display the converted value. You can then read exact values out at the top of the screen. If you want to slide horizontally, tip the phone on its side and the accelerometer will tell the software to rotate the screen.
The really neat thing isn’t the conversion at all – it’s just two big rules that you can flick about with your finger. But when you’re out shopping and have only got one hand free, maybe that’s exactly the interface you need. The app is a basic, trivial task, that’s enlivened by a useful interface.
Now, obviously I can’t charge you $10 for this. If I asked for $10, most people would either keep guesstimating weight when they go out shopping, or just use the calculator like they’ve always done. But for $2… it becomes much more of an impulse purchase. You’re not purchasing functionality; you’ve got that already. Instead, you’re putting down $2 for the interface I’ve built.
I’m not saying that interface alone isn’t worth a lot, or that it’s worth $2. Far from it. But taking a task that the user could already do and designing an appropriate, specific interface for it, that makes it pleasurable and immediate to use – that’s worth more than nothing. $1, $2 – as long as it’s less than a coffee, but more than nothing, that’s fine. That’s a business model. Not a complete one, or one to base an entire company off, but a business model nontheless.
The iPhone and iPod touch are devices that thrust their interface and interactions front and foremost. They’ve established within a market full of – in places – terrible interaction design, that it’s OK to pay a premium for devices that work well. People who’ve bought an iPhone or an iPod Touch have already made that premium decision. The iPhone Application Store tells us that it’s OK to pay a smaller sum for software that works well. It doesn’t matter that it’s not premium software, or that the software isn’t sophisticated; what matters is that we’re make money from genuine interaction design, rather than a list of features. That feels like another tiny watershed moment.
The hellish state of PHP frameworks
15 May 2007
As you probably know, when it comes to code (both in and out of work) I’m a Ruby and Rails guy. It’s not necessary to go into much detail “why”: the expressiveness of Ruby and the dynamism and speed of development in Rails are big wins for me.
But it’s not always possible – or practical – to knock out Rails applications for every task, and right now, I need to deploy something in PHP. Something very simple, that doesn’t warrant the deployment overheads of Rails (which we’re all aware of, right?)
Refusing to get caught up in WordPress if at all possible (not going into that again, either), I set out to look for a nice, well-documented, lightweight PHP web framework.
Continue reading this post…
The latency of software development, pre- and post-launch.
23 February 2007
In a recent post about offshoring development work, Ryan Carson explains that the way you know when you’ve outgrown a freelance developer is this:
Getting bugs fixed and new features implemented starts taking fricken’ forever.
There’s some interesting discussion on the post – about eastern-European wage rates, about freelancing, etcetera – but there was one elephant in the room that nobody really mentioned, and I really think it’s necessary. And that’s this:
once your application is live, everything will take longer.
Whilst you’re in the build process, you can turn on a dime; you can commit new code at a moment’s notice, change the direction of the codebase or even the application, churn out features at a remarkable rate. And, when something doesn’t work (despite having passed the test suite… which you do have, right?), you patch it and move on. It’s a doozy.
Once you’re live, everything changes. You’ve got an active audience using the site – you might even have paying customers. You can’t afford for a single thing to go wrong. New features are no longer about build it, run the tests, check it in, deploy. Your testing on the development box has to be more fastidious. The integration between new functionality and the existing needs to be really well thought through. The design needs to be seamless with that which exists already. And, if it goes live and there’s still one of those totally unforseen bugs… you need to be ready to roll back at a moment’s notice, and put the feature on hold until it’s ready.
This is not new. Some teams are lucky enough to make many deploys daily; most can muster up daily fixes; some might go to weekly. But the effort that a feature requires post-launch is far more than it does pre-launch.
So it’s inevitable – freelancers or no – that the pace of development is going to fall off a bit post-launch. Hopefully, only a bit – but it’s not going to be the same rate unless you’re extremely lucky. You’ve also got to keep your users in mind, and break them into new functionality slowly.
It’s a hard transition, going from the development site to live. To you, as an owner, a developer, it feels like the same product – so the change in pace is a bit frustrating. And it’s important to keep the pace as fast as possible. Some fixes are critical, and need to go out the door the instant they’re done; others can wait a little longer – a day or two, if necessary – for release. It’s a rare, focused, hugely talented team that can splurge out new features like a machinegun.
Now, I’m sure that the problem is compounded by avoiding maintenance contracts (and so having to re-contract and re-hire) and having developers whose time is precious. But it’s always important to bear in mind that the latency of any web software development shoots up post-launch. So if it does: don’t immediately reach for the outsource button. Take stock, have some patience, and see what the product needs – how often it needs to be released, how often it needs to be improved. And then you can make that call a little better informed.
The other golden rule, incidentally, is never deploy on Friday. I hope the reasoning behind that is obvious.