Content blocker is not a euphemism

We’re told that “content blocker” is just a euphemism for “ad blocker”, but it is not.

Consider Board Game Geek. I visited that site today with my content blocker active. I saw ads. I clicked on two of them, and there’s a chance I end up spending money on what one or both of them led me to.

The ads that my content blocker blocks? Ads I would have ignored. Ads that are so annoying they may have keep me from even bothering to read the content of the site they are supposedly supporting.

And, my content blocker blocks annoying content that isn’t ads.

Forget about the mobile internet

Forget about the mobile internet:

For as long as the idea of the ‘mobile internet’ has been around, we’ve thought of it a cut-down subset of the ‘real’ Internet. I’d suggest it's time to invert that—to think about mobile as the real internet and the desktop as the limited, cut-down version.

For as long as I have known† about the internet, I have believed that there should never be the idea of a limited, cut-down version.

And even if I believed that the cut-down “mobile internet”‡ ever made sense, it is long past the time to have forgotten it.

†And I’m old enough to remember the days before the web. And the days before gopher.

‡For all its faults, as I recall, WML had some nice improvements over HTML when it came to forms.

Dear Academy

Dear Academy Sports + Outdoors:

I came to your website to find out the hours for my local store. Your website could not tell me. In fact, your website couldn’t find my local store.

Also of note: Your website asked if it could use my current location after asking me for my state and zip code. Yet, despite knowing my state, zip code, and current location, it failed to find my local store.

I went elsewhere.

Can you guess why I’m posting this open letter on my blog instead of sending feedback directly to you? Here’s a hint: It also has to do with a failure of your web site.

It’s time for compulsory licensing of video

Since the owners of video content can’t wrap their heads around the simple fact that there is zero difference between streaming video to a phone, tablet, computer, “smart TV”, or set-top box†, I say it is time for compulsory licensing.

That’s how music is licensed (here in the US at least). You don’t have to go to the “rights holder” for permission to play a song. You just have to be sure that you pay them the mandated fee.

We get to watch movies and TV however is convenient for us; the “rights holders” get paid; win-win.

†Here’s how you can tell: Open them up and see that, inside, all of these things are computers.

Reading Premier Guitar electronically

Premier Guitar is both great and awful. Reading articles on their web site is painful. Their iPad app is also painful. It’s gotten better over time, but it is still one of the many awful Newsstand apps.

(For an example of a great Newsstand app, check out Marco Arment’s The Magazine. Perhaps it isn’t a model for how every Newsstand app should work, but it does show that Newsstand apps don’t have to be as bad as most of what we’ve seen so far.)

The actual paper magazine? Sure, it’s fine, but a paper magazine clutters up my house. A magazine on my iPad gets read.

But I have found something that works: Their RSS feed, the Reeder app, and Reeder’s Readability button.

The one thing that’s missing is their gorgeous photos. Not the photos from articles; I still get to see those. There is a really nice section of stand-alone photos in the print and app versions of the magazine. But I’ll take readability over the photos.

The trouble with online conversations

Twitter, Facebook, G+, blog comments, web forums, &c. None of them seem able to handle one very important thing that NNTP clients did since the 1980s: Keep track of what I’ve read & what I haven’t.

The Twitter iOS client does a decent job of remembering my position in its time stream. That position doesn’t sync between my iPhone, my iPad, & the web site, though. Twitter is also not a great medium for conversation in many other ways, though.

Some web forums make an attempt at it, but I haven’t seen one that does it well. Although it has been a while since I was keeping up with forums.

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.

Hyperlinks

So, I’m sitting here polishing up some blog posts. I’m grabbing URLs to create hyperlinks. And it strikes me...

It’s taking me longer to create these hyperlinks than it will take you to select some text, search Google, and get to the same page. Not only that, the hyperlinks might grow stale, but a Google search won’t. Heck, Google might turn up more relevant results than what I choose to link to the moment I post. Even after Google, some other even better search engine will be available. For all I know, what you’ll really be interested in following up on won’t even be anything I create a hyperlink for.

Google is making hyperlinks obsolete. But Google is built on hyperlinks. It’s only by analyzing hyperlinks that Google can come up with such good results.

Weird.

Why are we still talking about piracy?

