inessential by Brent Simmons

December 2011

Dave’s State of the Union

Scripting News, The Un-Internet:

Every time around the loop, since then, the Internet has served as the antidote to the controls that the tech industry would place on users. Every time, the tech industry has a rationale, with some validity, that wide-open access would be a nightmare.

Zeldman on Personal Empowerment

Jeffrey Zeldman, The maker makes: on design, community, and personal empowerment:

The year was 1995, and I was tinkering at my first website. The medium was raw and ugly, like a forceps baby; yet even in its blind, howling state, it made me a writer, a designer, and a publisher — ambitions which had eluded me during more than a decade of underachieving desert wanderings.

I’d be surprised if there are many readers who don’t recognize themselves in what Zeldman writes. Why I’m here and why you’re here hasn’t changed in the years since.

Faruk on Gamification

Faruk Ates, Gamification Fatigue:

Most gamification sucks because it breaks down our humanity like it is no more than a computer program that needs to be understood and then rewritten for maximum reward — reward for the company behind it, rather than for the player.

He makes the point that some game-like elements, in the right place at the right time, don’t have to be disrespectful or cynical. I agree with that. There are times when appropriate milestones and rewards (like getting more power on a forum) make complete sense. There are cases when they’re a natural fit for the system, rather than something designed to turn people into chattel.

More from Faruk:

No, the real science behind gamification is a far more perverse, depressing and manipulative one than Brent theorized. It is all about addictive substances and behaviors, human psychology, and taking advantage of the scientifically-verified knowledge we have of these topics.

Brands, Facebook, and You

Betabeat:

What most users don’t know is that the new features being introduced are all centered around increasing the value of Facebook to advertisers, to the point where Facebook representatives have been selling the idea that Timeline is actually about re-conceptualizing users around their consumer preferences, or as they put it, “brands are now an essential part of people’s identities.”

Brands are now an essential part of people’s identities.

Pukin’.

‘Gamification’ sucks

I protect the word “gamification” by placing quotes around it. The quotes stop me from sneaking in with my knife, flicking the dot off the middle i, cutting the c in half, flensing the g, gutting the f like a fish.

“Gamification” is a word and concept invented by idiocrats who confuse humane with manipulative.

Theory about how the mistake gets made

Everybody sees the trend toward simpler, more-focused, better-designed software. Enterprise developers see the consumerization of IT.

You could look at this trend and say, “As software improves, it respects its users more. It works better and looks better, is easier to learn, and leaves out the things that waste a user’s time.”

Or you could look at this trend and say, “As software gets simpler, it gets dumbed-down — even toddlers can use iPads. Users are now on the mental level of children, and we should design accordingly. What do children like? Games.”

Respect

It should be obvious that one conclusion respects people and one doesn’t. It should also be obvious that the first conclusion is correct and the second is incorrect, cynical, and low.

I can’t prove that good software respects people, but I can look at good software and show how it respects people. I can look at bad software and show how it doesn’t respect people.

“Gamification” treats people like children — children who need to be manipulated, who need to be tricked into doing what’s good for them.

And it makes bad software.

My hope

If you ever think of adding “game mechanics” (don’t use that phrase) to your app, please take a moment and consider your ground. What is your outlook?

Do you want to make good software?

Or do you want to impress a boss, client, or VC with your trendy expertise?

Or is this just a hail-Mary play? You’re hoping that this finally is the key to “going viral?” (It’s not.)

I bet, having thought about it, you’ll do the right thing.

An exception

If you’re writing a game, write a game! Games are fun.

Facebook and Ads

ReadWriteWeb:

If you pay for a product, you’re a customer. If you don’t, you’re the product. On Facebook, you are the product. The difference between content and advertising continues to slip.

Average web page almost 1MB

GigaOM reports:

The HTTP Archive charted the growth of the average web page and found that average web pages have grown from 726 KB a year ago to 965 KB now. The 33 percent jump is due in large part to more images and third-party scripts like ads and analytics.

