updated nokia stuff…

a good article about the future of nokia.

Granted it’s not written from within but it does address some of the concerns I raised in my previous post about nokia.

Nokia’s got to grow the app side fast – get the developers back onto symbian. And certainly looking backwards is not a way to do it.

There are some excellent assets in Nokia (especially in the LBS space) – not just in terms of products (Navteq, Dopplr, MetaCarta, Gate5 etc) but also people…it’s just a question of filling in the blanks that are missing and coordinating the consumer efforts.

As I said a couple of times – when you’re a developer (or work closely in the industry) it’s tempting to discriminate amongst platforms using preconceived notions of users and their preference.

But it seems that as soon as you move outside of early adopters those distinctions disappear.

Users appreciate touch screen apps with nice icon and pinch zoom (on images and maps), facebook, email and making calls and a decent camera for sharing images…

but beyond that – who knows?

Apple’s biggest trick with the iphone was getting those basics to be SPOT-on…

when it first came out – it was very cutting edge in an industry that allowed itself to become stagnant (RIM is doing too little too late…as for windows mobile – we’ll see with series 7 – but I don’t know if anyone believes it anymore)…but it’s not so cutting edge anymore.

it might be time for the pendulum to swing back to Finland 😉

motorola uses skyhook…on android??

UPDATE (I should clarify that we do actually use skyhook – see below)

Frederic wrote about this on ReadWriteWeb over a week ago but it’s actually a very interesting story which seems to have gone under-reported.

As Frederic points out in his article the impact on developers from a technical standpoint is nothing – the O/S functional calls will remain identical – however it’s a fairly significant decision for Motorola – especially when one factors in cost.

Google’s location services come for free with Android (which is in and of itself free) for any hardware manufacturers.

I spoke with Ted Morgan, CEO of Skyhook Wireless – (at the RWW mobile summit last friday – see next blog post for more of this) and without disclosing any details he assured me Skyhook’s deal with Motorola is by no means free.

BTW the official press release is here

So the scenario we have here is a company (Motorola) deciding to choose a fee paying service over a free service…which is very interesting – especially when the free service is Google?

If you think about this it’s not comparing apples with apples – because the playing field is not level. If you were a new mobile phone manufacturer and you wanted to choose between licensing company A and B to provide your GPS chipset…that’s one thing.

In this case we have Google location finding BUILT IN to Android and FREE and Motorola is choosinng to go with a product that’s NOT FREE and NOT BUILT IN

The question is – is skyhook’s performance (or skyhook’s database of cellid/wifi) that much better than google’s that it would justify a per-handset cost?

I haven’t seen any compelling evidence to support this claim – though I have heard that a few Android based developers licensed skyhook on an individual basis (disclosure – we do not use skyhook on android – we use google’s built in location finding feature – but we do use skyhook on Nokia and Windows Mobile)

What do people think?

Becoming a location connoisseur…

Written by Remy Kozak

I read a very insightful post on MediaWeek yesterday entitled Nowhere to Hide by Barry Lowenthal of Media Kitchen.  In it he describes his progression from “Check In” enthusiast to a more discerning “Check In” connoisseur.  Aside from the fact that the writing style itself was very engaging, this is not the first article of its type to surface regarding a writer’s increased awareness of the implications of  “Check In” and privacy. However, it is a very telling chronology of “learning” about what we are putting into our own social network domain (and sometimes the public domain) when we “Check In”.

Few of the pieces of personal information about us are as telling or invasive as location. Nick points this out is a prior blog post.

My favorite quote from Barry’s post is: “The brilliance of Foursquare, and many other location-based apps, is that they satisfy many of my narcissistic primeval urges. After all, doesn’t everyone I know really care where I am and what I’m thinking right now?”

I would venture to say that this narcissistic urge is highly developed in 99% of Foursquare and Gowalla users and also highly developed in a good portion of people that blog about their lives, heavy Twitter posters, and Facebook personalities with over 1000 friends.  For business bloggers, Twitterers and Facebookers, I would add that private enterprise is, by its nature, narcissistic – so their personalities cannot be judged by their actions 😀

But as Barry correctly deduces by the end of his experience (at least partially) location is a very different animal. Not one you want to share with anyone but the closest people to you, and then only for specific purposes.  In Barry’s case he only uses “Check In” now to help build on a desired reputation within a chosen social network.

