ENTRIES TAGGED "mobile"
Here's a couple of Big Questions that may take generations to answer
I spend a lot of time on this blog focused on the very short term issues regarding mobile. Is Apple better than Android. Will Blackberry survive? What’s the best strategy in Candy Crush? But sometimes you need to pull up to 30,000 feet and look at some of the bigger questions, such as:
What are the real long-term health effects of cell-phones? Wearable mobile technology has only been around for a few decades, and in true widespread use for less than 10. Are there health risks to having an RF transmitter that close to your head for long periods of time? More importantly, are there effects on offspring to carrying a two watt transmitter in close proximity to your reproductive organs for 18 hours a day? This is even more significant for women, where the effect would be cumulative from birth, since eggs are carried for a woman’s entire lifetime. Short term studies have shown mixed results, but lifetime exposure hazards are hard to gauge when the technology itself is so new. We really didn’t understand the cost to society of lead in our gasoline until half-a-century after its introduction. A decade of data on cell phones is unlikely to hold all the answers to the scope of the potential problems.
Brace yourself: Address exhaustion is coming
IPv6 is the global warming of the computer industry, an impending disaster that most folks don’t seem to be taking as seriously as they should be. We’re well into the exhaustion phase of the IPv4 address space, but most ISPs are still dragging their heels on supplying the wider protocol to the end user.
Velocity 2013 Speaker Series: A Sneak Peek With WebPagetest and Appurify
Now that more companies have basic mobile strategies in place, they are turning their attention to the issue of performance.
Mobile developers are thinking about how fast their apps and mobile webpages load and—more importantly—what they can do to make them faster. Consumers have little patience for slow loading apps and their expectations are only going to get more stringent. This expectation likely contributed to Apple making changes so that apps on iOS 7 load 11% faster than on iOS 6.
The challenge is that measuring performance for mobile is not as easy as it is for web. Many of us have used tools like WebPagetest to assess website performance across different browsers/locations and pinpoint areas for improvement but fully functional, equivalent tools don’t exist yet for the mobile space.
This has left mobile developers ill equipped to create the highest-performing mobile apps and websites.
Thanks NSA, you've spoiled mobile crowdsourcing for everyone else!
The continual drip-drip-drop of NSA secrets, courtesy of Monsieur Snowden, has provided many of us with a new piece of daily entertainment. But as much fun as it can be to see No Such Agency’s dirty laundry being aired in public, it has a real and lasting affect on how consumers are going to see interacting with their mobile devices. Specifically, it could provide a major setback to the new universe of applications that use crowdsourced data.
There are lots of examples of highly successful apps that are essentially just aggregations of user-provided data. Yelp comes to mind immediately, but another good example is Waze. In both cases, users are providing the service with some fairly private information, where and when they were at a particular location. Waze is even more sensitive, because it is also recording your speed, which might be a bit higher than the posted limits.
Unity, iOS 7, and the Quest for a Great Mobile Game Experience
Key highlights include:
- Game-specific APIs and standardized gaming accessories in iOS 7 [Discussed at 0:20]
- Android needs to catch up [Discussed at 1:55]
- Are tablets putting handheld consoles from Nintendo and Sony out of business? [Discussed at 3:13]
- Independent developers vs big game studios – fight! [Discussed at 4:53]
- Unity is now free for mobile game development [Discussed at 6:02]
You can view the full interview here:
How to "future-proof" your sites
Users expect to be able to use and bookmark a website by name—always the same name, regardless of the device used to reach and view the site. From a user’s standpoint, a site is a site regardless of which device is being used to reach it. The code that backs up the site should be smart enough to detect the requesting device and intelligently serve the most appropriate markup.
There are several ways to achieve this goal, and at least three realistic scenarios.
Distinct Sites for Mobile and Desktop
Modern websites are built around the typical size of a desktop or laptop monitor. In fact, until the advent of iPhones, web developers rarely considered the need to fit web content into different sizes. Now, however, establishing an effective presence on mobile devices is a necessity. Just because your websites can be accessed by smartphones and tablets doesn’t make them effective. To provide an effective experience, you must optimize your sites for specific classes of devices—typically, smartphones and tablets. For quite some time, it seemed that distinct “m”-sites were a good-enough solution. For example, the website at www.somecompany.com was available in mobile-optimized form using the URL m.somecompany.com. In terms of development, the two sites are completely different; they were projects that simply shared some portions of the back end.
OSCON 2013 Speaker Series
Andy Gup (@agup) is a Developer Evangelist at ESRI and OSCON 2013 Speaker. In this interview we talk about location capabilities in apps as well as location analytics.
NOTE: If you are interested in attending OSCON to check out Andy’s talk or the many other cool sessions, click over to the OSCON website where you can use the discount code OS13PROG to get 20% your registration fee.
Key highlights include:
- Mobile apps must have location capabilities [Discussed at 0:25]
- Consider your goals when incorporating location into an app [Discussed at 1:05]
- Is it difficult to add location functionality? [Discussed at 2:19]
- A real-world example of where it made a big difference [Discussed at 3:32]
- Location analytics are very powerful [Discussed at 5:11]
- Augmented reality and location capabilities [Discussed at 6:38]
You can view the full interview here:
Why "flow" and "context" are more important than screen size
Are we done with the Mobile First meme, yet? Can we be? Please?
Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.
The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.
Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.
Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.
Those two things are: Flow and Context.
Velocity 2013 Speaker Series
Be honest, have you ever wanted to play Steve Souders for a day and pull some revealing stats or trends about some web sites of your choice? Or maybe dig around the HTTP archive? You can do that and more by setting up your own HTTP Archive.
httparchive.org is a fantastic tool to track, monitor, and review how the web is built. You can dig into trends around page size, page load time, content delivery network (CDN) usage, distribution of different mimetypes, and many other stats. With the integration of WebPagetest, it’s a great tool for synthetic testing as well.
You can download an HTTP Archive MySQL dump (warning: it’s quite large) and the source code from the download page and dissect a snapshot of the data yourself. Once you’ve set up the database, you can easily query anything you want.
You need MySQL, PHP, and your own webserver running. As I mentioned above, HTTP Archive relies on WebPagetest—if you choose to run your own private instance of WebPagetest, you won’t have to request an API key. I decided to ask Patrick Meenan for an API key with limited query access. That was sufficient for me at the time. If I ever wanted to use more than 200 page loads per day, I would probably want to set up a private instance of WebPagetest.
To find more details on how to set up an HTTP Archive instance yourself and any further advice, please check out my blog post.
Going back to the scenario I described above: the real motivation is that often you don’t want to throw your website(s) in a pile of other websites (e.g. not related to your business) to compare or define trends. Our digital property at the Canadian Broadcasting Corporation’s (CBC) spans over dozens of URLs that have different purposes and audiences. For example, CBC Radio covers most of the Canadian radio landscape, CBC News offers the latest breaking news, CBC Hockey Night in Canada offers great insights on anything related to hockey, and CBC Video is the home for any video available on CBC. It’s valuable for us to not only compare cbc.ca to the top 100K Alexa sites but also to verify stats and data against our own pool of web sites.
In this case, we want to use a set of predefined URLs that we can collect HTTP Archive stats for. Hence a private instance can come in handy—we can run tests every day, or every week, or just every month to gather information about the performance of the sites we’ve selected. From there, it’s easy to not only compare trends from httparchive.org to our own instance as a performance baseline, but also have a great amount of data in our local database to run queries against and to do proper performance monitoring and investigation.
The beautiful thing about having your own instance is that you can be your own master of data visualization: you can now create more charts in addition to the ones that came out of the box with the default HTTP Archive setup. And if you don’t like Google chart tools, you may even want to check out D3.js or Highcharts instead.
The image below shows all mime types used by CBC web properties that are captured in our HTTP archive database, using D3.js bubble charts for visualization.