Categories
quotes

Why I don’t eat meat…

I don’t eat meat because I wouldn’t want to ingest an animal weak or dumb enough to enter a life of slavery under another species, that the only meat I would eat would be that of an animal which a human cannot actually kill.

Tim Rogers in Japan: It’s Not Funny Anymore [kotaku.com]

Oh that’s a good one… I’ll have to use that. Better than the classic I’m not a vegetarian because I love animals, I’m a vegetarian because I hate plants.

Categories
ranting

Entrance Keywords

According to Google Analytics, the top content on my site is /categories/goodies/ [confusion.cc]. Which I guess is better than the second place /2004/09/26/four-floors-of-whores/ [confusion.cc].

Then again, the top entrance keyword — in fact the only entrance keyword with more than 1 hit in the past month — is “1280*768 fucking”.

What?

I have no idea why this is. But if you do a Google image search for “1280*768 fucking” [images.google.com], you don’t get much porn…

Google Image search results for '1280*768 fucking'

The third and forth images are porn related but nothing else on the first page is naughty. Three of my images make the first page though; “Simian Eyes” [confusion.cc], “Yellow Jacket” [confusion.cc] and “Have you seen my keys?” [confusion.cc].

Now, I understand the “1280*768” keyword, as all the images in “goodies” are available in that size. But… While I have a potty mouth, the word “fucking” does not appear on the goodies page at all. So how is it that Google has associated “fucking” with my photos of monkeys, yellow jackets and my lost keys?

Categories
ranting

Not looking for another subscription

Came across this quote on Gizmodo [gizmodo.com] yesterday:

My expectation is that there’s not going to be a lot of people out there looking for another subscription.

We’ll it’s how Gizmodo quoted him… not quite what he said, see the Gizmodo article for the full text of the quote.

This apparently is how the CEO of AT&T covers for the fact that there is no subscription for 3G data on the iPad. I agree with Gizmodo — it’s more likely that Apple dictated it this way. But on the other hand I think it would be easy to get people to sign up to pay more each month just not a totally new contract.

See, one of the best things that my operator here in Singapore (that’d be Starhub [starhub.com]) has going is it’s Dual-HLR option. Without going into GSM network design this is what the consumer gets out of the dual-HLR option: a second SIM card, with the same phone number that works at the same time as your current SIM. This works because you nominate one of the SIM cards to be your “primary” and that is the one that rings (in Starhub’s case it rings first then, if you don’t answer the call rolls over to the second SIM where you can answer or let it roll over to voicemail.) All the features of your existing contract are active on both SIMs, both can consume data from the same data plan, etc. This is actually the reason Starhub launched the service. There are a lot of business types who have a Blackberry and an iPhone, but don’t want two contracts. This costs the consumer SG$10 a month as opposed to the cheapest two year contract here for about SG$35 a month. All it costs Starhub is a some configuration and whatever additional data the user would not have consumed otherwise, but I doubt that’s a big cost.

Of course you can do this with two SIMs that have different numbers — “family plans” have shared resources for years. But this makes more sense for a single person with multiple devices.

I think that for US$10 or US$15 a month to have this dual-SIM option users would agree to add this to their existing contract. Not just for the people with an iPad but for anyone with two data devices. US$10 or US$15 is low enough compared to a whole new contact that it’s almost an impulse buy, and as it is tied to the existing contract there would be, I think, less psychological aversion.

Categories
technical

Mobile Ad Serving

I’ve seen a lot of AdMob [admob.com] ads in iPhone applications over the past two years. But recently I downloaded two free — i.e. ad supported — applications that appear to use a Google ad server (of course Google purchased AdMob but I don’t think it’s just a re-branding I think it’s a different service.)

I noticed this for two reasons. First; for the past few years I have been working in the mobile advertising space, so this stuff stands out. Second; the ads were odd.

Why odd? Well, as I mentioned these were ads in iPhone applications. Keep that in mind and take a look at the ads:

Google mobile ads banner for SingTel Mobile SME services
Google mobile ads banner for Android
Google mobile ads banner for Nokia 5530 Apps Store
Google mobile ads banner for Nokia E63 Apps Store

The issue, I think, with these ads is they are all for competitors. I can excuse the SingTel ad, I’m a Starhub customer but this is an add for enterprise services and the ad was served while I was on a WiFi network, so there is not much chance that Google could have determined my operator.