So what might Barry use to make meeting with friends for dinner a little easier – without oversharing?

I would suggest echoecho – for the discerning location-sharer 😉

of course privacy is important…

well – unless you’re Mark Zuckerberg that is.

so the story flew around the web last week that Mark Zuckerberg doesn’t believe in privacy. Funny stuff.

Though it was all based on a whimsical tweet by a Facebook employee – it’s really no surprise. The entire model of facebook is based on maximising growth to increase the impressions and increase the value of the network to advertisers. Restrictive privacy settings of course tend to have a….well…detrimental effect on that kind of model.

Time will tell if Facebook will be able to jump the location hurdle as easily as many others they have cleared – what with federal probes in the US and articles like this one highlighting the EU position on privacy vis-a-vis location…Zuckerberg’s lackadaisical attitude will not go over well.

Location sharing (as I’ve said on this blog before) – mixes the real with the virtual in an unprecedented way. (if you don’t accept that this is revolutionary consider this paranoid overstatement…no matter what you tweet, blog post, say on skype, vimeo, youtube etc – no random person can kill you because of your opinions – because if for no other reason…no one knows where you are)

The second you add your location as a component to a discussion you effectively make your online presence REAL which means that behaviours become more REAL because the implications can be direct upon your being.

Privacy is something we take very seriously at echoecho – and it’s not just about having privacy settings.
What good are privacy settings if nobody uses them?

It’s about having privacy settings with appropriate defaults and designing your software and your business model to encourage responsible behaviour…not to trick users into revealing more information than they want.

location based ads don’t work all that well yet…

or do they ??

I thought it was kind of ironic to read stuff like this – 50% of all location based ads result in a clickthrough….REALLY ???

It’s funny because with no additional metadata about the customer a location based ad isn’t all that useful.

In fact – I will hazard a bet that without additional demographic information on a customer an advertisement blindly targeted on location alone is MORE LIKELY to be completely incorrect.

If you think about it – traditionally when a brand makes assumptions about marketing to a group it considers trends and demographics (because it lacks precise information about its target individual).
However if you seize upon a latitude/longitude as somehow representative of an individual – fairly quickly you realise the scenario is less accurate than the old school marketers assumptions.

On a given intersection in a bourgeois suburb like Beverly Hills who’s to say the person handling a mobile phone (with location detection software) is

(a) a cab driver
(b) a hollywood celebutard
(c) a blue-collar house cleaner to the rich and famous
(d) a tourist

and of course that’s just one example.
My point being that location data without any additional context (or demographic metadata) is actually a false prophet for brands.
Of course in a solution like echoecho you can make certain assumptions that are very useful for advertisers (e.g. that friends that are close to each might want a place to meet) – and we will certainly be exploring those shortly.

For now let me just add that there seems to be a big temptation to rush into location based advertising for many brands – including ones that have no real-world presence at all.
Ironically – it’s the other brick-and-mortar stores that took a massive beating at the hands of Amazon, ebay and many others – that stand to benefit the most from location based advertising…

Clarfication – AppWorld now gives Developers 70% of Revenue!

Written by Remy Kozak

I am not sure how many of you paid attention to the blanket e-mail that was sent to ALL vendors of software on Blackberry AppWorld by the Blackberry AppWorld Management Team on April 17, 2010 – just prior to WES. It took me a couple of days to get around to reading it but once I did I had to reread it twice… and send a message to RIM expressing my concern.  Needless to say, my questions appear to have fallen on deaf ears SO I might as well do the next best thing and make sure people are aware of the new Improvements to AppWorld. Well, the folks at RIM got back to me – thank in large part to the involvement of Caroline Lewko at WIP Connector.

Up until April 17th, RIM took 20% of the non-download revenue AND Digital River (their only Merchant of Record or MoR) also took 20% of the total download revenue.

This left only 60% 80% for the App Developer – worse better than the iPhone AppStore and comparable to Android Market. While Blackberry still dominates the Smartphone handset segment with >40% market share so they appear to have accepted that they are playing catch up in the application space.

It seems the Blackberry AppWorld Management Team was thinking the same thing. So aAs of April 17th, 2010, under the guise of “opening up” their market to operators and other Merchants of Record, RIM decided increase their share… and that of the MoRs.

