Josh Sharp design

Thoughts on Android and the HTC Dream

Mon, 27 Apr 2009 11:53 +1000

I recently signed up as to the Android Market as a developer so I could buy a "Google Dev Phone 1" which is an unlocked HTC Dream/G1. I've been interested in Android as an open-source competitor to the iPhone for a while, and given that the Dream has officially launched in Australia, and Australian developers are now able to submit (free only) apps to the Market, I thought I'd get a device to evaluate and maybe hack some apps on.

I'm quite interested in Palm's Pre OS too so I hope I don't end up with a Pre as well, "just to play with" :\

Hardware

When the G1 was first announced I was very underwhelmed. It looked decidedly average. I maintained this opinion for a long time until I had a play with one in person a little while back. It's actually not a bad device. It fits comfortably in your hand (at least when held vertically) and though it's a bit bulky the rubberised finish is nice to hold. Specs-wise it has all the nice things - wifi, GPS, compass, QWERTY keyboard and of course a touch screen.

Unfortunately though after actually using one for even a little while it becomes clear that it's definitely a developer phone, a reference implementation. The battery life is fairly poor. The "chin" of the device gets in the way when using the keyboard and makes typing harder than it should be. It's been around a week since I got mine and already I can feel a bit of travel between the front half (the screen) and the rest of the device, which is especially annoying when touching the screen. The clicks and scrapes are not something that I should be hearing from a week-old phone.

Also, I'm not sure about Android's hardware button spec, which requires a "menu" button in addition to call, end, home and back buttons. I still maintain that on-screen soft keys or some other on-screen input would make more sense. Moving from the touch screen to the menu button so frequently doesn't feel right to me. Having said that, I couldn't propose anything resoundingly better off the top of my head, so maybe it's just something that's tough to get right. It's unfortunate though that as long as Google want to maintain backwards-compatibility, they're stuck requiring and supporting these hardware keys. I'd much rather see a move towards an iPhone-like interface where options are presented on-screen as required.