That sucks. It’s a problem.

On the MoneyWell App Icon

Black Pixel’s iconmaster writes:

I built the bucket by using a cloner to arrange copies of a tapered rectangle in a circle. The taller planks are an extrusion of a curved spline, angled to to match the arrangement of the other planks. The handle is a sweep NURBS, while the metal bands and coins are lathes. Really, the modeling is very simple.

I love that simple part. Simple if you’ve spent hundreds (or thousands) of hours in Cinema 4D, I suspect. Me, I don’t even know what a NURBS is.

Great article. I love reading about how designers work, as I’m (slowly) learning on my own.

Speak Vim

Yan Pritzker: “To move efficiently in vim, don’t try to do anything by pressing keys many times, instead speak to the editor in sentences.”

It’s a key concept in Vim. It’s what makes it powerful.

It’s also what makes Vim seem like a game, where you keep getting little bursts of enlightenment and move to the next level.

(Via Pinboard popular.)

On Releasing Open Source Code

Matt Gemmell: Open Source Code.

I strongly encourage releasing reusable portions of your code - it’s the lifeblood of the developer community. Over the years, I’ve put together a set of best practices for releasing open source code, to make life easier partly for yourself but mainly for those who will use your code.

To his excellent article I’d add the following specifically for Cocoa developers:

  • Make sure the static analyzer shows no issues with your code.
  • Turn on the same warnings that Peter Hosey uses, and make sure there are no warnings.
  • Use ARC.

How to sell your app to another developer

Daniel Kennett asked on Twitter about how to sell his app to another developer.

Me, I’ve sold three apps — every major thing I’ve created, except for my current project — so I have some thoughts about this.

Find a good home

Your major concern is to find a developer who will take care of the app and its users in the way you’d want them taken care of.

You have to live with the decision later, and so it can’t be a “we drove Daisy out into the woods and left her there” thing.

The first thing to do is talk to other developers who you know who you believe would do a great job. Don’t worry too much about whether or not they’d want it — let them tell you. They might also suggest other developers.

If that doesn’t work, for whatever reason, write a blog post. Explain what the app is and why you want to sell it. Be honest, but don’t be unnecessarily self-deprecating. (Developers trust honesty.)

Link to your blog post from Twitter. Get the word out.

Be patient

You might get more than one person interested. Or it might take a few weeks or even months to find somebody. People make decisions slowly and carefully, often — as they should, with something important.

It can be stressful, but hang on. Give the decisions the respect they deserve.

Source code

I have never shown source code in advance of a sale. I don’t know what the industry standard is — it could be that I’m an outlier on this.

My thinking is that the product as a whole is the important thing, and code can be dealt with. Either they like the software, or not.

That said, if I had gotten to the point where a developer I trusted, who I wanted to take over the product, asked to see the source code, there’s a good chance I’d do it. If they’re not a person I’d trust to see the source code in advance, then they’re not a person I’d trust to take over the product.

The deal

The obvious way to make a deal is this: pay money for the source code, artwork, domain names, and all related assets. Just a straight-up transaction.

Sometimes it works that way, and that’s cool when it does — but it doesn’t always work that way. There are a couple others ways to structure a deal. These can be combined with up-front payment of some portion, though they don’t have to be.

  • Revenue-sharing. This is usually over the span of at least two years, but can be quite a bit longer, with a declining percentage of revenue. You want to make sure the buyer has an incentive to make great software and sell a lot of copies. This may come with a guaranteed minimum paid to you, either per-year or at the end. It may also have a maximum, beyond which the purchaser keeps all the revenue.
  • Installment plan. This is like revenue-sharing but with a set amount (which may also decline over time). It has the advantage of letting everyone know what the value of the deal will be.

You’ll need a contract, of course. Sometimes the contract can be the longest part of this, and sometimes it’s the shortest. I’ve seen some contract talks go on for six months (though not for any of my software). The contract is the boring part, but it’s important.