However, the ad for Android and the two ads for the Ovi store — which sells applications that work on Nokia handsets are not useful to me as a consumer and most likely a waste of the advertisers money. The odds that I am going to patronize either of these services from my iPhone is next to zero.

And there is little excuse for this. When I was working on requirements for a mobile advertising system the product team was adamant that it include basic relevance filtering. Now relevance filtering is complex and the simple business rule “the advertisement should be relevant and useful to the consumer” actually breaks down to a lot of technical requirements. The technical requirements of significance here are:

Requirement 1
The system shall attempt to retrieve the User-Agent header from the HTTP request. The header should be used to reduce the pool of relevant banners by removing banners that:
  1. have a User-Agent whitelist that does not include the User-Agent retrieved from the HTTP request
  2. have a User-Agent blacklist that does include the User-Agent retrieved from the HTTP request
Requirement 2
They system shall allow buyers to construct a whitelist or a blacklist of User-Agent strings which for specific campaigns or banners in a campaign.
Requirement 3
User-Agent lists (white- or black-) should be constructed of strings entered by buyers by selecting full User-Agents or pre-coded regular expression from a list or entering an arbitrary regular expression.

(Obviously there are a lot more details and other requirements that need to be clarified before you can actually implement this.) Here’s a use case that would prevent the issue of the Ovi banners being shown to me on my iPhone.

Use Case:
Setting up a campaign level whitelist, to filter out non-Nokia handsets.
Pre-Condition:
The buyer has created a campaign
The buyer selects Relevance Filtering from the interface
Post-Condition:
A new filter is added to the campaign level whitelist for the selected campaign
Scenario:
  1. The Buyer selects Create/Edit Whitelist from the Relevance Filtering menu.
  2. The System loads the Relevance Whitelist interface
  3. The Buyer selects the Filter Campaign checkbox
  4. The Buyer clicks on the Add Filter button
  5. The Buyer selects the Manual Filter filtering method
  6. The Buyer enters *nokia* in the Manual Filter textbox and clicks the Case Insensitive checkbox
  7. The Buyer clicks on the Test Filter button
  8. The System displays a list of all matching User-Agent Strings, highlighting the match(s)
  9. The Buyer clicks on Confirm Filter button
  10. The System adds the filter to the campaign level whitelist in the Database for the selected campaign