Another hardware niggle is switching from portrait to landscape to enter data - this is my first "side-slide" QWERTY phone so maybe it's a common issue - but it is quite jarring having to flip, open, wait for the UI to catch up, and when done close the keyboard and switch back. The upcoming Android release will introduce a virtual keyboard that negates this issue somewhat, but in the future I'd much rather a candybar form factor (like my SE M600i, which was candybar QWERTY. I'd love to hack that to run Android). Again, this is possibly personal preference, but it does make the experience jarring and interrupts flow.

The dithering on the screen also annoys me, but the screen itself can be seen easily from almost every angle, so maybe that was a fair tradeoff.

The UI

It boils down to this: just not as good. You know what I'm talking about. It's like GNOME or KDE versus Windows (let's leave OS X out of this one) - the fonts aren't quite right, things just aren't pixel perfect. That's how Android feels. Screen items feel like they take up more space than they need to (although bizarrely they're harder to press than on an iPhone). Input items like textboxes and checkboxes just lack... something. Certain subtleties are missed. It's not bad, and definitely not anywhere near Windows Mobile, but it does have a lot of catching up to do.

I think what it boils down to is that Android and the iPhone appeal to different markets, satisfy different needs. It's PC vs Mac all over again. Android's aim is to be ubiquitous, lowest-common-denominator stuff. The iPhone OS is designed lovingly, to great detail, for one device only. Observe their differences:

Because Android is in its infancy, it really does just feel like a call-out to geeks at the moment, both in the hardware and the software. The functionality is higher, it does some 'cooler' stuff, but it just doesn't look as pretty. I guess Google figure that the polish can come later, once they've gathered a following of developers and a large enough platform of devices.

However, there are good things. The home screen that in the next release will be able to display widgets (other than the built in clock and Google search) will be more immediately useful than the iPhone home screen, and its shortcuts allows you to separate commonly used apps from the full menu of the rest. It's a shame you can't arrange those menu items, though, because I'd love to be able to order them according to most used/useful rather than alphabetically.

I'm really struggling to think of other nifty UI innovations. Everything here fits into the "almost-iPhone" category, and that's just not worth writing about. Scrolling isn't as fluid either but it's hard to say whether that's software or hardware related.

Programming and cool stuff

Android apps are written in Java and run on Dalvik, a modified J2ME VM. Each app has its own VM which can be paused or pushed onto the history stack. This appeals much more to me, coming from a Java background, than the lower-level syntax-oddities of Objective-C.

The API is reasonably thorough and there seems to be a lot of support, tutorials, and code examples out there which should make the app-writing process easier. Having said that, there a few deficiencies I discovered straight off, like no way to write straight to the audio output buffer, thus limiting you to playing pre-generated sounds. This sort of thing is technically possible, of course, just not part of the API, meaning it should be added in eventually. Still, it shows that there are still rough edges on the whole package.

The cool stuff is really the integration with the OS, things the iPhone can't do yet. Notifications are a nifty example of this. Any app can create a background process and provide notifications of new events - for example, the Twitter client Twitdroid can keep running even after it's been "closed" and notify you when there are new tweets in your timeline. Any app can take advantage of this and it makes things like GPS tracking much more useful - turn on the tracker and then forget about it, go back to doing something else.

The other nifty thing is "intents" - basically certain system activities that other apps can view and act on. Apps can be "intent receivers" and be notified of things like new SMSes, etc. as they occur. Also they can register themselves as handlers of a specific intent. This means if you need to browse your photo gallery from one app (say, adding a pic to a tweet) you can choose from any number of apps that say they support that intent, which once you've picked a photo, then gracefully deliver you back to the main app issuing the request. Things like SMS inbox, email, music, all can be handled by third-party apps as long as they have the appropriate interface for that intent.

That's pretty cool.

Android Market

Not much to see here. At the moment Australia only supports free apps, so I can't remark on the quality of paid apps, but the free ones I've played with are fairly average, especially games. There are very few games (in fact, only two I can think of) with that high sheen of quality you see on the average iPhone game. I can only assume this will get better over time but at the moment it's almost an embarrassment.

Speaking of no paid app access, it'd be nice if Google just announced paid app support for all countries in which the device has officially launched. Lord knows they're big enough to have the capacity to coordinate it.

The future

Everyone knows it, but it needs to be said again: Android just doesn't come close to the iPhone as an overall experience. Every point I have covered above subtly or not-so-subtly drives this home.

Android has a long, long way to go. Fortunately it seems development of the OS is still going ahead solidly and I imagine most of the deficiencies I've addressed here will be resolved in time. What's really cool to me is Google's goal of making it the de-facto "device" operating system. Android is going to be powering the 17" touch-screen in the new Tesla Model S, and hopefully that's just the beginning - I think Android has a solid foundation that will make it work well as a device OS in all sorts of places. We might be well on the way to a "unified computing experience" across all our computers and devices, rather than the fragmented experience we currently have. And when that happens, people will hopefully be playing my ridiculously addictive Android games anywhere they go, and paying for the privilege ;)

Announcing Twitterscribe: archive your tweets

Thu, 26 Feb 2009 05:28 +1000

Update: Twitterscribe is now public. Anyone can sign up, so why not give it a go?

One of my resolutions this year was to deliver more of my side projects. Currently a lot of them are half-formed, either in idea or in function, and I wanted to change that by attempting to actually finish and make available whatever I start. So it is with a certain amount of glee that I announce my latest effort, Twitterscribe.

Twitterscribe is a pretty damn basic service: It archives what you tweet. That's it. Born from a tweet by Warlach, I thought it would be a great idea to give people the facility to save and output their tweets to CSV, so they have their own copy they can save/analyse/whatever. Brad Kellett has a similar utility, but it doesn't currently appear to be working. Also, Twitterscribe was built to overcome another flaw of Twitter's - the inability to go back in time past a certain point. Brad's tool output as much as it could, but couldn't go past Twitter's prescribed limit. Twitterscribe aims to circumvent this by archiving your tweets every day, so that in the future you will have a copy of things that Twitter officially can no longer show you.

Currently Twitterscribe has the bare minimum of functionality: you sign up, it archives your tweets every night, and whenever you like you can login and export a CSV file of what's stored.

So what's next?

There are a few different places to go with the service once reasonable archives have been built up:

Stats: Create some nifty stats tracking things like happiness over time, frequency of other things over time, etc. However a lot of Twitter stats sites exist already.
Search: Allow users to search back through their tweets by date or other criteria. This could potentially be useful.
More output: This is my favourite idea - let users create some pretty output from their tweets. I would love to be able to provide the facility for a user to order a custom printed book, like a journal of their tweets. It would be great to look back in a few years and know what you were doing and thinking about at a particular time.

I hope to work towards getting some more of this functionality happening, barring any big bugs appearing in the private beta.

Let me know if you have any other thoughts on functionality you'd like to see.

Adventures in PHP interfaces

Thu, 01 Jan 2009 10:58 +1000

So recently I've been having a play with Python. I like it a lot, and it's started to affect how I code in PHP - all of my freelance work still uses PHP, so it's still my 'primary' coding language. However, this means that all the little things I can do faster in Python come back to haunt me in PHP. It was bound to happen. Unfortunately, though, I can't just switch all my work to Python (and it has a number of shortcomings that make it harder to support, anyway) so to resolve this I've been attempting to replicate, in my PHP framework Rex, some of the things which in Python make my life easier.

The first of these is the syntactic sugar of SQLAlchemy's (and AppEngine's, Django's, and others) data selection syntax. With some nifty method chaining, SQL queries can be abstracted to such pretty code (yes, in PHP) as $user = User->all()->filter('Admin = 0')->order('FirstName','ASC')->go()->get(0);. I might follow up this post with another explaining how to achieve this method chaining, and it's really quite easy, but in the meantime I want to draw your attention to something else.

Scrutinise the line of code above for a moment. The very last function call is get(0), which will return the first index in the results array. Hold on, an array? That's right. Usually to get an array of rows back, there is a two-stage process in accessing the first index:

$results = $User->someMethodReturningUsers();
$user = $results[0];

It always really bothered me that you couldn't just chain an array index to the end, like $user = $User->someMethodReturningUsers()[0]; which is perfectly acceptable in a lot of other dynamic languages. But, aha! That's what we're about to solve.

ArrayAccess, Countable, and Iterator interfaces

As of PHP 5, the SPL has some very interesting (and largely obscure) classes and interfaces hidden away. The three I've listed here allow any class that implements them to act as an array.

Why would you want to do this? Well, for example, let's say that your random someMethodReturningUsers() now returns your own class AwesomeArray. Does the end-user need to know that? Not really. If they like, they can continue on oblivious and execute our two-step plan above. Everything's peachy. But, but... you now know better. Because AwesomeArray not only implements those array-like interfaces, it has a get() method that takes an integer and returns that array index.

Bam! Your process now looks like $user = $User->someMethodReturningUsers()->get(0);. But that's not all, you get the best of both worlds. You can have you cake and eat it too, because as well as chaining methods as shown, you can still use the AwesomeArray returned as you would a regular array. Iterate over it using foreach() (that's what the Iterator interface handles), access its indexes (ArrayAccess), and check its length via count() (Countable).

I'm not sure that this is a perfect solution (there may be array methods like array_unique that just don't work) but when used in conjunction with some sugary syntactic goodness, it really is the cherry on top, the finishing touch.