(My strong advice is to find a professional money person and a lawyer. I’m not either of those.)

One thing the deal has to be utterly clear about: the moment the contract is signed, the app and all its assets have been bought. It doesn’t matter what the structure is. It’s now entirely owned by the purchaser.

The transition

Don’t imagine that you just turn over the source code and call it done. There are a whole bunch of things related to the product that need to get turned over too, and some of those will take time. You’ll need to communicate with the app’s users. You may need to answer the purchaser’s questions about code, the website, future plans, the bug tracker, support, and so on.

There is a lot of work in the transition, even for a simple app. Plan for it.

(Dropbox is great for this. There’s often too much stuff to put in email. When I did the NetNewsWire transition to Black Pixel, I even gave them ancient screen shots and artwork — I wanted them to own the history of the app as much as the current app.)

Buck up

I may have made this all sound time-consuming and difficult. It probably is, more than you think it is.

But it can be fun, too, and interesting — and if you know it’s time to sell, then it’s time to sell. That’s a hard decision to make, but, once made, should be acted on. It’s the right thing to do.

Lincoln

Abraham Lincoln:

The provision of the Constitution giving the war-making power to Congress, was dictated, as I understand it, by the following reasons. Kings had always been involving and impoverishing their people in wars, pretending generally, if not always, that the good of the people was the object. This our Convention understood to be the most oppressive of all Kingly oppressions; and they resolved to so frame the Constitution that no one man should hold the power of bringing this oppression upon us.

Dave on deals and dilemmas

Dave Winer: “Today, in the area where I’m working, the equivalent of Apple is Twitter. They’re doing one-off deals with developers, and imho again the ones who will do well are the big companies with large installed bases.”

Iraq war

It’s over today. Today will never be a holiday. There will be no V-I day. There will be no pictures of revelers in Times Square.

Like everyone else, I just wish that this monstrous stupidity had never happened.

And I’m so glad it’s over.

Guy on TV

Here’s how Guy English would build an Apple TV set.

It’s entirely different from the other applications of software. First, it’s a shared experience rather than a direct experience like a Mac or an iOS device. Second, this shared experience means there’s necessarily an indirection of input — if a screen is big enough to be seen by everyone in the room you’re not going to be close enough to it to mess with it directly.

Tech Criticism

Dave Winer: “At the end of this year I’m thinking about the need for proper criticism of software, alongside other arts like theater, movies, music, books, travel, food and architecture. It’s finally time to stop being all gee whiz about this stuff.”

It’s overdue.

Clearing up a possible misunderstanding

I’ve discovered there may have been some misunderstanding of my recent posts on websites and reading: The Pummeling Pages, Pub Rules, and The Readable Future.

I meant to make it clear that I was writing to the people who make websites.

I was not advocating smartphone apps or Newsstand apps as a way for them to fix their problems. My entire purpose was to advocate for really great websites that I love visiting in my browser.

In fact, I’ll propose three rules for prospective Newsstand app authors:

  1. You’re not allowed to write a Newsstand app until your website rocks.

  2. You’re not allowed to require someone to use the Newsstand app version of your site when they’re on a phone or iPad.

  3. You’re not allowed to use obtrusive (article-obscuring) ads on your own site for your Newsstand app version.

If you still want to write a Newsstand app, after the above, then cool — do it. Make sure it’s as awesome as your website but also has a clear reason for existing.

(Hopefully it’s clear that I’m using Newsstand both specifically and as shorthand for all native apps, designed to replace your website, that run on smartphones and tablets.)

Apps and web apps and the future

Dave Winer: Why apps are not the future:

The great thing about the web is linking. I don’t care how ugly it looks and how pretty your app is, if I can’t link in and out of your world, it’s not even close to a replacement for the web.

Let’s set aside one thing right away. The browser is an app. Text editors, outliners, and web servers are apps. And, without them, there’s no web at all.

