MeeGo

Until a week ago, I knew virtually nothing about MeeGo. I had known it was an attempt by Nokia and Intel at creating a new OS for Nokia's smartphone line, and that was about it.

This week I attended MeeGoConf on a whim, as it was being hosted in Dublin so I wouldn't have to go out of my way to attend. As a direct result, I have been bitten by the MeeGo bug; there is so much potential here that I never would have expected given its heritage.

MeeGo is less about Nokia trying to be relevant, and more about the open source community creating the future Linux OS for embedded devices (smartphones, tablets, netbooks, in-vehicle entertainment and television). It's a full Linux distribution, a MeeGo 'Core'. For each device platform, there's a corresponding 'UX' (User eXperience); if you install the netbook version of MeeGo you're seeing the 'Netbook UX'. Evolved from Moblin, the Netbook UX is the most far-along and usable of the UXes.

Intel went out of their way at this conference to prove MeeGo to the attendees; what better way to convince someone something is worthwhile than to provide them with it for free and let them just use it themselves? Intel did just that, giving each of the ~700 third-party attendees a free Lenovo IdeaPad tablet netbook running MeeGo (to satisfy the nerdy body of attendees, everyone had to install the OS themselves from provided USB keys; the choice at collection was 'Broadcom' WiFi driver or 'open source' one :o) ).

MeeGo's Netbook UX is really well suited to touchscreen devices, and I was blown away by how smooth and responsive input was (stark contrast to Windows 7 on a touchscreen). I knew this was just the tip of the iceberg however, and I wanted to get the Handset (smartphone) UX up on running on my new tablet. A bit of massaging later (I lie, a *lot* of massaging - I now have the entire filesystem memorized) and I had my IdeaPad set up so I can switch between Netbook and Handset UX at a whim.

I went on a hacking spree after that, forcibly installing MeeGo on both my N900 and Nexus One. Right now, the Handset UX isn't usable for anything. It's just a pre-alpha glimpse of something with great potential. My N900 had previously convinced me that maybe Nokia wasn't going to wither into irrelevance after all (the OS, Maemo, that preceded MeeGo is very slick, and a stark contrast to Symbian S60), but now I'm downright excited to get my hands on a real MeeGo device, like the forthcoming N9.

MeeGo looks like it has legs, and is a distinct, user-friendly OS. But, influenced by the N900 that came before it, MeeGo is also a hacker's dream. A fully open-source OS that has a full Fedora-based Linux distribution under the hood and can potentially run desktop apps without issue (MeeGo's Netbook UX is a better Chrome OS than Chrome OS itself!). There's definitely another 6-8 months work before consumers can be entrusted with it, but from listening to the sessions all week it's clear that the people in charge are on the right track and know what they need to do to match the competition in the user experience space. I only hope that, like the N900, MeeGo handsets retain the Terminal app on the homescreen and the built-in SSH server. :-)

Return AirPrint sharing to Mac OS X v10.6.5

Today, Apple released Mac OS X v10.6.5 which was supposed to bring AirPrint to any printer connected to your Mac. Only problem is, a last minute issue (due to patent trolling?) has caused them to pull support for AirPrint in OS X.

Don't panic! You can return it, but you're going to have to pull some files from a prerelease version of 10.6.5.

The files you need are:

/usr/libexec/cups/filter/urftopdf

/usr/share/cups/mime/apple.convs

/usr/share/cups/mime/apple.types

