The great thing is that actually, with only a little knowledge, doing this stuff is really easy. The Arduino board designs and software are open source, which is a good thing. However as usual this means the docs can be problematic.

There’s a confusing array of Arduino hardware out there. The boards have the ATmega micro controller chips on them that you program, and lots of digital and analog input/outputs so you can control and measure things. There are boards with Ethernet, Wi-fi, USB and even LED matrix drivers.

Basic Arduino (UNO)

Using this Arduino which has just a USB port and the I/O connectors, plus a bread board and 4-digit 7-segment LED display from an Earthshine starter kit, I managed after digging out the spec sheet on the display, to create a counter from 0001 to 9999. This sounds trivial, but it has a few challenges:

1. The LED display is basically 4 x 8 LEDs (7 segment + decimal point)
2. There are only 12 pins on it. Huh?
3. If you don’t send power to one of the LEDs, it goes off.

The spec sheet showed that 4 pins control which of the 4 digits you are addressing – set them LOW (common cathode) to enable the corresponding digit.

Then you set some of the other 8 pins HIGH to represent the digit or symbol you want to show.

So to set all 4 digits without any shift register chips or other smarts to “remember” the state of segments for each digit, you have program the Arduino to continually loop through the 4 selector pins, set the segment pins HIGH, wait a few milliseconds, then set the selector pin for that digit HIGH (to turn it off), and then repeat the same process for the next digit’s selector pin. What happens is that each digit is illuminated for say 5ms and then it moves to the next one.

They are continually going on and off, but because you constantly loop at high speed over them, it appears to be a continuous display.

Much more fun – the Rainbowduino

The Rainbowduino is a self contained Arduino board and the latest v3.0 one has built in mini-USB. So its just like an Arduino UNO but has a bunch of other controllers to drive an 8×8 RGB LED matrix with constant current (which I think means when lots of LEDs are on, they stay the same brightness). CAUTION: the LEDs are also seemingly as bright as the sun and staring at them is likely to leave you with a disturbing 8×8 grid of dots burnt into your retina.

So I bought the Rainbowduino plus an 8×8 RGB LED Matrix. The Rainbowduino is built to have the matrix directly plugged into the top of it, which is very handy.

Rainbowduino board plus LED matrix mounted on top

There are some tricks to getting this working however:

1. Unlike the Arduino UNO, my Mac would not recognise the Rainbowduino when plugged in to USB. I had to install the “FTDI” drivers from here. Thanks to @andydavies for the tip there
2. The docs on Rainbowduino are sketchy, and seem to be mainly targeted at an LED 3D cube rather than the matrix, and using the Processing language (which is not what the Arduino IDE uses).
3. It turns our there are several options for controlling this matrix. You can flash your own Arduino “sketches” (programs) directly onto the Rainbowduino, or you can use the I2C serial protocol to drive the Rainbowduino from another Arduino – I am guessing this means the Rainbowduino ATMega has a custom boot loader that supports serial comms to drive the display. I may be wrong.

To solve (2) I had to find the driver code that would work with the Arduino IDE. The v3 Rainbowduino driver is here. If you save that to ~/Documents/Arduino/Libraries/Rainbowv3 or similar (for Mac OS X at least that is where it is) and restart Arduino IDE, you will see you can now insert it into your Arduino sketch using the “Import Library…” menu option.

You will then find it does not compile, complaining it cannot find “WProgram.h”. This is I think because the library is built to run with “Wiring” programming language. To fix this you need to edit the Rainbowduino.h file from the driver that you saved, and change the #include <WProgram.h> to <Arduino.h>.

After that you can use the driver, which is incredibly simple:

1. in setup() call Rb.init()
2. in loop() call some Rb methods such as: Rb.blankDisplay() and Rb.setPixelXY(x, y, rgbcolour)

Rainbowduino with diagonal spectrum

Why so dark? LEDs are too bright to photograph without a filter. I put lots of tissue paper over them.

So here’s an example to apply the colour spectrum diagonally to the entire grid in action:

Note that if you find your reds are not working you probably have a C typing problem, and need to explicitly cast your values to uint32_t to avoid the RR of your RRGGBB being lost to 16bit accuracy.

And seeing as most of my life is spent in Grails… this wouldn’t be complete without a video of the Grails cup shining in all its 8×8 glory.

And here’s the code, if you want some Grails glory yourself:

Further to my contribution to the everlasting mobile web apps vs native debate I was discussing these issues again with good friend Richard (who is truly called a platform ninja), and again cropped up the “why is a tablet different from a desktop then? why is native better for tablets and not desktop?” question.

