iPhone had the first two store UIs; the iTunes Store for content like music and movies, and the App Store for software. The iPad will add a third, the iBookstore, for buying eBooks. These stores all provide content for users to extend the utility of their device. But each has a pretty different user interaction model for accessing, purchasing, and consuming that content.

  • The iTunes Store is a separate app that is completely distinct from the iPod app. When you find something to buy, prompting you for your iTunes account password. It then adds the purchase to the app's Downloads tab. Once you have purchased the content, you must then switch back to the iPod app to listen to or watch it.
  • The App Store is a separate app. When you purchase something, it prompts you for your iTunes password, and then exits to the home screen, switching to the screen where the app will live. The state of the download is reflected in the app icon. When the download is complete, you tap the icon on the home screen to use it.
  • The iBookstore (the one word is the official name as used by Apple) is not a separate app, but lives within the iBooks app on the iPad. Purchasing content prompts for the iTunes password and downloads in-app, which can be directly accessed after it has finished downloading.

Each type of content follows a different workflow when going from access to purchase to use. If a goal of the iPad's low price is to drive content sales through the three stores, as some speculate is the case, then the purchase model should be as streamlined for the different types of content. Forcing different workflows will only confuse users who can't remember which type of content comes from where.

 

We've all got our thoughts on what the Jesus Tablet will be, so here are my guesses. I fully expect to be completely wrong on all of this, as many of these answers are completely blind shots and that Apple will blow my expectations out of the water.

Hardware

  • 8"-10" touch screen, running at 1280x720
  • Very thin; less than 1/2" thick (the iPhone 3GS is 0.48" thick)
  • About 1lb heavy, light enough to hold in one hand
  • 8 hours of battery life
  • 32 or 64 GB SSD
  • WiFi
  • 3G over GSM, and Apple's US 3G partner will continue to be AT&T
  • There will be some way to pair your Tablet cell connection with your iPhone's cell connection; either with an official announcement of AT&T tethering, or by adding your Tablet to the 3G account
  • Front-mounted camera
  • Some kind of collapsible stand in the frame, so the device can sit on a table

Input/Output

  • Multi-touch on the display, exactly like the iPhone
  • Multi-touch on the back of the device, similar to the surface of the Magic Mouse
  • Photos and video via front-mounted camera
  • Audio via front-mounted microphone and speakers, wired headphones, or Bluetooth
  • Dock connector
  • Expanded voice recognition
  • Software keyboard, no Bluetooth keyboards available

Software

  • It will run the iPhone OS 4.0; or rather, the iPhone OS will become a "Mobile OS X", consisting of the heavyweight Tablet and the smaller iPhone.
  • It will allow multiple apps to run at the same time, with some UI for viewing multiple apps alongside each other. This may not be possible on the iPhone.
  • It meant to replace a full PC for most common day-to-day needs
  • iPhone applications will not run "automatically", but will need to be resubmitted through the App Store approval process. Most applications will run without much modifications. Icons will need to be higher resolution.
  • A system-wide Dock for documents, applications, and small widgets will be onscreen at all times
  • The home screen will be significantly revamped, and renamed to the Dashboard. App icons, web clippings, and widgets will be freely arrangeable.
  • Handwriting recognition will be available for text input, with an optional stylus, or with a gesture such as two closed fingers drawing as if you had a pen.
  • Some gestures will be used on the back of the device, such as scrolling and zooming.

Apps

  • Standard kind of iPod and Internet communications apps the iPhone OS comes with. iTunes video, iTunes LP content, Maps, and Safari web content will look phenomenal.
  • Sketchbook, an unlimited workspace to sketch and write notes, with collaboration features.
  • iWork, a full port of the iWork application suite, tied to the Internet (and expansion of the iWork.com web application), with collaboration features.
  • iChat, a port of the Mac app, with a heavy emphasis on video conferencing

SDK

  • The SDK will be available immediately, with a simulator.
  • There will be an emphasis on application interoperability.
  • Applications will be able to register plugins with view controllers and UTIs. When an application wants to expose an object (say, an image) to other apps, it will look for app plugins which respond to the "public.image" UTI, load one which matches the UTI, and present the view without leaving the application.
  • Applications will be able to expose services, similar to how they work on Mac OS X. Services will be integrated into the voice control system.

Product

  • 32 GB model will be available for $899
  • 64 GB model will be available for $999
  • Available in US in March, major countries by summer
  • There will not be a WiFi-only model at launch.

Other Predictions

  • Updated MacBook Pros and MacBook Airs, with the mobile Core i5 "Arrandale" processors from Intel.
  • There will be no mention of Verizon
  • There will be no updates to the iPod or the Apple TV
  • There will be no announcements of the iPhone 4G
 

Ars Technica:

ChangeWave queried 4,068 current and potential smartphone consumers last month and noted that a full 21 percent said that they would prefer Android on their next smartphones—a jump of 15 percentage points from the year before. Comparatively, 28 percent of respondents said they would prefer iPhone OS; this makes the iPhone the leader in this category, though this number dropped four percentage points year over year.