I've included the code below so you can roll your own. Enjoy!

class Result implements ArrayAccess, Countable, Iterator {

	private $position = 0;
	private $data = array();
	
	public function offsetSet($offset, $value) {
		
		if ($offset == ''){
			$this->data[] = $value;
		} else {
			$this->data[$offset] = $value;
		}
	}
	public function offsetExists($offset) {
		
		return isset($this->data[$offset]);
	}
	public function offsetUnset($offset) {
		
		unset($this->data[$offset]);
	}
	public function offsetGet($offset) {
		
		return $this->data[$offset];		
	}
	
	public function get($index){
		return $this->data[$index];
	}
	
	public function count(){
		return count($this->data);
	}
	
	public function rewind(){
		reset($this->data);
	}
	
	public function current(){
		return current($this->data);
	}
	
	public function key(){
		return key($this->data);
	}
	
	public function next(){
		return next($this->data);
	}
	
	public function valid(){
		return $this->current() !== false;
	}
	
	public function size(){
		return count($this->data);
	}

}

How do you mockup websites?

Fri, 17 Oct 2008 11:38 +1000

I've been hunting for a new tool to help me mockup sites lately. I use Photoshop, but it's not quite right. It helps me lay things out quite nicely, and it doesn't bother me at all that it doesn't produce code - it's more about creating an image as close as possible to what I could replicate using HTML and CSS.