heavy sigh

I’m so tired of it.

The software industry—other than a few special cases—figured it out decades ago.

The RPG publishers figured it out about five years ago. (Don’t get me started on Wizards of the Coast and this issue.)

The music industry figured it out three to five years ago.

Seriously? Why are we even talking about this anymore? Piracy is not the problem you think it is. The pirates weren’t going to pay you anyway. Copy protection doesn’t work and doesn’t help you make more money. Overreaching legislation doesn’t help you make more money and probably won’t work either. Just make a good product, charge a fair price, and concentrate on the business you’re winning instead of the business you wrongly think you’re losing.

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?

Separating layout

The hypertext markup language (HTML) used to create the pages of the world-wide web began as a description for simple documents with hyperlinks. It supported headings, paragraphs, lists, and links. (Plus a handful of other things.)

Then tables were added. (Also notable was the addition of forms, but that’s another branch of the story.) Tables could not only be used to display tabular data, they could also be abused to create layouts beyond simply headings, paragraphs, and lists.

As styling was added to HTML, there was also a move to separate style from content, which brought us cascading style sheets (CSS).

There were problems with table-based layouts. To try to get away from the problems of table-based layouts, people have tried various HTML+CSS tricks. Many of which are based on a grid. Personally, I find these at least as troublesome as table-based layouts.

Perhaps we should separate content, style, and layout. HTML tables are, I think, a good way to describe a grid-based layout. If we, however, separate them from the content, does this eliminate or mitigate the problems we had with table-based layout?

OK, at this point, some understanding of HTML and CSS will be required.

Imagine a grid file containing mark-up similar to HTML tables. We’ll replace “table” with “grid”, “tr” with “row”, and “td” with “cell”. Cells support the rowspan and cellspan attributes. Cells contain CSS selectors that indicate what content from the HTML file should appear within that cell in the layout’s grid.

<grid>
  <row>
    <cell rowspan="2">div#header</cell>
  </row>
  <row>
    <cell>div#body</cell>
    <cell>div#rightsidebar</cell>
  </row>
  <row>
    <cell rowspan="2">div#footer</cell>
  </row>
</grid>

There’s probably a better way to describe layout, but I think HTML tables aren’t a bad start—once separated out. Personally, I’m not crazy about SGML/XML for things other than mark-up. S-expressions or some other syntax might be preferable. (CSS has its own syntax, so let’s not feel constrained to keep SGML/XML syntax for grid files.)

