This would be a smart move on Apple's part. There are already thousands of Mac Dashboard widgets in existence for Mac OS X, and since they're written in HTML/CSS and JavaScript, they don't need to be re-compiled for the iPad's ARM architecture - they can just run out of the box. So the barrier to entry to developing a Dashboard widget is much lower than that of a fully fledged iPhone app, and it is likely to prompt a mini-renaissance in widget development. This is great news for the iPad, and good news for Mac users, who should also see the benefit.
Of course, the question is, how will Dashboard be implemented? As a stand-alone app, as a part of the Springboard app (home screen), or as a system-wide resource that can be accessed while another app is running in the background. The latter scenario is obviously the one most favoured by those hankering for any conscession towards "multitasking" (or more correctly, running multiple apps concurrently).It's plausible that Apple may implement Dashboard as a system-wide service to be invoked in front of the active app. After all, the neat thing about Dashboard is that it's one process, which is running multiple gadget threads - so it can be implemented in a way that's pretty efficient in terms of processor cycles. However, the downside of this approach is that you might inadvertently trigger the Dashboard when you're in the middle of some other task - like playing a game.
I think it's more likely that Apple will introduce Dashboard as a part of the Springboard (home screen). While you can scroll from left to right to access Spotlight and the icon grids, I suspect that you will access Dashboard by scrolling down. And since Springboard remembers your state when you return to it, this means that you could have Dashboard appearing as your home screen every time you turn your iPad on.
The final touch would be to enable Mac users to sync the Dashboard widgets on their Mac with their iPad. Nice.



2 comments: