I have always been a fan of Google's innovations and I'm very excited to see this news: Google Enters Wireless World.
There's not much information out yet about what's going to be packed in the device. Knowing Google, I would bet that it will be simple, with a simplistic look and feel and packed with lot of functionalities. The news is that it's going to be packed with open source software and I'm sure it will have a great email service (client or hosted?) , great and simple document editors, collaborating tools and anything web 2.0ish.
What Google plans to do with mobile gaming will be interesting to see. According to Gartner reports, Mobile Gaming revenue has grown 50% (!) this year and is at 5 billion USD now. It's growing at an amazing pace and mind you, this revenue is largely out of revenue on product purchases and not around services built with that. Google also has noble policies on adult content and there's huge revenue on that segment which Google may not cover too much.
I hope that Google will displace the bully - Blackberry. I hope the proprietary technology is stashed away with and all office employees can safely, securely use their official email accounts via the Google phone and increase their productivity. And use SAME phone for other tools that they like depending on their personal tastes. (Read Opensource, Free sourced, Free Willed...)
Okay, if everything is open sourced and free, where does the revenue come from? We all know that Google can be innovative from that too :-)
Welcome gPhone .
Tuesday, November 06, 2007
Saturday, September 01, 2007
Micro businesses and Web 2.0 as I see in India
I was looking at the trends of Micro Businesses across the globe (a Micro Business, simple definition is a business consisting of max five employees and largely caters to local market. It is smaller than Home Business), I came across a staggering list of small businesses - perhaps micro startups already leveraging web 2.0 in India. My observation could be slightly skewed as I relied largely on internet and there could be businesses in other geographic regions not linked to internet...but nevertheless....
Let me give you some samples:
1. Event manager on Mobile - nothing new, eh? Well sample this. While the general apps like this cater for events such as Meetups, Class Reunions, Dating etc, this is for largely indian events such as weddings, traditional 1st year birthdays, house warming ceremonies etc. I think innovations like these are very important and caters to the local market and has a great opportunity to grow. Wasn't Bharatmatrimony a big success? These event managers are installable on mobiles (I'm not sure which OS) and cater to address book, invitations, tracking of invitees, specific preferences, profiling, notifications.............etc.
2. The second one I noticed was this one. This was Video resumes on your mobile. Well, lazy (busy?) interviewers like me would love it. All that my recruiter has to do is upload these screened video resumes on to a calendar that I use and that is automatically downloaded onto my mobile using either push or pull mechanism. So, I just play the resume on my way to the interviewing venue and i not only get the usual details in a CV but can notice communication, presentation, body language etc upfront even before I meet the candidate. There is nothing specific here for India but I have a reason for this. 80-90% of hiring happens in India now for atleast IT companies!
3. Public examinations tutorials and quizzes on mobile for GATE, IIT JEE, CAT, UGC... and it's not just the lessons and tests, but these include wikis, chat rooms, social networking...I guess how much you can extend these functionalities is really up to one's imagination. Here was a real need by aspiring students, a real opportunity and a real market since almost every student aspiring for higher studies has a mobile handset.
In some ways, everybody wants to be listened to (translates the need to write a blog), commented upon and get a chance to improve or fine tune. I think Web 2.0 helps this need so much saying 'let's collaborate, your feedback is as important as mine' and this is a way shift from 'I know, I speak, you listen' of the older 'article writing ways'. Asians (Indians and South Koreans) blog the most or contribute to other blogs as per various studies.
I dread the day when pokemon web2.0 sites are installable on mobile and I really dread that day when kids will shift from the humble telephone to the mobile social networking site to discuss which pokemon has a fire attack and which one has a laser attack! Until then...all web 2.0 is welcome :-)
Let me give you some samples:
1. Event manager on Mobile - nothing new, eh? Well sample this. While the general apps like this cater for events such as Meetups, Class Reunions, Dating etc, this is for largely indian events such as weddings, traditional 1st year birthdays, house warming ceremonies etc. I think innovations like these are very important and caters to the local market and has a great opportunity to grow. Wasn't Bharatmatrimony a big success? These event managers are installable on mobiles (I'm not sure which OS) and cater to address book, invitations, tracking of invitees, specific preferences, profiling, notifications.............etc.
2. The second one I noticed was this one. This was Video resumes on your mobile. Well, lazy (busy?) interviewers like me would love it. All that my recruiter has to do is upload these screened video resumes on to a calendar that I use and that is automatically downloaded onto my mobile using either push or pull mechanism. So, I just play the resume on my way to the interviewing venue and i not only get the usual details in a CV but can notice communication, presentation, body language etc upfront even before I meet the candidate. There is nothing specific here for India but I have a reason for this. 80-90% of hiring happens in India now for atleast IT companies!
3. Public examinations tutorials and quizzes on mobile for GATE, IIT JEE, CAT, UGC... and it's not just the lessons and tests, but these include wikis, chat rooms, social networking...I guess how much you can extend these functionalities is really up to one's imagination. Here was a real need by aspiring students, a real opportunity and a real market since almost every student aspiring for higher studies has a mobile handset.
In some ways, everybody wants to be listened to (translates the need to write a blog), commented upon and get a chance to improve or fine tune. I think Web 2.0 helps this need so much saying 'let's collaborate, your feedback is as important as mine' and this is a way shift from 'I know, I speak, you listen' of the older 'article writing ways'. Asians (Indians and South Koreans) blog the most or contribute to other blogs as per various studies.
I dread the day when pokemon web2.0 sites are installable on mobile and I really dread that day when kids will shift from the humble telephone to the mobile social networking site to discuss which pokemon has a fire attack and which one has a laser attack! Until then...all web 2.0 is welcome :-)
Friday, April 13, 2007
Wondering about Enterprise Mashups
About a year ago I did not know what enterprise mashups mean and I asked a friend. He said that it is mixing and matching different applications. I wasn't impressed because we have all crossed EAI era, now in SOA era and what is this new mashup - sounded like mashing up flour and margarine for the doughnut mix.
Recently I noticed a site that listed enterprise mashup tools. Big companies like IBM and SAP have already released early adopter releases and everyone is catching up on the web 2.0 fever. I read through the tall claims by all these companies and to me it fitted my ideal app pretty well. I wanted a mashup (for now I suppose it can be a portal web based and hosted or a downloaded rich client since I saw both kinds of tools) that includes news from my favourite news sites, information about my projects from within the company intranet (note this), occasional cricket scores, some funny dilbert, yahoo mail and google mail, my company mail and calendar :-)
To me, all the above listed in one mashup will increase my productivity because I don't have to separately logon and browse different web sites.
One of the tools was actually designed to work across multiple data objects across Siebel, SAP etc coupled with web 2.0 sources such as RSS feeds, services based on REST, maps, charts...etc. I'm not an expert and hence I struggled to create my app across different enterprise systems and that too within a firewall. I could not readily see how the mashup tools handles authentication and authorization leave alone later pain points such as compatibility, performance etc.
Another tool I tried just did screen scraping or web scraping. I could mention any web site or any news feed and as long as the content was available, the tool just siphoned that info into a mashup and created a mashup portal for me (WSRP? I don't know).
But the Ajax or Aflax? options that these tools offer are so beautiful. Now these mashups mashing up needs minimal coding but overtime we will have drag and drop and wizard driven mashup tools that will resolve various security, interoperability, scalability issues in the background.
Guess what? For people like who are not serious developers and who just want to do new things using tools which are 'simple yet exciting' these kind of new concepts and new technologies are absolutely great. Mashup for timepass!
Recently I noticed a site that listed enterprise mashup tools. Big companies like IBM and SAP have already released early adopter releases and everyone is catching up on the web 2.0 fever. I read through the tall claims by all these companies and to me it fitted my ideal app pretty well. I wanted a mashup (for now I suppose it can be a portal web based and hosted or a downloaded rich client since I saw both kinds of tools) that includes news from my favourite news sites, information about my projects from within the company intranet (note this), occasional cricket scores, some funny dilbert, yahoo mail and google mail, my company mail and calendar :-)
To me, all the above listed in one mashup will increase my productivity because I don't have to separately logon and browse different web sites.
One of the tools was actually designed to work across multiple data objects across Siebel, SAP etc coupled with web 2.0 sources such as RSS feeds, services based on REST, maps, charts...etc. I'm not an expert and hence I struggled to create my app across different enterprise systems and that too within a firewall. I could not readily see how the mashup tools handles authentication and authorization leave alone later pain points such as compatibility, performance etc.
Another tool I tried just did screen scraping or web scraping. I could mention any web site or any news feed and as long as the content was available, the tool just siphoned that info into a mashup and created a mashup portal for me (WSRP? I don't know).
But the Ajax or Aflax? options that these tools offer are so beautiful. Now these mashups mashing up needs minimal coding but overtime we will have drag and drop and wizard driven mashup tools that will resolve various security, interoperability, scalability issues in the background.
Guess what? For people like who are not serious developers and who just want to do new things using tools which are 'simple yet exciting' these kind of new concepts and new technologies are absolutely great. Mashup for timepass!
Thursday, January 18, 2007
Bill Payment Arthritis
I have spent couple of hours today trying to pay a telephone bill via the telephone provider's portal and these are the issues I faced:
- The telephone provider's portal has a prominent login button (with Signup) and signing up here/logging in here does not enable me for all services. For example, I can view the Value added services but not bill payment although 'Bill Payment' is UI-linked very close to the login button.
- Click on actual 'Bill Payment' link and I'm taken to a different site with the standard warning 'You are moving out of the trusted site with secure credentials...etc' and I wonder what has happened since I didn't log out.
- Next, I go to the real bill payment portal and from the URL I can see it is a different hosted site and I register/login once again. The password rules are different here (length of this password has to be 8 characters) while my earlier password to the apparently same portal had different rules with length/alpha numeric constraints. Nothing new here, so I proceed.
- Once I successfully login my Bill Pay portal, the bill is promptly put up (good integration with the database!) and then the next interface takes over. It looks like some kind of web service which displays all the banks that are approved with visa/master/diner card options and I proudly click my NetBanking.
- And now is the finale! I get an exception -" apache error - string out of length-10".
I forgive the site thinking perhaps the session didn't handle it well and again I go all the way back to my first page, login two times with different credentials and wait for the page to come up. With bated breath!
- Now, a different exception comes up - "Fatal error: Allowed memory size of 125829120 bytes exhausted".
- Now my son, aged 12, gives me an idea! Do it really fast - keep clicking all options as fast as you can and beat the time-out error. I laugh at that! What can a user do now other than perhaps dance in front of the computer to keep it in good humour.
I'm not sure if the Bill Payment test engineers tested much, but this is what anyone should test which I christen 'common sense tests'.
1. Estimate the number of users who would hit the site on an average and maximum (bill payment date). If there are 50,000 subscribers who appear in the log for a month, it is safe to assume 70% of the subscribers as maximum. I know that most companies don't have the luxury of affording a commercial testing tool that can simulate thousands of users and using an 'evaluation version' of a load tester does NOT give the actual picture at all. The results of the evaluation versions are not reliable and one has to find ways of simulating the no. of users by other means.
2. No. of users, no. of concurrent users, geographic distributions have to be tested. For example, Asia has about 300,000 million users while it progressively decreases for Europe, North America and becomes miniscule for Africa and Middle East. It is the not the % of Internet users that matter but the actual volume.
Account for latency tests from those demographic regions.
3. While ideally you will get marketing data about user behavior, how long a user's 'eye balls' are stuck to your landing page or how many times the same user might visit a typical category of web site, how many of us can afford the Forrester or Gartner report in terms of money or time? Rely on the good old fashion logs instead. There are open source based OLAP tools where you can create simple dimensions that you want to measure and run the logs through them. You will get a fair indication about user behaviour. If your company has a Tools Team, ask them to analyze for you. Base your tests on the data you get for your portal.
4. More often than not, like my Bill Pay application, each app is integrated (SOA) with another provider either providing a service or consuming or both and there will be standard SLAs for capacity and volume on both sides besides protocols, security measures etc. Check to have tests to see if the SLAs are defined as required by your business. It should have the right capacity planning.
5. Look for those pages or links or queries that are most accessed by users. A 'Search' or 'My Orders' is more critical than 'Customer Case Studies' from a performance point of view. Test and see if all parts of the portal have uniform performance problems or not. In technical papers, an often quoted line is this 'Run a mix of processing patterns and check the limits of infrastructure' :-). How's that for jargonizing!
6. Check for functional reliability - this means whether it is one user or thousand of them they can 'feel' the same for accuracy, security and ease of use and not broken sessions. I saw a hilarious note from a blog ( http://blogs.cio.com/node/228) that specified some rules that could affect functional reliability.
All traffic is encrypted. All fields that display sensitive information are invisible, unless you move the mouse pointer over it, and click (hold the click to see the info). All screen savers are locked on blank screen (no user customizable fancy-dancy screen savers) - and set at 1 Minute, maximum - no user ability to change / reset this. All user systems have USB disabled, no CD-ROM drive and no floppy drive. All passwords must be a minimum of 8 characters long, have at least 2 numerics, 2 symbols, 2 capital letters and 2 lower case letters. Zero repeat characters and no character can be used in the same position more than once in 16 months. Passwords must be reset every 28 days - no exceptions.
7. Last but not the least, examine whatever channels you have access to for 'unintended consequences'.
How a user did use it not to hack the system but to actually use it in some ways. When I got the string length exception in my portal, I wanted to somehow pay my bill. I googled for the error that said it happens with long named attachments. So, I set about looking for clues in the http path to avoid that. I couldn't hack it but what I'm saying is that a tester should observe a hacker/unintended user's behaviour and convert that to a test too.
Now, I sympathize/empathize with my Bill Payment portal. It was very kind to me! Tomorrow I will physically go and pay the bill!
- The telephone provider's portal has a prominent login button (with Signup) and signing up here/logging in here does not enable me for all services. For example, I can view the Value added services but not bill payment although 'Bill Payment' is UI-linked very close to the login button.
- Click on actual 'Bill Payment' link and I'm taken to a different site with the standard warning 'You are moving out of the trusted site with secure credentials...etc' and I wonder what has happened since I didn't log out.
- Next, I go to the real bill payment portal and from the URL I can see it is a different hosted site and I register/login once again. The password rules are different here (length of this password has to be 8 characters) while my earlier password to the apparently same portal had different rules with length/alpha numeric constraints. Nothing new here, so I proceed.
- Once I successfully login my Bill Pay portal, the bill is promptly put up (good integration with the database!) and then the next interface takes over. It looks like some kind of web service which displays all the banks that are approved with visa/master/diner card options and I proudly click my NetBanking.
- And now is the finale! I get an exception -" apache error - string out of length-10".
I forgive the site thinking perhaps the session didn't handle it well and again I go all the way back to my first page, login two times with different credentials and wait for the page to come up. With bated breath!
- Now, a different exception comes up - "Fatal error: Allowed memory size of 125829120 bytes exhausted".
- Now my son, aged 12, gives me an idea! Do it really fast - keep clicking all options as fast as you can and beat the time-out error. I laugh at that! What can a user do now other than perhaps dance in front of the computer to keep it in good humour.
I'm not sure if the Bill Payment test engineers tested much, but this is what anyone should test which I christen 'common sense tests'.
1. Estimate the number of users who would hit the site on an average and maximum (bill payment date). If there are 50,000 subscribers who appear in the log for a month, it is safe to assume 70% of the subscribers as maximum. I know that most companies don't have the luxury of affording a commercial testing tool that can simulate thousands of users and using an 'evaluation version' of a load tester does NOT give the actual picture at all. The results of the evaluation versions are not reliable and one has to find ways of simulating the no. of users by other means.
2. No. of users, no. of concurrent users, geographic distributions have to be tested. For example, Asia has about 300,000 million users while it progressively decreases for Europe, North America and becomes miniscule for Africa and Middle East. It is the not the % of Internet users that matter but the actual volume.
Account for latency tests from those demographic regions.
3. While ideally you will get marketing data about user behavior, how long a user's 'eye balls' are stuck to your landing page or how many times the same user might visit a typical category of web site, how many of us can afford the Forrester or Gartner report in terms of money or time? Rely on the good old fashion logs instead. There are open source based OLAP tools where you can create simple dimensions that you want to measure and run the logs through them. You will get a fair indication about user behaviour. If your company has a Tools Team, ask them to analyze for you. Base your tests on the data you get for your portal.
4. More often than not, like my Bill Pay application, each app is integrated (SOA) with another provider either providing a service or consuming or both and there will be standard SLAs for capacity and volume on both sides besides protocols, security measures etc. Check to have tests to see if the SLAs are defined as required by your business. It should have the right capacity planning.
5. Look for those pages or links or queries that are most accessed by users. A 'Search' or 'My Orders' is more critical than 'Customer Case Studies' from a performance point of view. Test and see if all parts of the portal have uniform performance problems or not. In technical papers, an often quoted line is this 'Run a mix of processing patterns and check the limits of infrastructure' :-). How's that for jargonizing!
6. Check for functional reliability - this means whether it is one user or thousand of them they can 'feel' the same for accuracy, security and ease of use and not broken sessions. I saw a hilarious note from a blog ( http://blogs.cio.com/node/228) that specified some rules that could affect functional reliability.
All traffic is encrypted. All fields that display sensitive information are invisible, unless you move the mouse pointer over it, and click (hold the click to see the info). All screen savers are locked on blank screen (no user customizable fancy-dancy screen savers) - and set at 1 Minute, maximum - no user ability to change / reset this. All user systems have USB disabled, no CD-ROM drive and no floppy drive. All passwords must be a minimum of 8 characters long, have at least 2 numerics, 2 symbols, 2 capital letters and 2 lower case letters. Zero repeat characters and no character can be used in the same position more than once in 16 months. Passwords must be reset every 28 days - no exceptions.
7. Last but not the least, examine whatever channels you have access to for 'unintended consequences'.
How a user did use it not to hack the system but to actually use it in some ways. When I got the string length exception in my portal, I wanted to somehow pay my bill. I googled for the error that said it happens with long named attachments. So, I set about looking for clues in the http path to avoid that. I couldn't hack it but what I'm saying is that a tester should observe a hacker/unintended user's behaviour and convert that to a test too.
Now, I sympathize/empathize with my Bill Payment portal. It was very kind to me! Tomorrow I will physically go and pay the bill!
Subscribe to:
Posts (Atom)