Tuesday, February 26, 2008

Cost of mobility

Today I joined an interesting webinar about enterprise mobility and device management. There were some topics that all mobility forerunners should be aware and think for a second:

When CIO's were asked 
  • the most important issue for them was how to improve the business benefits gained from IT (right answer!)
  • Number 20 in their list was how to better utilize mobile solutions
  • Number 23 was to improve wireless infrastructure for their company
  • There were just 24 items in the list 
I read this so that (surprise, surprise!) mobility is not important an sich, but it must benefit the business. Maybe mobile solutions don't boost company performance as much as they should?

But what's the price of mobility? Another session handled this and case study was about Finnish Government deal for approx. 400 users covering email and calendar (Intellisync Mobility Suite), device management (Fromdistance MDM) and anti-virus system (F-Secure). Cost structure per annum is:
  • services and 24/7 support 450€ 
  • terminal costs 250€
  • data costs 240€ 
In total this is 940€ / user and this was just "platform cost" from a developer's point of view. No custom applications or dedicated solutions. If somebody were to deploy a custom solution for them, that cost will be added to platform cost. Knowing how difficult it is to create an enterprise mobile application, the additional cost would be significant. Is that cost justified? Have you an idea how much your application really will cost to user, including support? 


Friday, February 22, 2008

JoikuSpot and MSISDN authentication

Some weeks ago a JoikuSpot application was launched - this is an application that allows users to turn their 3G/WIFI enabled terminals to WIFI hotspots. Application is currently in beta phase but it is still very usable; when you launch the application in your smartphone, you can connect to new Joiku hotspot with any WIFI enabled laptop, internet tablet, iPod Touch ... whatever you use. Nice and easy. 

For those who have been working with mobile applications know that user authentication is a big problem. Usernames and passwords are difficult to type with small keyboard, client-side certificates are not trivial to implement and so on. One solution that is used (if operator allows) is that user is authenticated with terminal's MSISDN. This is nice solution, because user is effectively authenticated with PIN code: if user can turn on the terminal, that identity is used when he opens a connection to back-end server. 

What you get if you combine JoikuSpot and MSISDN authentication? Security hole.

Today I tried this combination and result was just as expected. I installed Joiku to my terminal and let it publish a WIFI hotspot. Then I connected to that hotspot with a laptop and tried to access an MSISDN authenticated service. As you might guess, service authenticated me (or the Joiku terminal user) and let me in without any passwords asked.

Luckily this is quite difficult security hole to exploit. In order to do that following criteria must be met:
  • Joiku is running in a terminal that belongs to user who has access to MSISDN authenticated services
  • Attacker is close enough to connect to Joiku hotspot
  • Attacker knows which resource to access through the hotspot
Good news is also that Joiku people have announced that final version of Joiku will include WEP/WPA/WPA2 encryption. Hopefully all over 15.000 users who have downloaded Joiku will update when final version is available!

Update 25.2.2008
Just caught my mind that this same security hole applies also if somebody has Mobile VPN installed and connection opened from terminal to enterprise back-end systems. Then Joiku will publish this connection to everybody who is close enough, right? At the moment I don't have a VPN enabled device to verify this, but I can't see any reason why this wouldn't work. Scary.


Thursday, February 21, 2008

Who designs Nokia phones?

Noticed a press release from a design house named "Provoke Design" telling that they have  opened new office to Tallinn, Estonia. Their references seem to include quite a portfolio of Nokia Bluetooth headsets and E-Series terminals. Now I know who to blame/thank about product design. Check their website for more product info.


Wednesday, February 20, 2008

Special terminals for enterprises?

Having lately read quite a many news about ODMs (original design manufacturers) and their business I began to think about limits of mobile business ecosystem. In mobile business ODMs aim to sell their services to operators who can ask them to create a special device just for them. 

Operators' are fighting hard against falling margins and trying to justify their existence as something else than just dumb bit pipes. If they are able to find a market segment for phones manufactured just for them, fine. However, in the era of mobile internet, subscribers demand more that just terminals - are operators ready (and able) to take the step to innovate and create competitive solutions? Lately I have got a feeling that best services exist in spite of operators, not because of them.

What is missing from mobile ecosystem are mass customized terminals; when you are buying 1000 PC's for a company you can get workstations customized just according to your needs. When you are buying 1000 mobile terminals, you must satisfy to what is available. I have no idea about ODM's price structure but an idea about special device for a large company really would make sense, especially for some specific use-cases. Often companies have special needs for terminals and now they can't get the best but instead they must go for the least bad. What if ODM's could serve them? Why not? Would telecoms authority certification be required for every customized terminal type? Why mobile terminals must be special compared other networked devices?