So now the Buyer (in this case Nokia or an agent acting on Nokia’s behalf to setup the ad campaign) has created a campaign level whitelist (i.e. all banners in the campaign will be filtered by this whitelist) which includes a filter of *nokia* that is case insensitive. This means that, based on the requirements enumerated above, that no ad request that includes a User-Agent string that does not includes the word nokia in it will be served any banner from this campaign. The effect? Ovi store ads will only be shown to users who are using Nokia handsets (or who’s requesting user agent does not include a User-Agent string or is using an incorrect User-Agent string that includes the word nokia.

Lets look at two use cases for requesting an ad. One where the requesting handset is Nokia N95 and one where it is an iPhone 3GS.

Use Case:
A Apple iPhone 3GS makes an Ad Request from an application running the Ad Server SDK.
Pre-Condition:
The application is using the provided Ad Server SDK
The application makes an ad request
Post-Condition:
A banner is served
Scenario:
  1. The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.11 (KHTML, like Gecko) Version/3.1.1 Mobile/7A238j Safari/525.20)
  2. The Ad Request Handler Thread retrieves the Ad Request Payload and the HTTP User-Agent Header constructs an Ad Request, sets it’s state to New and pushes the Ad Request onto the Inbound Ad Request Queue
  3. The Ad Request Handler Thread registers with the Ad Dispatcher to wait for it’s Ad.
  4. The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
  5. The Ad Request Processing Thread checks the Ad Request state
  6. The Ad Request Processing Thread finds the Ad Request state is New
  7. The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
  8. The Ad Request Processing Thread sets the Ad Request state to Unfulfilled
  9. The Ad Request Processing Thread pops the first add off the Active Ad Queue
  10. The Ad Request Processing Thread checks the selected ad for White- and Black- lists
  11. The Ad Request Processing Thread finds an active Campaign Level User-Agent Whitelist
  12. The Ad Request Processing Thread attempts to match each string in the Campaign Level User-Agent Whitelist against the Device User-Agent String in the Ad Request
  13. The Ad Request Processing Thread finds no match for the string *nokia* (case insensitive) in the Device User-Agent String;Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.11 (KHTML, like Gecko) Version/3.1.1 Mobile/7A238j Safari/525.20
  14. The Ad Request Processing Thread rejects the ad for this request placing it on the Recycle Ad Queue
  15. The Ad Request Processing Thread pushes the Ad Request back on the Inbound Ad Request Queue
  16. The Ad Request Processing Thread monitors the Ad Request Queue
  17. The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
  18. The Ad Request Processing Thread checks the Ad Request state
  19. The Ad Request Processing Thread finds the Ad Request state is Unfulfilled
  20. The Ad Request Processing Thread pops the first add off the Active Ad Queue
  21. The Ad Request Processing Thread checks the selected ad for White- and Black- lists
  22. The Ad Request Processing Thread finds no active White- or Black- lists for the ad
  23. The Ad Request Processing Thread selects the Ad for this Ad Request attaches the Ad to the Ad Request and updates the Ad Request state to Pending
  24. The Ad Request Processing Thread pushes the Ad Request onto the Outbound Ad Request Queue
  25. The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
  26. The Ad Request Processing Thread Monitors the Ad Request Queue
  27. The Ad Dispatcher pops the Ad Request off the Outbound Ad Request Queue
  28. The Ad Dispatcher reads the Ad Handler Thread Id from the Ad Request and passes the Ad Request to the corresponding Ad Handler Thread
  29. The Ad Dispatcher Monitors the Outbound Ad Request Queue
  30. The Ad Handler Thread parses the Ad Request and retrieves the ad
  31. The Ad Handler Thread constructs an HTTP Response with the Ad Response Payload including the Ad
  32. The Ad Handle Thread sends the HTTP Response to the requesting application

A few explanations/notes:

The looping nature of the Ad Request Processing Thread makes it hard to write an efficient and clear Use Case but I’m not getting paid to do this (any more) so I’m not going to spend the time to do the work to make it clearer.

This use case leaves out details of filters other than the Whilelist filter, such as Logged In/Logged Out Ad Queue selection, Ad Unit size, etc. for simplicity.

There would be multiple Ad Request Processors/Threads running, so when the first thread that retrieved the Ad Request and found the request was in the New state it pushed all the ads in it’s internal Recycle Ad Queue back onto the Active Ad Queue because those banners still need to be served and may be suitable for this Ad Request. The second time the Ad Request Processing Thread finds the Ad Request in the Unfulfilled state it does not empty it’s Recycle Ad Queue to avoid endlessly looping over the same unsuitable ad. (Writing this I think I need to think more about this—there could be a condition where a thread only ever sees Ad Requests in the Unfulfilled state and would therefore never empty its Recycle Ad Queue…)

I’ve included a lot of stuff that would actually go to other use cases and just be referenced as Include X Use Case, again I hope this makes it clearer (at least to the techies) what is happening.

Anyway… Here is what would happen when an Nokia N95 made a request:

Use Case:
A Nokia N95 makes an Ad Request from an application running the Ad Server SDK.
Pre-Condition:
The application is using the provided Ad Server SDK
The application makes an ad request
Post-Condition:
A banner is served
Scenario:
  1. The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/10.0.018; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413)
  2. The Ad Request Handler Thread retrieves the Ad Request Payload and the HTTP User-Agent Header constructs an Ad Request, sets it’s state to New and pushes the Ad Request onto the Inbound Ad Request Queue
  3. The Ad Request Handler Thread registers with the Ad Dispatcher to wait for it’s Ad.
  4. The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
  5. The Ad Request Processing Thread checks the Ad Request state
  6. The Ad Request Processing Thread finds the Ad Request state is New
  7. The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
  8. The Ad Request Processing Thread sets the Ad Request state to Unfulfilled
  9. The Ad Request Processing Thread pops the first add off the Active Ad Queue
  10. The Ad Request Processing Thread checks the selected ad for White- and Black- lists
  11. The Ad Request Processing Thread finds an active Campaign Level User-Agent Whitelist
  12. The Ad Request Processing Thread attempts to match each string in the Campaign Level User-Agent Whitelist against the Device User-Agent String in the Ad Request
  13. The Ad Request Processing Thread finds a match for the string *nokia* (case insensitive) in the Device User-Agent String;Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/10.0.018; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413
  14. The Ad Request Processing Thread selects the Ad for this Ad Request attaches the Ad to the Ad Request and updates the Ad Request state to Pending
  15. The Ad Request Processing Thread pushes the Ad Request onto the Outbound Ad Request Queue
  16. The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
  17. The Ad Request Processing Thread Monitors the Inbound Ad Request Queue
  18. The Ad Dispatcher pops the Ad Request off the Outbound Ad Request Queue
  19. The Ad Dispatcher reads the Ad Handler Thread Id from the Ad Request and passes the Ad Request to the corresponding Ad Handler Thread
  20. The Ad Dispatcher Monitors the Outbound Ad Request Queue
  21. The Ad Handler Thread parses the Ad Request and retrieves the ad
  22. The Ad Handler Thread constructs an HTTP Response with the Ad Response Payload including the Ad
  23. The Ad Handle Thread sends the HTTP Response to the requesting application