And that's actually where it falls over. Photoshop does many things, bless its bloated heart, but it doesn't support CSS styles. And why should it? It's not a website-mocking-up tool really. But it does become a pain if I want to set individual border styles, or test a repeating background image, or any of these things that are better described in code.

So in my search for something better I recently asked my faithful tweeps what they used. I got a couple of common answers: Photoshop, Illustrator/Fireworks, and "I code it all by hand." Personally I think coding it first when you haven't decided on what it'll look like is a bit silly, but that's just me. I think visually, or something.

But nobody enlightened me about the existence of the product I have in mind: an app that exists only to mockup websites.

The app I have in mind would probably be built on a web browser base: WebKit, I guess, as the consensus seems to be that the Mozilla codebase is too heavy these days. It would let you draw elements straight onto the canvas, and probably make these to absolutely positioned initially. It'd have a Photoshop-ish interface allowing you to create layers and to easily modify any of the CSS properties a la Blending Options. Want to see what a 3px border on the bottom of that header would look like? No problem, you can specify that independently without hacks. I imagine too that some sort of visual highlighting system would make it easy to draw elements within other elements (rather than just sitting absolutely on top), making more advanced CSS rules possible.

And here's the kicker: when you were happy with how the site looked visually you could tweak positioning and then export it all to HTML and CSS, because that's what it would already be. Wouldn't that be nifty? Obviously nothing beats hand-tweaked code, but it'd be better than my current workflow of slicing and recreating my Photoshop image from scratch in code.

The only departure from a visual-code-mockup focus would probably be the addition of basic image tools - an easy way to import images from Photoshop, or a basic gradient generator.

So, how does that sound? Personally I'd love to have something like what I've described, and I'd probably even pay a reasonable amount for it. But I don't really have time to create it myself - would anybody else like to? I wouldn't mind some royalties if you do...

Does that sound like something you'd use? Or do you already use something similar? Let me know in the comments.

Something's not right with Android's UI

Thu, 09 Oct 2008 12:15 +1000

I've mentioned previously that I'm really excited about Android. Well, since the launch of the G1 phone, SDK 1.0, and now that its release is due very soon, I've changed my mind somewhat.

My feelings on the essential Android concept remain unchanged: I think it's a brilliant idea. A free, open mobile OS, unburdened by mobile operators' notions of what is appropriate, and with the ability to easily add and replace apps on the fly.

However, the Android concept and the final Android experience are two different things. Playing with the emulator and watching the UI walkthrough have made me uncomfortable. It's mostly a solid, functional UI, with some nice animations thrown in to spice it up a bit; certainly no worse than anything else on the market at the moment that doesn't start with a lowercase i. But I have some usability concerns.

I'm sure it's hard to visually design an OS that's device-agnostic. It has to support touch-screens, qwerty keyboards, standard numbers-and-soft-keys setups; if you believe Andy Rubin's aspirations, it also has to support not only phones but set-top boxes, fridges, car dashboards, and lord knows what else. So I guess that makes it tricky. I certainly wouldn't deny that.

And for the most part it seems like the developers have accommodated these different form factors and input methods admirably. You can almost comfortably only use the touchscreen, or only use the keys. Except for one thing: that bloody menu key.

I happen to own a competing hybrid touch-screen/qwerty phone. Take a look at it:

What do you see that Android has completely forgotten?

Full points if you guessed soft keys. Well, not physically, but along the bottom of the screen. Common actions are arranged along the bottom of the screen, in every app, so that for most actions I can do what I need to without ever needing to open a menu or move my finger from the touch screen. If I do need to access the menu, it's there on the right under 'more'. But for the things I do every day, I don't have to look or move away from the screen.