Somebody has to write these things. That implies APIs and more tools that are also apps. It implies an entire ecosystem of apps that are absolutely vital to the web.

I think Dave is talking more specifically about the kind of apps we download from the Android and iOS app stores — apps like Instagram. The difference between these apps and a web app are:

  1. They require downloading: the apps don’t live at a URL.

  2. The user interface uses native code and controls rather than HTML (for the most part).

  3. In the case of the iOS and Mac App Stores, those apps are reviewed before they’re posted.

  4. You can’t (usually, and not easily) link to a specific piece of content in these apps. (There are exceptions, yes.)

Jeff Croft on the web

In A List Apart’s What I Learned about the Web in 2011, Jeff Croft writes:

The most important thing I learned about web design and development in 2011 is that more and more, the “web” is APIs and services, rather than sites, apps, and pages rendered in web browsers. Take Instagram: it’s one of the most popular services on the “web” and the entire experience is controlled not by some HTML pages, but rather by an iPhone app.

Apps are the future and web apps are the future

I think we’ll have both with us for a long time.

There’s one simple reason that should suffice: some developers love writing apps and some love writing web apps, and some love writing both.

This means that people will keep making both kinds of apps. One thing we’ve learned about developers is that economics matters, but love matters too, and many developers will make the kind of software they love to make.

Me, I’m the kind who loves writing both. I’m doing some web work at the moment — it’s been about 10 years since I worked on a web app, and I’m totally excited. It’s fun. The technology has changed so much since then and I’m having a blast. (Today I’m doing my first work with Sass and Compass.)

Some questions

How could you make Instagram without a native client? Is it possible to do those image transformations via JavaScript?

Can you link to Instagram-taken pictures?

If I’m running OmniFocus on my iPhone, and it syncs over the web — do I want anybody to link to my OmniFocus to-do items? Or to my WeightBot stats? To my notes that I edit with Elements and keep in a folder on Dropbox? To my direct messages that go over iMessage?

When publications make such truly excruciatingly awful websites as they do, should I not read them in Zite or Flipboard or Instapaper instead?

Two layers of web

One layer of the web is the http web: the web of Apache, Nginx, node.js, CouchDB, MySQL, JSON, RSS, OPML, XML-RPC, and REST.

That’s the web of backend databases and APIs. That web powers both apps and web apps.

The higher level of the web is the web of HTML, CSS, and JavaScript. That’s the web that runs in a browser (and in web-views in apps). That’s the web that will always lag native code in some respects but that has strengths that native code doesn’t have.

In the past, that higher level of the web pushed most of its work to the server side. But today’s advancements (HTML5, CSS3, Bootstrap, Backbone.js, jQuery, and so on) are about pushing that work to the client side — as apps already do — and accessing the server via (usually RESTful JSON) APIs. Those APIs can be used by both web apps and apps.

I like this. A lot. I like the cleanest-possible separation between backend and presentation. I like language-agnostic APIs and APIs that don’t care at all about how the data is presented. That’s just good architecture.

The future is tangled

If I had to choose one or the other — if I had some crazy power but I had to wipe out either native apps or web apps — I’d wipe out native apps. (While somehow excluding browsers, text editors, outliners, web servers, and all those apps we need to make web apps.)

That’s not the case, though. Nothing has to get wiped out.

I think instead that we’ll see a more tangled future. Native apps will use HTML, CSS, and JavaScript more. Web apps will appear more often on smart phones as launchable apps. Native apps will support linking in and out more. Web apps will move more processing to the client — they’ll be written more like native apps. (Is Twitter an app or a web app? It’s already getting tangled.)

There will be times when you won’t know which kind of app you’re looking at or how to categorize it. I think that’s very cool.

There are multiple tracks of evolution, but those tracks are heading to the same city. And there are plenty of hobos like me that love hopping trains — for fun, to satisfy curiosity, to tell stories and hear stories — on the way there.

Insanely Hard

George Saines writes about how hard it is to make a “kick-ass iPhone app.”

