:analysis
think, then type.
:vision
do not step out
:analysis
twitter.com/mikeysan
twitterpence
05/Apr/2008 | 01:02

Social Network Equity

Call me nuts, but Twitter has its own economic system, and I've become fascinated—no, obsessed with it lately. As I see it, the monetary ebb and flow of a social networking site can be described, in an absurdly non-useful sense, by the ratio of nodes to which you're linked in either direction.

Given:

Following a person's Twitter feed adds information to your stream.

Gaining a follower sends information you produce to another person's stream.

We can elaborate:

  1. At a specific moment, there are a finite amount of people in the Twitter Information Economy.
  2. Each person you follow costs you time, and each person who follows you gains you some mindshare.
  3. Some people have a fairly equal ratio of followers:following.
  4. Some are richer than others, and have followers:following ratios that tip in the followers direction.
  5. Some are "poor" and their ratios tip toward following more people than they are followed by. (The funny juxtaposition is that in reality, they're information-rich.)
  6. Because it doesn't take following a thousand people to flood you with information, it's possible to be overwhelmed even when your ratio tips toward phat bank.
  7. Once the rich get rich, they always get richer; those with popular feeds continue to snowball followers through little work of their own. (I'm reminded of a saying: "Turning $1 into $100 is work; turning $1 million into $10 million is inevitable.")
  8. Even though there's no real-world cost or barrier involved, the economy will always be this way.
  9. Every day, the finite amount of producers and consumers increases, and with that the economy inflates further.

Anything I missed? Endless subtleties guarantee that there's no way I'm completely right. Twitter at me with your thoughts for a follow-up article and I'll be your best friend.

link to: twitterpence

file under: analysis | comments (0)

privacy
12/Mar/2008 | 03:52

Encouraging Failure: A Brief Tutorial

Dave Jewell has written an article over at RegDeveloper regarding Mac OS X preferences windows. He titled it "A Better Way to Build OS X Preferences". I hoped that with such a title, the article was going to be insightful and informative. Instead, I found ignorance and arrogance posing as a qualified advice.

Or as I said to a friend, I'm calling this guy the fuck out.

#import <GenesisKit/GenesisKit.h>

In the beginning, there were some developers working day and night to ship an operating system. This operating system included some modules—frameworks, as it were—that were created to provide common, useful functionality. Along the way, the frameworks changed frequently in both how they worked and how they were supposed to be used. There came a point in the development of the frameworks where the engineers plotted out what parts they could let everyone use, including third-party developers, and which parts they'd have to keep to themselves.

The problem, they realized, was three-fold:

1. If Feature X of a framework was still changing internally, they couldn't give it out. They knew that if Feature X's implementation was in too volatile of a state, they may introduce bugs for anyone using it.

2. Volatility exists outside of the implementation of Feature X. Once they released a public API for using Feature X, they couldn't just change it up later or yank it completely without causing problems for everyone involved. Especially third-party developers, who'd be mighty pissed, and rightly so. Once they put forth a public API, they knew they'd have to support it. In that respect, it needed to be well-designed and well-tested.

3. Once these public APIs were settled upon, they would need to be well-documented. This is no easy task, and it's extremely important. During documentation of public APIs, it is often discovered that a piece of the public API didn't work well, or something important was missing. Now they'd have to start part of the cycle over again. And then come back to finish, review, edit, review, and publish the documentation.

This is a pretty big order.

You're wondering what any of this process has to do with the article. It all ties together, baby. Don't move.

Typecasting

Since we have a good picture of what went on behind the scenes, let's take a look at who's going to be using these frameworks. At the most basic level, there are four kinds of mindsets when it comes to developers and private APIs:

A. "I will not use any private APIs, period. They're completely unsupported, undocumented, and I can't rely on them. I need my code to be reliable and future-proof, and if I can't find a way to do something with a public API, I won't do that something."

B. "I really don't like using private APIs. They're unreliable, undocumented, and I can't rely on them. I prefer my code to be reliable and future-proof, so I try to avoid them. Once in a while, I find something that I need to do that can't be done with a public API, so I weigh the importance of what I need to do against the dangers of using things the developers didn't want me using. If I don't really need to, I won't; but I won't rule it out."

C. "I prefer to ship code written with public APIs, but I love exploring private stuff. It's a hell of a lot of fun to dig around inside the wiring and put together neat shit I wouldn't normally be able to implement. Sometimes the product of this ends up in an app I release, but I try to keep it from happening too much because I can't predict when something's going to change."

D. "Private APIs are just features like anything else, but secret. There's nothing wrong with using these even though they're undocumented and we have to figure out how they work. The API developers wanted to keep all the toys to themselves, but I'll do whatever I think is best. It's not really going to cause a problem."

Take a strong guess as to which kind of developer the author is. To demonstrate how I arrived at this conclusion, let's do some surgery.

Coming Together to Pull Things Apart

We're going to take what we've learned so far and apply it to the RegDeveloper article. Deep breath.

Here, on a regular basis, Dave will introduce you to unknown and undocumented aspects of the Foundation and AppKit class libraries that Apple has, er, neglected to tell you about...

Think back to the section that described the development of the operating system and its public and private APIs. Now reread this quote and tell me if you think Apple "neglected to tell you about" something that they don't think is ready for public, widespread use. Sounds much less secretive now, doesn't it?

The author is just setting up a justification for bad advice, it seems.

In my opinion, there's no sense in re-inventing the wheel if Apple has already done the job for you.

This is the second in Dave Jewell's Series of Bad Assumptions. Apple hasn't done the job for you already; they've done the job in a way that isn't ready for other people to use. They have deemed it not to contain unshippable issues, but it has either not been finalized or documented well enough to be used in real, shipping third-party applications. Or both. There's also a really strong chance they know about quirks that they haven't worked out, which makes the API unsuitable for mass adoption.

Over the coming months you'll find there are an amazing number of undocumented wheels within the Apple libraries that let you get on with writing great applications without having to reinvent what Apple have already done.

Undocumented "wheels"—which is a misleading way of saying "shit that wasn't designed for you to use"—usually have nothing to do with writing great applications. The two are mutually exclusive concepts when the mass of public APIs are as rich and powerful as they are. We're not talking about things that are essential to creating good software being hidden from developers.

Alternative thought: Fuck, he's going to keep recommending people use private APIs in shipping applications. And green developers are going to listen to him.

They are just waiting for you to set 'em spinning!

No, they're really not. That's the point of being private.

At this point, a few folks will doubtless be sharpening their quill pens (or even wooden stakes!) and preparing to chastise me for using undocumented features.

Using a private method once in a while is common practice in software development, though usually not recommended; commandeering an entire private CLASS is almost always frowned upon. And when what you want to do is so trivial as what we're about to encounter, it's silly to go out of your way to dig into private APIs to accomplish your task unless you're just tinkering for the sake of curiosity.

I'm not chastising anyone for using private shit, but I am taking the author to task for encouraging people to ship applications to people that needlessly make use of PRIVATE FUCKING UNDOCUMENTED FUCKING UNRELIABLE FUCKING STUFF.

That's true, but I'd offer a couple of counter arguments in return.

I braced for the bullshit excuses and pressed on . . .

First, Leopard (OS X 10.5) has only recently been released, and is likely to be good for several years - it's very unlikely that minor system updates would impact what I'm describing here.

Is Dave Jewell privvy to the past, present, and future engineering plans of the AppKit team? No? Then perhaps he should pretending he's some kind of authority on what private APIs will not undergo unannounced changes. They're private, they're 100% subject to change, and private changes don't get announced.

And if they do, I'll obviously make every effort to bring you a work around.

Excellent idea. Should I set up a POP forwarder to your e-mail address so you can also handle bug reports and incident support from people using my application when one of the private APIs changes in an update? And will you help implement and support the "workaround"? How soon can I expect a workaround?

I mean, if you're gonna push someone down this path, you'd better not ditch them in the woods when they bump into a tree. It's almost like . . . having to support an API you encourage people to use. Sounds familiar, yeah?

Next, and more importantly, you can spend more time making your great Mac application even greater - and surely that's what we'd all like to see, including Apple. Right, Apple?

Apple wants to see developers make great applications. They don't want developers making applications that break because their engineers need to change something internally and no one was supposed to have been relying on what got changed in the first place.

This is also how internal API engineering gets jammed up sometimes. When it becomes apparent that third-party developers have come to rely on some undocumented private API, it makes decisions based around that API more difficult. In a perfect world, whatever people were using would've been public anyway. But things are rarely that simple in the real world.

You'll also note that evil-looking call to _nsBeginNSPSupport. This is a fairly recent addition by Apple that is designed, I suspect, to prevent third party use of NSPreferences. Without a preceding call to this extern void routine, the call to super init will return nil.

1. Developers who have used this private API in the past have been bitten by a change to the API. I'm shocked.

2. It's extremely easy to find function calls buried in libraries. Apple knows people will find things that they go searching for. As a result, the addition of a private function like _nsBeginNSPSupport() does not mean that Apple's trying to prevent third-party use. It's too easy to find, and people will find it, as the article shows. What the article doesn't show, however, is what evidence is behind this "suspicion" other than the same shortsightedness from the rest of the article.

3. A corollary of #2: "Evil-looking"? Are you serious? Painting things in a malicious light does not make your article any better.

Remember, an API often remains private because it's volatile or hasn't been documented to give developers the information they need to use it properly or debug problems encountered while using it.

This Could Have All Been Avoided

I sludged through the article and realized something:

This guy wrote two pages about how a developer could use a completely private system to do something as trivial as making a preferences window for his or her application. That's pretty weak. Not only is it weak, but it's very lazy thinking.

It's just a preferences window. With the exception of the individual preference bindings, it's an extremely generic thing. A better solution would be to write solid, supported, portable code using documented APIs, with the intent of reusing the generic preferences window base you built.

This is exactly what Apple did with NSPreferences and NSPreferencesModule. They have their own simple interface for creating and managing preferences windows. It's not that hard to use public APIs to build your own generic preferences classes like these. Once you've built it, you can reuse it. Maybe Apple will finalize a public version of what they're doing for themselves, and that'd be great, but they aren't exactly withholding the secrets of the atom here.

The article suggests that you should hack around with Apple's private, unsupported APIs instead of letting work get in the way of building your next great application. I posit that a better article would've taught you how to build your own reusable preferences window construction kit just like Apple.

link to: privacy

file under: analysis | comments (0)

manifest
31/Jan/2008 | 12:59

Resume 3.0 has shipped:

Michael Watson - Curriculum Vitae

I had some specific design goals in mind with this version, so in that respect I'd like to deconstruct it a little:

The type had to be beautiful. There could be neither exception nor sacrifice here. After two days of experimenting, I chose Helvetica Neue Ultra Light/Light/Regular at no more than three different sizes.

The presentation of the text should not be immediately apparent. No fancy graphics, no Web 2.0 gradients, no Microsoft Word Executive Resumé Template divider lines running under my top-level headers. The paper should hold the words in place, not graphic elements. In this vein, the type itself is actually the graphical element you see:

mikey-san resume header deconstruction

I placed my first name in black, while leaving every single piece of text framing it in a slightly cooler grey. The bottom two lines have been kern-adjusted to justify against the bounds of my name, and as a result my first name is held in place. It also gives a slight impression that it's just a little higher on the z-axis, which makes it an anchor of sorts for the body of the page.

And honestly, I just think focusing on your first name makes a nice personal impression.

I inverted this for section headers and bodies, but left the headers in caps so they would feel balanced and prominent while remaining subdued. My feeling was that most resumés focus too much on bullet points, and I extended this to the headers. It was a decision; you may disagree.

Avoid formatting noise. I avoided situations that would force me into awkward text layouts and lots of noisy characters like forward slashes and parentheses. The big trick was to write the text so I wouldn't need to pepper the body with URLs, which are both extremely turbulent and difficult to format within the text. (Where do I put it? In parentheses? At the end of a line? On its own line surrounded by a line of whitespace leading and following? Turn it into a caption on a header?)

The other solution to sidestepping this problem was to tell some kind of story about me in both voice and content. A series of randomly penned blurbs ends up just as haphazard on the page as was when they were running through your mind.

I wonder what I'll do for 4.0. Maybe—gasp—serifs.

link to: manifest

file under: analysis | comments (0)

release note
11/Jan/2008 | 14:54

Daring Fireball posted a snippet of the Interarchy 9.0 release note, and I'd like to say a few kind words to the developer who wrote it. First, the note:

Interarchy now has much improved resolution independence. If Apple ever get their act together and finish Mac OS X's resolution independence support Interarchy should be ready.

YOU GUYS SURE ARE CLEVER BUT I THINK I CAN IMPROVE UPON THIS MASTERPIECE:

"It took our application seven years to become relevant again, but we're going to knock another company publicly for being only 95% of the way there with technology that is orders of magnitude more complex."

A release note is not where you get to be Arrogant Developer Man and take shots at fellow developers. Does anyone think the RI guys at Apple appreciate this kind of junk, let alone respond to it? Whoever wrote that release note is an asshole and deserves to be called out on it.

Oh, kind words. Right. I almost forgot.

GTFO

link to: release note

file under: analysis | comments (0)

elements
18/Sep/2007 | 10:25

The Elements of Identity: How to Fuck Up a Logo

Adobe's John Nack gave us a peek at the new identity for the Adobe® Photoshop™ Line® of Products™ today.

Before we discuss this rather unfortunate combination mark, let's look at the CS3 branding. I consider it a good example of identity design, despite what some people on the Webinet have said.

Learning from History

Prior to CS3, Adobe's product line used a rather nasty set of icons for the different Creative Suite applications. All of the icons' central design elements were plastered randomly on empty, white rounded rectangles, which I'm sure looked really great in the committee meeting that designed them, but in reality signaled to me that the icons required a workaround to be visible in people's Docks and desktops.

The problems with the CS2 icons didn't end there, though. When you have a single application, you only need to differentiate it from other people's icons, which generally isn't a difficult task. Your identity is not someone else's identity, so you only need to coordinate against:

- Yourself
- Everything else

Easy task.

When you have an entire suite of applications, you have to coordinate against:

- Yourself
- Your other crap
- Everything else

It's the middle one that's the hard part. Each product needs to fall in line with the overall identity of the suite, but still stand alone, because they serve different purposes. I can hear how the CS2 icon/identity meeting went:

Bob: Each of our applications needs its own fingerprint.

Bill: Right, Bob. Go on.

(the room nods slowly)

Bob: You know the difference between a feather and a seashell, right?

(more slow head nodding)

Bob: And a flower and a starfish?

Bill: I think I know where you're going with this, Bob, and I like it. What do you see this saying to our customers?

Bob: Butterflies and feathers are creative. "Be Creative!"

Sure, it sounded great in the meeting, but in reality, we got this mess. Sure, you know the difference between a butterfly and a leaf, but that doesn't mean you'll be able to tell them apart in your Dock.

But that isn't the real problem we care about here, is it? Not really. The relevant problem is that they really didn't carry any clear identity. Maybe they looked creative, but that's stretching. What does "look creative" mean? It's an unremarkable throwaway phrase, and these were unremarkable icons that reflected an unremarkable identity.

Sapphire Bullets of Pure Fail

Fast-forward to, uh, several months ago, when Adobe (via John) unveiled the CS3 icons and identity. Some people cried out in horror, but as it turns out, Adobe really cleaned up the house. Not only were the icons very easy to discern in the Dock and on the desktop, but they had very clear identity:

The elements of creativity.

Crisp, clear, clean. You know exactly what message Adobe is tying to send. What is Adobe trying to say with the new Photoshop logo? Nothing, from what I can tell. It's haphazardly designed, an incongruous mix of sharp and round, bad 3-D perspective (take a close look at the cutout on the right side), and TRADEMARKS FUCKING EVERYWHERE. Goddammit, it's like looking at the logo for a company that sells trademarks instead of actual products.

Just how much is wrong with this new logo?

1. The official slogan is in the combination mark. It makes the mark harder to use in layouts, it introduces more type noise, it upsets the balance of the rest of the mark, and it introduces one of the ™ flies buzzing nastily around the identity.

2. The official slogan, now that it's been mentioned, sucks. "See What's Possible™", I guarantee you, was written by committee. So on top of a bad slogan, we have to look at it whenever the logo is used.

3. I get it. The graphic is a stylized letter P with an eye. This is the absolute best anyone at Adobe could come up with? P is for Photoshop, and you can See What's Possible™! (See, it's got these conclusions that you can jump to.)

4. As far as I can tell, the typeface is the same one used in the CS3 branding, but it doesn't match the P-eye graphic at all. Perhaps it's more accurate to say that the graphic doesn't match the typeface, however, and this should really be a mark against ol' P-eye.

5. Why is this giving me the impression of the old PBS logo? OH WAIT

6. And the most important bullet, a direct repeat of what I've been talking about: The logo is part of your overall identity, and this piece of your identity says absolutely nothing to me. Zip. Zero. All I get from this is "corporate committee meeting logo design session", not "we want to empower and inspire you to create beautiful things".

Wait—I like the sound of that.

Create Beautiful Things.

link to: elements

file under: analysis | comments (0)

blame
15/Sep/2007 | 16:01

If you were wondering why some songs in the iTunes Store are available as ringtones, while others are not, Apple has sneakily decided to tell you:

an iTunes alert dialog explaining why some songs aren't available as ringtones

This is essentially Apple putting blame squarely where it lies: the record labels. The language Apple uses here is also interesting. "Cleared for use" implies an impolite or uncaring bureaucratic authority, akin to getting approved to put a lawn ornament on your grass in a gated community.

"We can't give you what you want because the record labels have not approved of it."

Subtle, but effective. Then again, it's ridiculous that I have to pay twice to use "Don't Stop Believin'" as my ringtone in the first place, but Gruber said it best already.

link to: blame

file under: analysis | comments (0)

adobe failshop
30/Aug/2007 | 13:32

Dear Adobe,

where did my menu items go?

You fail at Mac OS X. I can't move the application after installing it without it bitching, and I can't see half of my menu items. What platform do you think this is?

link to: adobe failshop

file under: analysis | comments (0)

fail #002
20/Aug/2007 | 10:46

I may have to add a new category for this crap if it keeps up.

Psst, Apple: Your browser detection sucks. That you use browser detection in the first place is fan-fucking-tastic,[1] but if you're going to do it, get it right. And when I decide to ignore your warning, don't require me to have cookies enabled to proceed even when I don't check the persistent no-warning box.

Granted, this is a very pretty "hey your browser sucks" page. However, as it stands: FAIL.

dot mac browser FAIL

Postscript: What should one take away that "#002" implies that I expect a great deal more of these?

[1] Sarcasm.

link to: fail #002

file under: analysis | comments (0)

opacity
07/Jul/2007 | 00:12

I get the need for opaqueness when it comes to telling the average user what's been changed in a software update. I do. I really, really do. It's too easy for most users to misinterpret a developer's release notes for a particular update, and showing those details can oftentimes result in confusion amongst your user base. (Don't believe me? Feed the average Apple Discussions thread a sliver of fact and watch them fuck it up royally.)

