Marc Palmer

Users and particularly developers of Palm’s old line of PalmOS devices will keenly remember that Palm were the only people to get syncing right at the time.

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.

Might as well join in the fun eh.

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!

So you focus on getting your “don’t worry be crappy” code together to bootstrap your startup and get something the real world can play with. All the user-oriented features you need are there for 1.0.

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 recently upgraded our JIRA instance to version 4 and installed the GreenHopper plugin – after getting them for the bargain price of $10 as part of Atlassian’s amazing repeat bargain offers for charity. I can’t recommend this enough – $10 for enterprise Jira is amazing.

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).