The app market is cruel, even moreso for the need to do a Hollywood launch. Because nobody has solved the discoverability problem in the app store, you need to launch big and magically figure out exactly what users want ahead of time.

Good read. Via @globalmoxie, who you should be following.

(The app market is cruel, but that’s part of why we love it.)

On the Tab Labels in the New Twitter App for iPhone

There’s a lot to like in the new Twitter app for iPhone. It’s beautiful, easy-to-use, and packs in a bunch of useful features.

(Of course, that was also true of the previous Twitter app for iPhone.)

One of my favorite things about the new app over the old app is that it’s now closer to a standard tab-bar app, rather than the previous app’s slick-but-odd sometimes-tab-bar and sometimes-toolbar style.

It’s a good app — but there are, nevertheless, things to criticize. The previous app didn’t have labels for the tabs, and the new one does, which is good. But I disagree with the actual text used for each of the tabs.

What tab labels are for

Tab labels don’t always comprehensively describe everything you can do in a given tab. They’re more than hints — they’re indicators — but they don’t have to accurately encapsulate everything about a given tab.

People know this. They know to tap on each of the tabs and get an idea what’s in there. They then associate the features with location (where the tab is) and label/icon. Each time a user wants to do action x, they don’t read the tab labels and figure out which of the labels logically applies and reject any that aren’t perfect matches. It’s fuzzier than that.

And users are aware of context: they know that the Search tab in one app might be different from the Search tab in another app.

They learn the software by tapping and recognizing patterns, not by thinking logically and strictly at all times.

What we know about people and words

People respond best to concrete words, and English speakers respond best to non-Latinate words.

When asking your significant other to pick up some milk on the way home, you don’t ask, “Will you attend the purveyors and retrieve a dairy beverage?”

You ask, “Will you stop at the store and pick up some milk?”

Marketing-speak

How many times have you been to a product website and seen big bold letters proclaiming that you can CONNECT and ENGAGE and DISCOVER? Every time I see that, I hit the back button, and I bet you do too.

It’s because it’s vague. It’s supposed to sound exciting, but it’s not. It doesn’t say anything about what you can really do with the app.

Nobody wants to connect or discover. People want to talk, send email, chat, share, post to Facebook, tweet, and so on. They want to find old friends; they want to find new friends; they want to see if their brother went skiing on the weekend so they can remember to ask about it on Christmas.

They want to find out if people are talking about them or to them, or if other people are talking about the same things they’re talking about.

The tabs

There are four tabs: Home, Connect, Discover, and Me.

Home is what you call a tab when you don’t have any other idea what to call it. The label Home means nothing in particular. I would have gone with Tweets or Timeline — a more-concrete word that says what’s actually on that tab.

Connect and Discover are the ones I like least, since they sound as if they weren’t decided upon by designers but by a murder of marketing executives perched around a big table. Both are too-abstract Latin words with the blood sucked out of them.

I would have gone with Mentions and Find. Those words may not encompass everything you can do on those tabs, but they’re close enough, and they mean something — while connect and discover mean almost nothing. Those require translation into the concrete. (Why Find instead of Search? Because Find implies success, while Search is an action that may fail.)

Me I almost don’t mind, except that it reminds me of Microsoft, which would always have things like My Computer and My Photos and everything — which made me wonder why my computer thought it owned my stuff. The computer isn’t me, and the software I run isn’t me — I and only I am me. (I probably would have picked Profile for the last tab. Even though it’s Latin, it’s concrete in the world of software.)

Words are UI

Words are as important as graphics and animation. Words are part of the user interface. People prefer words with meaning to words that could mean just about anything.

Path Sliding Clock Thing

Tim Duckett checked out Path: “I was quite intrigued by the little touches, particularly the little clock icon that slides up and down the right-hand side of the screen as you scroll down the timeline. It looks really neat, and it got me wondering how it was done.”

Tim then explains how it was done.

Matt + Octopress + MarsEdit feature request