That having been said, YOU GUYS AREN'T EVEN TRYING ANYMORE:

iPod release notes

link to: opacity

file under: analysis | comments (0)

ponder.app
23/Apr/2007 | 02:40

Thinking About Your Application: What's in a Name?

It's time to get thinking about what to name your Next Great Application. You're in alpha, maybe early beta, and up until now, you've just been using a code name. Probably something quick and dirty, because you had to name your project folder something when you started eight months ago. You can't use the code name when you release, so now you've gotta do the part that's just as difficult as it is fun.

Certain considerations have to be made when developing a name for your app. Can you pick something that just "sounds cool"? Sure, but what's cool now is going to look lame in a year. Shooting for "cool" also brings you close to the edge of Trying Too Hard. That isn't a place you want to be.

Dissecting Frogs Can Be a Real Mess

In general, there are four ways you can go with the name of a product, be it software, hardware, cuisinarts, or anything else:

The practical name, the conceptual name, the nonsensical name, and the connotative name.

The practical name describes what a product resembles or does; it's mostly a description of functionality, but usually incorporates the metaphor of the product. Microsoft Windows is an example of a practical name that describes part of the product (a window being a piece of the operating system), while at the same time being a reference to the product's associated metaphor (the "window" metaphor). It's really not a bad name, though I know Mac users like to dump on it with clever names like Windoze and Winblows. (You're not clever. Stop doing this.) Other examples of good practical names would be Pages and Lightroom.