Mobile Mobilitics

With a help from Mowser I am happy to announce that Mobilitics blog is now available also as a mobilized version. Just type m.mobilitics.net to your phone's browser and you can read this site also while you are on the move.


Thursday, February 14, 2008

Happy traveller sleeps well

Today when I was commuting back home I fell asleep and almost missed my bus stop. When I rushed out from bus I began to think why there isn't such a "commuter's smartphone solution" that - among other things - could notify people when they are approaching their destination.

How the notifier could be implemented is not obvious: using GPS data precision is either very good or zero and power consumption might be a problem (after a busy day). Using cell id information works as long as there is network coverage but public cell registers don't exist - service provider would need to gather data from various sources. Google has a nice MyLocation service that uses cell ids; that information would be optimal but unfortunately it is unaccessible to developers. Without a cell id register users would need to first record cell id's in their neighborhood to get alerts - not something that typical users would like to do.

Do you know any solutions that already have a feature that is capable of waking up a sleepy traveller? 


Tuesday, February 12, 2008

Some questions to guide mobile development

Quite often when thinking about new mobile solutions I feel people are somehow getting lost and forget both their target audience and target devices. Continuing solution development in a situation like that will lead to end result that is neither successful nor something to be proud of. Below is a short list of questions that I feel might be worth asking from your project group and customer.

Is solution needed regularly or does it contain information that changes frequently?

This question relates to a very primary requirement - the solution must be available in the phone when user needs it. If user cannot understand that he might sometime need the mobile solution, he will not install nor bookmark it. If solution is not available when user's need arises, it is very difficult - or even impossible - to find it while on the move. Finding the solution with mobile terminal is still something that rarely happens, typically you find the solution with desktop and then deploy it to terminal. Give user an actual and understandable use case about the solution so that he will deploy the solution to his terminal. If user has a feeling that solution is not really needed in a mobile device - using the solution with desktop will keep user happy - he will not install it.

Do technical requirements match with target group?

It is very easy (and sometimes also fun) to design a solution that runs only on the latest and greatest high-end terminals. What is even more fun is to design the application to run only on those devices that "will be available later this year for selected market". If your target group is technology savvy early adopters then this approach can be OK but if you try to reach the wide consumer market then some rethinking is needed. Try to find out what are the minimal technical requirements and build solution to depend only on those; save the 3D effects for future releases, please.

This question can also direct your development efforts to another direction: for example when creating a browsing solution you should ask whether old WML terminals should be supported or not. If your target group doesn't use such old terminals you can put more development power to xhtml-pages.

Can you make it any simpler, please?

If there is a current solution available you can start with a simple test: take the most important feature from the application and think how would you implement that if you remove 90% of all the available features. If that seems possible then creating a mobile version from that solution looks promising. This acid test is justified by following reasons:
  • mobile devices have very limited input mechanisms and screen resolutions
  • mobile applications are used in situations where user cannot concentrate fully on the usage of the solution 
  • mobile application use cases are very task oriented; something needs to be done quickly and easily. Users will not navigate through different menus or screens

However, remember that creating a mobile solution is not only about cutting features away from the "original" solution. A winning mobile solution also adds value to its desktop variant - what that might be in your case?

How to publish the solution?

This is a major paradox in publishing mobile solutions: you will use the solution with mobile device, but you will get to know the solution's existence by desktop browsing. You must get your solution deployed to terminal before there is actual need for that. When user is on the move and wants to use the solution, it is already too late to find it. Any mobile terminal has a very limited screen estate and different solutions are competing on the same resources. Make your use case very clear and tell potential customers an emotional story why your application matters. What is the target audience and what is the right channel to reach those?

Is it visual?

On the surface this is simple item: make your solution visual so that you all the time give user visual clues where he is and where he is going, what is mandatory and what is optional, what will cost money and what is free, and so on. In practice you should consider consulting professionals to help you in this.

Well, how much does this cost?

In the desktop world users feel safe when using different applications because network connections will not cost you any extra. In mobile world situation is worse. If you target consumer users, you should remember that they are very afraid of usage costs and vast majority of them will not have a flat-rate data plan. So, make it very clear how much the application will cost to user. If you do use data connections, send SMS's, make voice calls or whatever make that very clear to users so that they feel they are in control when using your solution.


Sunday, February 10, 2008

Custom search available for mobile developers

