Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 23 2011

Is your Android app getting enough sleep?

Android developers have unprecedented access to smartphone resources, but this access carries responsibility. The potential to unwisely hog available resources, like power consumption, is a real concern.

I recently spoke with Frank Maker, a Ph.D. candidate at the University of California, Davis, who is doing systems research with Android on low-power adaptation techniques. Our interview follows.

What are the main power consumption issues Android developers should be aware of?

Frank MakerFrank Maker: The number one thing developers should do with their app is allow it to sleep. On a desktop computer, you just launch the app. It runs. You close it. You open it. But on an Android device, you actually go through states where it has focus, it doesn't have focus, things like that. A developer needs to handle those states appropriately instead of trying to make an app work like it would on a desktop. So, if the activity loses focus and the user is going on to another application, then your app should respond to that if it has anything that's going to use serious power. You can bundle up the state and put the app to sleep rather than letting your app's tasks run in the background.

What are the risks associated with poor power optimization?

Frank Maker: The biggest risk is that you'll get eaten alive in the Android Market. There are many applications in the Market that are marked one star because of bad battery performance. Even worse, if your app has a reputation for poor power use, you're going to completely lose your market share to competitors with better reputations.

On the user side, are there tools for monitoring and managing power consumption?

Android battery screenFrank Maker: There's a battery usage screen on Android. If you go to "Settings," "Application Settings," and then "Battery Use," there's a nice little display that shows you the ranking of the different applications. I've looked into it as part of our research, and while it's simple and not super accurate, it will definitely tell you if one app is using way too much power.

Battery life basically isn't a problem until you make it a problem. By that I mean it's not something users think about initially, but if their battery starts going down really fast and they just installed your app, they're generally going to put two and two together. They'll then go to the Market and see if other people have posted about their experiences with that app.

Tell us a little bit about the research you're doing at UC Davis. What exactly are you working on?

Frank Maker: I sit on the border between hardware and software. We're trying to solve the problem of taking one piece of software and putting it on lots of different platforms without changing the software each time. Right now there's a lot of refactoring that goes on when you deploy an application to a new mobile platform. We are trying to create automatic methods instead. One of the things we've looked at is building a model for the power usage in real-time on the device. So the idea is that when you launch the software on the device, you figure out how much energy it takes to do tasks on the device, rather than trying to know it beforehand.

Related to porting across platforms, do you think Android's fragmentation issues will improve over time?

Frank Maker: I'm pretty confident that the Android platform will solve the fragmentation problem. Google is addressing it. For example, on the Android developer blog, Dianne Hackborn recently wrote about new tools that help you adapt to different screen sizes. There's also the battery usage meter, which I mentioned earlier, and Android has always provided a directory structure for your resources to adapt to different configurations. You can automatically select the right resource for the right device and pinpoint exactly what you want to do for each device.

Broadly, I feel like Android is in a transition period. It's evolving from a young, scrappy platform into something more established, and now it has to really solve these issues as it moves into adolescence.

This interview was edited and condensed.

Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

Save 20% on registration with the code AN11RAD


August 22 2011

MagAppZine's goal: From PDF to app in about 15 minutes

MagAppZineLogo.PNGThe next TOC Sneak Peek webcast on August 25 will feature startup company MagAppZine, a platform that allows publishers to create custom apps without a lot of overhead.

In the following interview, MagAppZine founder Paul Canetti (@paulcanetti), who worked at Apple during the birth of the iPhone and the subsequent app revolution, talks about how the MagAppZine platform works and the benefits he sees for publishers.

How did MagAppZine get started?

paulcanetti.jpgPaul Canetti: I was working at Apple when the iPhone was first released and I got to see the effects of the "app revolution" firsthand. I left in 2009 and started creating apps for hire, and that is when I realized the huge potential for publishers — but the costs and demand on resources were just too high. So I set off to create a platform where publishers can actually create apps themselves and manage their content over time, quickly, easily, and affordably.

MagAppZine really aims to get publishers of all shapes and sizes up and running in the digital age as painlessly as possible. Anyone that tells you it's hard is just doing it wrong.

What's the process for creating an app through MagAppZine?

Paul Canetti: There are five basic steps:

  1. Sign up for an account at
  2. Once logged into MagControl, our web dashboard, click "Create New App"
  3. Enter basic information like name, description, and upload your logo, app icon, etc.
  4. Start adding issues by uploading PDFs
  5. Click "Submit" and we send your app off to Apple

The whole process takes about 15 minutes, assuming you already have your icon and such ready to go. I should also mention that starting in September, it is going to be free to sign up for an account and try out the MagControl tool. You can make an app and upload issues using your free account. Only when you want to actually submit it to the App Store in step 5 will you be charged.

Is the platform targeted toward a specific kind of publisher?

Paul Canetti: Clearly the name brings in magazines first and foremost, but the tool itself is really applicable to all sorts of publications. Anything that can be a PDF is fair game. I have a lot of conversations with small book publishers looking to create a bookstore app on a particular topic or as a branding tool for the publisher or a specific author. It is my philosophy that you should be everywhere your readers potentially are, so when someone searches for you on the App Store, it's you that they find.

How can book publishers use the platform?

Paul Canetti: The bookstore app is really cool, and chunking up books into collections fits nicely under the umbrella of the app. I'm also excited to start seeing sub-divisions of books — selling chapter by chapter — or using the subscription functionality to have a sort of book club app or a series where new content is being released regularly. The possibilites are really endless. Not only that, but using our new multimedia and link tools, you can add audio or video to your books, skip around within the book — remember the "Choose Your Own Adventure" series? It really opens up the doors for being creative and taking advantage of the format.

What's your launch schedule?

Paul Canetti: Our most basic app package launched in April of this year, but in September we are re-launching MagAppZine 2.0, which will include the new links and multimedia, an InDesign tool, and integration with Apple's upcoming Newsstand feature. We're also rolling out a new tiered monthly pricing structure that has plans starting at $99 a month.

This interview was edited and condensed.

Webcast: TOC Sneak Peek at BookRiff, LiquidText, and MagAppZine — Sneak Peeks are a TOC webcast series featuring a behind-the-scenes look at publishing start-ups and their products. Our next episode will feature presentations from BookRiff, LiquidText, and MagAppZine.