Almost every phone* takes this soft-key concept, and it's easy to see why: it makes common actions easier. Popup menus should be avoided because they add an extra action every time you want to do something, but also because they make it hard to know what options are available. On the G1, whenever I want to actually do anything, it'll be: scroll with finger. Select item. Press menu. Select option. Make changes. Press menu. Select save. Is there a pattern emerging here? The joy of using a touch-screen device is quickly going to be lessened by the annoyance of this repeated, unnecessary action.

I imagine it'll be even worse on a traditional numbers-and-soft-keys phone, as finger presses will become repeated direction-pad presses: Menu. Right. Right. OK. Down. Menu. Right. Right...

I'm not sure why this oversight has been made; obviously it's not the end of the world, but give it a few months and new owners of G1s will be making their annoyance known. It's probably also something a firmware update could fix quite easily, without any action on the part of app makers (take the first two menu options, put them on the first two soft keys, add a menu soft key to the right). But it just seems strange to me that Google's plan is for Android to be the standard device OS, whatever that device may be, but they've made touch-screen interfaces a pain, and non-touch-screens even worse.

(*Interestingly, the iPhone doesn't use this concept, but it does make actions available on the screen without any involvement from physical buttons.)

Update: Added a picture below that demonstates what I mean, for clarity. Doesn't that look immediately more useful?

My lance is free

Mon, 06 Oct 2008 06:21 +1000

It's been a while, folks.

Just over a month ago now I waved goodbye to my previous job; to steady pay, job security, and working with some close friends. I gave it up for the chance to do my own thing. I liked my job, but was becoming increasingly bored and disillusioned with the work. What had begun as a chance to develop new applications from the ground up, to really be involved in not only the implementation but the core ideas behind the app's functionality (which is something I really love to do) had devolved into a cycle of "Hear from existing client -> Make arbitrary changes for client, often hacking apart code into a steaming mess -> Release -> Repeat."

But I'm not here to criticise my previous job, which really did teach me a lot and let me make a lot of great software without being overly constrained. The main thing I am here to tell you is this: freelancing rocks*.

Good things

My lifestyle has changed completely. No longer do I have to be up and out of bed in time for the morning commute. My hours aren't constrained by normal business hours, either. I usually get up around 9am and by 10, I'm ready to go. Sometimes I work past dinner, sometimes I take the afternoon off early. If there's something else I want to do or somewhere I need to be, I'm there, no hassles. As long as I'm getting my work done, I can keep whatever hours I like.

I cannot overstate how wonderful this is. My stress levels are down considerably. I get to spend more time with my girlfriend, and I get outside more. I'm saving money on petrol, parking and food (I used to buy lunch every day). I read much more, and have more time (and more inclination, as I'm less tired at the end of the day) to work on my own projects. Basically: I'm in control now.

Also, I charge more than double what I was paid as an employee. If I can keep work consistent, I'll be earning more than double as well. If not, well, it means I only have to work every second month to maintain my previous lifestyle.

Not as good things

I'm certainly not an extrovert, so working from home, alone, day after day, hasn't bothered me in the slightest. It may eventually, but for now Twitter does an adequate job of keeping me company.

However, it does mean that I don't have people around to talk things through with, or to help me if I get stuck. You know those stupid, basic bugs you write when you're not really thinking, and try as you might you just can't see them in your code without walking away and coming back later? Yep, they're more of a pain when you've only got yourself to help. Thankfully that doesn't happen too often though.

Also, I quit my job having about two months worth of living expenses saved - and it wouldn't have worked if I hadn't, because I'm most definitely living off them. The change from fortnightly-pay-cycle to not-having-been-paid-for-my-invoice-yet was abrupt and a bit of a shock. I know that I have invoices due and I will be getting paid, but I'm reluctant to spend money as freely as I did as an employee until I can see that money.

Obviously the lack of job security is also a related issue - thankfully I've fallen into another contract after my first finishes, but I'm going to have to make a lot more effort now to maintain my income, as opposed to knowing there will always be work for me as an employee.

Still, none of these came as a surprise, and nor should they; that's just how it goes.

What's next?