If you migrate those from a 10.6.5 prerelease build (there seem to be many floating around torrent sites and file sharing sites - build 10H542 works; naturally I can't link you to the files themselves, sorry!) to your machine you're just one step away from having AirPrint working.

The final key thing is you have to remove and re-add your printer in the Print & Fax preferences pane. Once you do that (and share your printer in the Sharing preferences pane) it should show up on any iOS devices that support AirPrint.

Nerdy extra info: Basically, doing this should add the image/urf mimetype to your shared printer, and a new Bonjour field 'URF'. Once you have those, it should work. Theoretically, there's no reason someone can't write a server application that broadcasts said Bonjour info and prints for you, so you don't have to use files from a prerelease build. I would expect something like that to appear over the next few weeks.

Thanks to Patrick McCarron for helping me debug this method

Good luck!

Mac OS X 10.7 Brain Dump

On Wednesday, Apple revealed their plans for Mac OS X 'Lion', which will bring a lot of ideas and research from iOS to the desktop.

LaunchPad

A lot has been made of Apple's new 'Launchpad' feature; basically a re-imagining of the iOS home screen for the desktop. It makes a lot of sense, application discovery, installation and removal has always been problematic on Mac OS X. But it also signifies something far more interesting for the platform - the idea is to create an abstraction between your 'Applications' and the /Applications folder on your hard disk. Maybe in an OS release or two, you won't even have an Applications folder on disk anymore - all your application access and management will happen through Launchpad.

This signifies, at least to me, a move away from the files and folders model of interaction with computers. As with iOS, the location the applications are stored in becomes an implementation detail. In the very near future, we may not even need a Finder app to browse our hard disk; folders just become metadata, and everything lives in a global 'soup' (Apple Newton users will be familiar with this idea).

Never Quits

According to rumors I've heard, and evidenced in the demo of Lion given, apps in 10.7 also do not seem to differentiate between 'running' and 'onscreen'; there is no indicator in the Dock when they're open, and when you quit them and reopen them they re-launch in exactly the same state you left them. You effectively do not know what's running or not without a window onscreen. It sounds like an insane change, but actually isn't if you think about it: in the near future, there may not be a speed difference between something being 'in-RAM' or on-disk, if the two storage media are equivalent in speed (SSDs, while still a long way off, are getting there). If disk access is as fast as RAM access, what *is* the difference between 'quit' and 'offscreen'? There effectively is no difference. It may be a bit premature for 2011, and perhaps this decision will be reversed by the time Lion is released, but it's an interesting view of the future.

App Store

Apple also announced plans for an App Store on Mac OS X, something I've seen coming as a logical conclusion ever since it came to the iPhone. Feelings are mixed about this, but it doesn't matter - in the next few months the App Store is going to become the dominant distributor of Mac applications and developers will be scrambling to retrofit their software to abide by the store's rules. Whether the walled garden is good or evil, there's no doubt that it will change the desktop computing landscape just as it did in mobile.

Right now, you can't use the same application ID for your iOS app and your Mac App Store app. I think it's conceivable that in the future there will be no difference between a Mac and iOS app binary, so I can understand why they don't allow you reuse the same ID across both platforms.

Speaking of App Stores, I find it curious that neither Dashboard Widgets nor Safari Extensions have received an App Store of their own yet; I can definitely see both getting their own integrated stores eventually, as it just makes too much logical sense. I'm totally against putting either in the Mac App Store, however; that would defeat the purpose of a single-purpose, streamlined store.

Still no mention of iBooks on the desktop either - I've always imagined that Preview would gain such capabilities, but it's also possible that a standalone 'iBooks' app for Mac is coming.

Multitouch

Apple devoted quite a lot of stage time to talking about multitouch on the desktop, and saying how their solution is their powerful multitouch trackpad. They reason that touch screens don't want to be vertical, and they're fully right. Unlike many in the media, however, I certainly do not interpret this as Apple saying they won't implement multitouch screens on the Mac line. On the contrary, they kept saying how *vertical* touch screens don't work. This leaves them wide open to introducing horizontal touchscreen Macs, and they have many patents on such ideas so have obviously been working on them. Don't be surprised if in a year or two Apple introduces real touch screens to the Mac.

Lion looks to have much better, integral multitouch gesture support, which is going to be awesome for pro users. Right now the mouse is generally a point and click affair, but with multitouch it turns into something far more like a practical version of the Minority Report UI; every flick, swipe, pinch, rotate has a function in the OS.

Contextual UI & Fullscreen

This is also a big one - of course, people have defended iOS' unitasking and fullscreen apps saying it allows them focus better on whatever they're working on on iOS. There's a lot of truth to that, and it will be interesting to see how much of a difference it will make on the desktop. I definitely feel more at-peace and relaxed when unitasking on the iPad (this blog post was written on the iPad, for reference).

The contextual UI is something that interests me a lot; quite apparent in the iLife demos, specifically iPhoto, is a lot of contextual UI. It appears when it's needed, just like on iOS. It doesn't clutter the screen when not needed, and it shows up near the object you're interacting with instead of in some global toolbar or sidebar. I believe this is going to be a big thing as Mac OS X assimilates more of the design philosophy of iOS. It's definitely going to be a big deal on smaller screens, like the 11.6" MacBook Air. Mac OS X is also losing the permanent scrollbar, replacing it with a contextual scrollbar (again, just like iOS).

Wrap Up

There's so much coming in Lion that they've shown already, way more than I expected. I was expecting Mac OS X and iOS to become far more similar, but not this soon! Even now, it's clear that Lion is going to change the Mac landscape vastly, and the App Store is going to have a huge effect on Microsoft's planning for Windows 8. The stringent rules on the App Store will be a pain in the ass for Mac developers, but it will end up accelerating the evolution of the Mac platform immensely (no private APIs, no external dependencies beyond what ships with the Mac OS, no writing outside of specific locations - it will allow Apple to make huge and rapid changes to Mac OS X without worrying about backwards compatibility).

For the first time in many years, I am actually excited about the future of desktop computers. The iPad hasn't killed the Mac, it's brought it to a whole new level.

AppleTV + Apps

I guess it's no surprise that the new iOS-based AppleTV was jailbroken instantaneously on release, but as the former AppleTV plugin developers race to the new platform to disassemble it and get their own plugins up and running on the new system, I can't help but wonder how the future of AppleTV will play out as regards developers.

It's widely rumored that Apple will open up the AppleTV platform and create an 'App Store', allowing developers write apps for the big screen. It seems almost inevitable that they will make this play, if not to compete against Google TV then to at least make the AppleTV a relevant platform; leverage against the movie studios reluctant to agree to Apple's movie rental terms and who knows what else.

What I don't see is an AppleTV SDK being built around BackRow, the current framework that provides the UI on the device. Previous AppleTV plugins have all been built for BackRow, using a framework that is decidedly not very Cocoa-like or developer friendly. They have nonstandard design patterns, and they run as actual plugins to the UI process; a crashed plugin can currently take out the entire UI. From what I've seen (and I've been using it since the original AppleTV hacks back in 2007), the BackRow framework is not fit for third party developers and was never designed to be.

Assuming Apple does launch an App Store, then, how are we going to write apps? The only option I see is UIKit. UIKit is familiar to all iOS developers, is very Cocoa-like, and very powerful. In fact, since iOS 3.2, 1280x720 (720p, or the same resolution as AppleTV) is a supported resolution for developers, mainly for those creating TV-out UIs in iPad apps (Chopper 2 is a great example of this). Developers have already started crafting ten-foot-UI experiences in existing iOS apps, so it would be a no-brainer for that to translate over to AppleTV wholesale. To make it work, Apple would have to build remote control support into iOS… - but hold on a second, Apple already added that in iOS 4! Effectively, all the pieces are in place to build a remote-control driven 720p iOS app. All Apple needs to do is build the distribution mechanism and open the floodgates, and 'Universal' apps would be a definite possibility.

Of course, some people will complain that UIKit isn't the native UI for AppleTV; our apps will look and act differently from the native experience on the device. Point taken, and it's an important one; I think Apple could effectively build an AppleTV UI framework on top of UIKit that internally uses the BackRow APIs but offers the developer a much cleaner way to implement common features. Does it need to happen? No, but it would certainly feel unfinished if they didn't do it. Then again, Apple can be surprising: I'm still astounded they let the iPad ship with that horrific iPhone app scale-to-2x support :o).

Apple Financial Results Q3 2010

Little infographic for you; executive summary - the iPad in its first quarter of sales accounts for almost twice as much revenue as all desktop Mac sales.

Puts the future in perspective, don't you think?

Taken from Apple's financial results PDF.

Retina Display Update

By now, most developers have got their hands on iPhone 4 and run their old iPhone apps on it. And I'd like to think that they, like me, are appalled at how terrible they look on the new Retina Display. The screen is just so amazingly sharp and vibrant that your artwork will look like crap unless you get it redone.

Cue the sound of a hundred thousand developers' voices suddenly crying out in terror.

Why? Updating your artwork for the Retina Display is a time consuming and expensive process. iPhone artwork often costs thousands of dollars to produce in the first place, and if you have to go back to your artist to get it all redone (possibly from scratch, if they didn't think to design with vector shapes) then you're looking at a significant cost just to get your app to a passable visual state on the iPhone 4.

Those with in-house designers are at an advantage here, but for those of us who work alone it could well be a nightmare.

My plan is to have Retina-Display-ready app updates as soon as possible. I have already redone all the artwork for SameGame myself (and it looks stunning, to be honest), and Grace and Speed will follow with minor updates (in that order). Lights Off will require huge effort, so as of right now I'm not promising any release dates (just as with the Universal update, there's too much going into it to give a timeframe). Hopefully you'll start to see the others soon enough.

For those developers who haven't yet seen their app running on a Retina Display, start freaking out right about now. If you think you can get away with not redoing your art, you are sorely mistaken. :-)

PS: That Retina Display is like nothing I've ever seen. It changes the way you view computer screens forever. You can never unsee pixels on other displays again.

Labor of Love

I have downloaded (and paid for) a lot of $2.00 programs that are just amazing. It’s not that you couldn’t make these on the PC, it’s just that people would scream that it should be free. And as a developer, I can tell you, I won’t spend time making stuff "for free" when I could be spending that time with my kids unless it’s a labor of love. As a result, a lot of cool little programs are being made because developers can actually get paid for making cool stuff.

Brad Wardell, CEO/founder of Stardock (a long-time Windows development house), on the iPad as a threat to Windows.

Thoughts on Flash on Froyo / iPhone Safari Plug-In SDK

Some initial observations regarding my first twelve hours with the Flash 10.1 beta on the Nexus One:

Flash scrapes a pass in the performance test. Videos can be choppy at first, but after a little while they seem to play smoothly enough.

Flash utterly fails the UI test; forget any video playback controls on any Flash video you plan on watching. Tested it with the Engadget Show live last night and was unable to change the volume, also tested with some Zero Punctuation reviews and similar problem. It appears that Flash renders at the Nexus One's native resolution (480x800) which means the playback bar on virtually any Flash video is so tiny it's unusable. There's no automatic fullscreen mode when you double-tap a Flash context like some of the earlier demo videos mentioned, but the 'fullscreen' button on many Flash video players work fine (of course, Flash contexts that handle double-taps themselves to go fullscreen work fine).

Photograph here with SD card for comparison; you can't pinch-zoom in fullscreen mode, so how on earth are you ever expected to press any of the controls? This is worsened by the fact that Android phones' touch sensors aren't the most accurate either.

I can't give comments on battery life one way or another. The Nexus One's battery life is poor by default, but after watching a short Flash video or two I left the phone (in sleep mode) on my desk overnight; the battery was dead by the time I woke up.

Overall, for Flash to work on mobile devices virtually every Flash video site is going to have to redesign their Flash video player to support touchscreens. They may also have to re-encode all their videos for best performance (Flash keeps popping up 'This video is not optimized for mobile').

That being said, with the web as it is today, I don't see how Apple can ignore Flash for much longer unless there's significant movement to HTML5, which offers less features and generally performs worse than Flash, in the next year. To be honest, I don't see that happening; the pace of the web is glacial, at best, even when Apple is trying to force peoples' hands. It's really nice to be able to go to a website and not have to worry about whether it uses Flash or not; before this, I'd have to get a laptop out if a site demanded it. I don't think that's where Apple wants the iPhone or iPad to be, and I think the egos on both sides have done enough damage.

The Solution

I think Apple should put together a Safari Plug-in SDK for iPhone OS, and let developers decide. It's no more difficult to create a Safari plugin for iPhone than it is for the Mac, and Apple can sandbox them as much as they like, run them in a separate process and use IOSurface to draw them in a web view. Let the plug-ins access the same APIs that App Developers can, and let any developer submit them to the App Store. Why should Adobe get special privileges? Why can't Engadget, say, write an iPhone plugin that adds additional interactivity to their website when viewed on an iPhoneOS device? Should we wait for the web to catch up, or should we make something great using native code?

To prove a point, I have sample iPhone Safari plug-in source code available from my GitHub. You can test it in the Simulator, or you can test it on a jailbroken device. Make something amazing with it, and give Apple a reason to give us a plug-in SDK.

Update

I posted a video on Vimeo showing part of Lights Off running as an iPad Safari plug-in, just to give a concrete example:

'Open'

If you're going to have a curated experience, isn't it better to at least have one where the curator is making their decisions primarily around the quality of your experience?

Jeff LaMarche on Android and openness. I fully agree.

The worst part of all this talk on 'open' is that the Android source code Google provides isn't the complete source code, and doesn't include any of the Google portions like Maps, Gmail, etc. To get those, you have to pay a lot of money to get an Android license from Google.

There's no less lock-in with Android than there is with iPhone, the only difference is you can install any app you want without paying extra. You still have to root your Android device (/jailbreak) to do anything interesting. Pay Apple's yearly $99 license, and you also get the ability to install any app you want without using the App Store (among many other benefits). You're trading one walled garden for another, except Google doesn't have any design or UX sense.

Very interested to see how Google's all-out assault on Apple this week will affect Apple's plans for 2010 and beyond. Google doesn't seem content without trying to oust Apple from every market they have (except the Mac). This is war.

Karma, Baby

Although Google launched the Nexus One with grand plans to radically change the way consumers purchased phones and service, it looks like the experiment has fizzled to an end -- the company just announced that will eventually stop selling handsets online…

Google's flagship 'superphone' a complete flop, carriers rejecting it left right and centre, and now Google halting online sales. I love news days like these.

Via Engadget

Pixel Doubling

Public Service Announcement for Developers writing iPhone apps that are not Universal; if you use UIImageView to draw your UI elements, and create your art at double size (pixel size, not DPI), it will render at its native resolution on iPad.

This way you can provide an iPhone app that's not specifically compatible with iPad yet doesn't render horribly when pixel doubled on the iPad.

I'm guessing this trick will also position you well for any future iPhone with a higher resolution screen that may or may not be announced next month.

As you can see below, when run at 2x on the iPad, the artwork remains crisp (naturally at the cost of larger file sizes for images).

Update:

Just to clarify, using a 2x image will use 4x the RAM as a normal image; it's up to you to figure out how the performance affects your application. Also, I haven't yet looked into a way of drawing text at the higher resolution (rendering the text to an image and using that is a possibility, but I wouldn't recommend something that clunky).

The Future of HTML

From Wikipedia:

The first web browser, WorldWideWeb, was developed on the Nextstep platform. Some features and keyboard shortcuts now commonly found in web browsers can be traced to Nextstep conventions.

The basic layout options of HTML 1.0 and 2.0 are attributable to those features available in NeXT's Text class

Makes you wonder, if the NEXTSTEP APIs directly influenced the web (history lesson: NEXTSTEP was the OS that became Mac OS X), how much of the future of the web will directly be based on the technology and design patterns used in the iPhone OS?

You laugh, but a lot of HTML5 (canvas, css animation) already comes directly from the Mac OS X APIs, where they were implemented first.

Food for thought.

Related reading: Joe Hewitt's thoughts on the state of the web

Jailbroken iPad Gets Mouse Support

Now all I need is Photoshop.

Via Sebastiaan de With.

Grace Support Blog Launched

Lisa has launched a new blog to directly support all the users of Grace, answer their questions, and provide a lot more background information about the project.

I wholeheartedly recommend anyone with questions or comments to check it out and get in touch. I merely handle the technical questions here, and my e-mail address is readily available on my main website.

3. Why is the Picture vocabulary on the App so Simple/Complex?

The pictures chosen were the absolute minimum required to create good sentences without the need for much scrolling or searching. There are much more complex apps for people with a sophisticated vocabulary out there already so we didn't need to go there.

I was also determined that the app would work in real time on the simplest and oldest devices - without any delay. So you press it and it appears. This was to make it as accessible as possible for people who might have an older phone or for first time users.

If you're not involved with children with special needs, and have old iPhones or iPod touches you'd like to donate to Autism Ireland to help support them, there are details on the site too.