Thanks NOOK!


Today I resigned from B&N NOOK Apps to embark on a new journey in my career. Before I talk about the next destination, I wanted to talk openly about my time at NOOK Apps and say thanks to those who made it great.

NOOK Apps was an amazing journey and will always be a highlight of my career. The opportunity to build a marketplace for applications atop a new class of content centric device was big, complex, and a ton of fun. I joined a small team and we built out all the required elements to succeed from scratch in 5 months.  We launched NOOK Apps with 136 apps within an operating system update to NOOK Color. We went from 0 to millions of app installs per month and worked non-stop to make the platform better for all developers building applications. Over the past year we have helped thousands of app developers monetize great content on a new platform in a new market.

The best part of working on NOOK Apps was the team. I have worked with great teams before but never quite as good as the team on NOOK Apps. Every role was filled with a person with vast experience in the mobile space and together we made NOOK Apps a success.

Claudia, Simon, Tavares, Steven, Josh, Gideon, Cary, Titus, Eric, Ron…

Thanks, You made my time at NOOK great and we accomplished allot working together as a team.

As for next steps for me…  I will save that for tomorrow.

GO NOOK GO!

Thanks for all the fish!

Ted :)

Living in the Future


What if you received a copy of the Wall Street Journal dated November 12, 2015, today?

What if you knew what the future would be like 5 years from today, and better, how things would play out?

Where would you invest?

What problems would you solve?

What would you start to build?

For the past decade, developers within the Flash ecosystem have been living in the future building upon a stable consistant runtime with great tooling and advanced text/graphics/animation/vectors/video APIS for building interactive applications. As an ecosystem, Flash enabled amazing things, impossible things, fantastic things with a technology with very humble beginnings centered on vector graphics. I spent the last 12 years working with Flash professionally and evolving with the medium over that time has been an honor and highlight of my career.

A few years back browsers began innovating and that innovation is beginning to fix many of the inconsistencies and capabilities once only privy to Flash. While still in their infancy around rich media, browsers and standards based platforms will evolve along a similar path to the Flash ecosystem’s evolution over the last decade. The same problems, patterns, solution, services, tools, tips, tricks, and know-how will be required to make this standards based ecosystem as vibrant as Flash is today. The fact is that knowing Flash is far more than just knowing ActionScript or a raw Adobe tool, it is the knowledge of how to build rich interactive content. Much of our knowledge domain is not in implementation details but rather understanding the nature of interactive media, architecting a proven interactive solution, and balancing usability, design, and interactivity to create a great experience. In short, you have a massive upper hand in an emerging market called HTML5 and Adobe is shifting resources and investing there too.

Exploring OpenGLES – A break from Flash

For the past 8 months, I have been personally exploring and investing in tools and technologies that are focused on leveraging fast graphics and hardware acceleration using OpenGLES. As I work for Barnes and Noble on the NOOK Platform, I wanted to figure out how best to deliver fast graphics within native apps on NOOK with a lower end hardware profile (800Mhz 256Mb OpenGLES 1.1 & 2.0). Given that Flash/AIR does not directly support an OpenGL-like surface today on Android, I explored several alternatives that included CoronaSDK, Moai, Marmalade, but have settled on using the native Android SDK with ANDEngine. The output results on NOOK Color are 60fps regardless of the volume of graphics and textures I throw at the displaylist. Physics, fast vm, great java tooling, it is a real treat to develop interactive content this way! This exploration was hugely enlightening for me and has made me realize that even when I completely switch stacks my interactive skills I perfected with Flash are extremely relavant. Even the easing equations were a java port from Robert Penner’s work.

Truth is, things have changed but the foundational knowledge of interactive development will remain with us all long term regardless of what platform you target. Should you choose to focus on native or open web apps, you have a great advantage, once upon a time you lived in the future called Flash.

Cheers,

Ted :)

PS. Adobe please improve the performance of AIR on Android.

Perspective Matters


This past week I got very frustrated at a process at work. Initially I thought, surely this is broken. How could something this simple be architected this way. So I decided to understand and I dug deeper. After about 2 days of digging I found some dependencies that forced the very solution that I was complaining about. Had I been in the shoes of the creator, I would have been forced down the same path.

From the outside, problems can look trivial but inside, there is often far more at work.

As technologists we are ready to declare something stupid, silly, wrong at first glance and at times say, “I could do that better”. Behind any problem is a larger more hidden set of dependencies and problems. Problem is that often dependencies are invisible and the larger problems are hard to see unless you went though the hard lesson of actually building something under the same circumstance. It is easy to judge but solving real problems is often dramatically harder than it looks.

Perspective Matters.

cheers,

Ted :)

Live Wallpaper?


About 2 months ago I started to explore building apps to allow end users to decorate their NOOK Color device (desktop and lock screens) with licensed art/images. The exploration lead me to a simple idea of packaging collections of images within a Live Wallpaper and making then interactive on the desktop, yes wallpaper???

Given that NOOK Color has a majority female market demographic, I thought that decoration and customization would be a clear winner within NOOK Apps. Also given that end users tend to be a-technical, packaging as a Live Wallpaper meant simplifying adding them via Wallpaper Manager and making them easy to use. Ideally I wanted to avoid any type of “settings” within the apps and have all interactions occur on the desktop. My expectations were that I would most likely break even against licensing of images and open up the market for wallpapers on the device. Little did I know…

With licensed images in hand, Android SDK, and configured Eclipse, I went about coding up a simple interactive live wallpaper for image viewing. The codebase started very simple and I build in image automation using ANT and ImageMagick. I used Adobe Fireworks for master image manipulation and cropping and added support for opening the Wallpaper Manager via API (Android Intent) and deep linking into NOOK Shop via API (Android Intent) for cross-promotion. By the end of the weekend I had built 3 live wallpapers. Here is what they look like:

Yes, Beaches, Cupcakes, Paris! :)

I setup my nookdeveloper.com account and entered in all my banking info, and added all 3 apps for meta-data approval. Working with my wife Linda we decided to brand everything Abbey’s Wallpaper given the demographic and marketing fit. When the apps were approved I uploaded the final APKS, final icons, and screenshots and waited til the apps were approved and published. Once published to Shop we began to get some eye turning reports…

  1. June 17 – Fri – $412  – Interesting..
  2. June 18 – Sat – $722  – Almost double day 1. All right!
  3. June 19 – Sun – $746  – WOW Wait is this a mistake?

After the first weekend of sales we were break even on costs of 30 licensed images and selling the collections at $0.99 each was doing very well with end users.

June Sales:

July Sales:

August Sales:

Today total revenue sits at $19,630.43 against costs of $6800 plus 40+ hours of my time, for a profit of $12,830.

I never anticipated that on weekends I would find myself packaging Live Wallaper nor did I ever expect to see a market for wallpaper exist on NOOK. I had doubt that I would break even and the results today seem amazing to me given I work for Barnes & Noble on the NOOK Apps team. In doing research against my success, apps and games are yielding 10x results to what I have been seeing with wallpapers. The customers attached to NOOK Color have no hesitation to purchase interactive content, they are the same customers that have been purchasing content from Barnes & Noble for years and as they say… habits die hard. Given that apps tend to do far better overall, I am refocused on providing apps and games onto NOOK Apps but will continue to push in wallpapers via automation from time to time. Obviously one can dismiss this as a small success but the proof is that there is a real market of consumers attached to NOOK Color and they do not hesitate to purchase digital content. Even things as simple as wallpapers sell well provided the content is of quality. All told with about 40 hours of weekend work, it has yielded a small side business for me and my family and I have learned a ton about the market attached to NOOK.

To get started building apps for NOOK Apps… Visit NOOKDEVELOPER.COM

Cheers,

Ted :)

A-technical World!


Since joining Barnes & Noble I have been trying to better understand our core customer demographic for NOOK and the target user for mobile apps. This exploration has really changed my perspective on consumer software and what end users actually want, love, and most importantly expect. It has been an unexpected and eye opening experience yet it highlighted a truth that I seemed to know was true all along.

The world is by large majority a-technical!

When I write software I automatically bring a technical bias to problem solving, interaction, and UI. I make assumptions about my target user and this is where I fail. I assume they can install software, complete forms, gestures, can use the back button, understand the mouse, right-click, know something is draggable, know how to use a drop-down, etc… all the basics apply here. At issue is that each of these skills, reduces the overall addressable market for my app. The more I assume, the smaller my potential user base for my app. Designing apps for a-technical users really means starting fresh with a simple foundation of assumptions about the user.

I have found that there are 4 great techniques for addressing the a-technical users:

Write down your assumptions. Writing down assumptions lets you see the skills you are asking a user to perform. It provides an inventory of skills from which you can add new features without alienating users. Even the simplest of assumptions apply.

Teach - Ever notice how good games teach end users how to play progressively? Typically to broaden the market for a game, developers will have several levels that are essentially tutorials. How to shoot… How to throw a bird… How to use the camera. Great apps teach end users how to use the app progressively.

KISS – Keep It Simple Stupid - The other approach which has gotten every popular lately is to strip away features down to the core. Sometimes the best app does just one thing and does it very very well. The focus on simplicity removes user confusion and lets users take full advantage.

Prototype - Looking at UI allows you to quickly assess the complexity. It also makes implementation far easier especially with great tools like Balsamic Mockups. One trick I have found that is helpful is to ask an a-technical user to explain a UI back to me. You will be shocked at the responce you get in using even the simplest UI elements.

What gets really interesting is that most users on NOOK have no idea it is Android. They just expect an app to work when the icon is pressed. Users just want apps that are easy to use, provide value, and are fun. If you are interested in building apps for NOOK, you can sign up here: http://nookdeveloper.com

Cheers,

Ted :)

Corona SDK, a short stack


One of the elements that I most like about Corona SDK is that it is built atop a short but solid stack. Here are the elements:

Corona SDK Parts:

  • Lua 5.1 Interpreter – 110Kb interpreter
  • OpenGL ES 1.1 and 2.0 – The graphics hardware acceleration standard
  • Native Libraries – Injected at compilation depending on the platform
  • Not a ounce more!!!

The Lua 5.1 interpreter is written in C and is thus highly portable. It has been widely adopted within the gaming industry given it’s tiny footprint. The entire interpreter + vm + systemlibs + gc + coroutines + data types are implemented in ~110Kb and there are extremely few platforms where Lua doesn’t run today.  Given the footprint, it is easy to embed the entire interpreter within an application where the result with graphics and logic outputs a file 300Kb at the low end. As the entire vm is embedded within your application, you are only a compile away from adding in the latest features. Lua also brings in 10+ years of portable libraries to choose from LuaRocks, Lua-users Samples, and if you are really interested full source for the VM is openly available.

One of the big mental hurdles to get past with Lua is that interpreted does not mean slow. Here is a good set of benchmarks to look at. Lua is well within the required range of performance for interactive development. I would suggest spending all of 5 minutes looking into Lua performance and then forget about it. Lua 5.1 within Corona SDK is fast enough for any mobile application and hardware will only improve things moving forward.

OpenGL ES 1.1 and 2.0 standards allow you to get the most from your application graphically due to wide GPU hardware support. I have yet to see any smartphone not implement either of these two standards in GPU hardware for the past year. With a GPU accelerated graphics you can push a ton of pixels at the screen before you see any sort of performance bottlenecks. Android 2.1+ and IOS 2+ have great implementations of these APIs and having Corona SDK standing atop them just means your app has all the graphics and video capability needed moving forward.

The Lua interpreter provides a means to integrate native API calls into the language easily. Depending on which OS you target different APIs are includes within your application at compilation time. This allows Corona SDK to expose native API’s to your application. Things like Native dialogs, graphics, fonts, audio, Box2D, In-App-Purchase, Camera, Webview, Accelerometer are all integrated into Corona with a simple API in Lua methods. This makes Corona very extensible as a platform allowing the core teams to integrate desired features in quickly. Since I have been working with Corona SDK the evolution of the platform has been very fast paced and the teams have gone to great lengths to let the community drive the platform forward, see roadmap.