Be warned: the practical name loves to show off puns, plays on words, and InterCaps. Not that there's anything wrong with that, right, QuickTime? (If you ask me, intercapping dates your application's name. Avoid if you can. QuickTime seems to have gotten away with it, but you probably won't be so lucky.)

The conceptual name is similar to the practical name, in that it relates to the metaphor of the product. Where conceptual names differ, however, is how they drop the practical resemblance aspect of the practical name. They describe the idea behind the product instead of the product itself. Dashboard falls into this category, because it doesn't describe any functional aspect of the product, but it communicates the concept on which it's based.

The nonsensical name is the blue jeans ad of product naming. It doesn't have anything to do with the product, you can't pull meaning out of it, and it's just as malleable as it is impervious to interpretation. Think Kazaa or Zune. This is probably the most volatile type of product name, because it's a complete toss-up as to whether or not you're going to gain any kind of mindshare with an otherwise meaningless name. Your marketing department both loves and hates the nonsensical name.

The last category is the connotative name. It wants to be nonsensical, but it knows that it needs to be somewhat descriptive. It doesn't directly describe the product, and it doesn't describe absolutely nothing, either. The connotative name is the sort of name that tells you something about the product after you've experienced it. Twitter, iPod, these are connotative names.

On paper, none of these categories is bad. Really, they all have their place in the vast, unending sea of products. The trick is choosing the right kind of name for your product.

Anything You Can Do, I Can Do More Pretentiously

Here's the part where I put up or shut up, right? When I started my last application, I had to name the project, and didn't want to put much time into it. I chose the first thing that came to mind, Blackout. The app was a GTD toy to help keep you focused on a single thing at a time. It BLACKED OUT the distractions. Get it? It's clever.

I knew that when 1.0 rolled around, I'd need a different name. Code names rarely make good release names. First, though, I had to figure out what was broken about the provisional name. After all, it described what the app did, right? It wasn't hard to remember, pronounce, or spell. But some things just didn't sit right.

Here's the list I came up with:

Okay, it's a short list.

I gave the matter a few days of thought and while standing on a subway platform waiting for an N train, I realized I was trying too hard to figure it out. It hit me like, uh, something that hits people when they're trying to solve something. It was so simple! I asked myself a question:

"What is this application helping you do? What is the point of focusing on something?"

To think clearly; without distraction. Yes! That's it.

Think.

Not only did it describe the concept, it fit with the look and feel of the app. You never had to ask how to spell it. Most of all, as pretentious as it sounds, the name inspired me. I had ideas about the look of the manual, late-game interface changes, and even a tagline: Because sometimes you have to.

On top of all these things, the name instantly told me what the icon looked like: a thought balloon! And what are you thinking about, exactly? Well, an application. Why not put that application's icon inside Think's icon during runtime? HOLY SHIT THAT'S AWESOME.

All of this from a name. A name so simple that it didn't come to anyone immediately. These are the sorts of patient, seemingly simple decisions that make even toy projects like Think something really special. Did I overanalyze everything—dare I say overthink here—you ask? Yes, I did.

Was it worth it?


Think icon

link to: ponder.app

file under: analysis | comments (0)

bugging me
10/Mar/2007 | 01:55

Bugs Are Not Design Choices

"How can you have two blinking cursors at the same time?" asks Pierre Igot.

I'll summarize:

"Carbon text controls still blink a cursor when you show the Spotlight field, while Cocoa controls appear to be unaffected. Now that we've established this short fact, insert massive lecture about two-cursor usability here, as though this were a design choice, and not a clearly identifiable bug."

Uh oh. Here I go again.

HIUnnecessaryEntityMultiplication

The problem I have with Pierre's post is that it has very little to do with the actual problem that inspired it. There's an actual bug manifesting itself here, and it's definitely something that Apple should address in future revisions of Mac OS X. (I won't say that this is specifically a Carbon bug, but it affects Carbon applications, so it's related to Carbon somehow.) But that's not what the dissertation revolves around.

Here's the bit to which I alluded in the summary:

If Cocoa text controls relenquish cursor focus when the Spotlight field gains cursor focus, while Carbon text controls do not, then this is a concern that has been solved in one place but not in another. Therefore, either an oversight or a mistake has resulted in the inconsistent behaviour, not an explicit design decision. Yet, the post speaks forcefully and authoritatively, as though someone inside the Spotlight team sat down and decided two separate things:

Ockham's skeleton is spinning in the ground right now.

DANGER: Falling Sky Ahead

"This can be misleading for the user, who, based on the window's visual aspect, might assume that the window is still in the fore and that he can still interact with it."

Yes, bugs can sometimes result in misleading situations.

"In the case of the Spotlight text input, however, the visual focus does stay on whatever is in the foreground when Spotlight is invoked. And that's just plain wrong."

Correct, bugs are typically "wrong". If they were "right", they wouldn't be bugs.

"It's the kind of ugly UI you might expect in Windows, but, you know, the Mac is supposed to be better, more elegant, more consistent, more intuitive."

Bug.

"I am sorry, but there is just no way that having the visual focus on two different UI controls at the same time is intuitive."

I am sorry, but this is a bug.

"I submitted all kinds of feedback about this during the testing phase for Mac OS X 10.4, and nothing ever came of it. [. . .] So whoever makes such decisions bears the full responsibility for them."

If the feedback you send to Apple is as heavy-handed and accusatory as this article, one might find it difficult to wonder why those on the receiving end have been less than responsive to your complaints specifically. If you want people to take you seriously, take them seriously. It's a bug. It's clearly a bug. You don't need to lecture anybody on it.

(Also: Bug.)

"And I'd argue that Apple's Spotlight UI designers are simply irresponsible. it's a bug."

Fixed that for you.

link to: bugging me

file under: analysis | comments (0)

rookie play
06/Mar/2007 | 19:33

Overreaching: Internet-enabled Disk Images

I'd like to take a moment to lay down why Apple's "Internet-enabled" disk images are a pretty bad piece of user experience. First, a short explanation of what they are:

When you build a disk image with the command-line hdiutil tool, you can choose to "Internet-enable" the image file. Upon mounting, the image copies its contents to the folder containing the disk image. The image then unmounts its volume and deletes itself automatically.

Apple's got great human interface people, but they're not perfect, and I think they've got this one quite wrong. Let's explore.

Peanuts and Cracker Jacks

1. When you put in a CD and open the icon, does it install your program on the Desktop and eject itself? No? Score card:

Internet-enabled images: 0.

2. When you double-click a zip file on the Desktop and an app appears, does the zip file delete itself? No?

Internet-enabled images: 0.

3. If you back up software you download, which isn't a bad idea necessarily, an Internet-enabled disk image kicks a bucket of suck all over your plans. Before you double-click the image and it does its thing, it just looks like . . . a disk image. Inconsistent behaviour that results in deleting stuff people might want. Argh.

Internet-enabled images: 0.

4. Sometimes, users want to install software on a different computer than the one that downloaded it, but they check it out before migrating the disk image file and performing the permanent installation. Skynet-enabled Internet-enabled disk images force the user to download the software again in such an event. Essentially, this is a corollary of #3 that occurs when there's no way to know that new download of yours is plotting to destroy itself.

Internet-enabled images: 0.

5. When Software Update downloads the latest iTunes update and installs it for you in the background, you never see the temporary package. It's buried--out of sight. Disk images you download from Web sites aren't like that. Users have an expectation that when they see something on their Desktop, it's not a temp file that the computer is going to remove automatically. I downloaded it by clicking on a link, I saw Safari say it downloaded to my Desktop, I see it next to my HD icon, it's "my" data.

Internet-enabled images: 0.

6. Let's say by some magical psychic ability, you know the disk image going to delete itself like some Mission: Impossible dossier, so you back it up before using it. Now there's a new problem: EVERY TIME you go to use the image from my backup, the image is going to delete itself, so you have to remember to back it up every time. BOOOO-urns.

Internet-enabled images: 0.

John Madden, Where Art Thou?

With no points on the board, the Internet-enabled disk image doesn't get to the playoffs, and probably should get kicked out of the league.

To the user, a file is a document is an item is an object is a thing. You click on it and then, um, Stuff Happens™. When Mom and Dad click on Word files, the files don't vanish, for example. They will not assume nor expect the zip file next to the Word file to vanish immediately. Data with a mind of its own is unsettling and potentially frustrating for many, many users.

The problem of course is that, as Finlay Dobbie puts it:

"[T]he issue here is that users find the whole concept of a file which appears on the desktop like a disk to be fairly confounding."

He's right.

Internet-enabled disk images attempt to simplify a rather abstract concept for the user. That's Good™. We like that. The opacity of the behaviour, however, raises several points of further confusion and frustration for people.

It's great to make things easier on users, but Apple hasn't convinced me that this feature improves the overall user experience enough that it outweighs the significant problems presented by it.

link to: rookie play

file under: analysis | comments (0)

icon cinematics
06/Feb/2007 | 20:58

Seeing What You Don't Notice: The Feel of an Icon

This article is a bit esoteric, but I haven't posted in a very long time, so I can get away with it.

When you look at the icon of an application, what goes through your head? Do you get a sense of what the application does? Are you reminded of tasks you've been putting off, or have in queue? Do you get ideas for new projects you'd like to start?

The answer, of course, depends on what kind of person you are. Are you a stay-at-home parent? Are you a software developer? Are you a writer? Are you an icon designer?

I've been doing some thinking about this lately. A lot of things go into making good icons, but few icons are truly great in the larger sense of the word. Don't get me wrong, I can name a ton of really kickass icons—avatars of application function, as one might say, that cause me to lean in close to the monitor and study every line and pixel contained within the rather constrained canvas—so perhaps that's what makes it difficult to declare kings and sultans in a landscape of art from which to choose.

But I'm going to declare one icon king of the land. The best icon in any piece of software shipping today.

BEHOLD, he rang out, the pompous announcement deafening his audience:

iMovie icon

What Makes a King?

"What's the big deal? It's one of those, you know, movie action things. Yeah, it looks really good, but what's so special about it?"

(It's called a clapperboard, in case it ever comes up in Trivial Pursuit.)

Take a closer look at the iMovie icon. What do you see? You're not looking for any specific detail, so don't put your nose against the screen, but there's something here that the designer slipped in without hitting you ham-fistedly over the head with it. We'll come back to it in a moment.

Getting technical details out of the way, it's solid design. Lines are clean, it scales down well (possibly the most difficult post-concept part of icon design), the colour choices are very slick, the perspective and lighting have been chosen appropriately, and the object in the icon conveys the purpose of the application quite well. (This last one isn't always a requirement, but when a designer goes that route, you can tell when he or she nails it.)