Matt Gemmell is Blogging With Octopress. I think that’s cool. (Yes, that article is a few months old.)

This site is run by my own custom software, but the idea is the same: Markdown files are stored in a directory structure on disk, and a Ruby script generates the weblog and rsyncs it to the server.

I love blogging this way. I still get to use MarsEdit, even.

I can use MarsEdit because I run a local webserver that has a Ruby CGI I wrote that implements the MetaWeblog XML-RPC API.

But I wonder if it would make sense for MarsEdit to handle this situation natively: that is, it could read and write files directly on disk. The directory structure is simple, with relative paths like 2011/04/16/some_file.markdown.

If MarsEdit worked that way, then it would allow developers to write blog-generation software like mine and like Octopress, and still have MarsEdit support without having to jump through the hoops of running a local webserver and a CGI script.

Justin on iPad magazines

Justin Williams: “Don’t just export PDFs from InDesign and then slap them around an iOS app wrapper.”

Includes plenty of other good advice. (But first take a moment to imagine slapping-around PDFs. Kinda fun.)

Will not ‘Continue to Site’

I was about to link to an article on Forbes.com that I had seen on my iPhone. But when I went there on my Mac I got one of those full-page ads with a countdown and a “Continue to Site” link.

I didn’t click “Continue to Site,” and I decided not to link to the article.

This is one of the things that gets me about analytics. You can measure how many people don’t click “Continue to Site,” or who don’t wait for the ad to finish. But you can’t measure how many people would have then blogged or tweeted or shared that article but then didn’t.

Piezo

Our pals at Rogue Amoeba have released Piezo, their first Mac App Store app. Looks very cool.

Your name matters

Take a look at your weblog. How easy is it to find your name?

It’s hard in a surprising number of weblogs. But I’m not going to link to your weblog unless I can find your name.

I don’t think it’s deliberate, most of the time — I think it’s just a case that people forget to think of it. After all, the author knows whose weblog it is.

Info Libre

Tim Bray, Bits as a Service:

At this point, the voices of traditional journalism and other information-providing businesses are raised in a howl, along the lines of “you’re gonna miss us when we’re gone!” Yep, and as long as you hold onto the silly notion that you’re in the business of selling information, you’re gonna be gone.

Pat Dryburgh’s Updated Ballard style for NetNewsWire

Pat Dryburgh made an updated version of my Ballard stylesheet that makes it so images don’t extend beyond the content column. Good thinking.

(It’s not a problem I run into, since I almost always run NetNewsWire on a large display. But if you’re using a laptop, this is a great idea.)

I totally don’t mind Pat’s taking my stylesheet and updating it. I think it’s awesome. But if a situation like this comes up again, it might be a good idea to use a different name and just credit the original. (But I don’t mind. Other stylesheet developers might mind about their own styles, of course.)

Frank Luntz

I don’t understand Frank Luntz. He’s clearly gifted. He’s excellent with words.

And yet those gifts don’t come with love or even respect for language — instead, language is debased, used as a tool for power and nothing else. That is the opposite of what language is supposed to be.

How is it that some people take Orwell’s warning about Newspeak as a blueprint? It’s not a rhetorical question. I don’t know how.

More about splash screens

Here’s what I found, that freaked me out, when discussing iPhone apps with web publications.

Yes, they always wanted a splash screen instead of the standard screenshot of the interface. That’s not great, but I understood, and we made it possible in TapLynx.

But that’s not all they wanted — they wanted an animated splash screen, and they’d tell me which apps they’d seen that have that.

Here’s the thing: there’s no way to do an animated splash screen unless you delay the appearance of the app UI. While the app is being launched, the system displays a PNG file provided with the app. It can’t be animated.

But you can animate once the app is actually loaded. What people asked for is that we then display an animated splash screen, and delay the appearance of the user interface.

I didn’t do it.

(To be fair, I would have done it for ONE MILLION DOLLARS. Oh, totally. But publications don’t have that kind of money.)

