Browser/OS stats for this blog

I was looking through the blog’s stats, and the browser and OS stats seemed kind of interesting.

• 63% Firefox
• 15% Chrome
• 10% Safari
• 8% Internet Explorer

• 40% Macintosh
• 37% Windows
• 16% Linux
• 2% iPad
• 2% iPhone
• < 1% Android
• < 1% Other Unix

Based on what I’ve been seeing from more generic reports, that seems atypical. I’m surprised that Chrome isn’t closer to or a bigger percentage than Firefox. I’d expect Safari and IE to be reversed, but they are pretty close. It seems that fewer of my visitors who use Macs use Safari than I would’ve thought.

For this blog, that’s pretty much just trivia. If you are someone who has to make decisions based off this kind of data, though, I can’t emphasize enough how important it is to collect your own data rather than relying on what others report. e.g. When I was in the shrink-wrapped software business, Macs made up a lot more of my company’s market than the general marketshare they held at the time.

Is Apple prepping a new programming language?

waffle → Surpass:

It is my belief that Apple is definitely working on a new language to surpass Objective-C as their intended, primary, publicly recommended programming language...

I’ve been thinking that it seems very strange that Apple’s primary language is (still) Smalltalk grafted onto C.

If he’s right, I hope that, like the A4 processor (which is ARM based) and Safari (which is HTML, CSS, and Javascript based), it isn’t a wholly new language.

Would Smalltalk be a hard sell to developers who have accepted Objective-C?

iMac apps vs. iPad apps

In a comment to I’ve Changed My Mind About The iPad, Joeflambe wrote:

yuck, an iPad, really?

not a real computer since there are no real apps that you use daily on your current computer.

This seems like an interesting exercise. Let’s look at the most used apps on my iMac and whether there is an iPad equivalent.

• Safari: Check

I have a Flash blocker installed on my iMac, so lack of Flash on the iPad isn’t much of a change for me.

• Mail: Check
• iChat: Check (AIM)
• iCal: Check
• Address Book: Check
• iTunes: Check
• iPhoto: Check
• GarageBand: Check (StudioTrack)
• Evernote: Check

Now, to be fair, the iPad equivalents of the above do not always have all the features of their Mac counterparts. The main functionality is there. The rest...well, the iPad isn’t even a year old yet.

• Preview (as PDF reader): Check

The iPad has PDF reading built in, but no specific app for it. I do most of my PDF reading/referencing in GoodReader.

• iWork: Check

Some people will say matter-of-factly that nobody is going to want to write a term paper or create a spreadsheet on an iPad. shrug

OK, Pages for iPad doesn’t have footnotes...yet. It can’t print directly from the iPad—though Jobs himself has allegedly acknowledged that printing is in the works. (Yes, I’ve seen the photocopier pic. I LOL’d...the first time.) With my Bluetooth keyboard, I can’t see why I wouldn’t write a lengthy document with Pages for iPad. Even if I currently have to move it to my iMac for the finishing touches.

The whole keyboard + iPad topic is fodder for its own post.

I’ve created a few spreadsheets on the iPad. No less complex than those I would have created on my iMac. Although, I’m not that much of a spreadsheet user.

The iPad actually seems like a fine platform for creating presentations. We’ll see how it goes when I next need to create one.

• GuitarPro: Strike

I recently bought this Mac app. In fact, I bought it—in part—to produce content for the excellent TabToolkit iPad/iPhone app. (The fact that I can’t use it for that at the moment could be another post.) This is another app—like Keynote—that might actually work as well, if not better, on the iPad.

• DrScheme: Strike

Unfortunately, Apple’s rules don’t allow for an equivalent to DrScheme.

What if? Well, if it were a fairly straight port, it probably wouldn’t work very well without a keyboard. (Which is OK; I have one.) I can imagine a visual/touch interface for editing Scheme source code, though. (I’m imagining something like what I imagine the Viaweb editor was like.)

I think you could do a “DrEcmaScript” within Apple’s rules, though. As either an app (if it used WebKit) or a web app. I suppose a Scheme interpreter written in Javascript would be allowed, though perhaps not practical.