But lots of icons can say the same about themselves. What's iMovie got that the rest don't?

More Than a Feeling

Back to staring at the iMovie icon.

The element the designer managed, it's clever. It's obvious, too, and when I tell you, you're going to say, "Well, no shit!" It's obvious-after-the-fact obvious, which is the kind of obvious I like the most.

It's not lines, it's not shading, it's not the object itself . . . it's emotion.

There's an element of the icon meant to invoke an emotional response. It's really clever. In fact, it's fucking genius. Lots of people try to do it, but the brilliance here is in the subtlety of not attempting to beat you over the head with fake sentimentalism. This is not WELCOME TO THE SOCIAL. It's not a marketing statement. Here, it's a evocative concept rather than a slick brand promotion.

There are two elements in the icon: the clapperboard and the image of the two people running across. What are they doing? Are they two friends running through a park at night, lit by nearby streetlamps? Are they lovers running across the beach at night? A brother and sister ice skating across a snowdusted pond?

They're a memory.

Reliving a memory is an emotive experience; it creates a connection between you and something else. Maybe it isn't even a memory that really happened—you see the two people streaking in a flare of light past the camera and suddenly you imagine a story, which means you've been inspired on some level. Home movies are memories, and this is what the designer wants you to see, but not notice, when you use the application.

I posit that you've never actively thought about any of that, though. Nobody actually thinks about this stuff. It's just happened, and you never gave a thought as to why. Hell, there's an equally strong chance looking at the icon hasn't had this sort of effect on you at all, but you've still had a warmer response looking at it for just a moment than you would have with its competitive peers.

At least, you will now.

link to: icon cinematics

file under: analysis | comments (0)

postal services
08/Aug/2006 | 02:40

I'm at WWDC 2006 this week, and today Apple showed off two new features of Mail 3. I've heard some people begin to compare it to Outlook, and I thought it was worth dispelling this soon-to-be-everywhere myth.

The first new feature of Mail is called "Notes". It's pretty much what you think: start a new note from the main Mail window, jot something down, save. It's then accessible via Mail and searchable with Spotlight. This seems bloaty, right? Let's look at both the inspiration and the goal for the feature for a second.

Right now, in Jaguar, Tiger, or OPERATING_SYSTEM, a crazy-huge amount of people are already sending e-mail notes to themselves. My boss does it. My co-workers do it. I do it. Why? It's convenient. It's easy. Remember that PEOPLE ARE LAZY and WORK IS HARD, and launching another app while I'm trying to remember that idea I just had is WORK. Screw it, I'll just e-mail it to myself while I'm reading and sending mail.

Apple's not adding something people aren't doing, they're giving them a better way to do what they're already doing.

So, myth #1 is no more. What's all this about the "To-Do" button in Mail 3?

The To-Do feature in Mail 3 isn't so much a "Mail 3" feature, but a system-wide service that Leopard's Mail just happens to incorporate. Think of it as a flagship demo of how nice the feature is. So, not really Mail bloating up like a whale, but Mail taking advantage of a service that any app can implement if the developer so desires.

Imagine being able to mark things in Mail as a To-Do, then doing the same in OmniOutliner and SomeOtherApp, and seeing them all show up in iCal automagically. Now picture not being able to do that in Mail. Starting to sound less like bloat and more like obvious now, right? Right.

We now return you to your regularly scheduled developer conference.

link to: postal services

file under: analysis | comments (1)

out of context
15/May/2006 | 02:02

Our Common and Continual Mischiefs

I've got this quote lodged in my head lately. It's not a song lyric or something Morgan Freeman said in a movie; it's a philosophy that seems to have been lost over the years since the quote was born.

Context is a driving factor in the adoption and evolution of language: the idiomatic is rooted in context, dialects are almost meta-contexts, and phrases that find themselves in the same context frequently can suddenly adopt additional standard meanings. Context drives and shapes meaning in living languages. The more I thought about it, the more I could see that the quote might have a different meaning out of context. Without any labels or encapsulating concept, what would it mean to different people?

More importantly, I knew the true context of the quote and wanted to see if the answers people might give would have a reflection on the actual meaning.

I placed the quote in the hands of my friends and asked them a simple question:

"What is this person talking about?"

I didn't inform anyone of the other participants' hypotheses, and I made sure to prefix the quote with the comfort that there were no "wrong" answers. I specifically asked them not to use Google or any other search engine or reference material, and I'm pretty certain they obliged me, as no one got it "correct".

First, the quote:

"It serves always to distract the public councils and enfeeble the public administration. It agitates the community with ill-founded jealousies and false alarms; kindles the animosity of one part against another; foments occasionally riot and insurrection. It opens the door to foreign influence and corruption, which finds a facilitated access to the government itself through the channels of party passion. Thus the policy and the will of one country are subjected to the policy and will of another."

Second, the replies:

Finally, the context:

In 1796, George Washington was completing his second term in the office of the President, and when faced with the decision whether or not to run for a third, he declined. In his farewell address to the country—which was actually a letter[1] published in The Independent Chronicle and The American Daily Advertiser, not given as a speech—he outlined his reasons for not running again, acknowledged his debt to the country and its citizens, and spoke of the wisdom he had gained during his years as the infant nation's President.

What was on George Washington's mind when he penned this part of his farewell address was not religion or foreign occupation. George Washington was warning the country, its citizens and leaders, about what he believed was a much greater threat to the nation he fought for and led.

Let's put the quote back into context.

I have already intimated to you the danger of parties in the state, with particular reference to the founding of them on geographical discriminations. Let me now take a more comprehensive view, and warn you in the most solemn manner against the baneful effects of the spirit of party, generally.

[. . .]

It serves always to distract the Public Councils, and enfeeble the Public Administration. It agitates the Community with ill-founded jealousies and false alarms; kindles the animosity of one part against another, foments occasionally riot and insurrection. It opens the door to foreign influence and corruption, which find a facilitated access to the government itself through the channels of party passions. Thus the policy and the will of one country are subjected to the policy and will of another.

George Washington was asking us to be wary of letting political parties become entrenched into the function and design of the state; while it is in our nature to describe ourselves with popular labels and identify with them, do not let your political, social, and moral leanings become determined by the agenda of another group with whom you identify, lest you be left at the whim of those in power above you.

As I say more abrasively, "Party lines are for people who can't think for themselves." I'm not nearly as eloquent as Washington was, and I suppose my point differs a bit from his.

Don't Breathe or You Might Skew the Statistics

What have I proven here? Nothing. I write this under no pretenses of having discovered anything of utility or practical significance. The results of my wildly unscientific poll are completely interpretive and with a set of flaws nearly as large as the country's current political party climate itself.

I do, however, find it interesting. Clearly, it interests me enough to write about it here. Of the responses I got, 40% associated it with religion in some fashion. That's a fairly significant segment of the response pie, and worth pondering. Does it say something negative about religion, or does it imply political parties are indistinguishable from religion when removed from context? Both? Could correlations and relationships be drawn between the answers I received, irrespective of the quote and its "correct" context?

In reality, yes and no to all of the above. As a distraction, yes, these are all valid contemplations—but as the sample set lacks any sort of quantitative value, it's factually meaningless. I sampled ten people I already knew, and no more, which doesn't provide enough data to dissect deeply into the subject matter. What's more, they're my friends, and not random samplings.

It's interesting think about, as long as you don't take it out of context.

[1] The full text of Washington's farewell address can be read here:

http://www.earlyamerica.com/earlyamerica/milestones/farewell/text.html

link to: out of context

file under: analysis | comments (0)

cat herding
28/Feb/2006 | 13:40

I stumbled across this (admittedly dated) write-up the other day:

http://rixstep.com/1/20030112,00.html [Google cache.]

Just to get this one out of the way:

Freedom of speech is a protection that applies to the government's inability to prevent you from saying what you want. Civics 101. Tossing around the First Amendment as though Apple or another company have somehow removed your God-given rights to say or do whatever you want is absurd and inflammatory.

And now, on with the article.

Noise is a Symptom of Hearing

Apple didn't "censor a critical post". The post was removed because it added nothing but noise; the thread didn't detail, investigate, or solve a problem, and therefore added nothing to the Discussions community.

Apple Discussions is a forum for user support, not anything else. A thread that consists of complaints about something that isn't a technical issue is not productive. The Rixstep rant takes plenty of time to discuss the reasons posts and threads can be gassed, according to the Discussions Terms of Use, but it misses The Point™ entirely:

Stay on topic. Apple's discussion forums are here to help people use Apple products and technologies more effectively. Unless otherwise noted, don't add Submissions about nontechnical topics, including:

People who get angry that these sorts of threads get 86'ed have never done mass-level user support. How does a thread that just complains about policy do anything to help users of a technical support forum? Remember that every word that isn't helpful in regard to a technical issue is by definition unconstructive; it is noise that must be sifted through by both users and AppleCare employees who monitor the forums to track technical issues, monitor support levels, and develop support strategies. Does anyone honestly think that their mission is to kill threads that criticize the company?

There are thousands of new posts every day that have to be reviewed by Apple staff—every post gets reviewed by human eyes. This means NOISE IS COUNTER-PRODUCTIVE. If you leave the thread or post in the wild, it will continue to generate more noise, which must be read. Noise is dissonance, and dissonance dilutes the ability to provide support to people who are actually having technical support issues. It's all aggregate.

But I guess it's easier to blame Apple for "censorship" than to think about the entirety of the user base instead.

We now return you to your regularly scheduled Internet.

link to: cat herding

file under: analysis | comments (0)

micro machines
14/Dec/2005 | 12:04

Today's ramblings are just in case any Mac users read this article and the quote near the end, excerpted below:

http://lowendmac.com/musings/05/1214.html

"Dreams of the best kernel and the best GUI working together . . . No more beach balls of death."

The best kernel for what? Don't we need to define "best" before we can declare something so?

The author posits that Mac OS X's kernel should be a monolithic kernel instead of a microkernel, and that such a change would magically eliminate the issues that exist in Mac OS X hitherto.

Mac OS X's kernel, XNU, is based on Mach 3.0. Mach 3.0 was a microkernel, but XNU grafts on the networking stack and virtual memory system: under the strict sense of a microkernel, since these would-be servers are part of the XNU kernel, Mac OS X's kernel is technically a monolithic kernel, even if that determination might seem a bit pedantic.