Join us on Thursday, August 25, 2011, at 10 am PT
Register for this free webcast


  • The ascendance of App Inventor
  • Apple's in-app shift: What does it mean for publishers?
  • The secret to digital publishing success? Don't start with the book
  • Ubiquity and revenue streams: How HTML5 can help publishers

  • Sponsored post
    Reposted bySchrammelhammelMrCoffeinmybetterworldkonikonikonikonikoniambassadorofdumbgroeschtlNaitliszpikkumyygittimmoejeschgeKameeel

    August 19 2011

    Place Pulse: a new website rates city safety

    Flash cars, swept pavements, no graffiti ... what makes us think one street is safe to walk along and another not? A new crowdsourced project can help us find out

    What makes us feel safe on some streets and scared on others? Why is one neighbourhood nicer to live in than another? Which city looks better, Boston or Vienna? And why isn't there an app that just tells us how we work these things out?

    When it comes down to it, we're not really sure how we make judgments on the quality of our surroundings – is it down to the architecture, the width of the street, the amount of greenery? Or are there other, subconscious factors at play on our perceptions? Does a street look nicer if there's a new Audi parked on it rather than a beat-up old Toyota? Perhaps we take in what people are wearing, the quality of the paving stones, the signage. It's often a matter of guesswork for architects and planners, too, when it comes to designing agreeable places and spaces. But the good news is: there IS now an app that can tell us this stuff. Sort of.

    It's called Place Pulse, and it's more of an online experiment, run by researchers at MIT Media Lab, the Mecca of future-tech design. The experiment bit is very easy to participate in: you simply look at two street views and vote on which one has more "curb appeal".

    At present, there are just three questions (which city looks safer/more unique/more upper-class?) and five cities (Boston, New York City, Linz, Salzburg and Vienna), so it's not exactly a comprehensive survey, but from the results published so far, we can at least answer the initial question. The perceived "safest" images are all from the Austrian cities, while the least safe are all in Boston. Why? You could characterise the safe places by tree-lined avenues, pedestrian areas and historic architecture. And conversely, the least safe places by empty expanses of concrete, unpopulated streets, conspicuous walls and barriers.

    But what about those other, subconscious factors? The purpose of Place Pulse is not so much to come up with a league table of cities or areas, as to reveal the visual cues that make a place appear safer or wealthier. It's not gathering the data that counts – it's understanding it.

    Place Pulse's software promises to analyse those crowdsourced votes (nearly 300,000 votes so far; the target is a million) and reveal the attributes that influenced them. This information will be presented as "a visual symphony of electronic data", the team promises. We'll have to wait for their exhibit at Linz's Ars Electronica festival in September to find out what the hell that means.

    So how can this help the real world? One example is graffiti, says Place Pulse's Phil Salesses. City councils across the world spend millions cleaning up graffiti in the belief that it is universally undesirable, and yet in his home town of Boston there are safe, pleasant areas with plenty of graffiti. Rather than a blanket graffiti-removal policy, might that public money be better spent, say, cleaning soot off building facades, if that has a better net result?

    Of course, there's a danger that this research could encourage cash-strapped city councils to simulate safe neighbourhoods rather than reduce actual crime rates. But anything that makes our cities a little less ugly is surely welcome. And a better-looking city could perhaps help reduce crime rates.

    Place Pulse draws heavily on the work of Kevin A Lynch, an influential urban planner and former MIT professor. Lynch was interested in understanding the city not so much in terms of empirical data as people's mental images of it – how people navigate and read their environment. In effect, he told architects and planners that there was only so much they could do, but his work at least helped them to do it.

    In the 21st century, there's a new layer to how we read a city: the electronic one. "Geo-social" devices such as smartphones, advanced mapping technologies and localised information are helping us to map places in novel ways. According to future-watchers, we're heading towards an era of "hyperlocality", when invisible webs of electronic information will define our environment as much as boring old trees and buildings. Having said that, you'd rather be hyperlocal in a tree-lined avenue than an abandoned parking lot, wouldn't you? © Guardian News & Media Limited 2011 | Use of this content is subject to our Terms & Conditions | More Feeds

    August 16 2011

    August 15 2011

    Honeycomb and the Android tablet tipping point

    There are encouraging signs for Android tablets, including release of the tablet-friendly Android 3.0 (Honeycomb), strong early sales for the ASUS Eee Pad Transformer, and critical acclaim for the Samsung Galaxy Tab 10.1. But these positive signals have yet to translate into a robust inventory of Android tablet applications.

    Marko Gargenta (@markogargenta), author of "Learning Android" and the forthcoming "Programming Honeycomb," discusses the state of Honeycomb and the adoption pattern of Android tablets in the following interview. Many of these topics will be further explored at the upcoming Android Open conference, which Gargenta is co-chairing.

    We've been hearing about the lack of apps designed specifically for Android tablets. Why is this area slow to develop?

    Marko GargentaMarko Gargenta: It's true that there aren't as many Android apps designed specifically for tablets. The reason for this is two-fold. On one hand, most of the existing Android apps will happily work on tablets. On the other hand, developers want to see a sizable market share for tablets before they invest their time. It appears that we're at that tipping point where the number of Android tablet devices out there supports the development costs to create tablet-optimized applications.

    What are the biggest technical challenges for Android tablet apps?

    Marko Gargenta: Honeycomb brings a couple of new concepts to app development, namely Fragments and new UI capabilities. Developers need to learn how these work in order to take advantage of the new features. While not too complex, they do take some time to master.

    The other technical challenge is the emulator. In previous versions of Android, the emulator worked great and most developers did not need a physical device for development. But the Honeycomb emulator is extremely slow. That means developers need actual tablet devices, which are somewhat pricey compared to subsidized phones.

    What's your take on Honeycomb thus far?

    Samsung Galaxy Tab 10.1Marko Gargenta: I like Honeycomb and the general direction of Android for tablets. I think the tools have a ways to go in order to be more appealing to developers. The issues with tablet tools are the same we see with smartphones, but they're amplified on the tablet side. In addition to the emulator issues, there's also the quirks and steep learning curve of Eclipse, a powerful and feature-rich tool that many developers use for Android development.

    That said, I think Honeycomb is overall a well-designed platform. The Android team took a holistic view at how tablets are used and they developed a platform that addresses that view. At the same time, Honeycomb isn't as polished as the iPad. There aren't any major features missing in Honeycomb when compared to iOS, but there are differences in the ecosystems: the economics, the user bases, the distribution, etc.

    How difficult would it be for an iPad developer to transition apps to Honeycomb?

    Marko Gargenta: There are two types of iOS applications: native and those based on WebKit (web applications wrapped in a native app shell). WebKit apps are easy to port and many tools exist to help with that. Native iOS apps usually require a total rewrite. It's like starting a new project with very little reusable code.

    Which Android tablet do you use?

    Marko Gargenta: I use the Motorola Xoom. I have it rooted, and I've reinstalled the operating system many times to experiment with how it all works. It's certainly a heavier tablet than others on the market, but it's also fairly rugged.

    This interview was edited and condensed.

    Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

    Save 20% on registration with the code AN11RAD


    August 11 2011

    The evolution of iOS development: Better tools and a lot more to think about

    The first edition of "Head First iPhone Development" came out in 2009, which feels like decades ago in app years. Now, with "Head First iPhone and iPad Development" arriving earlier this summer, I checked in with the authors of both editions, Dan Pilone (@danpilone) and Tracey Pilone (@traceypilone), to get their take on the maturation of the iOS world, how the iPad has changed development patterns, and what they hope to see in iOS down the road.

    Our interview follows.

    Has the learning curve for iPhone/iPad development improved?

    Dan Pilone: That's a really tough one to judge after spending so much time working with iOS. I think the fundamentals are still the same: you still need to learn Objective-C, you're still dealing with memory management, you still need to learn the core Cocoa Touch patterns. In some ways it definitely has gotten easier. For example, Xcode 4 is a huge step forward. Provisioning and iTunes App Store submission have been streamlined as well.

    However, iOS has gotten harder in some ways. There are a lot more devices in the mix and iOS as a platform is bigger than ever. You have Game Kit, Map Kit, Store Kit, Grand Central Dispatch (GCD), fully capable audio and video frameworks, and more, all under the umbrella of iOS. There are entire parts of the iOS SDK that you might never bump into depending on what kind of apps you're writing. It's a great platform to develop for, but I don't know if I'd describe it as "easy" just yet.

    Tracey Pilone: Actually, I'd say it's gotten worse! When iPhone development started, it was just one iPhone, with fairly limited developer access to parts of the OS, like multitasking. Since the last time we wrote the book, we have multiple iPhones, different displays, iPads, different OS versions to support, etc. You can start in the same place, but the topics for us to cover have expanded.

    How have iOS development tools evolved since you wrote the first edition of your book?

    Tracey Pilone: The tools have evolved a lot, which is part of why it took us a while to print an update. Xcode 4 was announced and in developer preview for months, and we struggled over when to print the new edition. We finally went ahead when Xcode 4 became public.

    Xcode 4 integrated Interface Builder and dramatically changed the workflow, mostly for the better. You can link outlets and actions directly to code, unlike in previous versions. The editor for the views is completely integrated. Git support is included and there's better support for coding with features like code completion.

    Dan Pilone: The provisioning and signing tools have significantly improved and you can now do application validation prior to submission, which saves on needless round-trips trying to get your first application in the App Store. Testing tools have improved a good bit with Unit Tests being a first-class part of Xcode. Automated UI testing through Instruments is a big win as well.

    Head First iPhone and iPad Development, Second Edition — Learn how to design for Apple's devices and master the iOS SDK tools -- including Interface Builder, Xcode, and Objective-C programming principles -- to create eye-catching apps.

    Have you noticed any iOS development trends tied to the popularity of the iPad?

    Tracey Pilone: What we have seen is that clients come to us looking for completely different experiences out of the iPad verses the iPhone. The iPad has opened up lots of possibilities for extended user interaction. The iPhone is always with you, but the interaction time frame is significantly shorter. It's been fascinating for us to see so many different types of uses for the devices.

    Dan Pilone: I love the way iPad application UIs have evolved since the iPad first came out. Apple has gone to great lengths to get developers to think differently about iPad application UIs, and this has resulted in some really stunning apps. The integration of iPad applications and UIs with the real world is the most fascinating aspect. The virtual game board in "Scrabble" and Adobe's applications for working with Photoshop are examples.

    What technical issues does iOS need to address?

    Dan Pilone: Provisioning and certificate management are still harder than I think they should be, but my biggest issue is the lack of a garbage collector. I understand the constraints of a mobile device and I'm willing to put up with it, but right now, to the best of my knowledge, garbage collection is the biggest hurdle to getting MacRuby as a viable development platform for iOS. I like the Cocoa Touch framework, and GCD is absolutely unmatched by anything else I've used. But I'm still lukewarm on Objective-C. If Apple makes iOS development more approachable through something like Ruby with real garbage collection, I think the application rush will start all over again.

    At this point, do developers have to choose one mobile platform over another?

    Dan Pilone: Unfortunately, yes. Either that or they're choosing both iOS and Android and basically writing their applications twice. There are some mobile applications that are great as HTML5/CSS3/JavaScript and those are cross-platform, but I still think nothing beats a true, native application. As a great example, try ordering pizza from Papa Johns through their web application — it's well-done, pretty straightforward, and it looks a lot like an iOS application. Then use Chipotle's native iOS app. It's phenomenal. It doesn't do a whole lot more than Papa John's mobile web app, but the Chipotle app's user experience is dramatically better.

    Papa Johns web app and Chipotle native app

    We went through the whole "cross-platform development" thing with desktop apps, then again with web apps, and I guess we still need another round with mobile devices. In the end, HTML5/CSS3/JavaScript might be the cross-platform solution, but I don't think it's there quite yet.

    Tracey Pilone: The overlap for iOS and Android is there, but it's limited. UI and graphics work can be used for both, but they won't share any code. There are a lot of mobile developers out there who can do Android and iOS, but our experience has been that the iOS market is significantly stronger than Android.

    What aspects of app development — or types of apps — are you most interested in?

    Tracey Pilone: I'm most excited about the prospects for education with iPads. The ability to integrate video, audio, reading, and tactile exercises into teaching topics is a great area for growth and it has the potential to deliver good teaching even to those students who can't physically be in the classroom.

    Dan Pilone: For me, it's the idea of mobile devices acting as entry points for users into an always-connected network of information. We do Rails development in addition to iOS development, and I'm much more interested in applications that present me with exactly the right UI to plug into and take advantage of interconnected back-end systems. Combine heavy lifting on the server side with the location awareness and always-on connectivity of a mobile device and you have a pretty amazing change in how people interact.

    Web 2.0 Expo New York 2011, being held Oct. 10-13, showcases the latest Web 2.0 business models, development tools and design strategies for the builders of the next-generation web. Save 20% on registration with code WEBNY11RAD.


    August 08 2011

    Mobile metrics: Like the web, but a lot harder

    Flurry is a mobile analytics company that currently tracks more than 10,000 Android applications and 500 million application sessions per day. Since Flurry supports all the major mobile platforms, the company is in a good position to comment on the relative merits and challenges of Android development.

    I recently spoke with Sean Byrnes (@FlurryMobile), the CTO and co-founder of Flurry, about the state of mobile analytics, the strengths and weaknesses of Android, and how big a problem fragmentation is for the Android ecosystem. Byrnes will lead a session on "Android App Engagement by the Numbers" at the upcoming Android Open Conference.

    Our interview follows.

    What challenges do mobile platforms present for analytics?

    Sean Byrnes: Mobile application analytics are interesting because the concepts are the same as traditional web analytics but the implementation is very different. For example, with web analytics you can always assume that a network connection is available since the user could not have loaded the web page otherwise. A large amount of mobile application usage happens when no network is available because either the cellular network is unreliable or there is no Wi-Fi nearby. As a result, analytics data has to be stored locally on the device and reported whenever a network is available, which can be weeks after the actual application session. This is complicated by the fact that about 10% of phones have bad clocks and report dates that in some cases are decades in the future.

    Another challenge is that applications are downloaded onto the phone as opposed to a website where the content is all dynamic. This means that you have to think through all of the analytics you want to track for your application before you release it, because you can't change the tracking points once it's downloaded.

    What metrics are developers most interested in?

    Sean Byrnes: Developers are typically focused on metrics that either make or save them the most money. Typically these revolve around retention, engagement and commerce.

    One of the interesting things about the mobile application market is how the questions developers ask are changing because the market is maturing so quickly. Until recently the primary metrics used to measure applications were the number of daily active users and the total time spent in the app. These metrics help you understand the size of your audience and they're important when you're focusing on user acquisition. Now, the biggest questions being asked are centering on user retention and the lifetime value of a user. This is a natural shift in focus as applications begin to focus on profitability and developers need to understand how much money they make from users as compared to their acquisition cost. For example, if my application has 100,000 daily active users but an active user only uses the application once, then I have a high level of engagement that is very expensive to maintain.

    Social game developers are among the most advanced, scientific and detailed measurement companies. Zynga, for example, measures every consumer action in impressive detail, all for the purpose of maximizing engagement and monetization. They consider themselves a data company as much as a game maker.

    Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

    Save 20% on registration with the code AN11RAD

    What do you see as Android's biggest strengths and weaknesses?

    Sean Byrnes: Android's biggest strength is adoption and support by so many phone manufacturers, and the fact that it's relatively open, which means development iterations can happen faster and you have the freedom to experiment. The installed base is now growing faster than iOS, although the iOS installed base is still larger, as of now.

    Android's biggest weakness is that it offers less business opportunity to developers. Fewer Android consumers have credit cards associated with their accounts, and they expect to get more free apps. The most common business model on Android is still built on ad revenue. Also, because the Android Market is not curated, you can end up with a lower-average-quality app, which further reduces consumer confidence. At the end of the day, developers want a business, not an OS. And they need a marketplace that brings in consumers who are willing and able to pay. This is Android's biggest challenge at the moment.

    Is Android fragmentation a problem for developers?

    Sean Byrnes: Fragmentation is definitely a problem for Android developers. It's not just the sheer number of new Android devices entering the market, but also the speed at which new versions of the Android OS are being released. As a developer you have to worry about handling both a variety of hardware capabilities and a variety of Android OS capabilities for every application version you release. It's difficult to be truly innovative and take advantage of advanced features since the path of least resistance is to build to the lowest common denominator.

    It will likely get worse before it gets better with the current roadmap for Android OS updates and the number of devices coming to market. However, fragmentation will become less of a concern as developers can make more money on Android and the cost of supporting a device becomes insignificant compared to the revenue it can generate.


    July 20 2011

    Four short links: 20 July 2011

    1. Random Khan Exercises -- elegant hack to ensure repeatability for a user but difference across users. Note that they need these features of exercises so that they can perform meaningful statistical analyses on the results.
    2. Float, the Netflix of Reading (Wired) -- an interesting Instapaper variant with a stab at an advertising business model. I would like to stab at the advertising business model, too. What I do like is that it's trying to do something with the links that friends tweet, an unsolved problem for your humble correspondent. (via Steven Levy
    3. JSON Parser Online -- nifty web app for showing JSON parses. (via Hilary Mason)
    4. Facebook and the Epiphanator (NY Magazine) -- Paul Ford has a lovely frame through which to see the relationship between traditional and social media. So it would be easy to think that the Whole Earthers are winning and the Epiphinators are losing. But this isn't a war as much as a trade dispute. Most people never chose a side; they just chose to participate. No one joined Facebook in the hope of destroying the publishing industry.

    July 12 2011

    Getting started with HTML5 apps

    HTML5 logoBuilding apps in HTML5 and JavaScript may be easier than using other development tools, but there's still a learning curve. In the following interview, "Programming HTML5 Applications" author Zachary Kessin (@zkessin) discusses the skills you'll need — and the mistakes you should avoid — if you want to create solid HTML5 applications.

    What's the difference between an HTML5/JavaScript app and a regular website?

    Zachary Kessin: There isn't a line you can draw and say that things on this side are "web pages" and on that side they're "apps." It’s more of a common-sense definition: Google Docs is an app, Wikipedia is not. If I had to define one factor, it would be how long do you go between page loads? In an app, you may work for an hour or more before reloading the page.

    That being said, many of the ideas behind apps can be used in web pages to improve the user experience. For example, having an office wiki that cached the data on your local computer so you could use it offline would be a very useful feature.

    How much programming experience do you need to take on HTML5 app development?

    Zachary Kessin: There are two key things you need. First, an ability to do some amount of functional programming, and second, you need an understanding of asynchronous operations. In a web app, there are lots of times when a function does not return a value; it takes a callback that is called at some point in the future when the value is available. This takes some getting used to and it can often hit you in a strange way.

    OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript's imminent colonization of server-side technology.

    Save 20% on registration with the code OS11RAD

    What are most common mistakes you see in HTML5/JavaScript apps?

    Zachary Kessin: JavaScript, like PHP, is one of those languages that lets a beginner cut and paste code and get something that more or less works. The novice doesn't really need to understanding what's going on. This can lead to some really bad code. Common mistakes include:

    • Directly using the DOM. It is buggy and a pain to use. Use jQuery instead.
    • Overuse of the global name space, by design or not understanding things. Keep things lexically scoped.
    • Not really understanding the language. I think people see the "-script" in JavaScript and treat it as a "toy language," which is a shame.
    • Not using JSLint. I can think of so many problems that would be caught in advance with JSLint.

    What about HTML5/JavaScript apps most needs to be improved?

    Zachary Kessin: The state of the local storage interfaces is kind of a mess. We've got IndexDB, SQLite and a few others, and it’s not quite clear what to use. The vendors need to get their acts together there.

    Being able to do Web Workers is nice, but it would be great if there was some way to step through code and set breakpoints with Firebug or Chrome dev tools. I expect that will happen eventually.

    Programming HTML5 Applications — This practical guide shows you how HTML5's JavaScript APIs give you the power to take web development into fields that used to require more platform-specific development — particularly mobile deployment.


    June 30 2011

    How Netflix handles all those devices

    Netflix's shift to streaming delivery has made quite an impression on Internet traffic. According to Sandvine's latest report, Netflix now claims almost 30% of peak downstream traffic in North America.

    That traffic occurs, in no small part, because Netflix can run on so many devices — PCs, tablets, gaming consoles, phones, and so on. In the following interview, Netflix's Matt McCarthy (@dnl2ba) shares a few lessons from building across those varied platforms. McCarthy and co-presenter Kimberly Trott will expand on many of these same topics during their session at next month's OSCON.

    What are some of the user interface (UI) challenges that Netflix faces when working across devices?

    Matt McCarthyMatt McCarthy: Scaling UI performance to run well on a low-cost Blu-ray player and still take advantage of a PlayStation 3's muscle has required consulting WebKit and hardware experts, rewriting components that looked perfectly good a week before, and patiently tuning cache sizes and animations. There's no silver bullet.

    Since we've standardized on WebKit, we don't have to support multiple disparate rendering engines, DOM API variants, or script engines. However, there are lots of complex rendering scenarios that are difficult to anticipate and test, especially now that we're starting to take advantage of WebKit accelerated compositing. There are WebKit test suites, but none that are both comprehensive and well documented, so we're working on our own test suite that we can use to validate partners' ports of our platform.

    OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript's imminent colonization of server-side technology.

    Save 20% on registration with the code OS11RAD

    How do the platform lessons Netflix has learned apply to other developers?

    Matt McCarthy: The challenges we face may be familiar to many large-scale AJAX application developers. In addition, mobile developers need to make similar trade-offs between memory usage and performance, other sophisticated user interfaces need to handle UI state, and most large code bases can benefit from good abstraction, encapsulation, and reuse.

    The urgency and difficulty of solving those challenges may differ for different applications, of course. If your application is very simple, it would be silly for you to use the level of abstraction we've implemented to support A/B testing in Netflix device UIs. But if you're innovating heavily on user experience, your performance isn't always what you'd like, and your UI is an endless font of race conditions and application state bugs, then maybe you'd like to learn about our successes and mistakes.

    There were reports last year that some Netflix PS3 users were seeing several different UIs. What are the benefits and challenges with this kind of A/B testing?

    Matt McCarthy: Netflix is a subscriber service, so ultimately what we care about is customer retention. But retention, by definition, takes a long time to measure. We use proxy metrics that correlate well with retention. Some of our most closely watched metrics have to do with how many hours of content customers stream per month. Personally, I find it gratifying to have business interests that are aligned closely with our customers' interests.

    The challenges grow as the A/B test matrix grows, since the number of test cell combinations scales geometrically with the number of tests. Our quality assurance team has been working on automated tests to detect regressions so a fancy new feature doesn't inadvertently break another feature that launched last month. Our engineers adhere to a number of best practices, e.g. defining, documenting, and adhering to interfaces so we don't find nasty surprises when we replace a UI component in a test cell.

    A/B testing user interfaces obviously takes a lot more effort than developing our "best bet" UI and calling it a day, but it's been well worth the cost. We've already been surprised a few times by TV UI test results, and it's changed the direction we've taken in new UI tests for both TV devices and our website. Every surprise validates our approach, and it shows us a new way to delight and retain more customers.

    This interview was edited and condensed.


    June 28 2011

    From app to meetup: A new kind of running route

    More and more online communities are forming around social apps — from foodies to readers to gamers to shoppers to just about anything else you can imagine.

    RunKeeper is taking a note from these other communities, but it's expanding the boundaries into the real world. The company recently launched meetups, which allow users to identify other RunKeeper runners in their communities and gather for group runs.

    In the interview below, RunKeeper CEO Jason Jacobs (@jjacobs22) talks about the community that developed through the app and how it's evolving from a digital concept to a physical reality.

    Disclosure: O'Reilly AlphaTech Ventures is an investor in RunKeeper.

    An interactive map of the RunKeeper communities around the world.

    How did RunKeeper evolve to include real-world meetups?

    JasonJacobsJason Jacobs: We built up a passionate user community of more than six million users in the last three years, only 30% of which are in the United States. This community has pushed for more social functionality and more in-person interaction as well. Group runs seemed like a great way to do both.

    As a test, we did a single group run a few weeks ago at RunKeeper HQ in the South End of Boston. It was a huge hit, more than 100 people showed up, and everyone had a lot of fun with it. When the opportunity came about to partner with our friends at to hold a "global group run," we loved the idea right away. The upcoming event on July 9 will be the first, but if it goes well, there will be more to come. More than 2,500 runners around the world have signed up so far in almost 1,000 cities, so we are off to a good start.

    What was involved in getting the RunKeeper meetups set up? Any lessons learned or best practices you could share for others considering something similar?

    Jason Jacobs: Well, this is only our first (out of hopefully many) and it hasn't occurred yet, but there are a few nuggets we have picked up so far. One is that the relationships people are forming online can be real and powerful, and their desire to bridge the gap between the physical and digital worlds becomes stronger as more of these online relationships proliferate.

    Also, if done right, people all over the world can feel like they are part of a larger movement, even if they don't leave their local areas. Each community is rallying to build up these meetups in their local regions, and some have even started going out and soliciting sponsors to donate free food and drink at the conclusion of the run. The local meetups are also starting to get competitive with each other about which event is bigger, and that has been a really cool thing to watch.

    Did it feel natural to bridge the app and real worlds? Is that a model you could see working for other types of affinity groups?

    Jason Jacobs: I can, yes. It isn't a one-size-fits-all model, but when there are big, global, passionate bases of people rallied behind a shared interest, it can be incredibly powerful to give those people in-person interaction opportunities to solidify their passions and also grow the base.

    We'll see how it goes, but my gut tells me that when this group run is over, the participants will be more passionate about RunKeeper and each other than they were beforehand, and that our user base will also grow in the process as more of their friends in the local communities get energized to participate.

    Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

    Save 20% on registration with the code AN11RAD


  • Personal data is the future, but does anybody care?
  • Location data could let retailers entice customers in new ways
  • The long road toward the Community Leadership Summit

  • June 23 2011

    9 digital book-making tools

    This is part of an ongoing series related to Peter Meyers' project "Breaking the Page, Saving the Reader: A Buyer & Builder's Guide to Digital Books." We'll be featuring additional material in the weeks ahead. (Note: This post originally appeared on A New Kind of Book. It's republished with permission.)

    Demibooks ComposerI'm looking forward to the free webcast I'm giving next Thursday on digital book-making tools (June 30th; sign-up info here) . There's quite a land grab happening right now, as software manufacturers — new and old — try to become the tool of choice for authors, small publishers, and illustrators. I still haven't finalized exactly which software I'll be talking about, but now seemed like a good time to share a selection of my research notes.

    Demibooks Composer

    iPad-based app gives authors a touchscreen-based development tool from which they can create an iPad app. You can do things like move objects to indicate motion paths. Ideal for kids' books with lots of illustrations. In private beta, planned release later this summer.

    My Story Book for the iPad

    Like Composer, this app lets you create kids books on the iPad itself — though with fewer interactive and motion capabilities. Includes basic tools for adding and manipulating text atop photos and illustrations. Beta launching this summer.


    Plug-in tool lets you add interactive and multimedia enhancements to InDesign or Quark layouts. Good for complex layouts featuring a mix of text and images. In limited pre-release.

    Active Reader

    Plug-in for Unity (high-powered game development program). Flowchart-like user interface lets you program interactivity and motion; especially useful for highly illustrated books like graphic novels.

    Atavist's Periodic Technology

    Authoring tool lets you add "Inline Extras" (e.g. pop-up character summaries, timelines, maps) to long-form articles that The Atavist specializes in (longer than an article, shorter than a book, they say). Export options include iOS app and stripped down Kindle files. Tool currently in private beta.


    Desktop app (Mac or Win) for creating interactive iOS and Android ebooks, especially illustration-rich kids books. Open beta starting in July according to their Twitter account.


    Desktop app (Mac or Win) lets kids book authors create iOS interactive ebooks.

    App Press

    Web-based tool for creating iOS apps. Early uses include photo histories and cookbooks. Web-based preview tool lets you share in-progress designs. Developer provides InDesign and Photoshop templates for preparing assets before importing into the App Press tool.


    Lets you use pretty much any blogging tool to publish an ebook. System accepts RSS feeds, HTML, or Markdown and outputs ePub 2.1, Mobi and PDF. Built-in e-commerce system takes care of sales for author and offers very generous royalty rates (usually about 90%).

    This is by no means an exhaustive list. I've looked at, easily, a couple dozen entrants and the ones listed above are mainly there because my notes on them are ready for sharing. My goal for the webcast is to give attendees a guided tour of the main kinds of tools out there, with a look at what feels to me like the most promising tools in each category. Hope you can join in!

    Webcast: Digital Bookmaking Tools Roundup — Pete Meyers looks at the growing number of digital book tools: what's best, what's easiest to use, and what's worth putting in your book-building toolkit.

    Join us on Thursday, June 30, 2011, at 10 am PT
    Register for this free webcast


    June 21 2011

    How is HTML 5 changing web development?

    Although still in draft form, HTML5 is seeing widespread adoption and implementation. But there's still a fair amount of pushback and skepticism about whether HTML5 is really ready for production.

    At a session at OSCON next month, Left Logic's Remy Sharp will address this. Sharp's OSCON workshop will dive into HTML5 technologies that are already in production.

    I recently asked Sharp about how HTML5 is changing development, in terms of what's developed and how. Our interview follows.

    How is HTML5 going to change web apps?

    Remy SharpRemy Sharp: We're going to see JavaScript being used to push further and further out of the old confines of the browser. We'll also see more applications that work without an Internet connection.

    The more APIs that the browser gives us, the more the idea of the browser fades away. There are APIs to access the file system and we can do drawing and photo editing and save the files to our computers. There are APIs that are just making their way in to the wild that give us access to the webcam and microphone — all natively — with JavaScript.

    We're seeing it already, but with time, I believe people won't access the web apps through the gateway of the browser. The "browser" part will be invisible and the web app will just be part of the computing experience.

    What is HTML5 going to make easier? How is it going to aid performance?

    Remy Sharp: I see HTML5 and related specs as heavily focused on the JavaScript. The HTML5 spec used to be called "Web Applications 1.0," and it shows given the amount of APIs that have been specified out of that process.

    So to me, as a web developer who spends most of his time in JavaScript, HTML5 and related specs, this make doing a lot of things easier.

    For example, adding audio and video is a doddle. Adding real-time two-way communication between the client and the server is a matter of a few lines of code and it has an extremely low barrier to entry.

    OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript's imminent colonization of server-side technology.

    Save 20% on registration with the code OS11RAD

    As for performance, I see it improving in two key places: first, the browser won't have to rely on external plugins for more advanced applications. This reduces the work the browser needs to do, and the amount of work JavaScript would have to do, if indeed the technology is baked directly in to the browser. More practically there's a number of APIs that allow data to be stored on the client side, allowing for local access to data or website assets. Removing this dependency on the server for data and assets (like images, CSS, JavaScript, etc.) increases the free resources the browser has for doing other things, like rendering the page and responding to the user.

    Second, the time required to develop will decrease since the learning is limited to HTML, CSS and JavaScript. If my company wants me to create a branded video player for their website, it's just CSS. If I want to learn how someone has built a branded video player, I just view the source.

    Developing for a multitude of browsers has long been the bane of web development. Is HTML5 going to make this simpler?

    HTML5 logoRemy Sharp: HTML5 first and foremost gives developers a consistent specification that all the browser vendors can work from. HTML4 didn't have this. In fact, some of the key technologies we rely on today were reverse engineered into specs, which is why we see subtle differences. HTML5 is specified right down to the tiniest detail, ensuring that all the browser vendors are singing from the same hymn sheet. This means that new HTML5 APIs are easier to work with, since the implementations are the same.

    As for making it easier to work with browsers: on-going that's certainly easier, but today's development and browser wrangling remains the same. That said, we're better off than we were 10 years ago. Developers' approaches to JavaScript have matured, and more developers are relying on clearly maintained libraries (jQuery, although having nothing to do with HTML5, is a perfect example of this).

    When developing an application that solves a problem using a new technology that's part of HTML5, or even not part of HTML5 — like geo-location or Web Sockets — we developers can rely on polyfills: micro-JavaScript libraries that mimic future APIs by providing fallback support to "older" browsers. This means I can write my markup to use the new HTML5 elements, and a JavaScript polyfill can trigger IE8 to allow me to style those new elements.

    Most importantly, HTML5 and related APIs provide native technology that means I, the developer, do not have to rely on Flash or some other plugin technology to solve the problem I've been faced with. I only have to learn open web technologies and I'm able to create interactive, real-time, graphics-rich web applications — should I chose to.

    This interview was edited and condensed.


    June 03 2011

    Radar's top stories: May 30-June 3, 2011

    Here's a look at the top stories published on Radar this week.

    How the Library of Congress is building the Twitter archive
    One year after Twitter donated its archives, the Library of Congress is still building the infrastructure to make the data accessible to researchers.
    10 ways to botch a mobile app
    With the aim of injecting reason and business know-how into the app development process, "App Savvy" author Ken Yarmosh outlines the top 10 reasons why apps often falter or fail.
    The story behind Velocity 2011
    As we approach the fourth Velocity conference, here's a look at how the web performance and operations communities came together, what they've done to improve the web experience, and the work that lies ahead.
    The state of speed and the quirks of mobile optimization
    Google performance evangelist and Velocity co-chair Steve Souders discusses browser competition, the differences between mobile and desktop optimization, and his hopes for the HTTP Archive.
    Open Question: Would you fund your favorite author?
    With the launch of the publishing platform, readers can fund the books they want to read. If given the chance, would you fund the next book from your favorite author?

    OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. Save 20% on registration with the code OS11RAD

    May 26 2011

    Mobile apps and the quiet handling of data

    iPhone settingsThe web was never designed to be personal. Until Netscape added cookies to its servers and browsers in 1994 there was no way for a web server to store data on a user's computer. In 1996 there was a bit of a ruckus in the media about the privacy implications of cookies, then everyone relaxed a bit and got used to them.

    Fifteen years later, the European Union has leapt into action and is now keen to enforce legislation in this area (despite a last-minute reprieve for the UK). As cookies are clearly defined and limited in scope, they make a good attack surface for legislators.

    The Internet, and mobile in particular, have moved on a bit in the last 15 years, however.

    Mobile apps, scattering data

    I would happily predict that even in 20 years there will not be a 100% reliable, always-on, cheap wireless broadband option.

    So unless you reside in Mountain View, Calif., luxuriating in virtually unlimited mobile data connectivity, I think you're going to find living 100% on the mobile web to be a pretty miserable experience.

    Conversely, it will be harder and harder to find examples of apps on mobile devices that do not benefit from connection to data networks. So, unfortunately for the legislators, the once-clear boundary between device and service continues to blur and morph.

    Software and data on iPhones and other devices are going to remain smeared across devices, the open web, and various other data services. Let's look at how this currently works.

    Unique Device Identifiers (UDIDs)

    To track a user across multiple apps you'd need some way of putting a unique tag on each device so that no matter which app read it, you'd know you had the same person.

    This is precisely what the Unique Device Identifier (UDID) number on iOS devices can do. It's easily available to the writer of an app, and it cannot practically be changed or deleted.

    These UDIDs allow developers to link data collected by different apps. (Interestingly, as the UDID acronym gets bandied about it will probably become irrationally feared.) Apple forbids the sharing of this data between companies, but within a company there is no effective means of preventing this.

    The Shared Keychain in iOS allows apps published by a single developer to share data if they find themselves installed on the same iOS device — no network required.

    Here's a theoretical example of how this might apply to apps from an insurance company:

    • You provide your date of birth to a motor insurance app to get a quick quote.
    • A year later you download a pension calculator app from a different division of the same company.
    • The pension app already knows your age, so it can get straight down to convincing you to buy savings products.

    Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

    Save 20% on registration with the code AN11RAD

    Data access to the Internet, with local storage on the device

    The elephant in the room when talking about data protection is the fact that any app can silently connect to the Internet and send and receive data to its heart's content.

    Developers are encouraged to show a spinner to indicate that the network is being accessed, but this is a guideline rather than an enforced requirement. This is not all about tracking users, of course. These capabilities allow things like remote throttling of app usage, enabling of new features, binding of sponsor data to parts of the app, updating media in the app, syncing with other services, etc. As there is no clear way to identify personal or tracking data within the app's local storage, any focused privacy legislation will be tricky.

    The bottom line is that your iPhone apps are increasingly likely to be using a full set of web services without you ever setting up accounts, accepting terms and conditions, logging in or even being aware of it.

    Apple Push Notification Service (APNS)

    One of my personal favorites in terms of potential unexpected consequences is the Apple Push Notification Service (APNS), which allows developers to remotely pop up messages on iOS devices, or add badges with numbers to the icons of their apps.

    Angry Birds notificationsThat's all relatively straightforward, but there is also the ability to make the iPhone play any audio file included in your app, whether the app is open at the time or not. Check the push permissions for "Angry Birds" for an example (Settings > Notifications).

    When you installed "Angry Birds," Rovio explicitly asked for your permission to play sounds from Angry Birds on your phone whenever they like.

    As an aside — If you're looking for true Internet notoriety, then gaining control of Rovio's servers would allow you to remotely command all iOS devices with Angry Birds installed to "tweet" (audibly, not via Twitter) in unison.

    Data handling on PCs vs. data handling on mobile apps

    Given all that's happening right now, how are we doing on transparency and consent? Let's compare some of the warnings and alerts you might get from three different use cases:

    Case 1: Installing software on your PC that uses data on the Internet

    • Warning: this software was downloaded from the Internet
    • Please enter your administrator password to install
    • Antivirus warning: new software identified
    • Firewall warning: Unauthorized software trying to connect to the Internet

    And when you run your new PC-based software:

    • Please provide your email to register your account
    • Please set a password
    • Click the confirm link in the email we've sent you to authorize your account
    • Accept the terms and conditions

    Case 2: Accessing a website through a PC

    • Please install Flash plugin / authorize Java applet / install Silverlight
    • Register or log in
    • Provide email address / password
    • Click link in registration confirmation email
    • Can I set a cookie on your PC? (Thank you, EU)
    • Please accept the terms and conditions

    Case 3: Installing an Internet-enabled app on your iPhone

    • Tap to install app
    • Errr...
    • That's it

    Some final thoughts

    The comparison between PC-based software and smartphone software shown above is stark, with many implications. There's a lot to work out, and there's a lot to debate. With that in mind, here's a few discussion points I think are worth exploring:

    • The "app way" of working could be great for business, but it only works if you trust the app delivery platform and the app developer. Organizations create and destroy trust in many ways, and we might benefit from a more explicit review of or focus on this.
    • Developers could be more open about what they are doing, but explaining technical issues in plain English can be tough. Frankly, most users aren't that interested, either.
    • New laws to control use of cookies are focusing on what legislators can see and understand. Legislation will always trail technology, leading to more "privacy theater."
    • Broader technology legislation that relies on applying judgement and intelligent interpretation may succeed more than narrow, knee-jerk legislation and zero tolerance.
    • The iPad brings the smartphone approach closer to the standard PC. Expect Mac OS X Lion to bring it all the way.
    • Just because it fits in your pocket, doesn't make it private.


    May 20 2011

    Publishing News: BAFTA nomination hints at app crossover appeal

    Here are a few highlights from the publishing world. (Note: These stories were published here on Radar throughout the week.)

    An app is up for a TV BAFTA for the first time

    MalcomTucker.pngFor the first time ever, an app has been nominated for a TV British Academy of Film and Television Arts (BAFTA) award. The Malcolm Tucker: The Missing Phone app, which has a story line based on a character of a popular BBC series called "The Thick of It" and a subsequent book "The Thick of It: The Missing DoSAC Files," was launched in December. In a post for The Bookseller, Charlotte Williams talked to Henry Volans (@FaberDigital), head of the digital arm of UK publisher Faber & Faber and part of the team responsible for the app. In the interview, Volans responded to the nomination:

    It's really thrilling. When we made this app we wanted to do more than translate a book to an app, but made something that made sense of the platform and I think this nomination shows we've gone some way to doing that.

    I reached out to Volans via an email interview to find out more about the app and the nomination. (The BAFTA awards will be announced May 22.) Our interview follows.

    How did the app get started?

    Henry Volans: It started with a question that's quite common but to which the answer is usually "no." We looked at the book and said "can we make an app from this?" Because the material is so rich, and I had the freedom at Faber Digital to develop something new — and on a schedule independent of the book — it got off the ground quickly. The project also worked because we went straight back to the creative team — Armando Iannucci and his four co-writers — rather than shoehorn the book into an app template.

    • This story continues here

    Kindle book sales officially outpace print — are we at the ebook tipping point?

    questionmarkIn a news release today, Amazon announced that Kindle book sales are outpacing sales of hardcover and paperback book sales combined. The release included several interesting statistics:

    • Since April 1, for every 100 print books has sold, it has sold 105 Kindle books. This includes sales of hardcover and paperback books by Amazon where there is no Kindle edition. Free Kindle books are excluded and if included would make the number even higher.
    • Amazon sold more than 3x as many Kindle books so far in 2011 as it did during the same period in 2010.
    • Less than one year after introducing the UK Kindle Store, is now selling more Kindle books than hardcover books, even as hardcover sales continue to grow. Since April 1, customers are purchasing Kindle books over hardcover books at a rate of more than 2 to 1.

    These stats beg the question: Are we at the ebook tipping point?

    • Please share your thoughts in the comments here

    How to revolutionize the Kindle

    KindleAmazon is well positioned to advance the Kindle platform much faster and further than they have in any 6-12 month period up to now. Here's where I hope they end up between now and the middle of next year:

    An insanely inexpensive entry-level device. Picture the current Kindle, but for $99 or less. How about $49? Better yet, how about free with a customer commitment to buy a minimum of X books in each of the next two years? Sounds a lot like a cell phone plan, doesn't it?

    Of course, if you're instead looking for something a bit more powerful and extendable, how about...

    An Android tablet device with an LCD screen. This one is the worst kept secrets since the iPhone 4. Amazon didn't launch that Appstore for Android because they want to push more cell phone sales. The only questions here are (1) when?, (2) how much?, and (3) how open? If they're smart the answers will be (1) any day, (2) $300 max, and (3) wide open.

    But if you can't stand the thought of reading long-form content on an LCD screen, then how about...

    That same Android tablet with a hybrid E Ink/LCD screen. That's right. A single device offering both the bright-light comfort of E Ink with the backlit option of LCD. Unfortunately for Amazon, it seems Apple is the one who's taking the lead on this front. Just search for the phrase "hybrid E Ink LCD display" and you get nothing but Apple news. That's a bummer since the first company to offer this solution could own the high end (and my loyalty). A fully open Android tablet with hybrid E Ink/LCD could easily command a $500 price or higher.

    • This story continues here.

    Got news?

    Suggestions are always welcome, so feel free to send along your news scoops and ideas.

    Keep up with Radar's latest publishing news and interviews with our publishing RSS feed.


    Kindle 2012: Wish-list features for the next model

    This post originally appeared on Joe Wikert's Publishing 2020 Blog ("What Will the Kindle Platform Look Like in 2012?"). It's republished with permission.

    KindleAmazon is well positioned to advance the Kindle platform much faster and further than they have in any 6-12 month period up to now. Here's where I hope they end up between now and the middle of next year:

    An insanely inexpensive entry-level device. Picture the current Kindle, but for $99 or less. How about $49? Better yet, how about free with a customer commitment to buy a minimum of X books in each of the next two years? Sounds a lot like a cell phone plan, doesn't it?

    Of course, if you're instead looking for something a bit more powerful and extendable, how about...

    An Android tablet device with an LCD screen. This one is the worst kept secrets since the iPhone 4. Amazon didn't launch that Appstore for Android because they want to push more cell phone sales. The only questions here are (1) when?, (2) how much?, and (3) how open? If they're smart the answers will be (1) any day, (2) $300 max, and (3) wide open.

    But if you can't stand the thought of reading long-form content on an LCD screen, then how about...

    That same Android tablet with a hybrid E Ink/LCD screen. That's right. A single device offering both the bright-light comfort of E Ink with the backlit option of LCD. Unfortunately for Amazon, it seems Apple is the one who's taking the lead on this front. Just search for the phrase "hybrid E Ink LCD display" and you get nothing but Apple news. That's a bummer since the first company to offer this solution could own the high end (and my loyalty). A fully open Android tablet with hybrid E Ink/LCD could easily command a $500 price or higher.

    Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

    Save 20% on registration with the code AN11RAD

    That's all great for the hardware side, but what about the rest of the platform? Will Amazon really stick with the proprietary AZW file format that's based on mobi, even as the rest of the world embraces EPUB? For backwards compatibility reasons they probably have to stick with mobi. What a shame though. EPUB is where the action is and EPUB3 adds a great deal of functionality to enable much richer content than the Kindle supports.

    Expanding into a tablet with LCD display means the Kindle will no longer be hamstrung by the limits of E Ink. What a terrific opportunity Amazon has to offer (and encourage the development of) richer content than just words on the screen. But will they? I've been critical of the glacial pace at which Amazon implements Kindle enhancements, but I hope they take advantage of this opportunity early on.

    Regarding formats and flexibility, I'd love to see Amazon support mobi and EPUB. Better yet, if they have the confidence to provide an open device, how about letting it run any reader app from the competition? Let me put the Nook app on my Kindle device and may the best content provider win. Now that would be a bold move! After all, if I could own an Amazon device that lets me buy content from any store, why woud I ever consider buying a device from anyone else?


    May 19 2011

    The next, next big thing

    In my old age, at least for the computing industry, I'm getting more irritated by smart young things that preach today's big thing, or tomorrow's next big thing, as the best and only solution to my computing problems.

    Those that fail to learn from history are doomed to repeat it, and the smart young things need to pay more attention. Because the trends underlying today's computing should be evident to anyone with a sufficiently good grasp of computing history.

    Depending on the state of technology, the computer industry oscillates between thin- and thick-client architectures. Either the bulk of our compute power and storage is hidden away in racks of (sometimes distant) servers, or alternatively, into a mass of distributed systems closer to home. This year's reinvention of the mainframe is called cloud computing. While I'm a big supporter of cloud architectures, at least at the moment, I'll be interested to see those preaching it as a last and final solution of all our problems proved wrong, yet again, when computing power catches up to demand once more and you can fit today's data center inside a box not much bigger than a cell phone.

    Thinking that just couldn't happen? You should think again, because it already has. The iPad 2 beats most super computers from the early '90s in raw compute power, and it would have been on the world-wide top 500 list of super computers well into 1994. There isn't any reason to suspect that, at least for now, that sort of trend isn't going to continue.

    OSCON Data 2011, being held July 25-27 in Portland, Ore., is a gathering for developers who are hands-on, doing the systems work and evolving architectures and tools to manage data. (This event is co-located with OSCON.)

    Save 20% on registration with the code OS11RAD

    Yesterday's next big thing

    Yesterday's "next big thing" was the World Wide Web. I still vividly remember standing in a draughty computing lab, almost 20 years ago now, looking over the shoulder of someone who had just downloaded first public build of NCSA Mosaic via some torturous method. I shook my head and said "It'll never catch on, why would you want images?" That shows what I know. Although to be fair, I was a lot younger back then. I was failing to grasp history because I was neither well read enough, nor old enough, to have seen it all before. And since I still don't claim to be either well read or old enough this time around, perhaps you should take everything I'm saying with a pinch of salt. That's the thing with the next big thing: it's always open to interpretation.

    The next big thing?

    The machines we grew up with are yesterday's news. They're quickly being replaced by consumption devices, with most of the rest of day-to-day computing moving into the environment and becoming embedded into people's lives. This will happen almost certainly without people noticing.

    While it's pretty obvious that mobile is the current "next" big thing, it's arguable whether mobile itself has already peaked. The sleek lines of the iPhone in your pocket are already almost as dated as the beige tower that used to sit next to the CRT on your desk.

    Technology has not quite caught up to the overall vision and neither have we — we've been trying to reinvent the desktop computer in a smaller form factor. That's why the mobile platforms we see today are just stepping stones.

    Most people just want gadgets that work, and that do the things they want them to do. People never really wanted computers. They wanted what computers could do for them. The general purpose machines we think of today as "computers" will naturally dissipate out into the environment as our technology gets better.

    The next, next big thing

    To those preaching cloud computing and web applications as the next big thing: they've already had their day and the web as we know it is a dead man walking. Looking at the job board at O'Reilly's Strata conference earlier in the year, the next big thing is obvious. It's data. Heck, it's not even the next big thing anymore. It's pulling into the station, and to data scientists, the web and its architecture is just a commodity. Bought and sold in bulk.

    Strata job board
    The overflowing job board at February's Strata conference.

    As for the next, next big thing? Ubiquitous computing is the thing after the next big thing, and almost inevitably the thirst for more data will drive it. But then eventually, inevitably, the data will become secondary — a commodity. Yesterday's hot job was a developer, today with the arrival of Big Data it has become a mathematician. Tomorrow it could well be a hardware hacker.

    Count on it. History goes in cycles and only the names change.


    Reposted bydatenwolf datenwolf

    May 04 2011

    Skimming on the digital side

    This is part of an ongoing series related to Peter Meyers' project "Breaking the Page, Saving the Reader: A Buyer & Builder's Guide to Digital Books." We'll be featuring additional material in the weeks ahead. (Note: This post originally appeared on A New Kind of Book. It's republished with permission.)

    The iPad and other touchscreen devices seem perfect for replicating the page flip. After all, one of the first gestures users "get" is the swipe: it's intuitive, it's quick, it's fun. And despite the power packed into today's tablets, virtual page flipping isn't as useful as its print counterpart. For starters, paging speed is noticeably slower than what you get with a wet pointer finger and the latest issue of, say, People.

    A bigger problem lies with a common digital publishing culprit: trying to faithfully replicate all the "features" of print. A regular magazine has pages, the thinking goes, so by golly we're gonna reproduce pages in the digital edition. Lotsa problems with that approach, but for this post let's tackle the "filmstrip"-style page-browser found in many e-magazines. Consider Fortune's, for example:

    Fortune's Page Viewer icons
    The "Page Viewer" icons are too small to deliver useful info

    What the average eye can easily decipher in each of these thumbnails is close to, approximately, zero. And once you decide you don't want to read, say, the article about Twitter, why the heck do you have to page through each of the article's other unhelpful icons? The system, in other words, replicates the act of browsing without delivering its essential benefit. You get none of the come-hither signals that are easy to spot on a print page: headlines, pull quotes, pictures, sidebars, and so on.

    App designers, my suggestion: don't throw the browser out with the bath water. Instead, a little redesign can satisfy the reader's desire to skim quickly and dive in when something looks worthwhile. A few suggestions:

    One icon per article is sufficient

    Print-based page flipping is how we readers solve what is, at heart, an information architecture problem: most magazines order their contents in a way that doesn't match our preferred reading path. So we flip to find the juiciest, most satisfying bits. In an app, then, swiping through page icons isn't the best way to aid that quest.

    How about, instead, article representations—let's call ‘em blurbs—that quickly convey what the piece is about? Something, in other words, like what you get in a table of contents (e.g. title + quick summary). Wired, for example, uses a horizontally-scrolling system:

    Wired's horizontally scrolling TOC
    Wired magazine's horizontally scrolling TOC is pretty useful

    A useful blurb at the top of the screen lets you know what the article or ad is about. And the size of the replica that hangs below the blurb signals the length of what you're in for. Nice.

    Similar options exist, many of which don't require the creation of new material. How about, for example, bundling up and making swipeable each article's nut graf and a great pullquote? Or the article's best art (an image, say) with the title super-imposed using compelling typography? (The Bold Italic magazine, a current events guide to San Francisco, sorta/kinda does this in their app.) Or even simply reproducing the article's title page with the headline's font bumped up for easier viewing.

    No need to replicate the trim size of the printed page

    The current approach in most page browsers is to offer up page miniatures that replicate the aspect ratio of the print magazine's dimensions. Why? Probably because designers wish to replicate the experience of reading the print edition. (Not to mention the fact that thumbnails are easy to generate.) But the essential service readers are looking for has nothing to do with trim size; it's about quickly scanning big chunks of info and deciding where to spend our reading time.

    That purpose can be better served by making the scannable units large enough to deliver meaningful info. So bump up the thumbnail to, say, a rectangle and give that headline it contains more room to breathe; you can even, then, include an image. Even better: have the blurb container's size reflect the importance of the article within the magazine. A jumbo rectangle, for example, could be used to showcase an important feature while a smaller square would indicate a shorter piece. Here's a quick example:

    multi-shaped article example
    Click to enlarge.

    Expand and reveal

    Apple has added a neat-o feature to its iPad Photos app. You've probably seen it: you spread your fingers over any photo stack icon to temporarily reveal the other pictures beneath it. If you did the same for each browsable icon representing an article, you'd give article browsers a chance to peek at individual pages before committing. Another option: let users control the size of the page-browsing icons. Popular Mechanics uses this approach.

    Popular Mechanics' sizing handle
    The sizing handle on the right lets readers adjust the page icons' size (click to enlarge).

    See those little icon-size controls (the four stacked lines on the right side of the page browser)? You can drag them up or down to change the size from jumbo to skinny mini.

    Got any examples you like of digital page-browsing solutions? Let me know (peter.meyers AT gmail DOT com) and I'll add them right here.


    March 30 2011

    On a small screen, user experience is everything

    gmail_mobileScreenshot.pngUntil someone comes up with a way to mind meld with mobile devices, the size limitations will largely define the overall experience. That's why a focus on interaction — not just look and feel — is an important part of any mobile project.

    In a recent interview, Madhava Enros, mobile user experience lead at Mozilla and a speaker at the Web 2.0 Expo 2011 in San Francisco, discussed three mobile applications that he believes handle user experience quite well.

    One that is very dear to my heart — at Mozilla we're really into the whole open web app concept using web technologies — is the Gmail web app for the iPhone. It's arguably a better mail client than the native one on the iPhone, and they're using a lot of really cool open web technologies to do it.

    Another that I really like is the Kindle. I love the hardware itself, but Amazon really seems to have understood that mobile usage is about a constellation of devices. It's not just about the one phone you have. It's being able to read at home on your ereader, but then read on your Android phone when you're on the train, or pick up your iPad when you're elsewhere. That kind of consistency of getting at your stuff across a bunch of devices is a really great insight.

    And there's Flipboard, where they understand how people are using some of these emerging technologies, like Twitter, as a protocol more than a service. It's the insight that people aren't using Twitter as an email replacement — though some people are — but as a way of reading a newspaper.

    Where 2.0: 2011, being held April 19-21 in Santa Clara, Calif., will explore the intersection of location technologies and trends in software development, business strategies, and marketing.

    Save 25% on registration with the code WHR11RAD

    Enros also talked about the trend toward voice activation technology. While typing on mobile devices likely won't prevail in the long term — he said no mobile device does it really well and he described the spectrum as "OK to terrible" — he also doesn't think talking to devices will be the default:

    You just have to watch that person on the bus who's yelling into their cell phone to know that talking to a device is not always the answer. Sometimes you need a little bit — or should have a little bit — of privacy.

    For more of Enros' thoughts on mobile design and interaction, check out the full interview in the following video:


    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.
    No Soup for you

    Don't be the product, buy the product!

    YES, I want to SOUP ●UP for ...