So...only two strikes.

It might be interesting to look through my iPad apps and see which ones don’t have Mac equivalents...or those for which I wouldn’t want a Mac equivalent.

Is the iPad going to replace my iMac? No, I don’t think so. Not anytime soon. It can, I think, come astonishingly close, however. There is a lot of overlap between the Mac, iPad, and iPhone; but there’s also enough outside those overlaps to justify each. The overlaps mean more flexibility.

The iPad may not replace my iMac, but imagine an iPhone OS desktop device. That might. Of course, being a programmer, I might still want a Linux/FreeBSD system for tinkering. (One of the nice things—for me—about Mac OS X is that I can get to the BSD personality underneath it when I want to.) For getting things done, however, I’m happy to use “app consoles”.

Scratch (no longer) on iDevices

More iPhone PL lockdown...Goodbye Scratch!

My wife has taught a couple of classes using Scratch with young kids, and to see the pride they feel at their creations is a marvelous thing. I think restricting their ability to share that feeling is really reprehensible. And the damage done to the programmers of tomorrow? Hard to say...

Damage?

Should Apple allow Scratch on iDevices? Yes, I think they should. Does the lack of Scratch on iDevices mean that kids are prevented from programming for iDevices? No. I looked over Scratch, and everything important that it does could be done in Javascript and work with Mobile Safari.

Is Javascript slow on iDevices? Yes. Is it slow enough to make something like Scratch impractical? I doubt it.

Apple’s mistakes

From the iPhone OS 4 SDK, section 3.3.1 of the iPhone Developer Program License Agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This is one of the ways that Apple is keeping Flash off iDevices. It—intentionally—keeps more than Flash off of them. (See “Thoughts on Flash”.)

It is, unfortunately true, that cross-platform frameworks often have lousy user experiences. Not merely “un-Mac-like” but just plain bad. It’s true that they often only end up supporting the lowest common denominator. It doesn’t have to be like that, however. Cross platform frameworks can support platform-specific features. I’ve worked on ones that have. It is all too rare though.

There’s also the fact that some apps—especially some games—don’t really need standard user interface elements. Flash (and other options) can work well for these things. If anyone chooses to use Flash for another sort of app, they’ll quickly lose to non-Flash apps. I’m glad not to have Flash in Safari on my iPhone or my iPad, but I don’t mind Flash apps.

Section 3.3.1, however, doesn’t only ban cross-platform frameworks. It bans writing honest-to-goodness Cocoa Touch apps written in any but the specified languages. (“Platform Control” by Mark Bernstein.)

It has been suggested that a compromise might be to require any frameworks to be open source. (“A reconciling proposal” by Michel Fortin.) That way, any developer that needs access to a specific feature can add it to the framework. That’s a good idea. Yet, the truth is that such extensions to a framework can be a lot of work—especially for someone who normally only uses the framework.

Ian Bogost has written that “Flash is not a Right”. He is right, I suppose.

Putting aside rights, however, I have to wonder if this is really in Apple’s best interest. I have to wonder if this is really in the best interest of Apple’s customers. Apple’s biggest mistakes, I believe, are when they try to compete via the law. Whether through intellectual property or license agreements. They compete and win in the market. They don’t need to play the legal games.

Do you really need Flash for the Web?

Do you really need Flash for the Web?
Originally uploaded by Kendall Helmstetter Gelner

Actual screen shots from an iPhone of the sites Lee Brimelow used in his “oh noes...the Internet on iPad won’t work at all without Flash” mock-ups. It turns out that six of the ten serve up Flashless versions of themselves to the iPhone.

On the iPad/Flash brouhaha

In a comment to this Smarterware blog post, Mark Williamson asks:

I am so torn, do I support 94% of my customers? Or do I let the 6% with either a choice that they made to not have flash or a choice that was made for them by their device supplier dictate how my site might work?

What you do is simply this: You make sites that degrade gracefully. That means you don’t use Flash (or any other such technology) for stuff you don’t need to use it for.

For example, I ordered pizza from Domino’s online recently with Flash disabled. I didn’t get to see the fancy preview image of my pizza with the toppings composited onto it because it required Flash. The actual functionality of the site—ordering food—worked perfectly fine without Flash.

