12
Feb 10

How to fit your website for the Apple iPad

Important note: Apple has not released any information about the iPad at the Safari Dev Center. This article is written on the assumption that previous guidelines for Safari on iPhone OS apply to version 3.2 and the iPad.

Step 0: Design for 980 pixels and do nothing

The width of the iPad screen when held in portrait orientation is 768 pixels. Since many pages (like the NYT, which Jobs has demoed) are wider than that, the iPad scales down pages.

Screenshot of the NYT website

The NYT website is automatically scaled down to fit on the iPad screen.

The default viewport width on the iPhone and presumably the iPad is 980 pixels. This means that pages are zoomed out until 980 pixels of horizontal content are visible. Text will wrap at 980 pixels, and elements wider than that will require horizontal scrolling.

If your site is designed to work at 980 pixels wide or slightly less, you probably don’t need to do anything. (Apart from not using Flash and the like, but we won’t go into that now.) The site will look all right, although a little bit small.

Step 1: Adjust your viewport settings

What if you don’t want automatic zooming? Perhaps your site is designed for a specific size, or maybe it flexes for different sizes. You’ll need to adjust the viewport settings with a meta tag.

City of Helsinki website screenshot

The City of Helsinki site is narrower than 980 pixels, causing unnecessary margins. Adjusting the viewport fixes this.

The viewport meta tag was introduced by Apple for the iPhone, and it has since been picked up by Microsoft for Windows Mobile and Nokia for Maemo. The tag is ignored by regular desktop browsers.

<meta name="viewport" content="width=device-width" />

The above example essentially sets the zoom level to 100 percent. More specifically, it makes Safari scale content so that the number of visible pixels matches the screen width. This is useful for flexible layouts, but you’ll have to make sure your site flexes to both the iPhone and iPad (see step 2).

A little gotcha is that Safari always calculates device width based on the portrait orientation. If you rotate to landscape, the content is not reflowed, but scaled up to fit the wider screen.

<meta name="viewport" content="width=800" />

You can also set the width to a specific number to fit content designed for that size. For example, a site designed to be 800 pixels wide can be scaled to show that exact width.

Be careful with using a number, however. If you set the number to 320 for the iPhone, the iPad will most likely obey this and scale your content way up.

<meta name="viewport" content="width=device-width, user-scalable=no" />

Adding user-scalable=no disables the pinch-to-zoom feature. This is useful for preventing accidental zooms and makes web apps feel more app-like. Still, consider if there’s something your users might want to see at a larger size.

Step 2: Make it flex

If you use the device-width keyword, you have to deal with greatly differing screen sizes. CSS media queries to the rescue.

CSS media queries allow you to specify completely different stylesheets depending on how large the screen is. You can have one stylesheet for the iPhone and other mobile devices, one for the iPad, one for desktops and so on.

An old CSS trick is to also include a print stylesheet, eliminating the need for a separate printer-friendly page.

<link media="only screen and (max-device-width: 480px)" href="small.css" type= "text/css" rel="stylesheet">
<link media="only screen and (min-device-width: 481px) and (max-device-width: 1024px)" href="medium.css" type="text/css" rel="stylesheet">
<link media="screen and (min-device-width: 1025px)" href="large.css" type="text/css" rel="stylesheet">
<link media="print" href="print.css" type="text/css" rel="stylesheet">

The above example gives a page four stylesheets, which are automatically switched based on need. The only keyword prevents non-CSS3-compliant browsers from picking up the smaller styles, while starting with screen makes them use the large one.

If you don’t include any media keyword or use all, every device applies the stylesheet. This is useful for global styles you want for each device.

You don’t necessarily need to split your CSS into separate files. You can also use media queries inside a single stylesheet.