Given that most applications using Corona SDK are 300Kb+, the productivity gains and cross-platform portability really hit a sweet spot for me. It is about as close to native development without the platform lockin, size limitations, vm dependencies, and performance limitations that plague other platforms for device development. If Corona were to add just two more platforms besides IOS/Android, say BlackBerry Neutrino(QNX) and Win Phone 7, I really think this platform becomes the next Flash for native device development almost overnight. Regardless of what it becomes, I am using Corona SDK on a daily basis for a large majority of my device development work.

Take an open look at Corona SDK, I am pretty sure you will like what you find.

Cheers,

Ted :)

Trees of Objects & Meta


Tree data structures provide the foundation for most interactive systems. In most cases one can take an existing app, class, or collection of objects and represent it with a tree structure. HTML, XML, JSON, DOM, Flash displayList, file systems, and programming languages are all hierarchical in nature.

I have been interested in serializing & deserializing tree based systems for a long time and feel like there is a gap in terms of file formats. Tag based formats (XML/HTML) tend to be fragile given closing tags and are generally hard to read and edit accurately without tools. Minimalistic formats like JSON and YAML lack type metadata and can be confusing to read and edit as well. Also parsers for these formats tend to lean towards generating a complete object hierarchy as a result vs emitting stream of events allowing a single pass of object generation.

Long story short, I haven’t found somethings that fits well and decided to build one. I settled on calling the format “Meta”. Here is the base definition:

Meta – A simple readable ASCII based format for typed tree serialization & deserialization.

The driving use case for Meta was storing levels of a game where you would simply clear the display list and generate objects representing a level of the game. The key was having an event based parser that allowed for type generation on a line by line basis. I tested this in JavaScript, ActionScript, Lua, and Python and in every case it was trivial to generate typed objects from a single .meta file. This is when I started to think about this as a file format and generally how the project came to mind.

Basics:

//comment
<NAME>:<TYPE>=<VALUE>
<NAME>:<TYPE>
	<NAME>:<TYPE>=<VALUE>
	<NAME>:<TYPE>
		<NAME>:<TYPE>=<VALUE>

Rules:

  • <NAME>,<TYPE>,<VALUE> are strings using any non-whitespace char, must quote if “:” or “=” is used.
  • Indention denotes object heirarchy
  • Types follows the colon “:” similar to type declarations in ActionScript 3
  • Values follows the “=” and vary in syntax to the type used.

Examples:

s1:String = "Hello"
n1:Number = 1234
b1:Boolean = true
//comment
innerobj:Object
	src = logo.png
	x : Number = 0
	y : Number = 0
	isFullResolution : Boolean = true
	rotation : Number = -30
	alpha : Number = 0.5
c1 : Color = #FF00FF55
an1 : Array = [1,2,3,4,5,6,7]
obj0:Object
	1:Number = 1
	2 = 2
	3 = 0
	4: Boolean = true
obj1:Object
	src = "logo.png"
	//comment
	x : Number = 0
	y : Number = 0
	isFullResolution : Boolean = true
	rotation : Number = -30
	innerObj:Object
		src = "logo.png"
		x : Number = 0
		y : Number = 0
		isFullResolution : Boolean = true
		rotation : Number = -30
		alpha : Number = 0.5

One thing I really like about the format is that it is streamable in that parsing of the file can start as soon as downloading begins, all you need is a complete line regardless of hierarchy. This makes it very useful for data exchange as sometimes it is handy to stream data(large array collections or ui) to a client. Within the game usage the format sets up large object trees of box2b enabled displayobjects (think of a level in Angry Birds…). Combined with a class that manages object creation/destruction/recycling and it gets really scalable. I especially like the readability aspect, just glancing at the file you can see the object tree and all you need is a text editor. Within the game engine I implemented Library and Reference types to allow for reuse of generated objects within downstream objects and properties. This sort of mapping made wiring up function handlers and material types far easier.

Obviously Meta is far from complete but I have found it very useful thus far. As soon as I apply a bit more polish to the codebase I will post the Lua and ActionScript classes for parsing and serialization.

Thoughts and comments always welcome.

Cheers,

Ted :)