John Nack writes:

And today, more than 15 years after Netscape debuted, Flash remains the only way to, say, display a vector chart across browsers (i.e., such that you can count on every viewer seeing it).

Except that you can’t count on every viewer seeing it. See the Smarterware post above. Those figures don’t even count most iPhone and iPod Touch traffic. That is why nearly every feature that has been added to the web over the years provides for providing alternate content for browsers that don’t support that feature.

It also doesn’t count the visually disabled who can’t see the chart even if they have Flash installed. This is why the standards today provide ways to provide text descriptions of visual elements.

If you use Flash to show a vector chart without providing a raster alternative and a text description, some “viewers” aren’t going to be able to “see” it.

Apple doesn’t support Flash on the iPhone, the iPod Touch, and won’t support it on the iPad. This is not about Flash vs. HTML5. This is not about Apple vs. Adobe.

Apple is not supporting any browser plug-ins on the iPhone OS devices. Why? Because browser plug-ins are the biggest source of Mac OS X crashes.

If you follow the advice of Lee Brimelow, as he wrote in the comments to his “The iPad provides the ultimate browsing experience?” post...

If you can do something in HTML then we recommend people to do that. Use Flash when you need richer interactivity. It’s not HTML OR Flash. They can coexist.

...then the iPad not having Flash won’t be a problem. Flash is for the butter, not the bread.

So, is Apple lying when it claims the iPad is “the ultimate browsing experience”?

sigh

Where to even start? The fact that this is opinion? (It’s not hard to find someone who feels that browsing without Flash is better than browsing with it, by the way.) The fact that it is marketing?

Flash on the iPhone

So, Adobe has given Flash developers the ability to build stand-alone apps for the iPhone. There will still be no Flash support in Safari or any other web browser. If you want to write an iPhone app, you won’t want to use Flash; but if you have a Flash app you want to port to the iPhone, then this looks pretty good.

Honestly, I really like this situation. The type of Flash content I’d like to see on my iPhone are the things that are essentially apps. Not having access to Flash used to make annoying web sites doesn’t really bother me.

A good thing about “full page zoom”

I really didn’t see any need for web browsers to implement “full-page zoom”. Pretty much the only times I’ve wanted to zoom-in on a web page it has been because it used too small of font in too wide of a layout. Making the text larger while keeping everything else the same size was exactly what I wanted. Thankfully, Safari (at least) has keep text-only zoom as an option.

Today, though, I realized a use for “full-page zoom”: To make an overly wide web page narrow enough to fit in my browser window by zooming out.

Of course, I wouldn’t need either use of zooming if people did a better job of designing web sites. Yeah, and I realize my idea of “better” is different than some other people’s. But they’re wrong, and I’m right. (At least, here on my blog.) (^_^)

Now if I could only use “full-page” zoom-out and text-only zoom-in together!

HTML 5 <video>

There’s some brouhaha over the decision that the HTML 5 standard (a work in progress) will not require browsers to support any specific codec(s) for the <video> tag. So...my 2¢...

Submarine patents: Really? You’re paying the licensing fees to implement the heavily patent encumbered H.264 codec, but you absolutely refuse to implement (or just take advantage of the open source code for) Ogg Theora because you’re afraid it may be discovered to infringe a patent? Despite the known patents covering H.264, isn’t it just as likely to be a victim of an as-yet-unknown submarine patent? It doesn’t look like the licensing future of H.264 is all that clear either. It’s hard for me to believe that Ogg Theora is any bigger a risk than anyone who has implemented H.264 has already assumed. I think Apple can weather any submarine patents better than Mozilla.

Quality: What does it matter whether Ogg Theora isn’t as good as H.264? Implementing Ogg Theora doesn’t prevent you from also providing H.264 as well. This is not an argument for opposing Ogg Theora being required by the standard or for refusing to implement it. Does iTunes refuse to play mp3 files because AAC are higher quality? Does Safari refuse to play mp3 files?