Now RIM takes 30% and Digital River (still the only MoR with a formal agreement) takes 30%.

This leaves 470% for the App Developer.

As I said, it took a After my first couple of reads of the new contracts for this to sink in I actually thought the developer share was reducing to 40% or 51%. And no,But the MoR does not take 30% of the remaining 70% after RIM takes their share.  The MoR takes 30% of the full retail price. RIM take NONE of the retail price but 30% of all subsequent revenues – except advertising.

Overall, not as nice as 80% to the developer but RIM has added access to Operator sales channels and also included the payment processing costs in their share. So there is upside, it just remains to be seen how much.

Thanks to Tyler for spelling this out for me and clarifying some major misconception.

This is all without mentioning RIM still need to try to do something about how much longer it takes to develop and test anything for RIM devices – due in part to the need to support and test legacy handsets but mostly because the various devices and operating systems are so inconsistent – especially across carriers.

We will launch version 1.5 of echoecho for Blackberry later this week. Since echoecho is a free app, we have nothing to worry about (aside from all the extra work to deliver a robust Blackberry solution).

oh Nokia ;(

inspired by an email I wrote to @gadgetman

I used to love Nokia.

Back in the pre symbian days when Motorola and Sony Ericsson (and whoever else was around) would go off and add all kinds of crap to their interfaces…Nokia was the only thing I ever wanted.

Super fast and intuitive – I remember my 8890 was just the bomb. (I think my dad still uses it).

Friends would show me their Ericsson headsets and the interface were just a total mindfuck – four clicks where there should be one etc etc…unusable menu structure, inconsistent button usage.
I even remember a keyguard lock on a motorola phone that required TWO HANDS – what cretin designed that.

But somehow somewhere people pulled in different directions and all these weird handsets started coming out. Sure the phone was an accessory item and so on – I get that – but when I picked up an N95 (first time it came out) and it was sluggish, slow to open screens etc…I couldn’t help but feel a pang of nostalgia for the focussed simplicity and speed of the earlier designs.

I know I know…I’m getting to my point…the ramble is just to set the scene.

When the iphone first came out and I started thinking about new business models (regarding what apple did with the Appstore etc) and Ovi came along of course…and then all you can eat data contracts became more and more pervasive…the wheels started turning.

I know all the GIS were preaching this a long time ago – but suddenly it was true…natch.

Locations would be an extremely interesting space – because it was a serious pain point for most users. They could just about figure out how to use their own location – but there was no easy way of communicating it to other people.

So I start playing with an N78, Blackberry 8820 and 9700, two WinMo phones, an iphone 3G and a G1…I was mostly comparing and contrasting UI experiences because I wanted to feel the user…each platform was a little different – but two things very quickly became obvious (and interesting)

1. Developers can massively enhance your platform – if you make it developer friendly (the iphone is living proof to this) – while we could debate the closed nature of the appstore and its arcane approval process – I’m mostly referring to the SPEED of development here…and the things available to developers in an API

2. There was an odd debranding exercise going on here….for example Google Maps Mobile on both Android phones and Iphones is just called….Maps

This is a very interesting position for a brand to take – on the one hand they might think “oh cool we’re ubiquitous – we don’t even need our brand” but the fact is that also means consumers are not experiencing the brand as much – they’re just experience the functionality.

In other words – when Microsoft brands its experience (on Windows Mobile series 7) Maps – huge amounts of people won’t know or care about the difference

Same thing for Nokia – it no longer matters as much whether it’s Ovi Maps/Nokia Maps or Google Maps – it’s just….Maps

Which brings me to the crux of it…for LBS on Nokia to really take off development-wise there are three key things developers need (I don’t care if they are echoecho, zhiing, wikitude, foursquare or whoever)

(A) Tiling maps as an API callable module
This is a big thing. It’s a waste for every developer to write their own tiling map client (not to mention that they would have to use data from OpenStreetMaps which is great in some places but so great in others)
having this module is (in my opinion) an absolute necessity for the platform because it allows the user experience to be smooth.
if user experience is not smooth – then goodbye users.

(B) Location finding as an API callable module
This one is possibly more important than (A).

Let’s recap for a minute here:

three basic techs for phone location – GPS, Wifi, Cellid (in order of precision)
(there are of course other issues e.g. TTL for cold start GPS, battery usage for continuous polling etc etc (many of which I discuss in some length in other posts on this blog) but in principle that’s it.

1. GPS
This is done on the phone and is accessible to 3rd party developers via API calls (on most platforms – unless of course you happen to be RIM and you create retarded agreements with carriers that allow the carriers to lock out hardware GPS access to developers…but that’s a different story ;))

2. Wifi/Cellid
Both of these require large databases of wifi/cellid data.
These databases are problematic because as a developer you need them to be global, cheap and uptodate.
There are two basic methods of getting this data – you either do it the fast and expensive way (e.g. like google/skyhook and you drive around in vans collecting tons of location data) or the slow way (e.g. like Navizon – where you focus on crowdsourcing to get all the data)

Here’s the current state of play (of smartphone location finding) as I understand it

Iphone – uses skyhook for cellid/wifi (GPS is built into phone) – location accessible via single API call to developers
(user permissions handled in app when app asks to locate your phone…if you answer YES twice – it never asks again for that app)
I’ve heard rumors that Skyhook signed a bad deal with Apple because they wanted the exposure – allowing Apple to cache their data on an ongoing basis. If true this means Skyhook is going to falter if not die entirely in the next 6-9 months.

Android – uses Google databases for cellid/wifi (GPS is built into phone) – location accessible via single API call to developers.
(user permissions handled via two setting entries in control panel -one for GPS, the other for wifi/cellid)

Symbian – has GPS accessible via single API call. In order to use wifi/cellid developers must make separate deal with Skyhook/Navizon or equivalent.

RIM/BlackBerry – GPS sometimes locked out from developers. wifi impossible to access even if present on device due to O/S implementation. Cellid is the only backup option for indoor locating. Skyhook does NOT support cellid only lookups. Navizon does.

Windows Mobile – so far it’s sort of like Symbian – because it has GPS accessible – but for wifi/cellid developers need skyhook/navizon etc…(however with windows mobile series 7 – navizon has an exclusive deal for location provision for all phone winmo devices)

None of these methods require any carrier involvement whatsoever…

Of course one can do cellid triangulation (like is done for E911 stuff – but to do this you do need carrier involvement – for a developer this is a horrible mess…because every carrier does it slightly differently…and they’re also usually a bitch to deal with)

For as long as Symbian remains without an easily addressable location API for finding handsets (that’s easy for users to control – i.e. they pretty much don’t have to control it apart from to turn off GPS if they want) the implementations are very inefficient. Every developer has to include a skyhook library or something like that – and then imagine how much duplication there is on a newer phone.

(C) Push notifications
Last but not least.

You might wonder why we need this. Simple answer – with flat rata data connections to cellphones and App Markets and background running apps – you might think…..nah – we don’t need no stinkin’ push notifications.

WRONG.

It’s nice for an app to make a background check of a connection. Very useful.

It’s NOT NICE for 30 apps to be making a background check of a connection or polling a server all at different times and with different frequencies.

Basically it spells early battery DEATH.

So – this was (as usual) a little longer than intended – but there you go…

I really want Nokia to go back to being as cool in the smartphone space as it is in the feature phone space.

But the old adage of “if you build it they will come” really stands here. Make the phones fast and intuitive…and give us (as developers) these features….your users will thank you in droves.

RIM annouces O/S 6 ;) – yeah ok…so ??

Yes I know I have whined about RIM before but I read a few articles about the new O/S 6.0 announcement e.g. this one and I can’t help but wonder if somebody at RIM just didn’t get the memo.

Which memo?

That’d be the one where the major way to drive users to your platform is to give them stuff they want – namely lots of apps….and the way to get apps…is to make it easy for developers like ourselves to make these apps.

Where’s the redesign of the access to the wi-fi card so that location detection indoors can be accomplished faster and more accurately?

Where’s the announcement about a Location API so developers don’t have to cobble together solutions from various suppliers?

Where are the features many developers might want including mapping elements we can include in our code – so we don’t all have to develop this stuff from scratch.

Yeah…thought so…

Unfortunately RIM seems to think that the most valuable software developer for BlackBerry software is still….RIM.

Here’s hoping these specs might change by the actual release date…