It's still early days yet, and I'm happy to keep going as I am for a while: taking on small jobs that I can do on my own, working from home, and enjoying the change of scenery. However, the long term plan is to do a 37signals if I can - use the freelancing income to pay for development of some products, hire an employee or two, and grow the income from the products until it's the main revenue stream, and I have a healthy little business going. I have some product ideas that are aimed at businesses, and of a sensible scale, so I'll be trying to get them started as soon as I can. I'd rather run it more like a small business than a startup though (ie. making money from day one, no outside funding), but the end-goal aspirations are largely the same.

I'm always happy to hear from interested parties, by the way, because having a co-founder/business partner would definitely be beneficial.

Anyway, I hope to blog again much more frequently, so I'll let you all know how that turns out.

(* so far.)

A short story about usability

Sun, 18 May 2008 04:39 +1000

I've recently moved house, and last weekend I went for my second grocery shop at Safeway, my new local supermarket. This Safeway has recently installed a new set of 'self checkouts' which allow you to scan, bag, and pay for your own shopping, without a checkout operator involved.

This was the second time I'd used the system, and the first time had passed without incident - it was even a little bit novel, a tiny bit fun to scan my own items and bag them myself. But the second time was different.

This time, I had more than one bagful of items. As I finished filling the first bag, I went to take it off the scales - the bags are weighed to make sure you don't slip anything extra in - and the POS system beeped at me. "Please replace item such-and-such," it asked me.

So I put the bag back down. "Please replace the item," it asked me again, tonelessly. So I removed the bag and put just the item in question (a packet of biscuits) back onto the scales. But no luck, the system simply refused to allow me to proceed. It wouldn't recognise that I'd put the biscuits and/or bag back onto the scales, no matter what I did.

Growing increasingly frustrated, and with a growing line of people waiting too (installing self checkouts allows Safeway to cut down on the number of express checkouts open) I signalled to one of the brightly-vested 'experts' hovering nearby. I explained the situation, and he whipped out a PDA and tapped out a command to allow the POS system to continue.

"Out of curiosity," I asked him, "what did I do wrong? Just so I know for next time."

His voice was curt as he replied, "You can't remove a bag until the big dollar sign is flashing."

Obviously.

My experience with the system illustrates perfectly how not to design with usability in mind. Members of the public will be using the self checkouts without any training, and even as I used one I could see other people getting frustrated with their experience as well. If you are dealing with an untrained userbase, things should be as obvious as possible. There should be very little room for mis-interpretation.

Adding a flashing dollar sign (next to a button marked 'finish and pay', not what I wanted to do) is far from a simple and obvious way to tell users, "it's okay to start packing a new bag now".

Twitter as social computer

Sun, 20 Apr 2008 11:09 +1000

Twitter is a funny little thing. It's one of those services that has been pared back to its most basic, essential ingredients - asynchronous chat/messaging. Or is it microblogging? Or lifestreaming? Whatever you'd like to call it, it provides the one service, and that's it. No file sharing. No 'social network' (well explicitly, anyway).

It actually sounded incredibly banal to me when I first heard of it. It seemed far too basic to be interesting, and once I did get into it, I found that it didn't really provide me with much. But as noted by Scoble, the service's value is in its users. Once I started adding people to follow, I started to get addicted. It gives you an insight into people that you don't get reading their blog posts, and an added benefit of finding out about news as it happens.

But the way in which Twitter lets people interact has provided other interesting developments as well.

Social searching

You might have heard the prediction that web3.0 is going to be about the semantic web - "understanding" and giving meaning to content, providing for a better search and better ways to relate data to people and to other data. This is all well and good, but the technology to add this layer of meaning isn't quite ready yet.

In the meantime, the best way of understanding a query and providing the right content is to ask a real human (not that ChaCha, who tried to provide human-assisted search as a service, got far with this). But still, the keepers of the semantic meaning are ourselves, humans. We are only trying to teach the system what we already grasp.

And this is where a very interesting property of Twitter comes into play. With an always-on pool of friends only a message away, suddenly Twitter is your own social computer. Tweet a question, say, "does anyone know which team won the footy tonight" or even "where should I stay in Sydney?", and if your social computer has "indexed" this data already, odds are you'll get a good answer. Try asking Google one of those questions and you won't get anywhere near what you wanted.