I don’t buy that HTML 5 should only codify what the browsers do. (Would there even be a <video> element to be debated if that were really the case?) A standard—backed by pressure from actual customers and implemented by competitors always looking for another bullet point—can and has convinced implementors to do things they wouldn’t otherwise.

That being said, I fully respect Ian Hickman’s decision as editor. It was a good decision, whether I might nitpick it or not.

And really, I haven’t been following HTML 5 as closely as I probably should be. Not to mention that, as interested (although that word seems entirely inappropriate) as I am in intellectual property law, I’m far from an expert on it. And my knowledge of video codecs is only having implemented some old codecs. (^_^)

Web browser: lousy universal client

I think the iPhone is reïnforcing for me is that web browsers still aren’t a good universal client, despite how far they’ve come and despite their success in that area. I almost always prefer a stand-alone iPhone app to accessing the site itself via Mobile Safari. Even sites that are optimized for Mobile Safari. Heck, I sometimes prefer the iPhone app to the site on my desktop web browser.

While I haven’t tried my hand at writing an iPhone app, I suspect they’re often easier to write than the web app itself.

There’s also the observation that the optimized-for-Mobile-Safari version of a site is often better than the site itself. So how much of it is that web browsers make lousy universal clients and how much is it that they merely aren’t well used?

Safari wish list

New tab toolbar button

Odd that this isn’t an option.

Copy text of link

The context menu for a hyperlink gives the option to copy the link, but not the option to copy the text. Oddly enough, choosing Copy from the Edit menu does copy the text.

“Open in...” for incomplete URLs

If you select some text that is a URL (though not a hyperlink), the context menu will have “Open in new window” and “Open in new tab” options. If it is a partial URL, however, these options aren’t given. If we’re dealing with a raw URL that isn’t a hyperlink, there’s a good chance it won’t be a complete URL either.

Search in Google in a new tab

Select some text, and the context menu will give you a “Search in Google” option. More often than not, however, I’d rather “Search in Google in new tab”.

Add RSS feeds to Google Reader

When Safari sees a page with an RSS feed, it makes it easy to subscribe to it with Safari or Apple Mail. I miss the way Firefox would add RSS feeds to Google Reader.

Go To Address...

I’m surfin’ around the net, and I come across a raw URL that isn’t wrapped in a hyperlink.

Sigh

Select. Right-click. Copy. Create a new tab. Click in address bar. Right-click. Paste. Hit return.

Wait a moment! Select. Right-click. “Go To Address in New Tab”!

It’s such a little thing, really; but it makes me smile.

Firefox 3

It’s strange. I can’t really work up any enthusiasm for Firefox 3. I guess I’ve fully switched to Safari now.

Why it’s hard for Safari to be my main browser

• Blogger (a Google site)
• Google Notebook (there is an iPhone version that works beautifully with mobile Safari, though)
• Google Docs (the iPhone version appears to be read-only (u_u))

But there is that whole integrated with the rest of the system bit. Working with keychain. Working with the Services menu. Syncing bookmarks with my iPhone.

Whither cut, copy, & paste?

I found some good tips on less obvious iPhone features. I thought I’d e-mail them to myself and then copy them into an iPhone Note.

As far as I can tell, there’s no way to do that. I’d already been aware of the lack of traditional cut/copy/paste, but this was the first time I really found it getting in my way.

The tips were...

• E-mail: Swipe you finger over the listing to quickly show a delete button.
• Quick punctuation: Hold the punctuation button & slide to the key.
• Settings → General → Keyboard → Enable Caps Lock. Then double-tap the shift key to lock it.
• Tap “AT&T” at the top to jump to the top of a web page.
• Use two fingers to scroll text areas, form fields, or scrollable iframes.
• Touch & hold a link to see its destination. (To cancel, drag before lifting your finger.)
• To mark an e-mail as unread, click “Details” and a “Mark as Unread” option will appear.
• The timer (Home → Clock) can put the iPhone to sleep when time is up.
• Earbud switch (in microphone) can be used to answer calls or pause/play music. Holding it for 2 seconds will dump a call to voice-mail. Double-clicking it will skip to the next song.

Hmm...and Safari (on the Mac or the iPhone) doesn’t seem to play well with Blogger.