Don’t look back or forward

Note to publications and bloggers everywhere — please don’t write 2011 retrospectives or 2012 predictions.

Retrospectives are just re-runs. Clips shows. Totally boring. I was there. I remember. It all happened just this year.

And predictions are useless and boring. Here’s one: “Each day will be pretty much like the day preceding it, with a few notable exceptions. We won’t know what those will be until they happen.”

Siren song

Dr. Drang: The siren song of Vim: “I know better than to try Vim again.”

I like this article. It’s important to try things and be curious and give tools a fair shake — and then it’s even more important to be self-aware enough to know which tools fit you and which don’t.

And no tool-user should insist that other people use the same tools. Tools are just tools. What’s way more interesting is what you make with them.

Justin on iPad magazines

Justin Williams writes about the experience of dowloading issues for GQ, Esquire, and Sports Illustrated on an iPad.

Remember, kids. The first rule of mobile development is that no one gives a fuck about your brand. A splash screen with a giant logo is something that makes editors and marketing directors feel good, but to a user it just feels like a meaningless delay.

While working with our TapLynx partners, I learned that splash screens were at the top of most everyone’s wish-list. Animated splash screens especially. They’d point to other apps that had them and ask why couldn’t they have them too.

I’d explain how and why those apps were doing a disservice to their users. But it didn’t matter. Splash screens are chocolate plus crack plus sex plus a big juicy steak to marketers.

Guy on a Siri API

Guy English: “Apple doesn’t appear to have an internal SPI for Siri yet, and it’s my bet that they’re a year or so away from it. Even internally it appears that they’ve not yet drafted an approximation. And I don’t blame them.”

LLVM 3.0 Release Notes

Check out the LLVM 3.0 Release Notes.

So much good stuff.

I can’t help but wonder — if you combine these great tools with the GNUStep Objective-C Runtime 1.6 release, will we start seeing Objective-C support on platforms other than Apple’s?

If you’re a phone or tablet platform vendor, it might not be a bad idea, since it might make it easier to attract developers.

But, then again, I have no idea what happened behind the scenes when Sony announced just such an intention and then withdrew it.

Justin on Windows Phone

Justin “Bieber” Williams: “The Metro UI paradigms used in the apps feel more futuristic and sexy than the cartoonish, leather-bound look of Apple’s latest applications.”

But there aren’t many apps. So Justin asks:

How does Microsoft combat this perception that Windows Phone’s app catalog isn’t up to par with the offerings in Apple’s App Store?

I hope they figure this out. I’m rooting for Windows Phone. It’s such an unexpected and welcome surprise to see Microsoft doing something different, actually innovating and caring about user experience. From what I’ve seen they’re doing a good job. (Though I must admit I haven’t tried using a Windows phone for any period of time.)

I live in Seattle, so I know people at Microsoft. They’re our neighbors across the lake. But, for all that, we Cocoa developers in town hardly ever think about them or notice their presence. It would be great if we had a reason to think of Microsoft again.

(Seattle is thick with Cocoa developers, by the way. Omni! Black Pixel! Flying Meat! Tons of small indies you haven’t heard of yet! Etc. etc. etc. Great big community.)

Info gatekeepers

GigaOM: The rise of the new information gatekeepers:

What if Apple decided, or was forced by law, to prevent users from going to certain sites in Safari? Or from asking Siri to search for certain terms, such as The Pirate Bay? That may seem far-fetched, but it isn’t. Google could be forced to do the same kinds of things in Chrome.

You should already be reading GigaOM.

Decentralized search engine

I downloaded YaCy for Macintosh. It’s massively geeky right now — but I love the idea.

Decentralization, in tech as in politics, is how we prevent one entity from having too much power. Power corrupts.

You could say that YaCy in its current form would never displace any of the current popular search engines. You’d be right — but that’s not an argument against trying to create a decentralized search engine. That’s just saying that early efforts are for techies. Which is as it should be.