3PMobile – The third “P” is for Personalization
So let’s get straight to it… what if the website that you load in your browser really recognized you? Would it be possible for something to change in real-time so that the “Experience” became more personal?
Let’s take a look at the standard Android Browser (image on the left)… and compare it to the 3PMobile enhanced browser (image on the right). Notice the difference?
Google is “branded” inside the browser (top right menu).
Think about this for a minute. Google is now literally 1 click away. And the second I click on that menu not only will I be taken to www.google.com but they will also know in real-time, my device’s capabilities, my exact geo-location and who I am. All before they even have to send a page back to me.
Everyone will be thinking – hold on a minute I don’t want Google knowing all that data. Now you can see why the second blog post was on Privacy. And that’s why you also see a Privacy Option menu so you can control who gets access to “YOUR” data. If you trust Google, then simply add them to your whitelist, check what you want to share, and let them provide you with a better Experience.
And therein lies the power of personalization. When a Web site knows “you” there’s so many more things that a Web service can do to enhance the customers experience. And the bandwidth and performance savings increase dramatically simply because the Web service knows before it has to make a response. Think of it as walking into your favorite restaurant with the meal you wanted already on the table.
So how do we add Personalization to the browser menu in real time?
With just a few lines of HTML – here’s the exact code for the menu in the picture above…
<META NAME=”5o9data” CONTENT=”
<menu name=toplevel target=primary>
<menuitem text=’Google Search’ action=http://www.google.com/>
And there you have it… the 3 P’s – Performance, Privacy, & Personalization. And combined they all deliver a better Quality of Experience (QoE) for your customers and employees.
3P Mobile – The second “P” is for Privacy
Following from my previous post on Mobile Performance today we’re going to look at the second “P” which stands for Privacy.
When we first started the company we talked to a lot of potential users about the issue of Privacy and the Internet. The feedback was unanimous, they wanted three things:
So we listened, and then built it into the browser.
Screen shot 1: Browser 2 is running, a Web page is loaded. Everything looks and feels like a normal browser would.
Screen shot 2: With Browser 2 running, simply click on the Menu key for a pop menu to appear. You’ll notice a new menu in the top left hand corner: Privacy Options. Our focus was to seamlessly integrate these new capabilities as “if they’d always been there”. This way customers would have nothing new to learn.
Screen shot 3: Clicking on Privacy Options launches a secure database (think of it almost as a wallet) where all of your information is stored. (For OEM customers this database is completely customizable to support a variety of additional fields). Click on “Owner Preferences” to continue
Screen shot 4: The Owner Preferences tab reveals an additional 7 menus. They’ve been designed to be self-explanatory so customers have nothing new to learn. Each menu links to a page showing fields of data with check boxes next to them. As you’ll see in the next screen shot simply checking that box enables the data to be shared. The reverse (unchecking) prevents access to that data.
Screen shot 5: Clicking on Owner Information allows you to select from the following options – simply adding a check mark to the box allows that information to be shared with a Web service. You can see in the image below that I’m NOT sharing my cell phone number (the check box is greyed out).
Screen shot 6: With all of your owner preferences set, there is one final setting to make. This is your approved whitelist. By adding a Web address to the whitelist every time you visit that Web site your personal data will automatically be included in the request. (We’ve encrypted the data so others will not be able to view it.) To access the whitelist you select “Advanced Options” from the Owner Preferences panel. There you simply add the approved Web site by typing in the address.
And that’s it. A way to control your privacy as you surf the Web. You choose what to send, and to whom you send it to.
My next post will be on the final P – Personalization. What happens when you trust a Web service and share your data in real time.
3P Mobile – The first “P” is for Performance
Once it’s installed all you have to do is launch the app and navigate to a Web page. (This will give you a summary performance result – for the full set of results you will need to have signed up for the free Web service). Let’s step through some simple screen shots from the Android Emulator to see how it works.
Screen shot 1: Browser 2 is running, a Web page is loaded, and you can see from the red arrow at the top that the device is using GPS.
Screen shot 2: With Browser 2 running, simply click on the Menu key for a pop menu to appear. You’ll notice the “Performance” menu – click on that
Screen shot 3: Click on the Performance menu brings up the following display window. You can select either from the Options or Summary Tab. You know there’s a performance report available by checking in the top right hand corner for a “number”. 1 or higher indicates a report is available
Screen shot 4: Clicking on the “Summary” tab brings up the following screen. Here you can see a quick summary of the Mobile Performance report. To see the full report you will need to have an account at www.3pmobile.com (for more information click here)
Screen shot 5: Assuming you’ve signed up for the full account you will use the Performance Options tab to send the report to 3P Mobile.
You will then be able to see the full performance report including a real time map of where the test was ran. Below you can see the Emulator was set to Rosemead Avenue in Cape Town South Africa
And that’s all there is to it.
Now there’s an app for that – Mobile Performance measured in the palm of your hand.
Measuring Mobile Web Performance – Simulated Vs. Real Time? (That is the Question)
I’m going to start this blog with a Quote from Shakespeare…
To be, or not to be, that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles
And by opposing end them.
Taking a “little” liberty with this famous soliloquy I’m going to look at measuring Mobile Web performance from a 50,000’ overview and address the thorny question of simulated vs. real time measurement.
The story has to begin with “measure what”? As in, what do you want to measure? Let’s take a quick peak at the OSI model
In a previous blog post “Measuring Mobile Web Performance 101” I talked about “Over the Wire” (the transport layer) vs. the “Application Presentation” layer (the browser). So the question has to be – do you want to measure the network performance or the user-experience?
Up until Smartphones came along I would happily agree (rather “than suffer the slings and arrows) with the simulation experts, that there’s virtually no difference between the packets arriving on the desktop and the browser processing them and displaying the content. If there is a difference, it’s not enough to materially impact the quality of the experience or most company’s bottom lines. Running simulated network tests is good enough for the desktop.
Well that’s all changed now. (Time to suffer the slings and arrows).
When it comes to the Mobile Web there is a difference. And in some cases a pretty big one. Our focus was to look at the user experience and apply our measurement tools squarely from the mobile user’s perspective – inside the browser (The Application/Presentation layer).
In my opinion, as we move to Mobile, not measuring the real user experience is a costly mistake. Mobile Web experience measurement is pushing us to transition from our current Quality of Service(QoS) thinking (simulated networks) to consider the total Quality of Experience (QoE) (real time networks).
What exactly is QoE? Well in short, it’s where the “user consumes IT services”. It’s also where IT and Marketing objectives intersect. That means not only does your network performance matter, but you also have to consider everything else that happens from the time the content leaves your Web Server to when it is displayed on the smartphone screen. The transition from QoS to QoE requires the alignment of IT and Marketing strategies to deliver a compelling mobile Web experience to mobile customers and workers. QoE measurement for the mobile Web is about extending the QoS concept out of the data center and into the real world.
So I ask you – how can a simulation of this possibly work?
Well in short it can’t (more arrows). And here’s why – until you’re measuring inside the browser on a real device, on a real carrier network, anywhere you can connect to the network, then you’ll never know the real experience. There’s simply not enough statistical data out there (as there is for the desktop) to build adequate simulations spanning the range of mobile user experiences.
In the old days, (pre-Mobile), approximation was “good enough”. Not anymore. There are more variables in play, you can’t simulate a real carrier network, you can’t simulate every location or connection and you can’t simulate every device. It will always fall short.
What really counts and what we should all be measuring is what the user – the Consumer – gets to experience/consume the results of what IT and Marketing put together.
And finally what of the browser? Does this factor into Simulated or Real? Fortunately another line from Hamlet comes to the rescue – “ay, there’s the rub”
And the “rub” is a big one. We’ve had years to perfect the browser on the desktop. Routines have been re-written and optimized for new processors, more memory is allocated to load pages faster. This is NOT the case on mobile. It’s still in the opening act.
Compare my desktop activity monitor (525MB allocated to Safari)
To my iPhone… total active memory is 38MB! (and Mobile Safari looks like it’s using about 4.5MB)
To my HTC Android phone (1.72MB – sorry no picture).
The delta between the desktop and Mobile device is huge. The processors are different, the memory is different – in short everything is different.
So desktop simulation now has to give way to a “more precise” measurement. One that includes the Carrier Network, the actual device location, the device’s Operating System version (yes we’ve found that it makes a huge difference).
In my opinion it would be pure folly to insist that simulation of Mobile performance will come anywhere close to really showing us what the Quality of the User Experience (QoE) really is.
If you have a different notion – be sure to send me an email and please include your data. When it comes to your mobile Web customers, the only thing that matters is the experience. If we can’t accurately measure it, we can’t improve it. .
Why Measuring the Real Mobile Web User Experience is so Valuable to your bottom line
Quality of Experience (QoE) is the ultimate barometer of whether or not an IT service is “successful” from a customer/consumer perspective. New application environments such as mobile require new types of metrics to assess not just response time and availability, but effective navigation and interaction with the application and application-supported processes at hand. (source: EMA Research’s Advisory Note: An Adopter’s Guide to User Experience Management – How to Pick the Right QoE Solution for You)
The PC Industry is clearly in transition. We’re now entering the “Post-Desktop” era where Mobile devices will now dominate. Technologies that were designed to measure Web site performance are going to become increasingly irrelevant in this mobile era. Tools that are considered adequate for the desktop user experience are not “precise” enough and lack context when it comes to accurately assessing response time and availability of mobile services.
If the desktop era was defined by Quality of Service then the Mobile era will be defined by the Quality of Experience. A simple slide illustrates the stark differences:
We’ve identified 6 critical “real time” elements to consider when measuring the Quality of the consumers Experience (QoE):
- The Carrier Network
- The user’s current location
- The OS and Browser
- The Device’s capabilities
- The need for a custom timing framework to further refine the experience
- The ability to personalize the Web page for the consumer and then measure its effectiveness
Here’s a sample test that illustrates the first 4 items above.
The test URL was http://m.cnn.com We then used Blaze.io to perform a performance test using an iPhone based in Ottawa, Canada. Next we followed with Firefox on a iMac configured to send an iPhone User Agent (tells CNN that it’s a mobile browser making the request), and we used the Network Link Conditioner utility (part of X-Code on the Mac) to “simulate” a good 3G network and one with a 5% packet loss on the download. Finally we ran two tests on an actual Android device running on Sprint’s network in Castle Rock, Co, and then connected via Wi-Fi to the Internet.
It’s clear from the table below that, in this instance, “simulating” the network, browser and OS all lead to under reporting the actual user experience. (other examples may lead to overstating performance).
Test URL: http://m.cnn.com
# of Requests
Blaze.io (link) – Ottawa, Canada (Eastern Time Zone)
Firefox Desktop (User Agent = iPhone – 3G Avg. 5% Download Packet loss)
Firefox Desktop (User Agent = iPhone – 3G Good. No packet loss)
Android HTC on Sprint EVDO_A (3P Mobile: Detail mode, Castle Rock, Co)
Android HTC on Sprint Wi-Fi (3P Mobile: Detail mode, Castle Rock, Co)
The Bottom line…
It means that new metrics are required to measure the quality of the Mobile user experience. The first three tests represent the old way of doing things. The lack of precision is clear. Moving to a new set of metrics to assess not just response time and availability, but effective navigation and interaction with the application and application-supported processes at hand is now imperative if an IT service is to be considered “successful” from a customer/consumer perspective.
Here’s who benefits from a B2B & B2C perspective, and more importantly how they benefit.
Usability – Key to the Mobile Web Experience
Jakob Nielson hits it on the head with this Click Z interview, Jakob Nielsen on Usability for Mobile Sites and Apps conducted by Melinda Krueger.
Performance Matters. It is not about short, it is about “ultra short”. Mobile use is secondary to the main activity of the user (shopping, dining, changing a tire, watching TV…). Make it fast and easy or you’ll loose their interest.
Mobile Web has “low commitment”. It’s easy to go to another site. Make what you do on your site count – fast and relevant.
The key is context. Know your user’s device. Know their location. And even better yet, know them! With all of that, you can create a compelling mobile Web experience and keep user coming back with right-sized, relevant content.
Privacy: Do You Know Where your USB Ports Have Been Lately?
In this NetworkWorld slide presentation “USB Device: The Big Hole in Network Security” you’ll see that of those businesses surveyed, only 50% have an “approved” USB device for employees. There are some great products out there to help with securing transportable data, such as the Encryptx/Imation SecureFlash solution. But how does this help on mobile devices?
Remember, mobile is different. You need to have access to some real-time context about the device, the user and their location if you want to effectively extend your data privacy policies to mobile users. So not only can you know where your USB ports have been lately, but also your memory card or any other “attached” device or drive.
A little bit of planning and some real-time mobile context can help you effectively manage the 2nd “P” of mobile Web success – Privacy.
The Complete Solution to making the Web go Faster.
Yesterday I wrote a blog about why web optimization is NOT the complete solution to making the Web go faster.
I promised that in my next post I would talk about the complete solution to making the Web go faster.
So here goes.
Let’s start with a couple of assumptions (I know, always dangerous but bear with me):
- You have the MOST optimized Web site on the planet. It passes every known test out there
- Your goal is to make it so that content gets to the device 30% faster with more relevance
There’s ONLY ONE way to get content there 30% faster, and that’s to send “less content”. And there’s ONLY ONE way to send less content and that’s to have MORE CONTEXT about the connecting device. There I’ve said it. You have to reduce the size of your content, and at the same time make it more relevant to the context of the person that is connecting to your service.
So all that remains is the HOW do I do that? Well you need to improve the functionality of the browser. (Whilst preserving the customers privacy which we’ll get to a little later). So how can you improve the browser (and remain true to existing Web standards)?
Step one is to use a plugin, also known as a browser extension. This is the “approved” approach by all OEM browser manufacturers (except Google’s Android smartphone) to extending the functionality of the browser.
Step two – you need more context so you can drive relevance. How do you do that? We can just use an app for this portion. We can create a secure database (wallet) that stores the customers personal information, their devices capabilities and their current location. Each item is stored as a “field” and can be turned on or off with a simple checkbox. This is so the user remains in control of their privacy.
Ok – we now have two industry standard components – a way to interact with the browser, and a way to interact with the device. You join those two together and you have real time context. Only one last problem to solve – how do I get the data to the server using approved standards?
Fortunately the W3C has already thought of that. They have something called an X header – it’s a “standard” way to send “non-standard” data to the server. Great we can use that. We’ll encrypt the headers (approved by the W3C) and send the data to the server. All we need to do then is decrypt it using a simple script and we have everything we need.
Now we’re in great shape. For the first time we have a way to augment the HTTP protocol and add some very powerful information that can be used to help manage performance (among other things).
So what does all this look like schematically?
- Using the X header approach we use one transmission up and one down – total 2
- Using the current approach we use 8
- That’s a 75% improvement (and we’re only looking for 30%)
- We’ve optimized our Web server/service
- We’ve now used STANDARDS to improve the browser
- What we can now do is optimize the “relevancy” of the content to make it more personal
- Finally we have a complete end to end client server solution that uses all approved standards
What does all of this achieve? You’ve cut down on the number of requests a Web server has to process, you’ve reduced the content size to EXACTLY conform to the devices capabilities AND you’ve personalized the CONTENT so the customer finds it compelling. And if you’ve delivered a personalized advertisement, there’s now a much bigger likelihood that the customer will click on it. Which in turn increases the amount of revenue for your Web service. And of course it’s much, much faster.
Optimizing a Web site WITHOUT optimizing for the browsers (user, device and location) is like driving a Ferrari with VW engine. No matter what you do, it’s never going to get there quickly.
Why Web optimization is NOT the complete solution to making the Web go faster!
Everyday now we hear about someone offering to “speed” up the Web. They tout all manner of “measurement tools”. They say “if you measure it, you can manage it”. And if you can manage it then you can make things go faster.
Let’s take this hypothetical case. You’ve called in all the worlds foremost experts in Web optimization and they’ve spent millions of your dollars measuring your infrastructure and then helping you install the very latest hardware to speed things up. They’ve also optimized every Web page that you transmit to be the very best it can be. They then pronounce that the job is done and that you now have the fastest Web site with the best optimized content on the planet.
Imagine then your shock when you get a call from a customer complaining about how slow your Web site is. How can that be? You’ve spent millions, you’ve hired the best and your Web pages are perfect.
Well you forgot one tiny little item. The Internet is a CLIENT – SERVER environment. You’ve only optimized 50% of the equation. (Think of it as two cans and a piece of string, the game you played back in the day before mobile phones).
Until you optimize the other 50% your destined to never improve the speed of the Web. (Ignore the piece in the middle (the string) no one is going to pay to optimize that.
Next blog post – The complete solution to making the Web go faster.
Measuring Mobile Web Performance: 101
From the end users perspective on a real device, connected to a Carrier network, anywhere in the world.
Well here things get a little more complicated. There are always two different ways to measure User-Agent (the device) performance, whether it’s on the desktop or Over the Air (OTA)/On the device. This translates into two different “categories” of performance testing.
Over the wire:
The first is simply testing to see what happens with any particular application “on the wire”. This includes all the simple “packet capture” style tools that are out there. These kind of test, historically, may or may not help you solve performance problems being seen with any particular User Agent (the device). Just watching some downloads take place doesn’t really tell the “whole story”… especially when it comes to analyzing something as complex as a modern HTTP protocol exchange.
Before you can measure anything on mobile you have to understand the fundamental differences between two categories.
Finally – Any testing MUST include testing the actual Carrier performance on a real device which a user would hold in his or her hands. There’s lots of “back end” fake Mobile sites around – sorry these don’t count as the real user experience. Carrier network performance is NOT the same as a copper connection to the Internet at your desktop. It’s something entirely different.
Finally one more critical item to consider – the devices real time location. Just as the Carrier network effects performance so does the location of the actual device.
Ignoring any of these conditions means that you’re not measuring Mobile performance.