Many iPhone developers and Apple enthusiasts are quick to shrug off the Android platform, for a variety of reasons ranging from aesthetic and design, to functionality and developer tools. Many of these criticisms are certainly valid. But iPhone has its own share of problems, and certainly is deficient in many ways to the Android.

With Google's press conference tomorrow, and CES for the remainder of the week, there will be a lot of focus on the Android platform. It will become a much stronger platform in 2010. It will be interesting to see how Apple responds with iPhone OS 4.0 (which history suggests they'll probably talk about in March).

 

VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.

Stylesheets

VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the "active" stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you'll want to tell your views to update their styles and redraw.

Styles

Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills
    • VSSolidFillStyle - Fills the current shape with a solid color
    • VSLinearGradientFillStyle - Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle - Fills the current shape with a glossy-style gradient between two colors
  • Borders
    • VSSolidBorderStyle - Draws a border around the current shape with a solid color
    • VSBevelBorderStyle - Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle - Draws a border around the current shape with four colors, one for each edge
  • Shadows
    • VSShadowStyle - Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle - Draws a shadow inside the content with a given color, blur, and offset
  • Positioning
    • VSBoxStyle - Adds a margin or padding to the content area
    • VSInsetStyle - Adds edge insets to the content area
  • Content
    • VSTextStyle - Draws text inside the current shape
    • VSImageStyle - Draws an image inside the current shape
    • VSMaskStyle - Clips the drawing area to an image mask
    • VSShapeStyle - Clips the drawing area with a VSShape object

Shapes

Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape - a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape - a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!

Status:

Active

 

While the WebOS SDK is not yet publicly available, Palm is seeding it to select developers. One of them came forth yesterday to talk to Ars about the new Palm device, OS, and Mojo framework.

 

There's been quite a bit of misunderstanding about what Palm's new WebOS is, versus what it isn't. So I'd like to dispel some of the questions surrounding it from the information I've been able to find on it. There isn't much I was able to find (not surprising, as the thing was just announced today), but we can draw some conclusions from the information.

From Web Apps to Widgets

Many people will respond with derision at the fact that applications in WebOS are built with HTML, CSS, and JavaScript; given the state of most web applications today, this isn't hard to understand. However, the biggest reason web apps are crap compared to their desktop equivalent is that web apps have no integration with the host OS. Which means that web apps have a tough time dealing with multiple OS windows, the clipboard, and offline access.

When Apple released Tiger, they shipped with it the popular Dashboard interface. Inside were miniature applications which were also written with HTML, CSS, and JavaScript. There was a slight difference, however; Apple included the means to integrate the Dashboard with JavaScript. One example is how a Dashboard widget will display its settings via a smooth, GPU-accelerated 3D animation where the 2D widget flips over. This is possible because Apple included JavaScript hooks to perform this animation. But the core tools were just the same - HTML, CSS, and JavaScript.

The Mojo Framework

WebOS applications are much more sophisticated than Dashboard widgets, and certainly more so than regular web applications. This is because WebOS includes a set of tools for creating apps, called the Palm Mojo Application Framework. This, at its highest level, is conceptually similar to Cocoa Touch on the iPhone; it provides common functionality to all applications. It's what will provide all the common code on the device, from data manipulation of stuff like your calendars to the whizzy animation effects you'll see throughout the interface. It's the reason that, in most iPhone apps, the scrolling behavior feels exactly the same.

So, from what I can tell, the Mojo framework is an implementation of all of these ideas, using JavaScript as the programming language, and using HTML5 and CSS for drawing to the screen. Despite there being very little information, they do mention the following features on the developer website:

  • apps are installed and run on the device,
  • apps are designed to be multitasked and run in the background,
  • apps have full access to gestures and the touch screen,
  • apps can use a Growl-esque system to display user notifications,
  • apps will have access to sqlite databases for data storage (part of HTML5), and
  • apps can exchange data via a common messaging mechanism.

The Performance Argument

"But won't it come down to speed?" Yes, it will. However, WebOS is based on WebKit, and likely is using the latest enhancements from the SquirrelFish project. There is a battle royale going on right now between the developers of WebKit, Firefox, Chrome, and Opera for fastest JavaScript interpreter, which means that JavaScript is only going to get faster and faster.

Why go with JavaScript? It provides a low barrier to entry; nobody really needs an SDK to write apps. It makes it very easy to sandbox apps, as the underlying operating system is still invariably written in some form of C, and JavaScript provides no way to break that barrier. And many other reasons, which I talked about last year before the iPhone SDK came out.

tl;dr: JavaScript is just a language. Palm used that to build a system for making applications. They're nothing like web apps.

 

This is big news, because WebOS is supposed to be their big SDK, and it's all based on WebKit. This means their JavaScript engine will probably be JavaScriptCore (with the enhancements from the SquirrelFish project).

 

I'm dying to see a video of this in motion. Their new developer platform appears to be very similar to Dashboard on the Mac; apps are written with CSS, HTML, XML, and presumably JavaScript.

 

Google's iPhone app has some hidden features. The coolest of all is the live waveform while speaking into the microphone, although the most useful is the ability to open links from within the app itself.

The UI they use to enable the more advanced features is pretty intuitive, too. Just keep scrolling up, and the "Bells and Whistles" row will eventually appear.