Now obviously the results aren't as formal as if you had queried a search engine, went to a news site or browsed a site which recommended hotels. They might not be quite what you are after either. But the humans on the other end can understand your question far more accurately than a search engine can, and with an added benefit of trust and authority - a recommendation from a real person carries far more weight, which is why word-of-mouth is such a valuable marketing tool.

Bringing back the command line?

Another interesting feature is the use of hashtags and @replies to give control and meaning through what is essentially a command-line interface. Replying to someone means putting an @ symbol and their username at the start of your tweet - a modifier built right into the command line, with no other way to do it. Putting a hash before a word (usually a noun) makes it into a tag that can be referenced across tweets, giving it some semantic meaning. These are two ways that the textual data provides control as well as content, which is the main feature of a command-line system.

But when you also add twitterbots to the mix, you start to see the sort of power Twitter's basic input/output system has. If you tweet @weather Melbourne, you'll get a weather report - just like calling a command line executable and passing it an argument. Twitter's system is ideal for this - as a basic IO system, it takes in a small set of data, and provides a response. That sounds limited, but it has so many varied functions that have only been half-realised yet. Of course, there is always the command line, Google, or some other GUI which can provide you with the same data, but I'm sure we'll see a benefit to having this data included as part of our attention stream.

An interesting ecosystem

It's funny what you can do with such a simple system. I guess when you create an open API that allows people to build bots, clients, and other ways to analyse the data, there's actually a lot to it. And I think this is only the start of the sort of clever social systems and lifestreaming services we're going to see (forget basic social networks, they're so last year). But maybe whoever said it was right - web3.0 really will just be about cutting out all the noise, so that we can hear the signal again.

techAU troubles - techAU.tv complains, new domain is born

Thu, 03 Apr 2008 07:18 +1000

When I came up with the domain name techAU, it wasn't already taken - but it wasn't unique either. Jason Cartwright had already been working on techAU.tv, a weekly tech podcast. And amidst the flurry of activity post-launch this week, I've been talking to Jason about the similarities in our sites' names. He isn't particularly happy.

Now, when you buy a domain, say a .com, and someone else buys the .net of that name, you're not really able to jump up and down about it. After all, if you wanted to be the sole owner of that name, you should be buying all of the TLDs for it. That's just how it goes.

However, being the jolly good sport that I am, and the endeavour being relatively new, I decided I would concede defeat to Jason. I don't want to go around making enemies, and the guy's already got his thing going. Seeing as I'm only aggregating blogs, I don't mind particularly about the domain name. Maybe I can sell it and make a tidy profit.

Thus techCollective.com.au was born

Hurrah! I'd like to think it's an even better domain. Invokes images of solidarity, and camaraderie. Bringing people together, and gently feeding them technology news.

For the moment, techAU is still active and redirecting to the new domain. But eventually, who knows. I trust you good ladies and gentlemen will remember the new domain and this will not slow anyone down.

Thankyou for a successful launch

Otherwise, thankyou everyone for all the positive attention you've given me for the site - we're still focussed on Aussie web and tech bloggers, and I'm sure we'll succeed in getting some more awareness of the local industry.

Announcing the launch of techAU.com.au

Sun, 30 Mar 2008 06:09 +1000

It didn't take long, and now it's live. As it says on the site itself, "techAU aggregates both prominent and up-and-coming Australian bloggers who write about the new generation of the web and related technologies." And it doesn't do much else at this stage. I mentioned my list of bloggers in the previous post, and with the exception of Sam Lai (get back to me Sam! We'll figure something out), all have made it to the list.

Its purpose

The idea is that, like Alltop or Web 2.0 Workgroup, you're able to visit the site and quickly scan a list of relevant bloggers for posts that look interesting. In this case, the focus is on Australian content, as I really wanted to boost recognition of prominent figures in our local industry. Bookmark the site and keep up to date on what Australian bloggers think about the future of the web.

Who can be on the list?

Any Australian blogger who writes consistently insightful posts on the web, social media, startups, and the like. I wanted to include Duncan Riley, but I'm not sure the world needs to know about his penchant for rescuing stunned birds :) If you do know someone who you think should be on the list, let me know. I'd be happy to add anyone who fits - the longer the list, the better!