But this is irrelevant. Spinning beach balls of death are not the result of Mac OS X originally being a microkernel-based architecture. What's responsible for that? Badly threaded apps. The Finder, for example, will not lose its penchant for throwing hissy fits if Apple starts compiling into the kernel your video drivers.

(We still remember that XNU isn't a microkernel, right? 'Cause it isn't.)

99% of users will notice no performance increase if Mac OS X were migrated to a more monolithic kernel (Joe User doesn't need to maximize SQL transaction performance), but they will get frustrated quickly at having to sit while their kernel recompiles every time there would normally be a minor framework update. As stated, tbe bottleneck isn't the kernel for most situations—and even in other situations, it's not always the biggest culprit—but badly written applications themselves.

I wish people would stop writing these articles. It's really getting old.

link to: micro machines

file under: analysis | comments (5)

race condition
22/Sep/2005 | 10:16

How Comcast Rooted My Box

"Dude, this is a worm or root kit."

Merv was thinking the same thing I was. It would be another half-hour before we were confident no maliciousness had taken place, and in that time I would wonder just what data existed that I could actually trust. My first thought: "Not much."

My second thought: "Less than that."

Perhaps we should begin with a story.

My mother is a nurse at a high-security psychiatric facility. When she began working there, they gave her a lanyard to which to clip her identification badges so she could hang them from her neck. When I heard about this, my first thought was: "Why did they give her something to wear around her neck in a facility that houses disturbed, violent patients?" We're talking people who can't stop themselves from killing other people, here. Arkham Asylum.

Aside: The casual way in which she recants stories of patients killing people inside the facility amazes me.

As I studied the lanyard, I noticed a few things about it. Not only was it made of a pliable rubber-band-like material which would easily stretch and break if tension were applied, but there were three breakpoints along the lanyard: two deep scoring marks at opposite sides, and a loose button snap in the back. It's too small to break at the scoring marks and still have a useful weapon without stretching the material, and the material will break when stretched out. It's a pretty smart design.

This article is about smart design, and how a well-known Internet service provider fails at it miserably. Let's see if we can prompt some change.

a = (dv)/(dt)

A passenger train barrels down a track that leads toward a city on the distant horizon. The track is switched: about a mile up ahead of the train, there's a switch control (called a ground throw, located at a split section of track called a turnout) that controls the direction of the train. To the east, the city; to the north, a blocked-off section of track that leads to a bridgeless cliff shear.

Everyone knows about the cliff shear, so it's always assumed that the track is switched to take trains to the city. In fact, there have only been two reported incidents of trains careening to their dooms in the last 100 years, and as a result, no one at the train station pays much mind to the state of things at the turnout.

Still, the conductor always announces his or her intention to travel along the east track. Today, someone's listening in on the conductor's radio, and as soon as he hears the conductor announce where he's going, a race begins to get to the ground throw.

"He thinks he's going to go east, but I'm going to switch the track on him," says the evildoer.

Sure enough, the evildoer arrives at the ground throw before the train and its conductor. The tracks are switched, the conductor decides to take a bathroom break after making his radio call, and the train quietly slips off the end of the northbound track into the ravine before anyone can say Isaac Newton.

For a moment, imagine you have a trusted program (train) and a trojan horse (evildoer) instead. When your trusted program attempts to write to a location in the file system, the trojan attempts to write to the same location first. Essentially, the outcome of operations is based on the timing of the events.

This is called a race condition.

The Glass Bead Game

Our trusted program creates a file in the Mac OS X temporary items folder, /private/tmp. (In traditional Unix systems, this is simply /tmp. We Mac people are weird like that.) It's a pretty simple file, nothing too significant. A temporary activity log, let's say.[1]

/private/tmp is world-writable by default:

[thermodynamics:~] mikey% ls -lad /private/tmp
drwxrwxrwt 11 root wheel 374 Sep 22 04:56 /private/tmp

The activity log operation is pretty typical: if /private/tmp/$UID/TrustedApp.out doesn't exist, create it and open it for writing, and if it does exist, just open it for writing. Empty contents into glass. Wipe hands on pants.

The trojan has other plans. It symlinks /mach_kernel (the Mac OS X kernel itself) to /private/tmp/$UID/TrustedApp.out before the trusted app can gain access to the temp file. Luckily for you, the trusted app isn't running as the root user, so mach_kernel can't be fooled with.

Right?

Kiss That Frog

Things begin to fall into place when we reveal the final piece of the scenario:

Let's imagine for a second that our trusted app has the setuid flag enabled. The setuid flag—for programs that have it enabled—tells the system to assign elevated or otherwise altered privileges to the program as the program is being run. When a setuid program is executed, it gains the privileges of its owner.

I can hear you thinking to yourself: "If my trusted app is owned by root and has the setuid flag enabled, that trojan is going to fuck me up."

You'd be right. When a setuid program owned by root is launched, it runs as root without requiring authentication.

Setuid is useful, but it's dangerous if you don't know what you're doing. You wouldn't give a hatchet to a six-year-old, would you? (At least, not unless you're looking for a good laugh, anyway.)

I didn't bring you all this way for nothing. Charge on.

Alarm Will Sound

I was playing around with some items in my home folder a few days ago, when I stumbled upon these four files that I didn't recognize:

-rwsr-sr-x 1 root admin 255676 Aug 7 01:23 .netprefs
-rw-r--r-- 1 root admin 36 Aug 7 01:23 .netprefs_current
-rw-r--r-- 1 root admin 43740 Aug 7 01:23 .netprefs_services
-rw-r--r-- 1 root admin 7490 Aug 7 01:23 .netprefs_sets
-rw-r--r-- 1 root admin 501 Aug 7 01:23 .netprefs_system

The s bits for owner and group permissions on the ".netprefs" file indicate setuid and setgid (set group ID) are in effect. Since everyone is allowed to execute the file, the program is going to run as root:admin without even asking.

WHOA.

This was hidden inside my home directory? Yes, it was.

But who put it there? Where did a setuid 0 program in my home directory come from?

The four files that accompanied the suspicious executable were human-readable XML files. The .netprefs_services file, for example, contained every bit of information about my network interface setup:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>0</key>
   <dict>
      <key>AppleTalk</key>
      <dict>
         <key>ConfigMethod</key>
         <string>Node</string>
         <key>__INACTIVE__</key>
         <integer>1</integer>
      </dict>
      <key>DNS</key>
      <dict/>
      <key>Ethernet</key>
      <dict>
         <key>MACAddress</key>
         <string>XX:XX:XX:XX:XX:XX</string>
      </dict>
[. . .]

Another file, .netprefs_current, contained a rather strange serial number that I have yet to identify—the only line of text in the entire file. (For this reason, I don't feel comfortable posting its contents here.)

And then I took a hard swallow:

[thermodynamics:~] mikey% strings .netprefs
[. . .]
/bin/rm -rf "
/usr/bin/killall "
[. . .]

The file was a compiled binary, but good ol' strings provided me with a little bit of plain-text insight here.

Reviewing what we hitherto knew:

1. A setuid 0 app appeared out of nowhere on my computer.
2. What appear to be files associated with it contain detailed network information about my computer.
3. It runs some sort of rm -rf and killall commands at some point, under some unknown condition(s).

I dug through every remotely relevant log inside every log folder on my PowerBook. Nothing weird matched the datestamp on the .netprefs* files. My Mac OS X Server box didn't have the files at all. Merv's rig didn't have the files present, either.

But Nic, he had a story to tell:

-rwsr-sr-x 1 root Nic 255676 Jun 25 14:27 .netprefs
-rw-r--r-- 1 root Nic 1 Jun 25 14:28 .netprefs_current
-rw-r--r-- 1 root Nic 22634 Jun 25 14:28 .netprefs_services
-rw-r--r-- 1 root Nic 4504 Jun 25 14:28 .netprefs_sets
-rw-r--r-- 1 root Nic 478 Jun 25 14:28 .netprefs_system

What did Nic and I have in common? PowerBooks and Tiger, but not a whole lot of similar software. Turns out, we had one big, stupid thing in common:

Comcast.

Those morons. I then remembered their setup program erroring out and ceasing to work when I attempted to set up the new Interweb connection here, just like it had done on every other computer on which I had run it, and suddenly things clicked into place. I knew their setup software was poorly designed and really quite pathetic before, but this took pathetic to all new levels.

It only took me a couple of minutes to dig out the setup CD and verify the program's origin.

Switching tense here. Hold on to your hats.

From what I can tell, their setup software is a compiled excutable that scrapes the network configuration data from your computer, attempts to write a new configuration, and uses an AppleScript to control Internet Explorer (and only Internet Explorer) to guide you through filling out the setup forms.

For this, this simple set of tasks, they ran and installed a setuid 0 program. They compromised the basic security of many people's computers to set up an Internet connection. A malicious person is essentially given an open door to pwning potentially any Mac user who has used Comcast in the past for high-speed Internet service. HEY LET'S GIVE YOU INTERNET ACCESS AND THEN PULL DOWN YOUR PANTS. Are you fucking kidding me?

There's no telling what kind of other potential security issues exist with their setup program for which its setuid flags could be an accelerant. It's only a matter of time before a malicous person finds something like this—just like always in the world of security—and at that point, they simply need write a trojan that executes the ~/.netprefs file on launch.

From what I can tell, their setup system doesn't need to run as setuid to accomplish its tasks. I bet I could completely re-implement it in AppleScript Studio and it would be improved tenfold.

For more information about setuid and race conditions, check out these links:

Man page: setuid - checklist for security of setuid programs

Avoid Race Conditions

To e-mail Comcast and complain about their sub-standard software, head over to this page:

http://www.comcast.net/help/contact/

To see if the monster is hiding in the attic, turn to page 42.

Update the First

It's been pointed out that one may want to remove these files if they exist. I do recommend getting rid of this garbage.

You'll need to log in as an administrator user for this. Please don't typo[2]:

sudo /bin/rm ~/.netprefs*

Enter your administrator password when prompted.

Update the Second

Before the comments were removed (see below), someone pointed out that setuid was disabled in Panther. This is not accurate. In Panther, Apple disabled setuid and setgid for scripts only—compiled binary executables still run respectful of setuid and setgid. If setuid and setgid were disabled for compiled binaries, many things would simply stop working. See for yourself if you're unsure how important setuid is to Mac OS X:

ls -la /usr/libexec /sbin /usr/sbin | grep 'r.s'

Even pretending all setuid and setgid functions are disabled in current versions of Mac OS X, it's still terrible software design on Comcast's part—a complete lack of future sight. From an even more pragmatic perspective, I constantly find people who still run Jaguar. This is simply part of the real world, where new toys cost money.

Of course, I really didn't expect much from a company that requires MSIE in order to complete a damned cable modem setup. I've been through their horrid setup process before, and it always ends the same: I call them, they enable the service with my MAC address manually.

Why did I bother running their setup software if I knew it was total crap to begin with? I almost didn't. I decided to see if anything had changed from previous experiences with both my computers and customers' computers, and as expected, nothing had changed. It's a shame that with the amount of money we pay Comcast for their service we can't get a setup process that isn't pathetically anemic.

If no one's watching, they won't have a reason to improve.

[1] I usually recommend, for the sake of cleanliness, using /private/tmp/$UID for storing temporary files for applications. But that's just me, and like I said, I'm weird.

[2] Seriously. Don't typo. I'm not responsible for damages, catastrophes, or the further decline of the U.S. economy if something goes wrong.

link to: race condition

file under: analysis | comments (1)

kMDFolderPath
14/Jun/2005 | 01:51

Folders Never Die, They Just Go to /dev/null and Get Indexed

I usually write my essays in a program called MacJournal before I post them to the MovableType-based waste processing plant known as /damage. Today, I'm writing this one in BBEdit, a straight-up text editor. Why? Because I authored the site in it, I'm just writing words, and GOLLY GEE GOSH ALL I REALLY NEED IS A TEXT FILE.

Right?

Enter SPOTLIGHT. But MacJournal lets me organize my writing, notes, and site entries like a composition book. METADATA. I know what each entry is about already, and I can point to which one I want to reference by just looking at the title. LIVE SEARCHES. How often do I really need to see my article on other stupid names for Bonjour along with other stuff?

See, both of the voices in my head are wrong. I need to do two things: organize and locate. Search systems like Spotlight all rely on various pieces of metadata, but how much metadata can be written by a computer that can't think like I do?

Let me cut to the chase and tell you where I'm going with this.

People are talking about metadata searches replacing folders. Some think it's really going to happen; some absolutely love their deeply nested folder structures. Me? I need organization, and file paths accomplish that. But I also need flexibility, something file paths can't pull off. There's got to be a solution here.

What Can Be Said About the Human Brain? (Or: The Big Dilemma)

I'm lazy. We're all lazy, to some extent, and metadata is WORK. That's right. Metadata means figuring out how you want to classify or tag things, and that requires thinking, and thinking is HARD WORK. If I stick to plain text files inside well-organized nests of folders, most of the metadata work is done for me by slick kernel extensions, but OH SHIT, that means I've gone through the task of classifying everything anyway, and WE'RE RIGHT BACK TO WHERE WE WERE BEFORE.

So folders are here to stay. My resume is in ~/Documents/Employment/Resume and those invoices for last month are in ~/Desktop/work/Accounting/Invoices/Incomplete . . . We don't need no stinking metadata here. I've got a deep and complex folder hierarchy, and the world is a hierarchical place. Leaves on trees; atmospheric layers; shoulder, arm, hand, fingers. But those invoices also pertain to that internal finances audit we're doing, so maybe they should go in ~/Documents/Company/Audit as well. So much for hierarchy when the human brain can't classify anything to save its life.

Luckily for us, we've been working with metadata the whole time: folders and directory hierarchies are just pieces of metadata that describe where a file exists on the disk. Perhaps we can exploit this. If the location of a file is a piece of metadata, and a file can have an arbitrary amount of metadata associated with it, why can't it then exist in more than one place? Our invoice file could exist in ~/Desktop/work/Accounting/Invoices/Incomplete as well as ~/Documents/Company/Audit at the same time. Is this too difficult to process, though, as human beings? Leaves on trees.

So our problem isn't that we as humans have to classify things, and it's not that data shouldn't be so rigid as to be classfied in the first place. Our problem is just how much classifcation we can do before the extra work expended negates any of the benefit of live searches and flexible storage and retrieval schemes. I know I don't want to have to get info on a file and add a bunch of stuff for it to be locatable or otherwise useful. Work is hard, remember? I take computer out of box, I plug in computer, I turn computer on, it does work for me. Not the other way around.

Where are we left? Folders are too rigid, though we could theoretically apply extra "locations" to files, and adding metadata is out of the question because, again, I'M LAZY.

We're left with no real solutions. Metadata will not replace folders, and the folder needs to evolve past its current incarnation. Anyone who thinks one will usurp the other doesn't understand the benefits and drawbacks of both methods. I'm reminded of a quote by Albert Einstein at times like this:

The significant problems we face can not be solved at the same level of thinking we were at when we created them.

Back to the drawing board.

link to: kMDFolderPath

file under: analysis | comments (6)

sit down
28/May/2005 | 21:16

Saying Goodbye is Hard Until You're Forced to Reinstall

INT. TRAUMA ROOM — NIGHT

EVERYONE stands around the PATIENT, lifeless on the gurney. A LONG, STEADY BLARE from the heart monitor fills the room.

NURSE
Doctor, we've administered enough epi. The
patient's been asystolic for an hour now.

ATTENDING
Dammit.

RESIDENT
Isn't there something else we can do?

ATTENDING
No, the nurse is right. He's gone. Time of
death: Midnight, 29th of April, 2005.

CUT TO BLACK

And with that, I say to you, StuffIt:

It's been nice knowing you, but it's time to let you go. While you've been a fine friend over the years, you're simply an annoyance at this point. In short, you need to be deprecated.

When you were the only easy-to-use program suite for compressing and decompressing my files, you were wonderful. You could even open the alien .zip and .gz files my Windows and Unix friends would send me. Once, I asked you to compress my Marathon folder so I could fit it on a Zip disk after I lost the floppies. You did that admirably, and for that, I thank you.

But when you were the only application that needed to be reinstalled after I upgraded to Tiger, I was not amused. From what I could tell, everything was in the proper place on the drive. You seemed to disagree. I didn't need to register you again, thankfully, but I was not pleased with having to dig through my backups to find your installer's disk image.

You told me, "You could've just gone to my Web site and downloaded the installer instead of hooking up your FireWire drive."

See, StuffIt, I did that before heading for my FireWire drive, but I would've had to download StuffIt Standard v.Whatever, and I really just needed StuffIt Expander. Now, my installer copy was StuffIt Standard 7.x, so there's no real gain there, but God knows what else the new version installs that I don't need. No telling how much slower the new version is, either.

Why do you need to put your fingers inside /Library, anyway?

I'm done with you, StuffIt. If you refuse to run without being reinstalled, that's just how it'll have to be. I have the Finder, so I can compress and decompress files faster than you've been able to since version 5, anyway. Don't let the door hit you in the ass on the way out.

Developers have no reason to sweat a mass migration from you, StuffIt, either—if their users aren't running 10.3 or 10.4, they've already got you installed to handle .zip files. No one's gonna be left in the dark. I know I won't lose any sleep.

Who's with me?

link to: sit down

file under: analysis | comments (5)

nuke and pave
27/May/2005 | 15:55

Who Moved My Hosts File?

By now, some of you probably know that the installer for Mac OS X 10.4 Tiger Super Turbo Championship Edition will completely overwrite the /etc/hosts file, even when you configure the installer to use the "Preserve Users and Network Settings" ninjitsu that is otherwise quite awesome.

Can someone tell me why "Preserve Network Settings" doesn't include the hosts file? There's no reason that the installer option shouldn't include other networking configuration the user has done in addition to simple network locations. Since I don't want this to turn into a half-balled rant, let's back up:

Theory:

You, Mr Pretty Good Programmer, need to make sure that there are three important entries in /etc/hosts before restarting the machine after install:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost

To ensure the client's hosts file has these lines, you have your installer write a clean hosts file, regardless of preservation settings. You've guaranteed yourself—and in doing so, your users as well—a perfectly working, painless installation procedure.

Well, you've got the "perfectly working" part down, anyway.

Do Not Pass GO, Do Not Collect $200

Okay, so your client base is pretty diverse. Grandmothers, high school English teachers, musicians, celebrity bloggers, and some pretty sharp scientists are all using your operating system, and they're all doing different things with it. Why, right down the street, Ack uses your OS every day. Ack is a typical network/systems admin. At any given moment, Ack's PowerBook could be connected to two or three different computers, browsing the Interweb, or waiting for the results of his latest nmap query.

Needless to say, Ack's hosts file is pretty decked-out. He's got a dozen different internal servers' IPs mapped to easy-to-remember hostnames like "suckbox" and "helldemon". (Ack's kinda bitter from an Oracle install that went awry once long ago. Don't ask.) His home ISP is pretty bad, so he's got a few frequently used sites' domain names plugged in there somewhere. In addition to all of this, one day Ack got fed up with seeing so many damned ad banners left and right, so he summoned some John Woo action and blocked hundreds and hundreds of advertisers' servers with a little help from everythingisnt.com.

Boy, was Ack pissed when he upgraded to Tiger.

Profanity Is a Stress Reliever

"Why did they have to overwrite my !&#^@*# hosts file?" Ack uses the word "they" because he sees you as having hosed his hosts file, not a faceless installer script. He uses the word "!&#^@*#" because he drinks too much coffee.

Ack goes and looks through his backups and with some head and diff action, he realizes that there was no change to the stock hosts file from Panther to Tiger. And indeed, the first nine lines of his hosts file matched the original file and the replacement file from the Tiger installer.

Even assuming Ack didn't do the Bright Thing™ and add his customizations to the bottom of the file, and peppered them all around the original three entries, Ack knows that the three lines themselves should always be identical to their original state, even if they're not contiguous. Grep, he figures, should have been able to find the entries. If they all had been there, the installer could have left the file alone; if one had been missing, it (or all three entries) could've been written back to the top of the file.

"All it did was erase all of my customizations, essentially!" Ack yells into his monitor. He's not too pissed, because he's got backups, but he, like many others, considers /etc/hosts to be part of his "network settings".

So if all it would have taken was a little bit of shell scripting to see if the hosts file still has the original three entries it needs, why just nuke it down?

Rule:

If you can reasonably avoid forcing your users to retrieve data from backups, you do.

Theory:

Ack could probably use a vacation, anyway.

link to: nuke and pave

file under: analysis | comments (1)

tigon? liger?
02/May/2005 | 10:56

Last week, Mac OS X 10.4 was released, and that means there are lots of reviews out there to read. ARE YOU SHOCKED YET? I AM.

Now, this isn't a review. This is a highly disorganized series of screenshots of Nifty Things™ you might have missed while perusing other sites' reviews, or perhaps even using Tiger yourself. Or maybe not, and I'm wasting your time. Let's find out!

First off, I'd like to point out that the new default screenshot format is PNG. Despite what some will say, PDF was a good format to use, but it was a bit unwieldy at times, so while PDF wasn't bad, I'm not going to complain about the change to PNG.

You may also notice a few other things about that screenshot: "Spotlight Comments" as a field for tagging your files with some basic metadata; the "More Info" area for, well, more info on the selection; and the fact that—though you have no way to know it from a single screenshot—I selected two files in the Finder, hit command-i, and was given two separate info windows, in a throwback to the Mac OS 9 days. I'm ambivalent toward this last change. Command-option-i still works, so everyone should remain happy.

This is an amazingly well-designed authentication dialog. Very simple, uncluttered, and informative in the right place.

It looks like someone had the sense to make the Finder's sidebar right-clickable. I can't count how many times I tried to right-click on items in the sidebar, in Panther, only to be reminded that I'm a short bus kid by the computer.

Thank you, iChat team, for adding autoreply to your application. You're only behind everyone else by about a decade. Sincerely, Everyone.

In a move to appease the Slashdot crowd, someone at Apple decided to build in a dialog to change modifier keys around. Hotness? Definitely not a bad thing. Is anyone else smiling at the idea of a dialog to modify a modifier?

YOU CANNOT SEE ME BECAUSE I AM IN STEALTH MODE. I AM ALSO WATCHING MY LOGS SO DON'T TRY TO HACK ME. KTHXBYE.

The biggest weakness in passwords is the user creating the password. Tiger includes a Password Assistant dialog panel, and it doesn't seem to be too bad. Nothing new, but certainly a welcome addition. (Some of you may remember this as being part of Panther's Keychain Access.)

That's one big-ass cursor.

Now this is pretty freakin' awesome: QuickTime Player now records both audio and video[2][2] If anyone wants to buy me a FireWire camera to test this, that would rock. Anyone? Bueller?.

The help system has been expanded to include AppleCare Knowledge Base articles in its search results. This should be helpful for just about any class of user. I definitely applaud the design decision that went into this one.

Finally, a couple more Spotlight notes. You can exclude disks and folders from being traversed during Spotlight searches by adding them in this preference pane tab. Very useful if you need to hide that girl-on-aardvark pr0n from your girlfriend while showing her how quickly you can find all of the pictures of her you've taken. And yes, Spotlight really is that awesome.

link to: tigon? liger?

file under: analysis, mirth | comments (5)

dashed redux
29/Apr/2005 | 10:33

Two down, three to go:

http://www.apple.com/downloads/macosx/dashboard/rssbean.html

http://www.apple.com/downloads/macosx/dashboard/wikipedia.html

I'm not sure if you can specify multiple feeds with RSS Bean, and I'm not a big fan of the UI for the Wikipedia widget, but we're at least getting somewhere, and it's only day one of the Tiger era.

Thoughts:

Wikipedia widget needs a content-indexed history for searching past Wiki articles you've viewed. Upon loading a Wiki entry, the widget should index all links from the article, with results viewable in an inspector-style drawer or something else that isn't a contextual menu.

This is also goodness.

Rock on, Chicago. Rock on, Dashboard.

link to: dashed redux

file under: analysis | comments (1)

ColdDesign CX
18/Apr/2005 | 08:05

In between cans of orange juice this morning, I read that Adobe will be acquiring Macromedia for $3.4 billion in stock, issuing current Macromedia shareholders a shares trade of .69:1. Considering Adobe is hovering at about $60/share right now, and Macromedia's shares are around half of that, the Macromedia shareholders are getting a decent deal.

Oh, look. Adobe's shares are falling. Oops.

So Merv and I made a bet: I say that within the next eighteen months—six months for the companies' boards to approve the merger, and twelve more months to complete an acquired product revision cycle—Freehand will be no more, its unique feature set being rolled into Illustrator. If Freehand still exists, it will not be in its current form. I get a dollar if I win this one.

Also dead: Dreamweaver, but only because it'll now be called "GoLive". The corpse of GoLive will be forced into Dreamweaver, and we'll lose the last really powerful WYSIWYG editor. Glad I use a text editor.

And three more final predictions:

ColdFusion MX Server will be ported to Mac OS X Server, and not just for "development purposes".

Flash MX will get Premiere's badly designed timeline interface. Not that it wasn't headed that way already.

I will win a dollar.

link to: ColdDesign CX

file under: analysis | comments (8)

prétentieux
13/Apr/2005 | 08:56

Naming a product by committee is a dangerous thing. It tends to, but not always, lead to silly product names like "Entourage" and "Paint Shop Pro"[1][1] Paint Shop Pro comes out of this article as soon as my copy of Paint Shop Standard arrives.. I have the feeling GIMP was named on a mailing list.

Looks like Apple's getting into the boat by finalizing the new name for ZeroConf Rendezvous OpenTalk: Bonjour. No, seriously.

"Hey, Bob, welcome to the meeting. Just hook up your laptop and we'll be ready to go."

"Hey, Bill. Are we all on Bonjour here?"

"What? Bob, you're fired, you elitist prick."

So maybe that exchange won't happen, but the new name isn't destined to help eliminate the misconception that all Mac users are all pretentious aesthetics whores with silly computers.

With this HOT NEW NAME, I thought perhaps Apple would like some help dreaming up other new, chic product names for future versions of Bonjour:

Ciao

Benvenuto

That Easy Networking Stuff

Not Just iChat

Easily Overlooked Protocol

iDiscover

Fill Strangers' Drop Boxes with Porn™

Now if you'll excuse me, someone just messaged me via Rendezvous.

link to: prétentieux

file under: analysis, mirth | comments (14)

simply dashing
11/Apr/2005 | 10:30

You don't know it yet, but Dashboard has the potential to make your life very, very happy.

Still, with power comes the ability to fail. The demos on the Apple site are indeed impressive, for starters. The on-the-fly language translation widget is something that makes most people look twice, and it's nice to have a useful app like Stickies right there at your fingertips. But what else? Most of the widgets Apple has demoed to this point have been bits from Sherlock or little desktop accessories. Calculator. iTunes controller. Weather modules.

In short, there's no killer app for Dashboard. Yet.

I won't pretend to know what that killer app is going to be, but I can think of five things that Dashboard is screaming to have. So here, I give you the five best Dashboard widgets that haven't been written yet:

1. RSS feeds are neither new nor are their reader apps that special anymore, so no one's going to run out to play with Dashboard just because it has an RSS aggregator. But what prompted me to say, "You know, Dashboard needs an RSS widget," was a friend saying that typical RSS reader apps suck up too much screen space. I thought, if your reader flew down when you hit your Dashboard key, wouldn't that solve the problem entirely? Sure, you could just command-h your copy of NetNewsWire, but that still leaves the NNW icon in the Dock, and somehow it simply doesn't feel as fast as a widget would feel.

With that one out of the way, let's start talking about the types of widgets that would make people content with spending $130 on an OS upgrade.

2. Quick, tell me everything you know about Ayn Rand. The Manhattan Project. Baking powder. Time's up. If you had a Dashboard widget that was a Wikipedia search and results display panel, you would be on top of the freaking world right now. Ken Jennings wouldn't stand a chance against you, with the vast and ever-evolving knowledge of Wikipedia at the slightest tap of your F12 key. Dashboard widgets can take streams of information from the Interweb, Wikipedia is published under a GNU Free Documentation License—put them together, already.

3. VoIP services like Skype are here to stay, whether the telcos like it or not. Imagine activating the Dashboard and a dial pad flies down onto the screen. Dial your number, hit enter or click the "send" button, and wait for the call to connect. Hell, why are we remembering phone numbers anymore? Address Book has all that information for me already. Dial pad descends onto the screen, I click the "people" icon on the side of the window, and a list of my contacts appears—name, picture, and phone number. This may not be possible with Skype, but surely this will be possible somehow, at some point.

4. Whiteboards are great for visualizing information, and can make meetings much smoother (or wreck them entirely, but that's beyond the scope of this article). Why not add a whiteboard to the Dashboard? Quartz has vector art capability as well as beautiful and flexible text capabilities. Tie it to the Postscript system and give the whiteboard widget the ability to save whatever's on the whiteboard as a PDF. Give it layers with adjustable opacity. QuickTime movie exporting to create a transitioning slideshow for importing into your Keynote presentation. Hell, make it Rendezvous-enabled and collaborate across the building or in a single conference room.

5. People bemoan the lack of apps that utilize the microphone built into many Macs. What we need is a "pocket recorder" widget that allows you to record, save, and play back audio snippets. The digital age version of carrying a minicassette recorder to class. Next time you're sitting at your desk and that GREAT IDEA hits you like a freight train, but you're too busy to stop and attend to it, drop the Dashboard, click RECORD, and let the idea fly. Save it and go right back to work. (Of course, if you think better writing by hand or typing, I guess it's Stickies or a fountain pen, but for others . . .)

That's just five off the top of my head. How many more could there be?

What I'm afraid we're going to see is a huge influx of extraordinarily useless stuff—more iTunes controllers, duplications of existing desk-accessory-eqsue apps, more clocks, and random quote generators. Dashboard is a usability solution for lots of ideas, but it's likely to get cluttered with useless trinkets and toys.

These five ideas are free for use for any developer who wants to tackle them, and I don't ask credit, because I think they are, for the most part, fairly obvious ideas. I'd like to encourage anyone reading this, as well, to think up one idea and post it to the comments under the same free use ideal.

Have at it.

link to: simply dashing

file under: analysis, method | comments (20)

head for an eye
10/Apr/2005 | 23:00

A Loudon County, VA court has put a major spammer in jail for nine years.

This is where I jump up and shout how awesome that is, right? He deserves it! I mean, just look at that photo! What a sleazeball. Only nine years? Why not twenty-five? One day for each piece of spam he sent!

Actually, I'd rather look at what his sentence can be compared to:

> In Virginia, the murder of an individual during the commission of a felony robbery without the premeditated intent of murdering an individual requires only a minimum of five years imprisonment. (Code of Virginia, § 18.2-33[1][1] § 18.2-33. Felony homicide defined; punishment.

The killing of one accidentally, contrary to the intention of the parties, while in the prosecution of some felonious act other than those specified in §§ 18.2-31 and 18.2-32, is murder of the second degree and is punishable by confinement in a state correctional facility for not less than five years nor more than forty years.
)

> Single counts of rape[2][2] § 18.2-61. Rape.

A. If any person has sexual intercourse with a complaining witness who is not his or her spouse or causes a complaining witness, whether or not his or her spouse, to engage in sexual intercourse with any other person and such act is accomplished (i) against the complaining witness's will, by force, threat or intimidation of or against the complaining witness or another person, or (ii) through the use of the complaining witness's mental incapacity or physical helplessness, or (iii) with a child under age thirteen as the victim, he or she shall be guilty of rape.
in Virginia also carry only a minimum of five years imprisonment. (Code of Virginia, § 18.2-61[3][3] § 18.2-61. Rape.

C. A violation of this section shall be punishable, in the discretion of the court or jury, by confinement in a state correctional facility for life or for any term not less than five years. There shall be a rebuttable presumption that a juvenile over the age of 10 but less than 12, does not possess the physical capacity to commit a violation of this section. In any case deemed appropriate by the court, all or part of any sentence imposed for a violation of subsection B may be suspended upon the defendant's completion of counseling or therapy, if not already provided, in the manner prescribed under § 19.2-218.1 if, after consideration of the views of the complaining witness and such other evidence as may be relevant, the court finds such action will promote maintenance of the family unit and will be in the best interest of the complaining witness.
)

> Collect 'em all: As it turns out, kidnapping is a fairly ho-hum crime here, it seems. One year minimum, ten year maximum. In theory, I'd have to kidnap a classroom to get a tougher sentence than nine years. (Code of Virginia, § 18.2-47[4][4] § 18.2-47. Abduction and kidnapping defined; punishment.

A. Any person, who, by force, intimidation or deception, and without legal justification or excuse, seizes, takes, transports, detains or secretes the person of another, with the intent to deprive such other person of his personal liberty or to withhold or conceal him from any person, authority or institution lawfully entitled to his charge, shall be deemed guilty of "abduction"; but the provisions of this section shall not apply to any law-enforcement officer in the performance of his duty. The terms "abduction" and "kidnapping" shall be synonymous in this Code. Abduction for which no punishment is otherwise prescribed shall be punished as a Class 5 felony.
)

Now, it wasn't a single count of "spamming" that got this guy nine years. He had been, according to news reports, masking his sending identity and pushing bunk products (v14gr4, anyone?) on his "victims"—in quotes because the word "victim" in his targets' cases somehow rubs me wrong after having cited the Code of Virginia article on rape—and was punished within the letter of the law itself.

But really, what's worse for a society: raping and murdering, or unsolicited e-mail? It kinda reminds me of the federal sentencing guideline differences for possession of powder cocaine vs possession of rock crack.

Now, if you'll excuse me, I've got some kids to hijack from the swingset down the street.

link to: head for an eye

file under: analysis | comments (4)

!standards
08/Apr/2005 | 09:46

A while back, I decided that my days of designing for the Interweb were over. One last bad experience with a client, I thought, was all the excuse I really needed to drop making pretty lines and graphics. At the most, I'd do things for myself and myself only.

Something funny happened on the way to the hermit cave. Early this year, I was given the opportunity to move to a different department in the company for which I work [1][1] If a corporation is considered a person, should it be "company for whom I work"? WE MAY NEVER KNOW.. The catch—if you could really call it a "catch"—was that I'd be doing what I swore I'd never do again. If you're wondering what I'm talking about, go back and start this article over.

There were three reasons I stopped writing markup:

1. Writing for multiple browsers is a pain in the ass.

2. Clients are all "idiots" who "never know what they want". This is simply a rule you have to accept; if you can't wrap your head around it, go ask ten people what they'd like to see in a single Web site, of whatever kind you choose. When you come back with more ideas than people, you'll know what I mean. In reality, the clients aren't "idiots", but they definitely don't understand what you're doing, because they—and get this—don't do what you do for a living. This makes communication difficult, sometimes borderline impossible.

3. HTML is ridiculously limited. Tables are horribly rigid for anything other than spreadsheet-style data, as well as being terribly unmanageable. Building a design with tables is like making a rug with a Connect Four set. Cascading Style Sheets were introduced to get rid of design rigidity and open up markup to removing layout code from actual content. In separating as much as you can, you gain design flexibility as well as a more manageable code base. Wow, I only have to specify that image tags have no border once, and they all behave that way? I can automatically have all paragraph tags inside my news posts indented for me?! HOLY SHIT.

So CSS was going to be this BIG REVOLUTION, and for the most part, it's lived up to the hype. But what about things it can't do? The W3C is drafting the CSS3 spec at the moment, and that adds plenty of really nifty things like curved borders, more typesetting options for you typewhores out there, and even a robust speech module. We're all good to continue heading into the future, right?

Right?

With the exeption of security patches, development on Internet Explorer was seemingly halted ages ago. So long ago, in fact, that Mozilla had a chance to hit 1.0, Apple had a chance to develop and mature Safari, and Amazon turned a profit.

Good enough for highway work, though, right? It renders my Yahoo! page, it lets me do my on-line banking, and I can surf all the good pr0n sites all day long in my once-a-month-washed bathrobe. If it ain't broke, don't fix it!

What Microsoft have seemingly forgotten is that while your users determine your user base, if you don't have developers on your side, it doesn't make a lot of difference.

Silencing the protestors

No one ever really sleeps in Redmond. Microsoft is a company of bureaucracy and complacency, surely, but that's like saying your laziest, but meanest, pit bull never keeps an eye on the yard. If a cat comes behind the fence, Mr Pit Bull will do something about it. In Microsoft's case, it was a Mozilla's Firefox.

Internet Explorer 7 was announced a few months ago, with the beta being available sometime this summer, and it's going to have features other browsers have had for many years: tabbed browsing, robust pop-up blocking, full PNG support, and increased security, among other things. While, honestly, I'm skeptical about that last security bit, it would appear the the pit bull in Redmond is going to get its browser act together and come into the year 1999.

But take note of one very relevant thing I didn't mention:

Standards support.

I've been looking through the IE7 buzz that's been floating around the Web, and I've yet to find any sort of solid, significant confirmation of standards support that it's lacked since 1996. It would seem as though, per typical Microsoft behaviour, no one in Redmond is interested in not pissing off every serious designer in the world with broken standards support. Internet Explorer's standards support is second only to its busted security model.

All this having been said, it's not out yet, there hasn't been much (if any, honestly) official word on the matter, and the version that's being released this summer is only a beta. For all anyone knows, IE7 will come out of the gate with all of the Mozilla organization bleeding and crushed in its jaws and show the world what standards support really means.

But I don't care.

It's not that I'm lazy or some open source nutball; I dealt with sucky browsers for years before giving up and caring only about the browsers that care about me. There was a time when all the major browsers were fairly pathetic in one way or another, but around the time Mozilla 1.0 and Firefox were released and Safari began to surface, browser developers got over the "let's implement our own special tags and handle tables and shit our own way" movement of the 1990s. The new attitude gave even more indie browsers like Opera and OmniWeb a fighting chance, not that they always took it. I mean, if the big dogs are shooting for standards, and the standards are published and open, we're playing on a level field.

But Internet Explorer didn't move. It got bug fixes for security holes and patches for crashes. It had and still has been years since a real upgrade to the browser, and at one point Microsoft even stated that IE7 wouldn't exist until Longhorn. If the only reason IE is going to change is because of an organization that moves to improve itself because that's the only place to go (Mozilla, of course), what reason is there to continue IE's progress after you've quashed the competition?

Internet Explorer, at one point, wasn't substandard. Right now, it's the worst of the bunch. With a laughably incomplete CSS1 and CSS2 model alone, it's worthless to me and anyone who takes their skills—as well as the time it has taken to develop them—seriously. No browser is perfect, but if someone has to be the broken-down Pinto in the parking lot, it's Explorer.

And if the past holds up, it always will be. If anything ever changes, it'll be that another browser will outclass it [Explorer] in every corner but marketshare, and Microsoft will update it a little bit to compensate before going back to doing nothing with it.

The standards will move on, and designers will slowly get fed up with being held back by Explorer's lack of support.

A real-world anecdote

If you're not reading this in Explorer in Windows, there's something you don't see. Cracking the source, we find:


<div id="ie_greeting">

<p><a href="../exploder.html" title="Sad panda . . .">Why does this page look so terrible?</a></p>

</div>

Feel free to read the page that's being linked to, but in summary: This site does not render properly in any version of Internet Explorer for Windows, and there's no reason it shouldn't. In fact, the reason Explorer users see that message and no one else does is because Explorer will ignore a rule flagged as !important when there's another instance of the rule after it. Example:


.class { display: none !important; display: block; }

In this demo case, IE renders the element as a block element, and everything else renders nothing at all. IE gets it entirely wrong, the warning message appears for IE users, and I have effectively used a bug to display a message to a subset of users. Because this bug has existed for so long, I don't expect version 7 to fix it or any of the other issues that have been part of the IE "feature set" for so long.

So what if it does, then? What if the earlier scenario occurs, and IE7 is released to be a shining example of compliance? Well, we won't have to worry about our code breaking, and no extra work will be required on my part. I still win. That's the point of standards. But how long until the W3C ratifies the CSS3 spec and IE is again left in the dust when everyone else updates their product?

My site is standards-compliant from top to bottom: DOM structure according to DTD, XHTML, CSS. I went out of my way to write very good, very clean code, and IE tosses it out of the window entirely. This is the problem that frustrates so many designers. Hard work means nothing when 95% of the Web population is using a product that ignores it all. We have to resort to hacks, workarounds, and what's worst of all, limiting our own designs in the face of the unwitting masses who use IE.

Making the best product may not be at the heart of capitalism, but if developers are at the heart of Microsoft, continuing to push them toward hating you isn't how you win them over.

For now, I'll be ignoring Internet Explorer[2][2] Disclaimer: For the purposes of remaining employed should anyone above me read this, I only disregard Explorer for my personal site; I do consider IE in my daily work.
, and I'm forced to encourage everyone else to do the same.

link to: !standards

file under: analysis, breaking things | comments (0)