Here’s my take on this, and I’m going to keep it short:

1. The web is a shit platform for making applications. All this effort we developers are putting into it to is well out of scope.
2. As many others have noted the primary attraction is that it is easy/easier to make cross platform apps with a web browser.
3. My conjecture is that point (2) is the only reason people have accepted desktop “apps” that are web based.  There was no other choice presented to the users, and the developers had no other choice.

The failure of Java as a cross platform UI/desktop consumer app environment is to blame for point (3).

It meant app developers had to begrudgingly support a mass market of Windows devs while actually using Linux or Macs themselves because Windows back in the 3.1 -> XP days was so unutterably shit. If you’re afraid of writing native apps for iOS or Android, you should have tried writing Win32 applications back in the 90s.

So the web came, and these devs had to keep their apps supporting Linux because they used Linux themselves or had Linux guys screaming at them – but largely ignored the MacOS users (hey I should know, I was one of these developers). The only way to do this was with the web.

Desktop apps, even if you could find a cross platform framework that was not total shit (this is impossible, an immutable rule of the cosmos), require lots of support, required per-platform installation scripts and documentation. Oh and nobody really paid for apps after the initial trend of Shareware subsided.

Consumers didn’t want to pay Joe Bloggs $20 for this or that.

So freemium was born, where we all have web apps and only a select few make real money. We don’t care if they actually need to be web apps, we just choose it as a default because it is what we know, and we are scarred by the memories of 1990s native development.

Well here’s the reality check. It’s nearly 20 years later. Expectations of apps are much higher now. Quality and UX is much more important. Making cross platform (including mobile) web apps is now harder than it ever was because there’s so many more layers of stuff we have to schlep into the apps, and reams of JavaScript to do anything half decent. To still fall far short of any meaningful native integration with the desktop O/S’s features.

…and now Apple and others are creating high quality app stores for native desktop software. This means that there is a simple “arms length” route to market. Millions and millions of users who can and will pay you $5 for your native app. Which, when you have made it native, is likely to be quite easy to port to at least 1 mobile platform as well.

As mooted in all the native vs. web mobile app discussions, the classic issue of access to all the raw platform features comes to the fore. This is even more important on desktop if you are making actual apps rather than services.

Ergo, I see a distinct possibility that the stage is set to that native desktop could actually kill the notion of the web “app”. By apps I am talking things that are distinguished from online services. The web is document retrieval and viewing. That’s always what it was designed for.

Photoshop, Keynote, Email, bla bla. These can be much better as native apps – there have  been many impressive attempts at web versions of such e.g. 280Slides, Google Mail etc.

However the cloud is not the place for the hosting these desktop apps. The cloud is just the place where you store the data.

People are used to cheap tangible purchases on mobile. They will expect the same on desktop. Its a massive opportunity for developers again to create really compelling applications. Free of the shackles of the 1990s – both in the sense that native platforms are much nicer to develop for now, and that the constraint of limiting your ideas to what is capable in a browser that 80% of your market uses can now be lifted.

Go and build great native desktop apps, go and build great web services. Don’t mix them up.

[Before you dismiss me as a madman, I've written many native Win32 apps in C, C++, Delphi. I've written many web services from right back when Mosaic was the only browser we had. I've also written and ported many J2ME mobile apps. I've also made my living off selling shareware as well as consulting.]