@media only screen and (min-device-width: 481px) and (max-device-width: 1024px {
	body{
		//iPad body styles go here...
	}
	h1{
		//iPad heading styles go here...
	}
}
//Styles for all devices go here...

In the above manner, you can write exceptions for a single screen size inside an otherwise shared stylesheet.

For more information about Safari, see the Safari Dev Center.


05
Feb 10

Lost Tech: How Microsoft didn’t launch the ebook revolution

Microsoft Reader logo In 2010, Microsoft launched an electronic reading revolution. A unified publishing platform that works on desktops, tablets and mobile devices, complete with crisp typesetting, inline annotations and support from major booksellers like Barnes & Noble.

Oops, sorry. I got the date wrong, this actually happened in 2000. The rest of it is true. Except that the revolution fell pretty flat.

“We will look back in five years and be very excited about what has transpired”

In the late 1990’s, a group at Microsoft led by colorful characters such as Bill Hill was working on improving electronic reading. They produced two major contributions: the ClearType font smoothing technology still in use today, and a book reading application called Microsoft Reader.

Reader automatically formatted electronic texts and presented them one screen-sized page at a time. The interface was beautifully minimal, with as little distraction for the reader as possible. (Kindle for PC designers, take note.)

Microsoft Reader screenshot

Microsoft reader on Windows 98 and Pocket PC 2000.

The application was first released in April 2000 for Pocket PC, the forerunner of today’s Windows Mobile. A desktop version followed in August, and a Tablet PC version two years later.

One very powerful feature in Reader was its annotation capabilities. The user could highlight text, add their own notes and mark any number of bookmarks. There was also a convenient index containing all the annotations for a book.

The books themselves were in the proprietary .lit format, an offshoot of Microsoft’s Compressed HTML Help. Microsoft published a plugin for converting Word documents to .lit, and there were also third-party tools.

Microsoft’s first partner in their book effort was Barnes & Noble, who would sell titles in .lit format. There was a DRM scheme which required users to authenticate devices using Microsoft Passport (later renamed .NET Passport).

Going quietly into that good night

Unlike other products in the Lost Tech series, Microsoft Reader never really went away. It was simply… neglected. You can still download it from Microsoft today, although the company doesn’t seem to remember it exists.

Reader was closely tied into Microsoft’s Tablet PC vision, which steadfastly refused to generate sales. One clue about the intended device was that the desktop version had portrait-only windows. You had to either deal with a lot of lost space on the sides, or hold your laptop sideways and rotate the app.

The last update for Reader on the desktop was published in 2003. There was a version made for the failed Origami form factor in 2007. It quickly went the way of the dodo along with the Origami.

Perhaps the most damning point about the saga is that when ebooks turned hot once more, nobody at Microsoft remembered that they already have a platform. Instead of dusting off Reader, Steve Ballmer stood at the 2010 CES demonstrating Kindle software.

Oh well, at least we got ClearType. It only took until 2007 for it to become default on Windows.


01
Feb 10

(Not) scraping Wikipedia – the easy way

Q: How can I download an HTML-formatted Wikipedia article without navigation and theming?

A: Try this URL pattern: http://en.wikipedia.org/w/index.php?action=render&title=Helsinki

Today, I spent over an hour looking for this little URL parameter trick. What led me astray was that it’s not in the most obvious place you’d look – the MediaWiki API. Sure, you can get a parsed article out of the API, but it’ll be wrapped in unnecessary XML and character escaping. This gives you just the HTML you need. (There will still be infoboxes and edit links, but those are page content.)


25
Jan 10

The Apple Tablet: Web side story

Safari IconI’m going to make an unusual prediction for the Apple Tablet: it’ll be a great platform for web apps. How do I know this? Because of what’s on the iPhone right now.

At WWDC 2007, Steve Jobs infamously announced Apple’s “pretty sweet” solution for iPhone development: web apps. The response was developer derision and an eventual native SDK.

Nevertheless, Apple has been steadily working on web technology and improvements for Safari Mobile. Among the App Store hoopla, they’ve built a nice (if largely ignored) secondary app platform.

The rundown

Here are the key web app technologies present into the iPhone today:

Web clips

Web apps can put their icon on the home screen and launch just like regular apps. You get a full-screen view with no Safari UI, and even a custom splash image while loading.

Offline

Apps can be cached for completely offline functionality – all you need is a manifest. You also get HTML5 offline storage for all your database needs.

Location

Apps have access to Core Location (with user permission) for GPS and Wi-Fi triangulation. Just ask for coordinates through a JavaScript API.

3D effects

Apple’s extensions to CSS give you hardware-accelerated 3D transformations. It may not be enough for realistic games, but plenty for smooth animation, UI work and transitions.

Dashcode: Apple’s best kept public secret

Apple has published a JavaScript framework for making iPhone-like web apps, and a visual IDE to go with it. Dashcode used to be an editor for Dashboard widgets, but now it makes iPhone apps as well.

Making apps with Dashcode involves no HTML or CSS. Instead, you get an Interface Builder -like tool for visually constructing your UI out of ready-made parts.

The code side of Dashcode resembles iPhone development, though in JavaScript instead of Objective-C and Cocoa Touch. A list view is connected to a corresponding view controller, for example.

Dashcode includes several templates for common app needs such as hierarchic navigation and flip-around settings views. Apple has not been too busy documenting the system, though.

So, I hear there’s this tablet coming up…

The Tablet is supposedly based on the iPhone OS, and its version of Safari will no doubt contain all the same technology as on the phone side.

Obvious advantages for the Tablet are a bigger screen and more power. Web apps will launch faster, and they will have more real estate for compelling user interfaces.

What could Apple add to the Tablet? Some possibilities are more APIs for internal sensors (acceleration, compass), access to local data (photos, contacts…) and support for new multi-finger gestures.

Some of these additions are more likely than others. Web apps are not high on Apple’s list of priorities, so chances of integration with local data might be low. On the other hand, new gestures seem likely, especially if they bring benefits to all sites.

In any case, I predict that in the next year, there will be several high-profile web apps tailored for the Tablet. Web apps may not get the same kind of media attention as the App Store, but more and more developers will discover it.

And of course, there’s the matter of Google’s all-web-all-the-time Chrome OS. Having web app developers on their side might be a pretty smart move for Apple.


22
Jan 10

The Apple Tablet: Look at the size of that thing!

With the Apple tablet reveal less than a week away, it’s high time for me to engage in some idle speculation. The two questions on my mind are: what resolution is the tablet, and how will apps be made fit?

When it comes to the size of the tablet, there are three things I consider fixed:

  1. The iPhone has a resolution of 320×480 with a density of 163 PPI (points per inch).
  2. The resolution of 720p HD video is 1280×720.
  3. The tablet is widely rumored to have a 10.1-inch screen.

The third point needs to be taken with a pinch of salt, of course, but I’m not going to argue against it.

I’m going to assume that the tablet plays 720p video at native resolution. For a resolution of 1280×720 at a 16:9 ratio, a 10.1-inch screen has a density of 128 PPI. This seems reasonable, but I don’t think it’s quite right.

I think that the tablet is going to have the same 3:2 picture ratio as the iPhone. This will make it easier to port current apps to the tablet. Apple is also said to invest heavily into digital reading, and 3:2 seems a more comfortable ratio than the very wide (or tall) 16:9.

Let’s make the screen a little bit taller. The ratio is now 3:2 but native 720p video fits inside, letterboxed. This gives us a resolution of 1280×854. It may seem a little oddball, but Apple used to make PowerBooks with the same resolution. Density for a 10.1-inch screen is now 152 PPI, which is closer to the iPhone.

Resolutions of the iPhone, 720p video and my tablet estimate.

This is naturally all guesswork. A large high-density screen might be too expensive, or Apple might opt for a more common resolution for the sake of mass production. Still, this is my best guesstimate.

What about apps, then? I’m taking it as given that Apple is making a custom UI for the tablet and not running standard OS X applications. They’ll also want to have apps quickly, so repurposing existing iPhone apps make sense.

The tablet has several times the screen real estate of the iPhone – seven times as much in my estimate. I doubt that Apple is going to implement windowing on the tablet, so apps have to be made to fill up the screen.

The simplest solution is to scale up existing apps – made much easier if the tablet has the same image ratio. It’s a stopgap method only, as blowing up the interface is going to provide a poor experience in most cases.

The buttons from Twitterrific appear gigantic at tablet sizes.

Apple has been working on density-independent interfaces for years. Existing apps might automatically benefit from this through bigger, native-resolution fonts and controls. Any bitmaps, however, will appear jagged or blurry after zooming.

A bigger problem is that enlarged versions of small-screen interfaces make little sense. Elements will be uncomfortably large, and any touch gestures will have to be scaled up as well. It’s a different thing to swipe across a phone screen or a tablet.

Developers are going to want to tailor their apps for the tablet, and for that they need a UI toolkit. The UI conventions of the iPhone and the Cocoa Touch library are made for a phone-sized device. When kept the same size but spread across a bigger screen, they appear ridiculously sparse.

A mockup of the current iPod app adapted to tablet size, clearly not viable.

What new UI elements could Apple provide? Some obvious choices are Cover Flow and a tablet-friendly version of the grid views in iTunes and iPhoto. A version of the column view from Finder could be used in place of hierarchic lists.

On a higher level, tablet apps don’t need to consist of tiny screenfuls at a time, like iPhone apps do. There will be less navigation and more context – more onscreen at the same time.

All of this is known to Apple, and they’ve no doubt been busy at work creating new interface conventions for the tablet. They have to present an easy way for developers to shift into the tablet without dragging in too much of the phone or the desktop. It’s a tall order.

I can’t wait until Wednesday.


18
Jan 10

Lost Tech: Put on your Magic Cap

This article is part of a series on forgotten technology.

Motorola Envoy

Motorola Envoy, a Magic Cap device with built-in wireless.

Before the PalmPilot and Apple Newton, there was Magic Cap. It was a PDA operating system with the communications at its heart, a focus on object-oriented distributed computing… and an interface that was a total woozy.

Magic Cap started out as an internal project at Apple called Paradigm. In 1990, it was spun out as an independent company called General Magic. The OS was licenced to hardware manufacturers like Sony and Motorola, who produced several models.

Magic Cap devices were PDAs, with functions such as address book and calendaring. They were also built for communications from the start, with fax and email functions as standard. Later models would feature web browsing as well.

The devices were pen operated, but featured an onscreen keyboard for typing. Two later prototypes had a physical chicklet keyboard, but these were never released.

Wireless networks were in their infancy in the early 1990’s. Some models like the Motorola Envoy could do wireless email – at an extreme cost. Others would actually plug into a phone line for connectivity.

Metaphors and objects, oh my!

The interface is heavily laden with metaphors.

The Magic Cap UI was based on a desktop metaphor, but it was carried much further than in for example the Macintosh. The system showed an actual cartoon desktop, with objects like a rolodex and paper pad on it.

Drawers, shelves, rooms and and buildings were used as metaphors for different levels of the system. There was even a tote bag which you had to use to carry objects from one place to another.

Email allowed in annotation and graphic stamps – if the recipient also had Magic Cap.

Real-world methaphors were found in unusual places. For example, when sending a message, you had to choose how it was delivered: email, fax or pager. Instead of using a menu, users affixed different kinds of stamps to a postcard which represented the message.

Cloud computing in the nineties

On the programming side, Magic Cap was built around the idea of software agents, popular in the early 1990’s. The agents didn’t appear as actual characters, although that would have been in line with the Microsoft Bob -like interface.

The idea was that agents written in the proprietary Telescript language could be started on the device, travel onto an outside server to do work and then return with data.

Internet Center, Magic Cap's connection to the famed Information Superhighway.

Telescript was an object-oriented language which with an ahead-of-its-time cloud computing flavor. It was specifically designed to run on distributed server systems. The only service actually available, though, was PersonaLink from AT&T.

The aftermath

Like most pen-based projects of its age, Magic Cap never really took off. It may have been the clunky hardware, lack of network services or cartoony interface. In any case, the devices were never a financial success.

General Magic eventually went in different directions, developing speech-recognition telephony services and automotive assistance systems. Magic Cap was spun off once again in 1998 as a company called Icras, but that company faded away soon after.

There was an effort by some Magic Cap developers to get the system released as open source, but this was not successful. Still, the developer documentation remains online for those interested in this bit of PDA lore.


08
Jan 10

Lost tech: Microsoft chromes up the browser

This article is part of a series on forgotten technology.

DirectAnimation sample

Sample of the DirectAnimation technology that was spun off Chromeffects.

Long before Google, Microsoft had a browser technology codenamed Chrome. It was a merging of 3D and web content, complete with XML-based modelling and hardware acceleration.

In July 1998, Microsoft announced the near-complete project under the name Chromeffects. A SDK was released, partners were prepped for an imminent launch. And then Chromeffects disappeared without a trace.

A lot of bling for a little band

So what went wrong? To answer that, let’s begin with what Chromeffects was meant to be. In 1998, the web was still fresh and bandwith was low. Most people were still on 28.8 modems, and broadband was a futuristic dream.

At the same time, 3D accelerator cards were beginning to take off. For the first time, you could have reasonably smooth texture-mapped animation without punishing the processor too heavily.

Microsoft figured that you could improve the web experience with client-side graphic effects. These effects would involve only a little markup, with most of the code already installed on the browser.

At the simplest level, web designers could add 3D transitions like ripples and page curls with a touch of markup, much like CSS styles. Chromeffects could also draw full-blown 3D objects, which were defined with a proprietary XML-based language.

Perhaps the most impressive feature of Chromeffects was to map live web content onto 3D surfaces. Video streams could also be used in the same way. One simple demo was a 3D cube which the user could spin, with a different web page on each surface.

An obvious use for these effects was advertising, with mentions of animated 3D banners. Web applications were also appearing on the scene, and there was talk of using animation to enhance web UIs. Another proposed use was 3D visualization for databases.

The makings of a ruin

Although 3D hardware was picking up, effects such as these required the very latest gear: a 300 MHz Pentium II, 65 megabytes of memory and an AGP graphics card.

Here, then, was the first issue: you couldn’t install Chromeffects on most computers of the time. In fact, Microsoft decided to make it an OEM installation only, and an optional one at that.

By November, the plan had changed to making Chromeffects a part of Windows 98 SP1, but by then everything was basically over. Microsoft had a major internal restructuring, and the project fell by the wayside.

Another thing that may have contributed to the fall of Chromeffects was pressure from other browser manufacturers and the W3C. After all, this was the time when the Department of Justice was coming down on Microsoft for bundling IE with Windows.

A brand new bundled media technology in Windows did not look good for Microsoft. Furthermore, Chromeffects was seen as competing with such key technologies as Java and RealPlayer.

The leftovers

What remains of Chromeffects? Not much. Parts of it, like DirectAnimation and DXTransform, made it into IE5. These techniques added animation capabilities, but they were little used. DirectAnimation was discontinued in IE7 because of security issues.

Now in 2010, 3D on the web is once again trendy. Apple has released 3D transformations for CSS, which share a lot of the same low-band effect thinking as Chromeffects. Mozilla and Khronos are working on a web version of OpenGL called WebGL.

And Microsoft, of course, is busy bringing 3D to Silverlight. With hardware acceleration, and all that.


24
Dec 09

Happy Holidays, Hyvää Joulua!


18
Dec 09

Polite extensions in Chrome

Noticed a nice design in Chrome’s extension mechanism:

Updated extensions requires additional permissions

Extension requests additional permissions


15
Dec 09

Lost tech: Pippin, Apple’s game console

A somewhat rare American version of Pippin, produced by Katz Media.

A somewhat rare American version of Pippin, produced by Katz Media.

Apple went on a number of wild goose chases in the 1990’s, investing heavily in things like OS development with IBM and tablet computing. One project they actually got to market was Pippin, Apple’s first and only game console.

If you never knew Apple had a console, you’re not alone. Pippin was largely ignored outside of Japan, and even there it was a flop. A major part of the problem was that Apple didn’t really intend Pippin for gaming.

In the early to mid-90’s, CD-ROM multimedia was a big buzzword. Major publishers were pushing out reference works, educational titles and simplistic games on shiny optical discs. It seemed obvious that CD-ROM would migrate out of computers into mainstream electronics.

Pippin was a console-like device for running desktop-style multimedia content on your TV. As the Internet was starting to pick up steam, Apple threw in a rudimentary web browser and online service as well.

The Pippin controller had an unusual feature: a trackball.

The Pippin controller had an unusual feature: a trackball.

Hardware-wise, Pippin was a PowerPC Mac, although one with a pad controller instead of a mouse. The software experience was simplified: the device booted off the CD-ROM and started whatever program was on the disk. The user never saw a Finder desktop.

Every Pippin disk had to contain a variant of Mac OS, and they were signed with a key provided by Apple. Apple licensed the hardware and marketing to the Japanese toy maker Bandai, who also produced the majority of Pippin software.

As it turned out, people didn’t really want a multimedia appliance, and certainly not one that cost $599. Pippin wasn’t really intended to compete with the Playstation or Nintendo 64, but that’s what it ended up being compared to.

Bandai only managed to sell 42 000 Pippins before pulling the plug. Apple has stayed out of the console business since. They have however found their own niche in the iPod Touch, which is now heavily marketed towards mobile gaming.

This has been part one in a series on forgotten technology.