I created a new custom search engine for mobile developers, you can access it from the right column of the blog-site or directly from address search.mobilitics.net. The idea of the search engine is simple: I have hand-picked only the sites that I feel are most valuable for mobile developers and when you use this custom search, only those sites are included. This should provide a better search results for busy developers.

If you want to give your contribution to this search engine, send me an email to harri (at) mobilitics (dot) net or register yourself as a contributor at the custom search homepage.


Wednesday, February 6, 2008

Will iPod maintain its status?

Today I noticed two pieces of information that at the first glance didn't have much in common, but second thought was little different. Take a look at this story how Apple is decreasing production volumes for iPod and then read this Nokia's press release about them sponsoring Grammy awards.

So what?

For quite a while Nokia's message to consumers has been that they shouldn't buy separate devices for email, mapping, music, imaging and so on. Just buy a smartphone that can do all this and much more, they say. Meanwhile iPod's have been dominating the music device market with ultimate user experience and tight integration with iTunes store. Last year Nokia launched "Comes with Music" initiative, opened Music Store in UK, launched several music optimized terminals and accessories and got good news coverage and market attention with all this. Now more marketing effort is put to Grammy-sponsoring and who knows what they will launch at MWC in just a couple of weeks. Is iPod market suddenly saturated or has Nokia's marketing message reached its audience and made consumers to rethink smartphones as music devices? Or maybe rumors from Apple production volumes are just...rumors.


Monday, February 4, 2008

Got the answer, where's the question?

Some time ago I posted an entry to my Forum Nokia blog about how to change the S60 browser identity to mimic iPhone. At that time I thought this trick only as a simple experiment that doesn't have other value. Then one comment opened my eyes that there might be something more than that:
So if you can modify this user agent on the E90 or make a patch wich can modify user agent how we like, all the features which come with our subscription will be unlock...

Orange's politic is certainly illegal, but I don't have the courage and money to fight with them :(.
In short: access to some services is blocked from users that have not bought their terminals from operator's shop. 

If you want to modify the plugin to best suit your needs, download iPhonesque source from here. However, remember that
  • you MUST HAVE a valid Publisher ID for Symbian Signed
  • seriously, do you have Publisher ID?
  • with that Publisher ID go get yourself a developer certificate with required capabilities (see the mmp-file)
  • if you want to use this on S60 3.0 devices you will need DRM capability which is almost impossible to get
  • read the code, understand it and make your modifications

Before anyone asks why I'm not delivering this application signed and installable the reason is quite simple: signing would cost me money.


A very niche home appliance

My typical workday begins with a cup of coffee and morning paper at 6 o'clock when my phone wakes me up. Fortunately this doesn't happen often, but today morning paper was late and I was awake at Monday morning, too sleepy to do anything productive. At that moment I remembered my old idea about a very niche home appliance. This is also very much a mobile gateway type of a solution, an idea I wrote about some weeks ago.

Rough idea has two parts:
  • small sensor device that I could attach to my mailbox. When mailbox door opens, a sensor will notice this event and save the data
  • alarm clock application in my smartphone

Think about following scenario: I have set my phone to wake me up at 6 o'clock, but only if morning paper has been delivered. When alarm would ring, my phone asks (over Bluetooth, WLAN, ZigBee; you name it) from mailbox sensor when mailbox was opened last time. If mailbox hasn't been opened this morning (i.e. morning paper is late) my phone lets me sleep one hour extra. Application for terminal is nothing special, any mobile developer can do it. Any volunteers who are able to create a mailbox sensor appliance?


Friday, February 1, 2008

Operators and rising use of mobile email

Companies are getting ready for this years Mobile World Congress (3GSM) and I seem to be on quite a many mailing list. Today I received a good newsletter from Synchronica that has some interesting topics / predictions for year 2008:
  • people are demanding more backup and restore solutions for mobile terminals to protect their personal data
  • mobile email is going to masses
In the newsletter Synchronica quotes figures from Visiongain Mobile Email Market Report that predicts that number of people using mobile email will rise from 8 million users (2007) to 184 million users (2011). Visiongain writes how operators are struggling to offer mobile users email services and how mobile email holds a huge potential for them. This Visiongain report (go Google for parts of it) and Synchronica's newsletter make me ask a stupid question:

Why different stakeholders are overcomplicating consumer mobile email issue? 

Currently all but the entry level terminals have email clients with IMAP/SMTP support - what there is for operators to do? I guess biggest problem is that people don't know about possibility to read email with their mobile terminals - problem is not technical at all. So dear operators: just tell people that they can access their email accounts today with their mobile devices, sell reasonably priced data plans to consumers and  -- watch this -- those 176 million people don't have to wait until 2011 for their mobile email!