; Just a thought...
(grid (row (cell (2 1) div#header))
  (row (cell div#body)
       (cell div#rightsidebar))
  (row (cell (2 1) div#footer)))

Without browser support for grid files, we could write a program that would read HTML and grid files and generate HTML that faked it with tables.

Just a thought.

P.S. Since writing this, I came across this: The Evolution of Web Design

Flatland, 10/GUI, and SEO

A trio of interesting things found today. (All thanks to Daring Fireball, I believe.)

In “Flatland”, Lukas Mathis presents a very good rebuttal to some of Tog’s viewpoint. I think I may agree with everything Lukas says there.

Lukas’s blog then pointed me to 10/GUI. I think they hit the nail on the head with the idea that the next step in GUIs is not from two-dimensions to three but to fewer dimensions. I don’t know if they have the answer, but I know that the answer involves the user spending less time managing windows.

In “Spammers, Evildoers, and Opportunists”, Derek Powazek says that “search engine optimization” is a racket, which has been my gut feeling about it. Although, I suspect that the things he calls “obvious” are—sadly enough—not obvious to a lot of people. Those things, however, aren’t really about SEO. They’re just about making a good web site.

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.

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. (^_^)

Scheme in the browser (again)

I found myself reading “Popularity” over at Brendan’s Roadmap Updates...again.

This time, a comment by Mike Ivanov stood out to me:

It took almost a decade for ‘average developer’ to grok JavaScript. Now it is understood, at least. How much time would pass before Scheme achieved the same level of acceptance? I bet forever.

Which again has me questioning that. I can’t believe that anyone who has really “grokked” Javascript couldn’t have grokked Scheme. After all, Javascript essentially is Scheme with C syntax. Grokking the language behind that syntax is much more difficult than grokking the syntax.

I think that Javascript was in a unique position. I suspect almost no-one learned Javascript for its own sake. People learned Javascript because it was (essentially) the only game in town for the role it played. (Indeed, it is still too difficult, IMHO, to use Javascript outside that role.)

That’s certainly why I learned it. At the time, I would’ve much rather used Perl, but my customers had Javascript built into their browsers. I wasn’t going to ask them to install client-side Perl.

Likewise, I suspect that Javascript is one of those languages that was the first programming language for a lot of people. Those are people who aren’t coming in with syntax-bias.

Which may be pointless speculation, but that’s what thinking-out-loud is for. I still give thanks to Brendan that I’m required to regularly, at work, program in Scheme/Self even if it is with C syntax.

Why HTML validation matters

Anyway, we validated as the much saner HTML 4.01 strict, and even then I'm not sure it was worth the time we spent. So many of these validation rules feel arbitrary and meaningless. And, what's worse, some of them are actively harmful. For example, this is not allowed in HTML strict:

<a href="http://www.example.com/" target="_blank">foo</a>

That’s right, target, a perfectly harmless attribute for links that you want to open in a different browser tab/window, is somehow verboten in HTML 4.01 strict.

—Jeff Atwood, “HTML Validation: Does It Matter?”

o_O

1. The target attribute is harmful. The user should decide where a link opens.
2. If you validate against the strict doctype, expect it to be strict. If you want to do rude things like use the target attribute, then HTML 4.01 strict is not for you.

But enough haranguing, on to the question at hand—assuming you’ve picked an appropriate doctype to validate against.

But the question remains: does HTML Validation really matter?

op. cit.

I validate my HTML to ensure that any errors in it’s use aren’t my fault.

Note, however, that this isn’t so that I can say, “It’s not my fault!” when something goes wrong. I may still tweak things to work around quirks in a particular browser or other program that may read that HTML. Rather it is to minimize the miscommunication.

People understand instinctively that the best way for computer programs to communicate with each other is for each of the them to be strict in what they emit, and liberal in what they accept. The odd thing is that people themselves are not willing to be strict in how they speak, and liberal in how they listen.

—Larry Wall, “2nd State of the Onion”

A Coding Horror horror

Jeff Atwood wrote an awful post on The Two Types of Browser Zoom. He sums up the awfulness in this one sentence:

Honestly, I can’t see much use for traditional browser font sizing.

Reader B.S.Smith’s comment scores a bulls-eye:

I’m a little bit shocked whenever anyone suggests that if they aren’t using it, then it must not matter. There is always someone with a view 180 degrees out from yours and obviously the text vs whole-page zoom issue has two (disturbingly passionate) points of view. The only good solution is to leave it up to the idividual[sic] user (remember them?). Any browser that fails in that is giving up on a portion of it’s[sic] potential maketshare.

Now, I’ve come to the conclusion that there is such a thing as too many preferences. This is not one of those cases. Actually, this isn’t even really a preference at all. We’re talking about two different—though superficially similar—features.

The really dangerous thought here, though, is the way we so often say “I can’t see much use for...” That should be a sure sign to us that we need to seek out the opposing point-of-view.

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?

What every company should know about the web, part 3

Look at your web site’s reports and you’ll see that most visits are from people using Microsoft Internet Explorer on Microsoft Windows with Adobe Flash installed.

What about the customer using their Blackberry hoping to find your closest location because they are out-and-about and they want to buy something from you right now? What about the customer using their iPhone who wants to check your menu so they can decide whether to come to your restaurant or your competitor? What about the search engine that may bring you leads who would not have found you otherwise? What about the handicapped customer...?

No matter how good that Flash animation looks, it isn’t doing you any good if potential customers can’t find the information they’ve come looking for. (Flash is, of course, only an example. Substitute whatever flashy technology you want.)

That doesn’t mean you shouldn’t have the animation. Just that it shouldn’t be a obstacle between potential customers and the answers they’ve come to your site seeking.

To put it simply: If you’re restaurant’s web site requires Flash to give me any information, then when I am using my iPhone to help me decide where to eat, you’ve lost my business.

If Flash was used merely to enhance your site for those visitors whose browser supports it, then you would’ve had a shot.