This type of White- and Black- list filtering would prevent me from seeing ads for the Ovi store on my iPhone (assuming the people provisioning the ads or campaigns used, and used correctly, the filtering options mentioned above — but that’s a business problem not a technical one.)

The ad serving space is complicated but have been surprised to see a number of examples like this on my phone over the past few days. In fact most of the ads I receive in the applications that use the Google system over the AdMob system seem to fall into this category. I have notices a lack of relevant ads in general for Singapore in the Google Web system. On some sites I see very relevant ads; global companies doing brand building or selling online. But on a lot of sites, and I mean a lot I see the same ads for the same service—a Singapore specific company so at least the location filtering is working. Or I see public service ads (invariably for Kiva [kiva.org].) So either there are not enough relevant ads for Singapore or these local guys are spending a lot of money to spam everyone.

The people at Google are a lot smarter than me, so I wonder if there is something I am missing in all this? Were my product people wrong? Are the users who are creating the campaigns not using some feature of the Google system that would filter these ads from me? Am I completely nuts? Do I have too much time on my hands?

Categories
ranting

Avant Garde vs. Usable Interface Design

Catching up on my RSS reader I ran across this post from Gizmodo titled Windows Phone 7 Interface: Microsoft Has Out-Appled Apple.

Oh. Provocative. Go read it. I’ll wait.

Back? Ok then. Now, opinions are like ass holes; everybody’s got one (well, not not everyone [wikipedia.org].) but I want to poke fun at the author, Jesus Diaz, opening opinion:

Windows Phone 7 feels like an iPhone from the future. The UI has the simplicity and elegance of Apple’s industrial design, while the iPhone’s UI still feels like a colorized Palm Pilot.

Jesus Diaz, in Windows Phone 7 Interface: Microsoft Has Out-Appled Apple [gizmodo.com] on Gizmodo.

Yea the Windows Phone 7 UI looks cool, and it remains to be seen if users will actually like it when it gets into the hands of all those people with ass holes opinions. But I’m going to bet on the oh-so-boring Palm Pilot-esque grid layout the iPhone uses.

Why? Same reason I don’t think everyone will be sitting on a Feel Seating System Deluxe [animicausa.com] sofa. The tired old sofa that your parents have might be musty and hold too many memories of the 70’s or 80’s to be healthy but there is a reason it looks like almost every other sofa in every other normal house in the world for the past, oh, I don’t know, 1000 years or so.

The basic design of the sofa —as used in the real world outside of the Milan furniture fashion show world— hasn’t changed much over the years. That’s a testament to one thing: it works. And while every furniture designer out there wants to do something new and original, so they make crazy sofas [freshome.com] (or crazy chairs, tables, etc.) their designs don’t change our platonic ideal of the sofa because they just aren’t practical in the end. Um, that’s why we call it fashion, different doesn’t mean good.

So, unless the Windows Phone 7 UI breaks down to a grid layout (or list layout) in the end, with some funky cool icons, I’m betting it eventually will by hook or software update.

Then again, this is just my ass hole opinion, feel free to ignore it. Oh yea, and I’ve been itching to use that sofa metaphor in a blog post for about a year.