Courtesy Mark Gibbs, NetworkWorld.com
Whenever one of my friends calls me from the 118 just east of Somis her cell signal gets choppy then dies. Why? Go to OpenSignal and you can see why; according to their data there’s a stretch of several miles of road where cell service completely vanishes.
OpenSignal is a great tool for checking which carriers provide the best service in any given locale and their heat map display shows the signal strength data collected by crowdsourcing users of their eponymous iOS and Android app, OpenSignal.
The site lets you filter the data by coverage or towers and cell service type (any combination of 2G, 3G, and 4G) as well as by provider. The Web service also shows the percentage that the selected location is better or worse than the average city and similarly for worldwide average.
An OpenSignal cell service heatmap of Nairobi
The app shows the same data as the Web site plus it adds
- a "signal compass" that shows you the direction your current signal is coming from
- which carrier you are currently using and the connection quality
- the WiFi network you’re connected to and the number f networks nearby (it can also show you a list of all nearby WIFi networks)
- a Wi-FI map to locate nearby public networks.
- a speed test feature allows you to see the true speed of your connection.
- a stats page to track your cellular and Wi-Fi data usage
You can also share your findings on Twitter and Facebook and compare your connection with other users. To round all of that off, OpenSignal even provides an API so you can access and massage the data yourself.
This is a great service and one of the best ways to figure out why you, or your friends, have lousy cell service.
Courtesy By Neal Augenstein, WTOP.com
WASHINGTON – The most-used mobile payment app in the United States stored its users’ personal information in a way that could have gotten a tech-savvy thief a lot of free coffee — on you.
Starbucks executives confirm the coffee chain’s mobile payment app has been storing usernames, email addresses and passwords in clear text — not encrypted, according to a Computerworld report.
That means anyone who can get access to a device with the Starbucks mobile-payment app could connect the phone to a PC and get the passwords, usernames and a list of geolocation tracking points — which could sacrifice the phone owner’s privacy and security.
Knowing the phone owner’s information would allow the thief to charge items to the victim’s account, until the stored value on the card is used up.
Even worse, if the phone owner activated an auto-replenish option, more money could be accessed from the victim’s bank account.
"What you’ve described is fair, at a high level," Starbucks CIO Curt Garner said. "From a design perspective, this could have potentially happened."
According to Computerworld, Starbucks chose convenience over security.
Two executives, quoted in a phone interview with Computerworld, said they have known the credentials were being stored in plain text.
"We were aware," said Chief Digital Officer Adam Brotman. "This was not something that was news to us."
Customers using the free Starbucks app only need to enter their password once, while activating the payment options. After that, users don’t have to enter their username or passwords again.
To exploit the easily-read information, a thief would have to steal or at least borrow the device upon which the Starbucks app is loaded.
Yet, a hacker could access the information even without knowing the phone’s PIN code, writes Schuman.
Brotman, with Starbucks, is downplaying the potential for customers to be victimized by easy visibility of passwords, saying "we have security measure in place now related to that," and that "usernames and passwords are safe," because Starbucks has added "extra layers of security."
Reporter Evan Schuman writes Starbucks offered no specifics of the improved security.
Courtesy John K. Waters, VisualStudioMagazine
Mobile development, cloud development and front-end skills are the most desirable for programmers to have at present, and it’s a trend that’s likely to continue into at least the near future.
That’s the conclusion of worldwide recruiting firm CyberCoders, which just published a list of the 10 most sought-after skills of 2013. The firm compiled the list from an analysis of the hiring requirements of more than 10,000 tech companies.
Demand for mobile dev skills is currently outstripping supply, said CyberCoders CTO Matt Miller. Proficiency with iOS and Android in particular continue to be among the most in-demand skills, because of the growing awareness that companies need to have a presence on native mobile apps. "Anyone looking to have a presence on these devices, or distribution in Apple’s AppStore," the company concluded, "needs to be able to develop for iOS." Cloud capabilities came in second, with a particular demand for AWS and Azure proficiency.
Among other things, the CyberCoders list reflects an increasing complexity in the front end, which generates demand for increasing specialization among the software tiers, Miller said.
"A few years ago you could have a great software engineer who could do the back end and work with the database and business logic in the middle tier, and also the front end," Miller said. "But the front end has become so complex that it has become a specific skillset that people want."
The CyberCoders analysis also revealed a strong demand for UX/UI designers, because "companies appreciate the importance of creating compelling and engaging user experiences – these experiences result in an engaged and returning user base."
The demand for C# dev skills edged Java because the language is "a bit more efficient" for the kind of development coders are being called upon to do, Miller said. Another reason, however, is that Microsoft has provided a great set of development tools in Visual Studio.
"Every day we see the engineers with these skills getting an average of four to five job offers," said CyberCoders CEO Heidi Golledge in a statement. "…"This is an incredible time for those who have tech skills or are willing to learn them. Unlike the dotcom bubble of the last decade, our need for continually improving technology is constant due to our improved processes and every day enjoyment of our smart phones and big data."
This is the second year the company has released a Top-10 skill list. No new trends emerged this year, Miller said, but the demand for mobile development skills continues to surge. "And we don’t see that slowing down," he said.
CyberCoders Top 10 Tech Skills for 2013
- Mobile Development (iOS, Android)
- Cloud Computing (AWS, Azure)
- UX/UI Design
- Big Data (Hadoop, MongoDB, NoSQL)
- Ruby on Rails
Courtesy Rahul Lalmalani, MSDN Magazine
The Mobile Playing Field
Today, a large portion of site traffic comes from mobile devices—namely smart phones and tablets—in addition to traditional PCs. Across the globe, mobile devices now account for 12 percent of Internet traffic, and this is scaling up faster than desktop Internet traffic. The fraction of mobile Web traffic is sufficiently higher in nations with high smartphone penetration (for example, 20 percent of US-based Web traffic is via mobile browsing). What’s more, this figure is expected to grow significantly over the next 10 years, as smartphones evolve and mature in terms of hardware and software and adoption picks up in South America, Asia and Africa.
Site owners have begun to take advantage of this trend over the past several years and have primarily relied on native mobile apps for top sites such as Facebook, Hulu and the New York Times. Moreover, up-and-coming Web services such as Pulse, Flipboard and others have even taken to a mobile-first approach, by building apps for iOS and other ecosystems before building a Web site experience. Native apps allow developers to create unique phone-first, touch-optimized experiences for users to interact with their content to take advantage of features like camera integration, geo-location and offline data storage.
Targeting users on mobile natively makes good sense, especially within the US, where more than 50 percent of mobile users own a smartphone. While mobile apps offer site owners a way to connect with users on new form factors, new ways to monetize across platforms and new mobile-scenario-centric experiences to empower and delight their users, they offer an incomplete opportunity for developers compared to the ubiquity and reach of the Web. There are a couple of problems that affect a native mobile-only approach.
Problem 1: Cost of Supporting Multiple Platforms
Creating similar content and experiences across multiple platforms is costly and requires site owners to choose platforms for which to optimize. Additionally, this translates to a limited Web site experience for users who seek out your content from other platforms, especially when you need to prioritize your development investments.
Adopting a responsively designed Web site can help address the investment costs and ensure that your users across all the latest mobile operating systems are enjoying a consistently useful experience.
Scott Scazafavo, former vice president of product management at Allrecipes.com, whose responsibilities included mobile product development, puts it this way:
"To do a decent job developing a native mobile application that can compete with “best in class” offerings that are powered by live data or content (like we have at MSN and also at my previous employer, Allrecipes.com), it typically takes a minimum initial investment of about $250k to define, design and engineer that native application, and then an annual maintenance investment for that native app of $75K to $100K per platform to keep it evolving, feature wise, to keep consumers interested and adoption numbers healthy. That is over and above any internal work needed for design or engineering to create and maintain the services (APIs) that power those products.
The approach we have taken here at MSN for our TMX product (the new touch-first version of MSN.com currently available on IE10) with HTML5, as well as thin-shell apps to help deliver that product into app marketplaces, in addition to mobile browsers, comes only with a small incremental initial investment to what we do with internal resources to create that app product. [That figure is] probably a $25K to $50K initial investment per platform for each app, and a negligible maintenance cost thereafter to maintain those apps."
Similarly, by using responsive Web design techniques, Clipboard.com was able to target many mobile, small device browsers like Internet Explorer 10 on Windows 8 and Safari on iPhone/iPad at half its expected costs to develop when they began the project.
Problem 2: Fragmented Ecosystems
Even within a given platform, a plethora of device geometries and sizes—as well as supported platform versions—exist. This requires site owners to not only design for near-similar display sizes and resolutions, but also to submit to multiple app stores (Kindle store, Google Play and Nook store, all on the Android platform). Managing multiple assets within the same platform adds complexity to the support matrix. Fix a layout bug in your native app for the Nexus 7, and you might have to fix it again for the Kindle Fire app. This means all your users are not on the same app version, with the same feature set and the same bug fixes.
Similarly (even within the iOS app ecosystem), top apps like ESPN, Spotify, Angry Birds Space and the App Store itself did not correctly occupy the full screen when the iPhone 5 was released, instead just showing users a black bar at the top and bottom of the app. The addition of iPhone 5 required developers to ship app updates to address this simple layout bug.
We’re also still at a stage where vendors are experimenting with new form factors, such as the big screen. For example, more than 25 million Xbox Live users now have access to Internet Explorer 10 on their living room TV screens and are interacting with it not just through a pointer but also through more human-centric mechanisms such as Kinect and Xbox SmartGlass. Today’s technical decision makers are facing a fragmented and very volatile landscape of devices that their users have integrated into their daily routines.
A Unifying Approach: Responsive Web Design
Responsive Web design aims to provide an optimal viewing/consumption experience—easy reading and navigation with minimum resizing, panning, and scrolling —across the gamut of devices that exist in the market, as well as to future-proof your site for those that are yet to come. There already exist different Web tutorials regarding individual techniques that help a site become more responsive. This series aims not only to provide a unified approach to responsive Web design, it aims to impress upon decision makers and developers the immediate need for adopting responsiveness as part of their reach strategy. According to a crawl of the top 5,000 Web sites by modern.IE, only about 14 percent of sites have some form of responsive design. It’s not difficult to see why developers think it’s a daunting task to consider.
Take a look at Figure 1. You can see the relative screen resolutions for the Web browsers on popular smartphones and tablets (the devices are identified in Table 1). The device resolutions, as well as ratio of CSS pixels to hardware pixels (a concept we’ll explain in part 3), are taken from Wikipedia. (Each square corresponds to 100 x 100 px of Web content, laid out at 1x optical zoom.)
Table 1. Key to Figure 1
Samsung Galaxy S3
Nokia Lumia 920
Kindle Fire, Nook Color
Kindle Fire HD
LG Nexus 7
Kindle Fire HD 8.9
iPad and iPad Mini (different hardware resolutions but same number of CSS pixels, more on this in Part 2)
So is cross-browser, cross-device code the solution?
Traditionally, OS-specific apps have been able to provide more sophisticated user engagement because they have access to valuable user information, such as geo-location, offline storage and even custom font support for customized interfaces.
However, modern browsers such as Internet Explorer 10, Google Chrome (version 22), Safari 6 and Firefox (version 17) now offer the lion’s share of these experiences as part of their support for HTML5 and CSS3. HTML5 is not your grandpa’s HTML, which was originally designed to let people encode and deliver pieces of textual information across the Internet. HTML5 is intended for developers to write rich Web-based apps for the twenty-first century. Between HTML5 and CSS3, you get access to once-native features such as media queries, geo-location, custom font support, offline storage and even touch events! This way, your sites can have a different look and layout on hardware of different dimensions, provide users with location-aware services and even provide a valuable experience when the user is disconnected from the Internet.
There are some common HTML5 myths out there. These include:
I can’t monetize HTML5.
HTML5 sites have arguably more monetization opportunities than their app equivalents. App monetization today includes app purchases (although most apps in the iOS apps store are in the free to $0.99 range). This is probably the only way in which HTML5 site experiences can’t be directly monetized. Otherwise, developers have a lot of control over advertising and in-app or in-site purchases. More importantly, a lot of apps tend to limit the amount of navigation a user can do. For example, most reader and newspaper/magazine apps offer textual content and don’t provide the “linky-ness” of the Web, which allows users to navigate to related content while consuming the current Web page.
The Web site experience, when responsively implemented, retains the “linky” nature of the Web and can lead to a higher number of user impressions.
HTML5 cannot be offline.
HTML5 has a couple of different solutions for ensuring that users have a great offline experience. First and foremost, Web pages can specify which of their assets should be made available to users when they are disconnected (using App Cache). This way, the user can still interact with the page even while offline. Additionally, HTML5 can locally store user information and input using Local Storage, as well as IndexedDB. This data persists even if the user closes the browser and can be synced back to the server at a later point in time when the user relaunches the Web page.
Check out the demo for this offline calculator. A user needs to be connected to the Web only the first time he visits it. Subsequently, he can access it offline. Moreover, the user’s calculation and results are stored via Local Storage so he can come back at a later time and continue a calculation.
The Mozilla hacks blog is a great start at busting some common myths about HTML5. It’s important to note here that native apps use APIs that are optimized for device-specific performance. However, HTML5 and CSS3 provide developers with tools to build engaging experiences across a variety of form factors and ensure that you are not missing out on users visiting from other platforms.
CanIUse.com is a great resource for understanding the available browser support for specific HTML5 and CSS features.
Media Queries and Responsive Design
One of the new tools in CSS3 to aid in responsive Web design is called media queries. Media queries allow you to offer your users the same HTML content but enable the browser to detect the size constraints of the device (in pixels) and layout the same content in a different, relevant manner. You can grow or shrink the width of your text and image content, increase or decrease the number of columns in your newspaper-style layout or even hide pieces of information entirely, depending on what you think the right consumption experience is for your user on a given device.
With a combination of media queries to dictate the layout of your content, as well as browser detection to identify additional constraints of the user experience (for example, if the user is interacting with a site via Xbox 360 on a large TV screen), you can identify your users’ needs and deliver the right experience for the current context in which a user has accessed your content—whether it be to consume it richly on a desktop, interact with it via touch on a slate or quickly skim through it on the go on a phone—and do so gracefully with Web technologies.
It should be noted that using media queries alone to build three different fixed-width layouts for your Web site can definitely help you target common screen dimensions today (for example, desktop, tablet and phone). However, this is not truly responsive Web design. It does not provide an optimal experience for users visiting your site with a device that has an intermediate width, nor does it prepare you for the next wave of “it” devices with new geometries and dimensions.
Build Once! Deploy Once!
In addition to simplifying your code base and support matrix, this has the following advantages.
Benefit 1: Leave No Users Behind
Betting on powerful native apps for the top one or two mobile platforms can mean that some of your users migrate to competitors if they offer a useful Web experience, with more reach, on all platforms.
Benefit 2: Unified Ad Story
Often, when sites rely on advertising for revenue, they engage with their business partners and sell them advertising piecemeal, based on whether the users are experiencing the full-blown Web version or a limited app version. Also, click-through rates for ads on mobile devices are less than those on desktop PCs, in which case the extra cost of engaging with partners, creating advertising assets for native apps and selling app-specific ad real estate does not justify the additional gains. For example, MSN.com (which has now begun to roll out a unified, media-query-based HTML5 Web site across its international markets) can now unify its ad partnership story across all device types.
With a single HTML5 experience that responsively scales to different form factors, you can cater to a single ad customer with the same set of ad assets across a variety of devices—in the living room, on the work desk and on the go.
Benefit 3: Upgrade Your Site Experience Directly into Your App Experience
Occasionally, you might still hit a roadblock where you want to deliver a great mobile experience to your users that takes advantage of their unique hardware—for example, you want users to get new content from your site by shaking their phone. In this case, you need to access the device accelerometer.
Well, the great news is that you can create a native app by applying a wrapper around your site content and only write the necessary native app code to interact with the additional hardware on the phone. For example, you can host (the responsively scaled down view of) your site content within a WebViewController on an iPhone and just listen for the accelerometer event in your objective-C native code.
This means that for any fixes/features that you build within the Web layer, you don’t need to go through the trouble of shipping app upgrades!
“So, how do I start?”