[Also interesting read here: http://mattgemmell.com/2011/07/22/apps-vs-the-web]

I’m very squarely on the “Native is best” side. Obviously if you don’t have the funds/expertise to make a native app then you’ll choose web – but I would wager this is only viable if you don’t actually want to make money out of the app. Unless you have some amazingly compelling content (like pictures of naked people) that can not be got at by native means.

The thing is, I’m not really interested in arguing this any more as its a classic polarized debate like the Mac/PC or Linux/Windows ceaseless arguments. However most people in web development seem to be very anti-native, and as I’m often the outsider in such things, but also sometimes right, I need to set out my stall so that I can try to keep my mouth shut in any more such discussions!

Let’s get this straight. Web is the perfect platform for presenting documents. It is what it was designed for. Everything else has been a hack. We have many very clever and useful libraries such as jQuery to make web application development half-passable. However anybody who seriously thinks these are anything close to a great development platform is chugging on a crack pipe.

Or not an actual developer, but a web site designer who wants to cash in on making mobile apps.

Before you stop reading – I’m a web app dev of many years, and also did more than my fair share of mobile development.

The Web is no cure-all, it is an ugly hack of document rendering turned into interactive UI paradigm. The only selling point for it is that it is cross platform. But your experience – even on powerful desktops – varies widely based on CPU, RAM, and browser – it is simply impossible to make great cross platform apps because to do so is to ignore the native OS paradigms, or poorly mimick them.

Why is it that we are still amazed when someone creates some “fast” game in JS and CSS, or creates some amazing new visual trick like… and animated background or … 3D!

I means seriously, WTF people? We were doing this stuff on ATARI ST when I was a teenager (> 20 years ago), and this still gets a “wow” when somebody manages to make the godawful browser tech stack do the same using CSS and JS? That’s not progress, that’s a SHITTY PLATFORM FOR APPS. Its like we all became stupid and forgot everything that goes on in the rest of the tech world once the web hit.

We’re amazed when stuff like this is done because its so damned hard to do anything good in a web browser. That’s why designers and animators used Flash so much and cursed us for a decade. It is nothing more than triumph against adversity.

The native OS paradigms (visual or otherwise) issue is borne out in the great many “Cross platform” frameworks that have existed over the decades. If you don’t know the awfulness of J2ME, or Java desktop UIs (Swing), or Tcl/Tk and all the old C++ cross platform toolkits, you have no idea how bad things get. This is in part a reason why Java never took off even when delivered via the web and is also part of why Android and iOS are eating the lunch of all the other phone O/Ses whose only realistic entry point was J2ME.

Anybody reading this remember WAP? The mobile Internet that was, right on your phone, back in the early 2000s. What a crock of shit. Why? The UI had no personality, and no styling. It was slow and clunky, and admittedly ran on shitty phones with tiny screens.

WAP lost out to J2ME – a lesser of two evils – which you could consider a “native” app vs. WAP’s “web” approach. J2ME won that battle, even though people (like me) had to write sometimes 30+ different ports of the same application to handle different handsets. And we’re not talking just different graphics/screen size here, different data/game levels, different media, different code workarounds to handle bugs and resource limitations.

But still it was better than WAP. You had complete control (if you ignored all the J2ME horrible UI libraries) and could draw pixels. WAP… you could show stuff on screen badly, and maybe submit some forms.

Web on mobile is today’s WAP, in the same way that Native (Android/iOS/Windows Mobile/WebOS) is today’s J2ME. For compelling apps you need to use native stuff. What language you use to write that is less important. i.e. PhoneGap apps that use JS to glue together web UI and native features like location, camera etc are native apps. They are just slower, clunkier, non-native UI and feature-limited compared to true native apps.

The pace of development in mobile devices is now unlike anything we have seen before. 6-12 month refresh cycles of hardware and OS releases means the web will never catch up, not even close.

The ease of development used to be a USP of web sites, but this is most definitely not true for non-trivial web apps. For a start, for anything non-trivial you need a back-end server app and all that entails.

Web developers who think web apps can replace native apps ignore another major issue aside from native capabilities and integration – resources. When was the last time you, as a web developer, cared about how much memory visitors to your site had, or how fast their CPU was?

As a result performance of web applications varies immensely across clients and this matters even for simple forms or content display (layout complexity, images etc). On mobile this is a critical issue. You have to test your web app on every target device your users may be using.

Think about that.

You’re doing that right now for maybe 3-4 browsers across maybe 2-3 OSes (you are, aren’t you?).

Now extrapolate that level of work to every mobile device out there (especially the large number of Androids), as they all have difference browsers and vastly constrained resources, and different pixels-per-inch which affects usability of touch UIs.

Native development doesn’t skip this problem completely, but it gives you a feel for the size of the challenge that awaits you. Using native UI widgets you are at least nearly guaranteed some reasonable behaviour out of the box.

The point is that web development might get you somewhere, but it is unlikely to get you compelling revenue-generating apps unless your product is incredibly trivial and unique – unless you focus, like J2ME developers had to – on the devices that make up the largest market share – so iPhones and hopefully just a few of the Android handsets. Oh and maybe a HP device too, eh? Oh and Windows Phone.

If you are selling an “app” commercially you better be sure you can deliver it in working order to your end user. Make that a “paying” user. Not so many of those on the real web are there.

Many web developers fail to understand that mobile devices are “embedded systems”, it is not just your desktop web available in your hand. The user expectations are entirely different from desktops. Its so frustrating that people don’t seem to get that this is consumer electronics: where you push an ON button and stuff happens right there and then.

You pick up a phone to do something, it has to do it quickly, cleanly and reliably. The user does not see a mobile device as a mobile desktop (though more powerful than PCs we used not too long ago) where its OK to spend 15s loading, bombard them with some pointless screens, download a ton of crap off the web.

Even a great deal of native apps fail horribly at this. They take too long to load, the UX is poor due to excessive navigation etc. I have some laughably bad iOS apps installed on my devices – which occurs because there is no try before you buy / returns policy, a major flaw that needs to be rectified. And if it does get rectified, you better fear for your app-store hosted web apps.

The fact is mobile devices are now so desirable as a platform precisely because of Apple’s iPhone and the native iOS. Web developers may see these as sexy devices they’d like to do stuff on, but everybody else sees these as great things that work better and faster than their old computer, with less fuss and (so far) no viruses – and nobody thinks of these as being like web apps but packaged up. Web applications pull it back to the sluggish land of the desktop. Response time is everything in touch interfaces.

As for native OS integration, whether using HTML5 features (still not fully standardized) or custom JS APIs á la PhoneGap, the features available will always lag behind native apps, and will usually lag behind in performance. HTML standards processes are inordinately slow and protracted. Never, ever expect and quick turnaround innovation from HTML. Just forget it.

“But my app is not performance dependent”. Yes it bloody is. If the user taps or drags stuff and it doesn’t happen in smooth realtime like native apps, you stick out like a shit on the arctic tundra. Remember that your app is competing UX wise with all the great default apps shipped on the device (well at least as far as iOS goes).

“But I don’t need native integration or true native UI”. Yes you do – as soon as you have any form of native competition. And if you are pursuing a market that actually generates decent income, you can bet people will come with native equivalents.

Some people point to WebOS – it’s web based technology. However it is effectively native, another proprietary platform. Its yet another OS to port to. Are people seriously saying that, even if performance issues don’t emerge from this, that they’d like to use all this hacked together HTML/CSS/JS crud we’ve amassed over the last 10-15 years to write apps for a tiny device that can have a perfectly good, fast, tightly integrated app written using the well-documented libraries provided in a native language? It’s a little like writing scalable web app back ends using BASIC. You could do it but… its the wrong tool for the job.

An interesting blip here is Symbian. This was a native OS platform on all the big Nokia devices. However it failed – the crown went to the UX-inferior J2ME platform present on the same handsets. Why? Presumably because there was no commercial marketplace of any worth for the apps (the handsets always featured low in app sales, a very small % of total market), and the devices it ran on were the horrible Nokia bricks that cursed us for the last 10 years, cost a fortune and had bad battery life.

In a nutshell the Web is a pile of cobbled together crap – from an application development point of view.

We can put up with this for true web applications/services as we can’t face writing native Windows, Linux and Mac OS X clients for our apps – it makes us gush when a tool like jQuery reduces the pain level by another 10%. Our users are accustomed to this paradigm, and for many of our apps we don’t need any whizzbangs that require really obscene hacks like Flash for camera access etc. Because their PCs/Macs are a bit of a hassle to maintain they appreciate not having to install apps. They also don’t expect always-on connectivity so settle for “just while I’m sitting at the computer”.

Even with tablets, there is no point making a web-based app for them. Just make your normal site work well on tablets. Desktop users will likely appreciate the improvements too. I can see the attraction of making a tablet-optimized “app” because its reasonably quick and cheap, but really, put that work into your regular web UI. For a Rolls Royce experience for your tablet users, give them a native app if it is commercially sound to do so.

The User expectations of mobile, including tablets are completely different. The device is a tool to get stuff done. In contrast to “I’m now sitting at my computer doing a bunch of stuff”.

Let’s not even talk about battery usage…

Bottom line: Mobile development is really hard work, involves lots of time and testing, the likes of which desktop web app developers have little idea about. Browser wars are nothing compared to real cross platform dev where the end product is high quality.

If you’re going to do it properly, do it native.

Aside from all the basics, they allowed 3rd party applications on the device AND the desktop to talk to each other directly to sync custom data. I’ve bitched about this before.

As an avid Mac, iPhone, MobileMe and soon to be iPad user, I have to wonder what is happening with this at Apple. My real-world gripe is this:

I was just about to open OmniFocus on my iPhone specifically so that it would sync with the latest data on my MacBook Pro, which is set to sync via MobileMe (using a pretty ugly file based solution). Why am I even doing this? Why isn’t this data synced (a) when I dock my iPhone to sync all the other iTunes stuff, and (b) why can’t it automatically sync wirelessly

Well part (b) is easier to answer, although it is a three-fold answer. First, there’s no background app support to allow automatic sync of the OmniFocus app on the phone. That should be addressed by the Push API functionality except that OmniFocus doesn’t support Push API (server cost to them to do so) and even if they did support Push, iPhone SDK Push is not able to automatically pass the data to the application to force it to sync – the user must acknowledge the event and run the app on the phone manually. It’s a pile of suck, surprisingly, with a real feel of “disconnected device”.

Part (a) is more tricky to answer. It must be trivial for Apple to add this kind of support for direct-to-app syncing. They already have/had Sync APIs for OS X for a long time. Lack of support for this apparently makes no sense.

In conclusion I am very surprised that Apple has not updated the OS X Sync APIs so that:

• Third party apps can sync any data they like to/from the iPhone/iPod/iPad with iTunes as the conduit (that was the concept’s name in PalmOS if I recall)
• The transport for sync is completely hidden from the applications such that sync will happen transparently via Dock, Wifi (direct between devices on local Wifi network), and via MobileMe cloud if the device is not on the same Wifi network.

This is not rocket science after all. And yet we still have to know / think about what networks our devices are connected to, manually make sure we run them frequently etc. It is pretty lame, Mr. Jobs.

Ironically, I think that there will not be that much hardware “frill” with the Apple tablet. I think that actually this is really all about software and the masses of computer users who are not “power users”.

Follow the logic:

Net books are very popular.

The iPhone and the new breed of beyond-smart phones is incredibly popular.

What is the common thread here? Both devices are very portable and offer most of the basic computing that people need day to day. What is it that most people – which I’m afraid guys means non-geeks, the truly massive market beyond geekdom – need?

1. Email
2. Web

That’s it. That’s what most people who are not raving geeks need. In fact some geeks may need only that. After all there isn’t much you can’t do with web apps now (e.g. bespin). Google OS/Chrome stuff has been geared to this from the get-go, its not a novel idea.

Functionally, most people also need to be able to write/edit documents that can be read by MS Word – not that they need MS Word, they just need to write out .doc files. This can be done via web apps or via lightweight local apps.

However Apple would not do something like this unless it also offered uniquely integrated stuff.

So on the back of this I reckon the tablet will:

• Not be that revolutionary hardware wise – eg physically this probably is like a giant iphone
• To include some web-hosted (with local offline usage) iWork for Pages (= docs & spreadsheets writing. maybe keynote too)
• Full access to all your iTunes audio and video media and photos (cloud or not) – I would be surprised if this is 100% cloud done at this stage, what with the awful 3G coverage and slow speeds to sync photos and videos. Access to this done “ipod style”, which is a killer recipe as the market has shown
• A first class large-form factor email app, geared to multitouch
• And as suspected the delivery of formerly-print media, possibly opening up iTunes marketplace to any author who wants to prepare and sell content. Who knows perhaps you will even be able to create new textual/mixed content on the iPad and sell it via iTunes. This content provision is probably the one really new thing that helps make such a pad a really attractive proposition.

In a nutshell, a beautiful portable computer that is most definitely NOT a laptop because a great deal of people will never see themselves as the laptop carrying kind. However they are likely to part with cash for something that is much smaller than that but a true lifestyle accessory that “just works”. Obviously it will support custom apps and app store too – which has already shown on iPhone that a lot of people just want little stuff that makes life easier.

Several programmers including myself have wondered “Why do I need something like that?”. The answer is if you have an iPhone and laptop, you don’t. The big market win here is not people like us, its everyone else in the real world! Laptops are complete overkill for a lot of people and the netbook market has sort of shown that. They’re not so much winning against laptops as a result of price, they’re winning on form factor and simplicity. If people really needed high-end laptop features, they’d still buy a laptop instead of a netbook.

I’m pretty sure netbooks aren’t aimed at programmers either – although I am confident some masochists code Perl on them and swear that its the best calculator computer they’ve ever had. The tablet on the other hand, is squarely aimed at attacking the netbook and light-use laptop market.

Let’s see what Wednesday brings!

But what about the rest? What about the things you need to make the service tick, to keep in touch with the users etc? These things are really important, as you can bet things are not going to go smoothly all the time, especially at the beginning.

We’re just going through this phase – all the basic 1.0 coding is near completion, and now we need to make sure we don’t miss out any major “duh” features we need to keep things going.

Off the top of my head, I can think of the following:

• Effective web stats so you can see how people are using the site
• Database backup policy and off-site backup of your users’ data
• A mechanism to easily send downtime/update/marketing emails to all your registered users
• The ability to add a banner on the site to indicate scheduled downtime
• Terms of use
• A predefined plan of action to take if the servers are swamped
• A way to update key content without a redeploy (= scheduled downtime!)
• Basic reporting to see how many new users you are getting, and what they are doing – over and above webstats, a summary of your domain objects etc.
• Make sure load/health reporting is set up and working in advance
• Detailed functional tests and/or manual test plans ready and in place. You tested 1.0 right?

Do you have anything to add to this?

UPDATE: commenters have also very wisely suggested -

• Screencast showing users how to use the service
• Issue tracker for support
• Privacy policy / data protection policy

I’m lucky to be out of mobile phone development now. I spent about 2 years coding J2ME games for a wide range of handsets and as anybody who has done it knows, its really shitty. This is because J2ME has standard APIs, but implementations vary in quality, nuance and in some cases downright fail to meet spec. Not to mention all the phones have different API sets and hardware abilities, input methods, screen sizes that vary wildly etc. Oh and I forgot – bugs across different firmware versions of the same handset – users without iPhones being unlikely to upgrade firmware as it is likely non-trivial / not handed to them on a plate.

I’m an iPhone fan, because iPhone makes mobile phones not suck. That’s all I cared about when I got one.

If I was an active phone developer now, I’d be very happy to dev exclusively for iPhone because of the tools and APIs and low variance in standard hardware. Issues about app store review policy notwithstanding (that’s a serious problem that has to be, and I think will be resolved). If you write good apps there’s easily a big enough market size already to make some good money.

Anyway last night I read this Fake Steve Jobs piece – ever sharp: Developers only now realising that Android is not a platform

You see when writing mobile apps the number of handsets you have to port to and test with (requires owning the phone typically) is key to your financial bottom line. Mobile operators want/force you to make sure your app supports a wide range of their crappy handsets, even if you will sell 1 copy of your app per year on that handset.

Because it is a phone there are few apps for or it has their logo on the phone, you have to support it.

You have to waste days debugging memory use issues – often across many different handsets

You have to waste days working out why your colours are coming out wrong on a crappy handset that has sold in high volumes and has a CPU so slow your game is barely playable.

You have to test every feature of your game/app to completion, with lengthy usage tests, incoming call issues etc to be sure it will not fall over / frustrate the user after a while. A quick flick through = poor QA.

The cost and effort behind this is immense and in many cases a complete waste of time. Generally speaking as a mobile dev you want to target the smallest number of phones that give you the biggest market share of people who actually pay for downloaded apps.

Now even with a unified “app store” for Android, you’ll still have to pander to these same requirements even if there is no network operator standing in your way. Because to make money, you have to follow the high volume handsets. Earth to those new to mobile dev: the highest volume handsets are very rarely the most capable or attractive from a development perspective. After the market matures, the highest volume will be in the cheapest/most subsidized handsets. This will likely be operator-badged “plastic-extruded turd with calculator buttons on” handsets.

This is why the FSJ post is right on the money. The higher iPhone market share grows – and the more global it becomes, because this is a double whammy compared to j2me dev with no mainsteam cross-phone app marketplace – the more attractive iPhone dev becomes. It is just easier to make more money there.

You have effectively one target device (ipod touch may not have mic and no phone but that’s it, 3gs has… compass oooh) and a clean reliable platform. Even firmware issues are almost removed because Apple/iTunes make it so trivial for people to update.

Contrast this with Android. From what I have read, it seems the O/S is not a rigid guaranteed platform like iPhone OS, and of course it is targetted at the mass market of phones. This will mean that the capabilities and APIs and quality of implementations will vary across all the handsets – just like in your old enemy J2ME.

High volume phone makers will try to shoehorn Android into as little RAM and CPU as they can, with the cheapest acceptable screen they can (who cares if everything looks a bit yellow!), to hit the lowest price point to make their handset the most attractive to the network operators so they can hit high subsidised sale volumes. If there’s some problem with a part of an API – maybe the CPU is too slow to do it, or the GPU can’t handle it, or the screen is “4.5-bit CMYK” colour as opposed to 24-bit RGB, they will just cut a corner/break compromise that API and almost certainly not document this. It is commercial reality. It is the classic design down to a price, not up to a standard.

J2ME suffered exactly this problem and Sun couldn’t fix it even though they had a licensing scheme for the VM. Because Google has open sourced Android, I don’t see how they’re going to be able to introduce a “Google Certified Android” standard that requires complete TCK success for all Android deployments.

As such, mobile devs on Android are doomed to the same existence they’ve had for a decade on J2ME.

Each new Android handset means another target to test, often requiring you to buy the handset contract free (ouch!), and the diminishing returns as the market is flooded with new handsets each garnering less of the market for your app.

Of course you’ll still be coding Android apps because manufacturers will be running to unite under an “iPhone beating OS”. Really, all that’s changed is you’re coding to Android APIs instead of J2ME.

I don’t mean to say Android won’t be successful. iPhone OS will not be “the” dominant OS in the mobile phone market any time soon, maybe never.

The thing Android devs have to fear is this: the mass market success of Android. Why? Because the mass market success = high volume = cheap crap phone, not a smartphone. That is where the money will be for Android apps, and guess what – its going to be really pretty ugly. You’ll make a “reference port” on your high end Android handset with touch and lots of RAM and great performance, and then have to downshift everything to the shitsville high volume ones.

So in terms of small developers making money off their apps, I’m very confident the ROI on iPhone will be far more favourable.

Let the big guys deal with the horror of porting and QA teams for all the Android stuff.

Oh, and wait it remains to be proven that Android users will actually pay for apps in any quantity. Apple creates an environment of value where people understand that, generally speaking, you get what you pay for. As FSJ often says… “freetards” don’t get this.

UPDATE: Oh look what just hit the news… one of (if not the) biggest J2ME game devs is scaling back their Android efforts. “It is not as neatly done as on the iPhone. Google has not been very good to entice customers to actually buy products. On Android nobody is making significant revenue,” AKA “freetard” attitude = no money for developers.

I have used JIRA for something like 5 years now. I am a big fan, in that it is definitely the best issue tracking solution out there. However I’m also quite critical of it at times, because I think it often fails in usability and UI terms to deliver an intuitive experience for those doing software (and particularly web) development.

So I thought I’d write some initial views on the Jira 4 UI and GreenHopper – my hope being that GreenHopper will alleviate some of my release planning frustrations with Out-of-the-box Jira. These are most definitely first impressions. Any major UI changes are likely to be met by resistance by seasoned users of any application.

First, the good:

• Jira’s main dashboard UI etc looks cleaner, drop-down menus for quickly getting to specific projects are welcome
• The whole thing feels less cluttered because the right hand side bar which, in my experience was almost never used by most JIRA users, has been taken away
• The drop-down action menu for each result in an issue navigator search is great
• The activity stream stuff is very helpful

Now, the contentious core JIRA stuff:

• I now feel like I have no issues. If only it were true. The whole JIRA UI feels “too” sparse, I feel like I cannot see my workload properly any more / the status of the project. A prime example is when you click on a project version and are shown the version summary tab which seems to show at max 3 updated + 3 “Due” issues. What use is that? Doesn’t seem configurable. UPDATE: Brian Lane, JIRA product manager has told me this is configurable in a configuration file but not in the UI, where the setting jira.project.summary.max.issues=3 can be found.
• Roadmap view – for me at least – is completely useless now. It no longer shows all issues for a version if there are “too many”. This should at least be configurable and behave like old Jira by default. Its an imperfect world. Some of us have 170 issues in a version What’s more the issues are sorted obscurely – you’d assume if only showing 50 issues it would show the 30 unresolved issues, but for me shows about 8 of those and 40+ resolved ones. Roadmap does not show me my roadmap, I have to drop into issue navigator
• I hate portlets. For dashboard overview stuff, fine – but they are used in other places too eg project overview, which feel like UI/usability cop-out. Its not Web 2.0, its iGoogle. Portlets are too generic to make any app feel seamless.
• “advanced” searching with some new Jira QL is enabled by default it seems, which I think is a mistake. Bring back the good old simple search for most users by default. UPDATE: Brian Lane also told me that this is not the case, it is not on by default. I don’t know how it became on for me though.

Next, my first impressions of GreenHopper:

• GreenHopper is very specific to a particular Agile methodology and “card” (or post-it) metaphor. This IMO is enough to make it a total WTF for any users who are not Agile Scrumbag 3rd Dan Blackbelt Extremists. That includes me.
• I was hoping for drag and drop planning of issues eg assigning them to people and versions in the roadmap. This is there, to a degree. GreenHopper is major overkill for the majority of users – and yet with no DnD scheduling in core Jira, you have little choice if you want to avoid the horribly repetitious standard Jira workflow steps to change fix-for on issues during planning where batch changes are not that workable as they require scanning all the issues before making your changes.
• The UI is highly functional for the specific metaphor and methodology, but is frankly insane for every day users. It makes me feel ill trying to using it. Too much colour. Too many options. Too small fonts. Web 2.0 was years ago, we’re allowed to use a font > 12px high now you know!

Things I want day to day but can’t seem to achieve even with the power of Greenhopper and Jira 4:

• Drag issues to become subtasks of a parent
• See a “tree” of issues as a list eg parent issues with subtask issues shown below them
• Get an instant view of how close we are to the top-level features (parent tasks) being completed – eg the red/green bar of subtask completion for all parent tasks, shown in a flat list. Don’t get me started on the “Task board” of GreenHopper. Powerful yes. For mortals? No way.
• JIRA completely lacks the personal element commonly found in Web 2.0 apps – avatars for user accounts. Github has this, so do most other hosted web 2.0 apps. Its a real omission and means functionality like “drop issue onto user’s face to assign it” is not yet possible.

JIRA is very powerful, has had some solid UI improvements, but ultimately I think from a web-app developer’s point of view it is now weakened by its un-opinionated and excessively generic underpinnings. This can be seen by the way GreenHopper had to shoehorn its way into JIRA UI with some truly ugly configuration screens, mismatched fonts, general lack of integrated look and feel – and popup windows with standard Jira issue edit screens in.

It feels like JIRA is still firmly rooted in the waterfall-approach era. It has been very successful by trying to please everybody, but I feel that it is not yet up to the task of truly excellent web-development tracking – although it certainly remains the best option out there at this time in my opinion.

The GreenHopper plugin tries to bring a visual metaphor to all this, and that is welcome. However I think the visual metaphor of just dragging issues in the normal JIRA roadmap view would work a lot better for 90% of users than the agile “card” approach and all the steroids that those UI screens have been given.

I hope this doesn’t come across as too negative. Both products are a move in the right direction and there’s no way you can do wrong with the currently special offer pricing that’s for sure.

However I hoped for a bit more progress in Jira’s UI for release planning etc out of the box - I wrote about these desires way back in 2006 - and GreenHopper despite normally being a premium product for exactly this, in my opinion fails to meet the needs of real-world users (eg the ones who don’t live in an Agile methodology bubble).

<bean:withBean beanName="form">
    <bean:field property="firstName"/>
    <bean:field property="lastName"/>
    <bean:field property="company"/>
    <bean:field property="email"/>
</bean:withBean>

This will render input fields of the appropriate type, with sizes set according to the fields’ constraints, select field items from inList etc. It also renders label tags, errors local to the field, and required indicators.

You can customize the markup used for all this stuff, so that you get a consistent and noise-free rendering of fields across all your GSP views.

Please do check it out and let me know if you have any issues.

Of course the web service is being built with Grails – it would be insane to use anything else! Chris our developer is doing an excellent job – Grails is massively empowering. In the timescale we’ve been working to an amazing amount of stuff has been achieved – even when some of it is being learned on the job.

Oh and of course the core idea is there but the details are being fleshed out as it is developed, but Grails reduces the pain for Chris as changing direction on some features is not as heartbreaking as throwing out weeks of work on thousands of lines of code.

Our designer Pat is also working well with editing GSPs directly, something new for her which she is enjoying, along with learning the joys of Blueprint CSS and jQuery UI.

However, what was obvious to me before starting this project, is painfully obvious to me now. Modern tools like Grails take the classically hard part of making a software product and turn the problem upside down.

We don’t spend time fiddling around with config and trying to glue various tech together, writing reams of bean accessors and lame JDBC code etc. – we spend all our time trying to meet the challenge of creating an application that really makes sense to users, hides all the technical detail – while providing features that a few years ago would have been considered very low priority due to the work required to get even the basics off the ground.

Expectations of modern web apps, especially the expectations that come from ourselves as designers and users of such services, are very high.

This is however a “high quality problem” compared to chipping away at a massive mountain of code just to get something half-assed ready, and deferring all the parts that are important and useful to end users (and hence ultimately the business) until later.

Time is of the essence. Grails cuts out maybe first 3 months of dev, and we focus on the business problems.

It’s a no-brainer in that sense.