Our Shipping Container from LEED Cabins, in Place, with the Completed Porch and Privacy Fence

My wife and I have now been living tiny for several months. For those who don’t know, tiny homes (living units under roughly 200sq’) have become increasingly popular in the past couple of years. When we researched many options for different types of tiny homes, we found a lot of information -- but very few first-person accounts of the experience.

And, after all, that’s what tiny living actually involves -- a fundamental shift in thinking about consumption and space utilization -- the rest (what type of tiny home, whether its mobile, how its built, etc) is all just details.

Given the increasing popularity of tiny homes, I thought it might be valuable to someone out there considering the same, for me to share some of my thoughts on what this experience has been like for us.

In our case, this isn’t a tiny home, so much as a my home-office. But we decided to place this small office structure on the land first, before building our home. Our land is 30 miles away from the nearest town (where 'town' is quite loosely defined; we're literally 20 miles away from the nearest service at all, which is our post office), which makes development quite challenging. So we started small, so we could establish a base of operations without too much trouble (that it took us a year to even get this far, is an entirely separate story).

We invested a good deal of effort in learning about the various options for tiny housing (you’ll be amazed at the variety that’s available). We purchased Jay Shafer’s book on Small Homes, and even went so far as to get the plans for his tiny Tumbleweed Popomo, before we decided to go with a pre-fab option to simplify our initial move.

Our Solution

The Semi-Raw Container

After considering our goals, we opted for a tiny structure built from a used cargo shipping container. The benefits of a shipping container, in the context of the remote Oregon forest, include that it is rust-proof, water-proof, highly wind-resistant, bear-proof, fire-proof, and resistant to damage from downed trees -- all of which promised to make our initial setup easier, and expedite the process of building our full home.

We located a firm named LEED Cabins, and Dan Sokol created a pre-fab office structure for us, converted from a 20’ used cargo shipping container. We had it shipped up to our land, placed into position, and secured by high-tension cable to concrete blocks in the ground (laid during the excavation of our driveway and homesite).

The Container Being Delivered to Site

This structure is 160sq’ total, with about 135sq’ of internal usable space. In other words, it’s very, very small for two people. Not to mention our pair of dogs and the cockatiel. But again, this is temporary, so we figured we’d give it a whirl and see how we do.

(For those wondering, our full home will not be tiny; though, at approximately 1,000sq’, it will be quite small by contemporary American standards.)

We have a fair bit of external storage space. We placed another used shipping container on the land, to function as our garage. We rented a PODS to help hold our excess furniture, and we have some Suncast outdoor storage cabinets and chairs in the yard. Not all of the storage is so conveniently located (our garage is 200’ away, up a steep driveway, where our full home is to be built), but it means we are able to safely store all of our possessions, even while we temporarily occupy a tiny structure.

Our "Garage" Being Delivered

Before too long, we also extended the living space of the office, by adding a deck, and then placing a lean-to greenhouse on the deck to form a (more-or-less all-weather) porch. At 98sq’, the porch represents approximately a 72% increase in living space (as well as an effective source of passive solar heating most days) -- and, more importantly, provides a second room (so that it is possible for my wife and I to both be in the structure, but be in separate rooms -- a luxury that everyone really takes for granted). As soon as weather permits, we’ll build a second deck, add a second, smaller (24sq’) porch, adjacent to our other door.

So, while in many ways this is tiny living, we’re using much more space and many more resources than you’d find with other tiny home dwellers.

Lessons Learned

If it’s not already clear, my wife and I took on multiple, separate challenges: living tiny, settling remote land, trying to develop on that land, all while continuing to run my company in Los Angeles -- and taking this all on in our first year of marriage! As a result, we’ve been forced to learn many lessons, across many different aspects of life. I will try to focus this post specifically on those aspects that relate to living tiny, but there may well be some spillover.

And with all that by way of introduction, we have some top-level lessons-learned for anyone else who may be considering a similar lifestyle:

Utility Consumption

The Power Box

First, one of the key benefits is the low level of power and utility consumption. This is in part due to our efforts to go off-grid. We have only electrical service to the property, with a generator back-up for when storms or downed-trees take out the power lines. We have no gas service, and we provide our own water from a gravity-powered, spring-fed system on the land.

That said, all of our life runs on electricity. In addition to standard electronic equipment that you’d find in any home, all of our kitchen appliances are electric (with an electric convection oven, an electric range, an electric hot-pot, and an electric rice cooker), we heat the structure with electricity (shipping container homes are too tiny and air-tight to safely use indoor wood or propane heating), and we use halogen for most of our interior lighting. And, all told, our power bill (which is, you’ll recall, our only utility bill) is under $50/month.

It might be obvious, but it is still nonetheless striking: living tiny is just much, much cheaper.

Consider What You Really Need and Want to Use Regularly

As I explained above, we have a good amount of external storage. But most of it is not so conveniently located -- especially given the precipitation in Oregon. When living tiny, you just don’t have that much interior storage space -- almost none, when compared to what you’d find in a standard studio apartment, much less a home. In fact, a tiny home is approximately the size of some walk-in closets that I have seen in houses in Los Angeles and Las Vegas.

So, living tiny means really considering what it is you need to function on a regular basis. Which clothes do you want to wear regularly? Which pots, pans and dishes will you need frequently? Which parts of your medicine cabinet do you really need on-hand?

Beyond the basics, you’ll also want to ensure that you have some comforts (which have to be tightly budgeted, given space and storage constraints). In my case (especially given our remote setup) that includes ensuring I can make a nice fresh cup of coffee every morning, which requires a grinder and coffee maker. Which books do you really want to read (as opposed to those you have around just for show)? My wife and I have taken to playing the Wii quite a bit, so that made the cut. We chose which of our board games we would want to play regularly. And, given our remote location and frequency of bears and cougars, we needed to ensure space for our gun safe. The weather here requires that we have a dehumidifier running.

And so on, and so on. You’ll make your list, realize it’s too big, and then you’ll be forced to really make decisions about those objects and items you really wish to use regularly -- even more so, if (like many tiny home dwellers), you don’t have 200sq’+ of external storage.

Smart Design

It may be difficult to understand (though many residents of Manhattan will immediately recognize this as true) how a functional interior design becomes more important, the smaller the quarters.

In a standard house or apartment, you can buy a chair and put it somewhere. If you need a cutting surface, there’s one around. You can place a nice, large bed in a bedroom and forget about it all day long. You generally have a single, large water heater, that’s easily placed somewhere on the premises.

Instead, when living tiny, you need to spend a great deal of time reflecting on how your interior space functions, down to minute details. Your bed needs to be a loft, or to fold-away. In general, folding furniture is great. As are multi-purpose items (such as our Suncast patio seats that are also all-weather storage; our bed, which is a couch during the day; our IKEA PAX wardrobe, that has full-length mirrors for the doors; and our printer, which quadruples as a copier, scanner and fax).

Container Interior, Immediately After Move

Some people (like Jay Shafer) believe in sculpting the interior space, with walls and in-line storage. After serious consideration, we opted for a structure that was almost an empty box (with an IKEA kitchenette pre-installed), so that we could maintain flexibility with how we furnished and utilized the space over time. In either case, you really need to consider the design of your structure, and how you wish to utilize it to the greatest effect.

Interior Line-of-Sight

Many tiny homes (though not all) are under 8’6” wide. This is so that they can be easily transported across roads and highways, without special permits or traffic provisions. Once that structure is insulated and drywalled, you are left with an interior width of, at most, 7’. Interior storage space, furniture and appliances all subtract from that very low starting number.

If you are like us, open spaces are important. Being able to see 10’ in front of you, is much nicer than seeing only 4 or 5’ in front of you; being in a room that is 7’ wide is much more comfortable than being in a room that is only 4’ wide. And, if you are building tiny, there are many tempting opportunities to cut into the limited (and precious) amount of open space you have.

As you do this, consider the importance that you ascribe to your interior line-of-sight. If you are like us, and maximizing that internal distance is important, this should be considered a design directive (this is one reason we opted for the open, rather than sculpted, interior design).

Multiple Entries

To build to code in most localities around the country, your structure requires two entries (in case one is blocked during a fire). Still, many floor plans and designs that we’ve seen for tiny homes incorporate only a single entry.

The Patio Doors

Because of code issues (and per Dan Sokol’s advice), without thinking much else about it, we opted for installing two entries in our tiny structure (a main door on one long side, and double patio glass doors on one of the shorter sides). It was only after experiencing life in this container (and a few months in which only one of our entries was actually usable), that we really appreciated the emotional impact of having two entries. Even now, as I write this, I find it difficult to express just how this improves quality of life, but it does. It gives you options on how you want to enter and exit. It allows you to establish two separate, easily-accessed outdoor areas. It allows for easier cross-ventilation of the structure. It makes it feel more like a ‘home’.

In short, having two separate entry-ways adds a lot of value to tiny living.

Outdoor Space

One significant factor in our decision to move to this remote area was to spend more time outdoors, in nature. Of course, this means hikes and fishing and similar activities. But if you plan properly, it can also just mean lounging in the yard, regardless of the time of year.

The Porch Deck, In Progress

Of course, having nice outdoor space, or a yard, adds value and comfort to any property. But, when living tiny, it becomes more important. Being able to step outside, and spend time comfortably, is just a lot more important, when your interior is very small. Even having a small covered entry-way helps in minimizing dirt and mud that can get tracked in. This is why we built the porch (and will be adding a 2nd smaller one later this year), have all-weather furniture in the yard, and have covered a portion of the yard (temporarily, with a tarp; we will replace that with a trussed roof that extends over the yard, later this year).

The more outdoor space you claim as your own, for easy use, the happier you will be.

Installed Fixtures and Outlets

Installed Fixtures and Outlets

Of course, planning which fixtures (particularly lighting) should be installed is an important part of any home design process. But, in the context of tiny living, it is important to remember that installed lights take up no floor space (no space at all, in the case of recessed lighting), and do not consume any outlets. For this reason, you should plan to use built-in lighting as much as possible in your tiny structure. In ours, we have only installed fixtures for illumination -- no floor or desk lamps.

Along the same lines, it is quite easy to underestimate how many outlets you will need. Tiny structures require a denser allocation of outlets than a standard structure -- particularly if all of your appliances are electric. And don’t forget! You want outlets on the outside of the structure, as well, for your power tools, or for a light to enjoy your yard, or whatever the case may be.

In short: built-in lighting and electrical outlets are not areas in which you should seek to save money or be stingy. You’ll want a healthy amount of both.

Clean Immediately

One main benefit of tiny living is reduced maintenance -- there’s less space and less stuff, so caring for it takes less time, effort and cost. And, by and large, this is true.

But, on an individual, case-by-case basis, cleaning can take much longer. Again, there’s just nowhere extra to put anything. Cleaning means moving and shifting around items, accomplishing one set of goals, then moving more items around, to accomplish your next set of goals. Just washing a normal amount of dishes can take much longer when living tiny.

As well, once you’ve decided how to design and furnish the interior, and actually move stuff into the tiny structure, everything will have its place. And I mean that very literally. Everything has a specific, allocated place. If you take something out and use it, you must immediately return it to its place when you are finished.

There is just no room for messes to accumulate -- and, in a tiny home, any item outside of its place constitutes a mess. Once messes occur, they rapidly become overwhelming (a small mess in a tiny home is a big deal). And if we’re talking about, for example, dishes and utensils, you just don’t have enough of them for any to lay around dirty.

The solution is to clean immediately, as best as you can. Don’t let any dishes pile up. Wash them as soon as you are finished (which also means ensuring that you have space reserved for a drying rack that is always out). If you trek in dirt, clean it up instantly. And so on.

As well, the garbage has to go out immediately. There is just no place for it. This means having adequate (in security and capacity) outdoor containers for your garbage, recycling (and, in our case, composting). We do have a small indoor garbage can, and kitchen composter, but other than that, garbage goes out immediately (to a series of bear-proof trash containers, steel-bolted to trees in the driveway). There’s just nowhere for normal quantities of waste inside of a tiny home.

Along the same lines, you have to finish jobs that are started, before moving on to anything else -- there’s simply nowhere to store a work-in-progress on multiple projects. So you must pick your projects (and battles) wisely, and then get them done as rapidly as possible.

So, there’s less to clean, but cleaning can take longer, and requires more discipline.

Small Problems Can Get Big; Big Problems Can Be Simple

Exploded Sediment Filters, Part of Our Winter Plumbing Escapades

When living tiny, small problems can get big -- very quickly. As a case in point, earlier this winter one of our plumbing pipes exploded from the freeze, leading to a tiny rupture in the pipe leading to the sink.

Of course a tiny hole in a pipe, leads to a relatively tiny leak, which persisted for about 60 seconds before I could run out and cut-off water to the structure. And so our tiny leak -- a leak that would be an inconvenience in a normal-sized dwelling -- turned into a flood of the entire container. So that was no fun.

At the same time, it took only a few hours to clean up from a flood of our entire structure, using 1-gallon Wet-Dry Vac Micro -- you can’t say that about any normal-sized home. Similarly, we can repaint the entire structure in under a day. We could rebuild all of the interior walls for just a few thousand dollars. We can execute projects on the structure -- projects that would take significant lengths of time in a normal-sized dwelling -- in a fraction of the time, for a fraction of the cost.

Got Friends? Visit Them, Instead.

With a very few number of exceptions, we have not hosted anyone at our container. We have a cute yard, so once summer kicks in, that will change. But for most of the year, outdoor hosting in Oregon is not possible, and so we forgo having visitors over. And when you do have visitors, you can really only have one or two at a time -- there just isn’t space for more (again, unless you have outdoor appointments and nice weather).

It’s obvious once said, but it was one aspect of tiny life that we hadn’t really considered in advance: you won’t be hosting all that much. And, unless you tell your friends why, you risk offending them.

Love the Ones You’re With

Again, it’s obvious, but when you voluntarily occupy tiny quarters with someone else, you really need to love that person. You are continuously exposed to all of each other, all of the time. There is very little privacy of which to speak. When one of you is in a mood, the other knows it instantly. And when tensions increase, there’s not really room for either one of you to blow off steam.

In short, don’t go tiny with someone else, unless you are very confident in your relationship with that person. This includes those of you living tiny by yourself; you’d better be comfortable being with yourself, in small quarters, for extended periods.

Our Biggest Sacrifice

We’ve discussed this subject many times, and my wife and I both agree on what has been the biggest sacrifice accompanying our choice of living tiny: the kitchen.

Now, most Americans have kitchens that are far larger, and more capaciously appointed than we think is necessary for our needs; I’m not saying we need or want that. And, in creating kitchenette plans for a tiny container, not everything has been a sacrifice -- for instance, we’ve adapted to living out of a ‘dorm’ fridge quite easily (we have a separate, all-weather freezer outside for meat and other frozen products).

Still, my wife and I both love to cook, and tiny living doesn’t make it easy to do the type of cooking we enjoy (it doesn’t preclude it, either; it just makes it much more challenging). Except for bar-b-q’s and other outdoor food-prep, there’s too little work space to comfortably create, say, a Thanksgiving meal -- or any meal in which there are multiple hot courses. We only have one burner, and a small convection oven, which makes for a lot of swapping out of pots and pans during meal prep.

We still cook (we have no other options, living where we do) -- but it’s just harder, and not as fun as it used to be.

Our Container Structure, Ready for Winter

Though, enjoying our meals -- on our porch, which we built with our own two hands, in the middle of a national forest, with the creek running just across the neighbor’s field, in the shadows of a tree-covered forest mountainside -- that’s a lot more fun now, than it used to be.

Again, living tiny is not a permanent state for us -- it’s a temporary solution to the challenge of building a full home, out here, in the remote wilderness. As we hoped, it has been an invaluable process for us, learning what is important to us in home and interior design, as we begin the process of building our full home.

But, more than that, living tiny has proven to be a great (sometimes overwhelming) learning experience about ourselves, informing us about our relationship to the spaces we inhabit, the items we fill them with, and how we consume and utilize those items -- not to mention, of course, how we relate to each other.

All in all, we’re quite comfortable these days, having acclimated to, and begun to enjoy many of the benefits found in, this life-style. Fortunately, though, we’re still just uncomfortable enough to ensure that we don’t slack too much on building our full home.

Us On Our Land

The number of things that have gone wrong, due to the mixture of cold and wet, has been relatively staggering -- and honestly, most of it was unforeseen (we’re incredibly glad that we’ve started with a tiny structure, that will eventually become my office; so we can incorporate all these lessons into the plans for our full home).

But, there is a subset of our disasters, which I can safely say were entirely predictable. And those mostly revolve around the plumbing system. As you may have read, late last year, we built our own gravity-powered, spring-fed water system. It was tremendously draining, exciting and rewarding.

And, when I finished it in August, I knew at the time that the water system would be susceptible to winter freeze -- because I hadn’t buried or insulated any of it.

Now, for those new to this game, there are two separate, but related concerns: freezing, and bursting. Your water system can freeze -- in which case, water flow stops. But, water flow will return again when the water thaws. Sometimes, however, freezes can cause pipe, hose, joints and canisters to burst or explode. And that’s when the real fun begins.

First, because when part of your plumbing explodes -- you likely won’t know it until the water thaws and starts flowing again. And, if you’re lucky enough to have that burst pipe indoors (or, better yet, in the walls), you learn about it when your home starts flooding (as mine did in December; but that’s not part of this story).

So, why didn’t I bury my system? Well, for one, I’m lazy. And the thought of burying my 1,000’ of plumbing line, which runs down a tree-covered draw on our mountain, was just too much to bear. It would take weeks to get that done. Plus, the vast majority of our water system is poly pipe (the black flexible hosing), rather than PVC (the hard white piping) -- and poly pipe (which is flexible) is much less susceptible to bursts. So, I figured I could deal with a frozen system for a while, as long as no damage was done -- at least, that was preferable to the amount of work required to bury the system.

But, what I neglected to factor into the mix were the few elements in my water system that are not made up of that flexible poly pipe. And one of these is my sediment filter bay.

For those who do not know, a sediment filter is just what it sounds like: it filters out the sediment from the water. This is important because that sediment will cause all sorts of wear and tear on your water heaters and plumbing fixtures. So I assembled three of these filters together: a 50-micron filter, a 20-micron filter, and a 5-micron filter (in descending order) to get out all that gunk.

The canisters for these filters are hard (not flexible) plastic. Which means that they can explode if the water inside freezes. But I did not want to bury my filter bay 18” underground, because, while that would have protected against freezing, I would then have to dig that up, and re-bury it, every time I needed to change my filters (or even check the filters to see if they needed changing).

Instead, I opted to run my water line over night, by keeping my garden hose running. I had thought that keeping the water running will suppress freezing (moving water freezes at a lower temperature than still water). Turns out, however, that I didn’t have quite enough flow to prevent freezing with some of the December temperatures that we had.

And so, one night, all three filters in our bay exploded. Which we quickly discovered when we didn’t have any water.

Of course, this meant that I had to rebuild my filter bay. But (obviously) I also didn’t want to rebuild it just so that the filters would explode again. And, I still really didn’t want to bury the filters, because that’d be an on-going hassle.

So I asked around for some options and suggestions, and I eventually rigged up an insulation system from scratch. It was so easy, that I thought my sharing this experience might be a helpful reference some day to someone with a similar need. So here goes...

It turns out that you don’t need much heat to prevent the water in the filters from freezing. Obviously, you just need enough heat to keep the temperature above 32 degrees. And, perhaps surprisingly, a 40-watt lightbulb does the job (long live incandescent bulbs!) -- if you are able to trap the heat.

So I purchased a plastic tub (like a Sterilite) -- one large enough to contain all three of my filters, as well as the main valve that feeds them. And I purchased the spray foam insulation -- the kind that expands as it dries. And I sprayed the tub full of that foam. I used four cans of the spray foam -- and I’ll likely go and get more to thicken the lining.

I had to dig and flatten the land, and reposition the filters on it, to try to get a decent spot on which to place the tub.

I then ran an extension work light out to the filters, and hung the lamp directly on the hose. And then I covered the filters with the tub.

I did splurge on one element of the system. Instead of plugging the work-light directly into an outlet, I purchased a thermostatically-controlled outlet. It turns power on when the temperature drops below 38-degrees, and turns the power off when the temperature gets above 50-degrees (you learn about so many awesome toys doing this type of work). So I plug this thermostat-plug into my outlet, and then plug my work-light into the thermostat-plug, and I’m done. The light turns on and off by itself, and ensures the water keeps flowing through my filters.

It’s been running for a few weeks now, and thankfully no more exploded filters (which is good, because these canisters are not cheap -- it’s about $60 for the heavy-duty one that holds the 50-micron filter).

Share and enjoy!

-r

So, we’ve learned a lot in this period. And, this sudden shift in our industry (along with the ensuing industry-wide uncertainty) gives all of us an unusual opportunity to reflect on precisely what it is that we’ve learned, and where we might want to take that moving forward.

Back in the late 90s, I was a boring ol’ HTML page builder (it seemed like such a cooler career choice than 'tech support'). In 2000, I entered the Flash world through the video side, with the creation of Flix, the first video encoder for Flash (because I was just so damn sick of the limitations of skinning Real with SMIL). So, of course in the past decade I have learned a lot about digital video and media.

More broadly, however, I have learned a tremendous amount about how to produce large-scale software and digital interface projects, profitably and on-schedule, in the stunningly complex intersection of rich experiences, internet, devices, browsers, businesses and customers. And I learned how to build and run a company (from scratch, with no external investment) that specializes in this new arena. And, of course, Flash afforded me many teaching, speaking and writing opportunities -- opportunities that I have exploited to improve and refine my style, and become a powerful communicator on a range of technical, creative and business subjects.

I say all this by way of explaining that, while I may have entered the Flash world as a coder and designer, the ensuing decade afforded me many opportunities to grow my skills on a variety of fronts, far beyond the scope of, and not directly related to, Flash.

And the same will be true for each and every one of you.

As you evaluate the new landscape of technological options, remember: coding languages, like all technologies, are just tools. We use these tools to build projects for clients, yes, but we also use these tools to build careers for ourselves.

There is significant temptation and pressure right now to make reflexive choices (and I suspect that in about 18 months there will be a fair bit of buyer’s remorse among some people who chose to specialize in HTML5, as they come to terms with the limitations of that technology, and the browser runtimes). Remember: don’t follow the tools; instead, let your selection of tools flow from a clear understanding of your own personal goals.

So, please take this rare opportunity of an industry-wide disruption, to really consider what those goals are. Don’t let the industry make these choices for you.

Share and enjoy!

-r

Is Flash Dead?

Adobe’s recent announcements on mobile Flash have led many to conclude that the death of Flash (rumored for over a decade) has finally come to pass.

So, is Flash dead?

The answer is, unfortunately, complicated, because ‘Flash’ is actually a complex array of inter-related technologies, most importantly:

• SWF, or the file format of compiled Flash experiences
• The Runtimes
• The Flash Player, or the plugin that plays SWF content inside of a browser
• AIR, or the Adobe Integrated Runtime, which is what is used to deliver Flash experiences as applications
• The Authoring Tools
• Flash Professional, which is the tool primarily used to design and animate Flash experiences, and includes full support for code (but not optimized for developers)
• Flash Builder, which is the tool used by coders to program Flash experiences
• There are other authoring tools for Flash, as well, but these are the two primary ones from Adobe
• The Frameworks, like Flex, which are utilized to accelerate and standardize ActionScript 3 development

So, given this landscape, when people ask ‘is Flash dead?’, you can see why the answer may be a little complex. I think that, what most people mean when they ask the question, is whether Flash Player is dead (most people still don’t even understand that Flash can run outside of the browser, using something called AIR).

Yes, Flash Player is (Almost) Dead

I believe that the short answer to this is, yes, the Adobe Flash Player is now, effectively, a dead technology, from a mass market perspective (the situation may well be different in specific niches, like gaming and enterprise).

Why do I think this?

Well, as I expressed in some length last month, the core value of Flash has always been that it runs everywhere. Yes, people use Flash because it delivers cool experiences -- but, more fundamentally, they use Flash because people can see whatever you create with it. It is certainly true (as I discussed in my recent review of Flash killers) that Apple delivered a key blow to this positioning of Flash as a ubiquitous platform. But it was not a fatal blow -- at least not until this week’s announcements from Adobe.

Adobe believes that the future of Flash Player is on the desktop, and they have set their sights on that. The thing is, the web isn’t supposed to be platform-specific that way (when was the last time anyone suggested building a Windows-only website). The web is supposed to work everywhere.

So, while Flash Player offers some amazing options for experiences in the desktop browser, the vast majority of firms and individuals will opt to exclude Flash from their websites -- simply because it will not work on a sufficient number of viewer machines. That is, there will be very little Flash Player in the browser, even for desktop viewers, precisely because it will now not function on any mobile devices.

I’m not saying there will be absolutely no browser work done in Flash -- just very, very little.

Because of the diminishing presence of Flash Player in web, there will be many fewer people learning how to work with Flash technologies. Already, Adobe lost a huge percentage of their Flash user base, when they introduced ActionScript 3 (and many Flashers were unable to keep up). And now, they will lose even more.

With the exodus of talent from Flash, there will of course be fewer resources available to create work in Flash -- or trying to sell work in Flash.

AIR

As I hoped to convey in the above intro, Flash Player and AIR are different technologies. So when I claim that Flash Player is dead, I do not necessarily believe that AIR is also dead.

Adobe has always had difficulty explaining the difference between Flash and AIR -- and this is one of the key problems with AIR. Very few people actually understand and appreciate the difference between Flash and AIR. And now that the world believes that Flash on mobile is dead -- because Adobe just spent a lot of time, money and effort saying just that -- it’s going to be very, very difficult to explain that Flash is actually a viable technology for mobile devices, through something else called AIR.

The broader market does not understand that, while Flash is dead on mobile, something else called AIR isn’t. Further, for those that do, they (quite reasonably) would question why they should believe Flash runs well as a mobile app, when Adobe itself claims that Flash does not run well as a mobile plugin. And finally, the same exodus of talent that I predict, above, will of course, influence the potential size of the market for AIR apps.

Thus, AIR’s future is in great doubt -- regardless of the quality of the engineering, or the scope of resources that Adobe puts behind the technology. AIR will only survive and succeed if people like me are able to sell it -- and that sales job has just become vastly more difficult (and the haphazard manner in which Adobe made these announcements has dramatically reduced the willingness of people like me to try to sell Adobe technology in mobile environments -- we just don’t know what massive changes in strategy Adobe has lined up around the corner). And I am unclear if Adobe is able to provide marketing and messaging necessary to support the sales of AIR apps.

Adobe should not have killed off Flash Player until Adobe figured out how to package and sell AIR as a solid solution. Adobe needed Flash Player to remain a web standard, until AIR could become an app standard. That they did not, places the future of AIR as a popular application development solution in great doubt.

Web

I think it is worth noting what all this means for the future of the web, because I think it is very easy to overlook this. Given the current discussion taking place inside the reality distortion field, too many people look at the death of Flash as a ‘good’ thing, without considering the full set of ramifications.

I don’t want to get into an HTML5-vs.-Flash discussion here again. Suffice it to say that HTML5 is just not anywhere near feature-parity with Flash. This means you can’t build stuff as cool with HTML5 as you can with Flash. And, with the immature state of HTML5 authoring tools, all the cross-browser, cross-platform consistency issues inherent in HTML, firms will have to spend more money, to create these less rich experiences.

Thus, with what I see as the impending death of Flash Player from the web, and HTML5’s clear lack of ability to fully replace Flash’s role, we're going to see a decrease in the quality of web experiences -- at least for the next few years.

What’s more, in this same period, we’re going to start to see a real differentiation in the quality of experiences that firms of different sizes are able to create. Flash was actually a leveling technology, with an economic model that enables even individuals to create cool browser apps and experiences. Because of the aspects of HTML5 I just referenced, by and large, only very large firms will be able to afford to create great browser apps and experiences (it is not a coincidence that today you see great HTML5 from firms like Google and Apple).

So I predict that one of the key results of Adobe’s recent announcements is that, for the next few years, the web will become more boring, with fewer great experiences, spearheaded by much larger firms.

As I said at the start of this post, these opinions represent my current guesses as to the future of these technologies. There's certainly plenty of room here for more perspectives, and I'd like to see what some of you think, in comments.

Until then, please share and enjoy!

-r

But I did want to share some initial reactions with the manner in which these announcements were made, because in there I find some real cause for concern with Adobe as a company, and the style in which they are executing on strategy.

Sudden

Adobe made these rather drastic announcements without any warning or notice. Just last month, I, along with thousands of my industry peers, attended Adobe’s annual MAX conference here in Los Angeles, and there was not a word that this was coming. Indeed, they ran multiple sessions promoting the powers of their mobile Flash Player.

And, it’s worth noting that the drive for Flash on mobile is not new. Adobe (and Macromedia before it) has been publicizing advances in mobile Flash and FlashLite technology for over a decade. And now, in 2011, as soon Adobe finally achieves it,they abandon it -- without any notice. You can see how that would be seen as a very confusing move to many who have followed the technology for so long -- a move so significant that perhaps some advance notice and explanation would be in order.

So, why did Adobe obscure their intentions with mobile Flash until the last moment? What benefit did they see in the intentional side-swiping of their customers? More importantly, for how long has this strategy been in consideration? Is this a brand new idea that they cooked up in the last four weeks? Or has this been in the works for a few months? What’s the deal? Why the secrecy?

Ignoring Customers

This treatment of the announcement as a surprise did a massive disservice to Adobe’s customers (many of whom are also, effectively, evangelists), who have been given no time to prepare, to consider the implications, or how to communicate the issues to their clients and colleagues, or to seed the market with accurate information and expectations. In an arena already plagued by fear, uncertainty, doubt (and, let's be honest, irrational antagonism), Adobe’s handling of yesterday’s announcements amplified all three, and in so doing, Adobe discarded a tremendous deal of good will -- far more than I think that they realize.

Beyond the lack of respect this shows to its customers, this act illustrates Adobe’s continuing lack of appreciation of the power and value that its community brings to the table (especially the Adobe User Groups). And this time, the announcement was so significant, and included absolutely no leading indicators, I feel that many in the community will feel very betrayed and the effects will linger for a long while (in a way that was completely avoidable).

By ignoring their users, Adobe also did themselves a significant disservice, by forgoing the opportunity to gain any feedback from these loyal customers. Changes of the scope Adobe made yesterday are big -- really big -- and it only helps to get market feedback on the impact these changes will have amongst Adobe’s customers, so that decisions can be tweaked and messages can be massaged, to optimize outcomes.

Irresponsible Standard Bearing

And, finally, when a firm owns a technology that is treated like a standard, that firm has a responsibility not to act capriciously with it, but instead to reliably and responsibly set future expectations -- to treat it as a balance of private IP and a public good. If the owner of the technology is going to significantly alter defining aspects of it, there is an implicit responsibility to announce this in advance, giving people and markets time to prepare.

With their handling of the announcements on mobile Flash Player, Adobe has illustrated that it is not capable of responsibly executing the duties required when one leads a standard. And, for this reason, people and firms should now be exceedingly cautious when opting to include any Adobe technology inside of a browser. Perhaps you consider this an over-reaction, but Adobe has shown that it is willing to kill off support for entire platforms with no advance notice, whatsoever.

Style

If you’ll notice, I have not spent one word in this post commenting on the strategy that Adobe has unveiled (more on that later) -- right now, I’m focused on style (something for which Adobe used to be known) -- because the style in which Adobe made these announcements is, indeed, quite troubling, performing a great disservice to their shareholders, customers, and brand.

The entire experience leaves one with the image of a leadership acting chaotically and reactively, and a firm that quite possibly lacks the chops to execute on a coherent strategy -- much less, what that strategy is. Whatever Adobe wanted people talking about on Wednesday, I can guarantee it wasn’t the discussion that we saw erupt on blogs and Twitter. And all of that -- and I mean ALL of it -- was both predictable and avoidable.

And that is a case study in failure of message and leadership.

I've been trying to avoid stepping in the numerous potential pitfalls, with which this subject is rife, which is why I have largely avoided posting on this topic. But, after opening a small can of worms with this post two weeks ago, I feel that it is important to provide some more detail and clarification around this issue -- especially as I’ve really come to appreciate the amount and degree of misinformation in the marketplace that is fueling ill-considered technical decisions.

It can also be challenging to figure out how to approach a discussion of this topic -- even on a broad, generalized level. But let’s give this a whirl.

How I Met Flash

First, for some disclosure, I’m a big fan of Adobe’s Flash technology, and have been for quite some time. So, of course, you should take that into account when reading what follows.

Why am I fan of Flash? I started my career in the web back in 1994 -- years before Flash even existed. For years I was an HTML builder. And then in 1998 I was working at an agency in New York that did some of the earliest pioneering commercial work with Flash 3. I was not on their Flash team (their ‘team’ was actually only two people, giving me some initial insight into man-power savings in Flash technology). But I did see what the team was doing with that very early version of Flash.

What I saw in Flash then is, by and large, the same thing I see in Flash now -- the ability to produce engaging content -- and I mean (if you do it right) really, really engaging content -- reliably, to every internet-connected computer in the world.

With HTML, I found that I and my colleagues were spending roughly half of our time ensuring cross-browser, cross-platform compatibility. Yes, I could eventually get my HTML to render in IE3 the same as it did in Netscape 2 -- but I didn’t get into the web to spend half my time debugging. Debugging that stuff is just no fun.

In Flash I immediately saw the potential of spending my time creating experiences and expressing myself, and deploying with a technology that ensured that my work could be viewed by anyone on the internet. So I got into Flash.

Does this mean that I see no role for HTML? Absolutely not! Would I say that Flash is better than HTML or vice versa? Of course not (the question is as ridiculous as asking whether a hammer is better than a drill).

In fact, if you’ll notice, there is absolutely no Flash anywhere on this website. Why? Because I don’t see a need for it here -- HTML is far better for presenting this type of information, just as it is for presenting the vast majority of data available through a web browser. No one wants to see Craigslist, or Wikipedia, or Google search to switch to Flash. Absolutely no one.

The Contribution of Flash

So what role does Flash play? Flash fills the role of providing the layer through which outstanding experiences can be deployed to any screen. What’s an outstanding experience? Well, it’s hard to define, but like Justice Potter Stewart said of pornography, ‘I know it when I see it.’

To state an unspoken truth: without Adobe Flash technology, the web would have been incredibly boring for the past 10 years. Before Flash, the only option for animation was animated GIF. Before Flash, the only way to deploy audio was through RealAudio, an external plugin (and which required an expensive server component). Before Flash, video was available through an array of external plugins (like Real, Windows Media and Quicktime), that could not be customized on a practical basis.

Even though it was only a decade ago, it’s hard today to remember what the web was like before Flash. HTML has just not proven itself to be a particularly expressive medium. If the web had waited for HTML5, YouTube wouldn’t yet exist.

Big Spaceship's Nike Air Project, Still One of the Most Visually Awesome Consumer Experiences Ever Created

And if you think back to the experiences online that you’ve enjoyed the most -- I mean those apps, games, toys and sites that have truly engaged and wowed you over the past decade, I’d wager that the vast majority of those were enabled with Flash.

When you envision the interfaces, games and experience of the future, those are most closely approximated by Flash -- you just can’t imagine building ‘Minority Report’ or ‘Iron Man 2’ in HTML. The interfaces that consumers really want to play and engage with (and I mean ‘play’, not just ‘use’) are those enabled by Flash, not HTML. Consumers want Flash in their internet experience.

So, why is there this persistent segment of the population that hates Flash? Well, any technology is going to have its haters. But, from my perch, I see Flash-haters breaking down into three camps (there are other gripes with Flash, of course, beyond these three; but, from a broad market level, I believe these three are the most persistent veins of discussion):

Flash-Hatred Camp #1: Flash is 99% Bad

I take this, of course, from the title of Jakob Nielsen’s (in)famous work. Were there horrible sites and experiences created with Flash? Of course. Was ‘skip intro’ indicative of obscuring, rather than illuminating information? Definitely.

But these, in my opinion, are reflections of poor design and engineering, rather than poor technology. Flash is far more powerful than HTML, so if you are poor designer, then you’ll be able to create some powerfully bad designs. And, over the next few years, as you see more and more HTML5 roll out across the web, you’ll see plenty of bad HTML5 design, too.

Flash-Hatred Camp #2: Flash is Not a ‘Standard’

This comment is both true, and misleading. It is true that Flash is not a ‘standard’, as CSS and HTML are. That is, Flash is not controlled or approved by an international standards organization, influenced by multiple corporate entities. So, in this sense of the word, Flash is most definitely not a standard.

However, Flash has long been so widely distributed, that it has been treated as a standard by web content creators and viewers alike. We can safely assume that people either already have it, or can easily get it. And for free. So, while Flash is not a standard in the way that W3C people or IEEE people mean the word, it is a standard in the way that the rest of the business, corporate and consumer world mean the word. And no, that’s not an overstatement. If everyone has it, it’s a standard, whether or not an international organization defines it as one. This is why there’s a large segment of the population that feels the ‘web is broken’ on an iPhone (in the way that it isn’t on Android devices) -- because Flash Player is missing.

Flash-Hatred Camp #3: Flash is ‘Closed’

Related to the issue of standards is this issue of ‘open’ and ‘closed’. Many have cited this issue (perhaps most notably Steve Jobs in his open letter ‘Thoughts on Flash’) in their critiques of Flash. So let’s dive into the details.

First, what do people like Steve Jobs mean when they say Flash is ‘closed’? They mean that Adobe, and Adobe alone, controls the definition of Flash. And this is true.

At the same time, the issue of openness is not simply true or false -- there are degrees. SWF (the compiled format of Flash) is an ‘open’ specification. Yes, only Adobe controls it, but any company can make content that publishes to Flash (and many do). The Flex compiler, like the Flex SDK, has always been open and free. And now, Flash Professional supports XFL, which is an open authoring format, meaning any company can now open and save Flash Pro source files. Indeed, in almost any and every respect, Flash is far more open than, say, Apple’s iOS.

I, like many of my peers, love open-source software. Linux, Apache, MySQL and PHP form the infrastructure of a huge amount of web work. Packages like WordPress, Drupal and Moodle facilitate the creation of powerful communication platforms. The web would really be a pale shadow of itself -- and fewer people would have a voice in the internet -- absent the contributions of open-source software.

But, open-source software alone does not make the web. We use proprietary tools like Photoshop and Illustrator (and yes, even GarageBand) to create a huge amount of digital content -- and thank god these closed, proprietary tools exist, because they enable a tremendous degree of creativity.

Flash Power

While some see Adobe’s control of Flash as a drawback, it is the fact that Flash is owned and controlled by a single company that has allowed it to grow and mature so rapidly in the past decade.

When I started with Flash, in version 4, we had 12 commands in the ActionScript language, which you edited with a madlibs-style editor, the default framerate was 12 fps (and you hoped to get that), there was minimal audio support (without MP3) and absolutely no video support. Today we literally have Unreal Engine playing, on full-screen desktop, inside of the Flash Player and Photoshop written for the iPad with Flash.

That’s an astounding degree of progress. That represents progress measured not in percentages, but in orders of magnitude. It is not an overstatement to say that Flash today is over 10,000 times more powerful than Flash 4.

HTML Molasses

What has HTML accomplished in the equivalent timeframe? They haven’t even ratified the fifth version of the specification. That’s right. HTML5 was first proposed in 2004 and it is still, today, not finally ratified as a standard.

And that, in a nutshell, is the problem with HTML and international standards -- progress is painfully slow.

So, HTML version 5, like HTML versions 1 through 4 before it, is great. You absolutely need HTML to power the web. It is the fundamental language of web experiences.

But, because it is an international standard, it takes very long to evolve -- far too long for the tastes of consumers. HTML5 is only today offering the ability to create experiences that Flash offered almost 10 years ago. And, in five more years, there will have been something like three or four or five more versions of Flash, and HTML5 will still be in deployment.

HTML5 is Cross-Platform? Really?

Not only is the final standard of HTML version 5 not yet ratified -- but it is not implemented consistently across browsers and platforms. In fact, HTML5 does not even work at all on over half of desktop computers.

(If you want some more details and specifics on browser-support for these specifications, check out the When Can I Use..., and if you want to see how your current browser stacks up to the HTML5 spec at HTML5Test.com. For more complete history, check out Wikipedia.)

And, because supporting HTML5 requires a browser upgrade, it’s going to take quite a while for HTML5 to reach high levels of desktop penetration. A notable percentage of people upgrade their phones more rapidly than their browsers.

And, on those computers and devices where HTML5 is supported, it is supported differently. For example, you may not realize that Firefox does not even support HTML5 video (update: see comment) there is not one single video codec that is playable in all HTML5 browsers (meaning that you must encode to multiple different formats to support HTML5 video). And, full screen video is not available in most HTML5 browsers.

One day, HTML version 5 will be a true, cross-platform technology (and, of course, Adobe will be giving us the best tools to create HTML experiences; after all, who else would?). Today, however, in 2011, HTML version 5 is not actually a reliable cross-browser, cross-platform technology. It doesn’t even work on half of desktops. And, by the time HTML version 5 really is solid and implemented, Flash will be even more powerful, performant and feature-rich than it is today.

How Did We Get Here?

If the case is as I state, and HTML version 5 is still not yet finalized, much less fully and consistently implemented and deployed, then how has the conversation reached the current point, where there is such an anti-Flash perception in the marketplace, and such momentum behind an HTML specification that is not even finalized or fully deployed?

Well, of course, the answer is ‘Steve Jobs’. People hated Flash before Apple blocked Flash Player from the iPhone, but Apple’s actions had two main impacts:

• First, the popularity of the iPhone as a product, and the absence of the Flash Player on it, meant that one of Flash Player’s core benefits -- namely, that it works everywhere -- was significantly harmed. (Adobe has since created new workflows enabling the distribution of Flash content to iPhones and iPads.)
• Second, the popularity of Steve Jobs as a visionary lent a very strong, almost hypnotic credence to his public claims about Flash technology, popularizing arguments (some valid, others not) based in a longer history of antagonism to Flash.

Earlier this year I concluded a series of posts entitled, ‘The State of the Flash’ (on this blog, and Almer/Blank labs), intended to provide an insider’s overview of Flash technology. And, in retrospect, I focused too heavily on Adobe’s improvements in the technology and authoring tools, and clearly omitted consideration of the impact that Steve Jobs, Apple and the iPhone would have on the Flash market.

Over the past three years since iPhone banned Flash Player, the market for Flash, and the market perceptions of Flash, have been significantly harmed. And, as a result, many businesses are currently making technical decisions based in a significant degree of misinformation. For example, we regularly talk to clients and potential clients that have no idea that Flash actually does run on every platform, including iOS. Similarly, we commonly speak with firms, who have authorized a switch to HTML5 as the primary method of video delivery, without realizing how few desktop computers would be supported.

And Adobe has not yet properly messaged a strong, fact-based defense of their powerful Flash technology.

So, Really, Flash or HTML?

To me, and my peers in this industry, the question has never been ‘HTML’ or ‘Flash’? It’s ALWAYS been ‘HTML’ and ‘Flash’ -- just which is better for which purposes.

Which technology is appropriate where? Everyone will have his own perspective on this question. But in my opinion, the issue broadly breaks down in this way:

• If you’re building for the web, you should opt for HTML over Flash whenever possible; use Flash for what it can do (provide amazing experiences), and use HTML for all else (if you’re still using Flash because you don’t want to program JavaScript roll-overs or menus, you really need to move on).
• If you’re building for mobile web, of course, iPhones and iPads do not support Flash Player, so you need to build in HTML to support mobile Safari.
• If you’re building games (either for the web, or as stand-alone apps), you really, really should be building in Flash. Flash has so much more power (from performance, to 3D, to video, to audio) and can be published to every platform (yes, including iOS). Just think: in what year are you likely to see Unreal Engine ported to HTML? Because, for Flash, that year is 2011. (I literally can not think of a single compelling reason to create games in HTML over Flash. I’d love to hear some opinions on that one.)
• If you’re building cross-platform apps, it really boils down to the nature of the app. If your app is largely forms-based, or features an otherwise simple UI and experience, HTML5 is likely your better bet. Otherwise, for any more engaging experiences, or complex UIs, Flash is probably your preferred choice.
• If you want to build rich experiences, and deploy those experiences to as many screens as possible (whether in a browser, or in an app), then your best choice is Adobe Flash (for many of the reasons I stated above). It’s not just a matter of the vastly superior feature-set offered by Flash -- it’s that Flash actually offers an option to publish reliable, consistent experiences to every major connected device in the world. HTML does not.

That last point is, to me, the most compelling. Consumers want to engage and interact with content and brands through a wide variety of devices. And if a company pays to build and deploy to one device, they should be able to offer the same experience to any of their consumers, on any device, both through the browser, and an app. Flash offers the ability to publish to web and desktop, Mac, PC, Linux, iOS, Android, Playbook, and even Samsung, LG and Google TVs -- all from a single code-base.

For the past several years, firms have been forced to choose which mobile platform to support -- often opting to support iOS now, and Android later (eventually, maybe). And, in the process, offering different and new experiences on mobile platforms that are not available through desktop web browsers.

With Flash, these firms do not need to pick and choose which of their customers to support. With one production team, these firms can deploy deeply-engaging content, experiences, games and apps to all viewers, regardless of the brand name on the screen. They can even easily port their existing web content to apps for mobile and tablet devices.

This, on its face, is a huge benefit. As we enter yet another year of what appears to be extended economic uncertainty and pain, the massive economic benefits of utilizing Adobe Flash technology for creating apps and games and video experiences will become increasingly compelling to decision makers.

One team,
one codebase,
one experience,
every screen.

That’s what Flash, and no other technology, offers today to firms and developers.

If you are trying to create a rich experience, and deliver it to as many people as possible, for as little money as possible, Adobe Flash is your best option.

So that’s one of the key roles for Flash, and where I believe we’ll increasingly see Flash work trending in 2012.

And, I hope that someone like me is able to express a vocal defense of Adobe Flash technology, and an honest assessment of HTML, without being considered an HTML-hater. These are different tools for different purposes. (That said, anyone who tells you that HTML5 is actually a fully-baked and truly reliable cross-platform technology is lying to you.) If you’re a sophisticated and experienced developer, you should be able to determine which is optimal for which purposes. And you should be able to hold an honest discussion that recognizes the reality of these technologies, rather than hiding behind abstractions, partial-truths, and future hopes.

Good afternoon, all. I've just posted another installment of my articles about StageVideo at Almer/Blank Labs.

This is the 2nd in the series of posts based on my Featured Talk at Adobe MAX 2011. Entitled 'Delivering the Best HD Video in Flash', the talk is really about the StageVideo enhancements that have been added to the Adobe Flash Player since version 10.2.

And, as I'm doing most of my posts about StageVideo over at A/B Labs, if you're interested in keeping tabs, you can check out this link of
my posts on StageVideo on Almer/Blank Labs.

Share and enjoy!

-r

Maybe, as some of the comments say, the baby is just using a magazine the same way babies-of-yore would. But I really doubt it -- I doubt that the pervasive nature of these touch devices on the connected side of the Digital Divide would not impact how people interact with non-digital, non-interactive, non-connected content and experiences.

And, as I raised in my Disconnecting talk, when this generation grows up, and there are events that force disconnection -- that lead to the failure of our connected devices -- what happens when the internet is just gone -- even for a brief time?

There's plenty to consider in that question, and it would be nice to see a bit more discussion around it.

If you've been reading some of my posts this year, you know that my wife and I placed a converted shipping container on our land, as an initial structure where we can be based while planning and building the rest of our home. This container, while nifty and secure, is only 160sq' (and only 135sq' usable on the interior). Given that we have pets and other items that won't fit in the container, we decided to add a porch.

I won't bore you with the details, but suffice it to say that man, porches are expensive! So, we eventually decided to build a deck, and place a lean-to greenhouse against it. Not super-cheap, but far more coverage than a standard deck (turning it into an all-year space) and far more affordable than a traditional porch.

We took our measurements, selected a greenhouse, and decided to build an 8'x16' deck for our 6'5"x14'7" greenhouse. (That's just how our numbers worked out; I later learned that it's much easier to work with dimensions that are multiples of 8' because that's the length of much of the wood.)

Then the question, how does one build a deck? Immediately, I envisioned having to dig a bunch of post holes, and pour a bunch of cement to create a foundation. I did some quick searching online at sites like Lowes, and found options that were, quite honestly, pretty intimidating.

And then, I discovered this site: DECKPlans.com

Now, as a disclaimer, this site is sponsored and run by the company that makes the Dek-Block® Pier, the deck blocks that they sell. So keep that in mind -- this is certainly not the only way to build a deck. But it's the way we chose.

DECKPLANS.com asks you two simple questions:
- How big a deck do you want?
- What material do you want to use? (2x6 cedar boards or composite decking)

And then -- VOILA! -- the site generates a PDF plan for you to build your deck, as well as a shopping list for you to take to your local Lowes. The plans utilize these concrete deck blocks, which eliminate the need for you to dig holes or pour concrete. Just place the blocks in a grid, and start building your deck foundation on top.

If you're wondering about materials, it boils down to composite decking is more durable, but more expensive. 2x6 cedar board is less expensive, and can look wonderful, but requires some on-going maintenance. In the end, I opted for 2x4 cedar board, instead of 2x6. It's less traditional, and definitely looks less deck-ish, but the price savings were significant.

Also note, that the cedar board, or the composite, is your choice for decking -- the material on the top of the deck. For the foundation, you want a cheaper, uglier, more durable grade of wood called pressure treated, which is stronger, and can withstand direct contact with soil.

So I took my shopping list to Lowes, put in a rather large order (including materials for some other projects, like a fence), and scheduled delivery to our land. Eventually, the day came and everything arrived.

Now, the pressure was on.

Once again, our friend James was invaluable to the process. This is most certainly not a one-man job. So James and I worked for most of four days completing this deck (as usual for our remote location, you really want to ensure that you have all your materials when you start work; in my case, I ran out of wood twice, leading me to make two otherwise unnecessary trips to town).

By the way, here is a list of the tools that we used for this project:

• hammer
• 1' level
• 4' level
• laser level
• power drill
• miter saw
• jig saw
• saw zaw
• hand saw
• chalk line
• 10"x10" tamper
• work bench

You start by laying out your Dek-Blocks in a grid. The plans generated by the site called for us to use 20 blocks (four rows of five), but we opted to use only 12 instead (three rows of four). 20 just felt like overkill, and I knew that the site had a vested interested in selling those blocks, so I took that into consideration, too. We still needed to all five rows of support beams, to create stable decking, but those did not need to be attached to Dek-Blocks. So that saved us some money and effort there.

I think I've heard it mentioned that the secret to building any type of deck is to level, level some more, then level again, then you can get into some real leveling. Then, before you do anything else, you'll really want to dive in there and level. It was amazing how
we had to take the same level readings, again and again, over and over, and how they kept changing! It was like the earth was actually moving underneath us.

Now, when laying the blocks out in a grid, you want to make sure that your grid is straight, and that each block is level with the earth, but these blocks do not need to be leveled with respect to each other. You'll use a 4x4 post to even out the differences later.

Once the blocks are leveled and in a grid, you can start building the framework. And you should start with the outer four sides. If, like me, you've left your wood outside for a couple of weeks, then you might have some warpage -- no worries! That just adds to the fun and the challenge.

You have several options for how to connect your corners. We opted to notch the joints, so they fit together like a jigsaw puzzle. Instead of chopping the beams into bits (reducing the strength of your framework), by notching, you allow the boards to remain at their full lengths.

Now, as you add the boards to the framework, you'll start to notice that your blocks are not level. This is where your 4'x4' post comes into play. Measure how far off your beam is from the block, then cut a slice from your 4'x4' post, and drop it into the Dek-Block. Then you can lay your framework beams on top of those posts.

Again, please remember to check your levels. And, as you start getting into beams that are longer than 4' or 6', you will really want a laser level. It's amazing how effective those are -- our laser level revealed slopes that our 4' level was just not picking up. The laser level helped us ensure that our final deck was remarkably level -- much better than I'd hoped or anticipated.

When your support boards are in place, just drill some 2.5" wood screws into the joint, until you are happy with how secure it is. Try very, very hard not to strip your screws -- since you do actually want the option to remove or tighten all screws over time.

Once your outer framework is in place, you can build the inner framework. Again, you are using pressure treated boards to create a bunch of support beams. As I mentioned above, we had more support beams than rows of Dek-Blocks, which is perfectly fine. And, because we were so happy with the results, we opted to utilize the notching joints throughout the deck framework.

Eventually, we finished that task.

The next morning, we checked all the joints. A few weren't flush, so, in lieu of a sander, we cleverly applied our jig saw to smooth out those joints, so all deck boards could sit flush.

And then we could finally start the decking! One by one, we laid down each deck board, screwing it into each support board it covered. This was actually pretty challenging and grueling work -- the downside of my chinsing out on the 2x4 instead of 2x6 decking, and the result of me leaving the boards outside for a few weeks. Because of the warpage, one of us needed to forcefully hold the board in place, while the other drilled in the screws. It took hours and hours, but we eventually finished.

Then, only one more task remained -- cutting the edge of the deck so that it looked nice, even and flush. We grabbed the chalk line, measured off where to cut, and I took the miter saw down the entire 16' length of the deck. I gotta say, that part felt incredibly good (though, since we got to that after dark, I was a bit worried that I would make a mistake -- thankfully we didn't).

After I left, Cindy applied a couple of coats of sealant. And, in a few weeks or so we'll begin constructing the greenhouse to sit on top of it. We'll have plenty more photos to share when that's done.

Until then, share and enjoy!

-r

And so, now that the conference is over, I thought it might be nice to take a brief break by posting on some of my recent experiences up in Oregon, building an off-grid water system.

To catch you up, if you're just joining the story-in-progress, earlier this year my wife and I moved up to settle some remote raw forest land in southwestern Oregon. And, the process of getting situated on our land ended up taking a bit longer than we anticipated -- in fact, it was 7 months, in total, before we could actually spend the night in a structure (a 150sq' shipping container converted into a home office) on our own land. (This extended period of living off-line was the premise for my talk, 'Disconnecting' at Adobe MAX.)

One of the core items we had to complete prior to using our land, was to establish a water system. I really enjoyed divining in and learning to harvest my own water from the earth, and thought it might be fun (and possibly even a useful introductory primer) to recount part of that experience here.

Our land is outside the reach of municipal plumbing systems. And, of course, we don't want to end up having to truck in a water supply.

When you're looking into water systems, there are a few basic options. You might have surface water available. There is a powerful creek across the road from us, but our land does not touch it. We have a creek on our property, but it's over 1/3rd of a mile from our office- and home-site.

Or, you might have subsurface water available. Given the lack of viable surface water options, we opted to seek subsurface.

With subsurface, again there are two basic options: well and spring. Of course, there's a lot more detail, but that's basically it. With either, you have to identify a water source. How do you identify where subsurface water is, you ask?

Well, if you're very lucky, you have a spring that is so full, it bubbles to the surface. If not, you have to find signs of water. Believe it or not, when you ask people how to find water, the most common answer is "find a water witch." I know, I was shocked too (and immediately thought of 'Princess Bride' -- but that's a separate story). But apparently, there is an art to the usage of a diving rod that can be employed successfully.

Still, even if water is not visible, and a water witch is not readily available, you can look for signs yourself. Depressions in the earth's surface. The growth of particular flora (in our part of Oregon, that would be reeds and ferns).

Now, there's the question of location. You want to find a water source as close to the point-of-use as possible. At the same time, you have the question of how you will actually transport the water from the source to the point-of-use: pump or gravity. Because we wanted to avoid the use of any external power for our water system, we hoped to find a source from which we might create a gravity-fed flow.

This meant that we had to find a source, higher up on our mountain, above our office- and home-site.

And, to extract subsurface water from the earth without any pump requires that you can dig to access the water at a certain angle (basically, you have to slant-drill to access the water from below the spring, and then run that water into your system).

Hiking around our land in the spring, we found signs of literally dozens of springs. And several that were directly above our pads.

But, because of the heat of summer, we had to wait until late August to locate a suitable water source, that would survive all year. So, before Labor Day, we hiked up the mountain and looked for sources. And, we were extremely excited to find a subsurface water source at the very top of our property, literally just feet in from the national forest land marker.

Because this spring is high up on our property, we had to dig the spring by hand -- there's no getting any welling equipment up there. Plus, we had a quote for $15,000 to install a well and pump! So we were pretty happy to do this by hand, and save that chunk of change.

Once we located a water source, we then had to find a location for a water storage tank. Now, you don't need a water storage tank in order to make this system work, but a tank provides two key features:
1) A tank adds pressure to your gravity fed system
2) A tank ensures that you can retain water, even when your water source dries up

In both instances, the bigger the tank, the more the benefit. So, we ideally wanted a 2,000 gallon tank.

But, in order to maximize pressure in the system (maximizing, and then controlling pressure, is the key to any successful gravity-fed system), we wanted the tank as high up the mountain as possible, as close to our water source as possible. And we found a nice little pad about 100' feet down the mountain from the source.

Given the location on our property, we had to sacrifice on our plans for a 2,000 gallon tank. Instead, we figured that 500 gallons was the largest we could safely navigate up the mountain by hand.

So I looked around, and found this nifty site called Tank-Depot.com where I could order a tank for delivery to our property.

The next day, I took a 100' tape measure up the mountain, and started measuring distances for the plumbing that I would need. It turned out that I needed about 1000' feet of plumbing to reach from the water source, through the water tank, and then down the mountain to our container.

When it comes to outdoor plumbing, you have two options for materials: PVC (the hard, white tubing that generally comes in 10' or 20' lengths), and poly-pipe (the flexible black tubing). PVC is better -- it's more resilient to cracking and other external pressures, and does not contain the same materials as poly-pipe that can break-down in sunlight and pollute your water supply.

Still, 1000' is a lot. Running PVC for the entire distance would have been pretty expensive. Plus, we're running this down an undeveloped mountain forest -- using flexible poly-pipe made the process much easier. So I opted to use the hard, white PVC plumbing for a few, limited stretches of the system, and poly-pipe for the rest of the way.

With either PVC or poly-pipe, you have the question of diameter. The fatter the diameter, obviously, the more water can flow through it. In gravity systems, this creates the opportunity for more pressure in the system. Generally, the items to which you will attach your plumbing will utilize 3/4" or 1/2" connections. But, remember, you want to be able to have more than one thing turned on at once!

We opted for 2" hard PVC out of our tank for about 30', then reducing to 1" flexible poly-pipe tubing to run all the way down the mountain (much cheaper than the 2"), reducing once more to 3/4" diameter just above the container where we are consuming the water.

So we received our water tank, hiked it up the mountain, and positioned it. I could not have even hoped to have accomplished this without the help of my good friend, James, who employed his forestry and logging techniques to run the tank up the slope. Intense. And I got "bit" by the rope -- nasty blister, that.

And we went to Grover's plumbing in Grants Pass to purchase all the plumbing tubing, pipes, connectors, reducers, adhesive and other doo-dads required for the job. They were incredibly helpful -- I (a novice who didn't know anything) walked them through my basic plans, and they translated my design into actual parts. Thank god.

Back at the land, once the tank was in place, we took a pulaski all the way up the mountain, dug out the spring, laid in hard 2" PVC for 10', and then capped it off. We later came back with quick-setting concrete to ensure that the spring didn't start leaking out water, once we had disrupted the existing structural integrity with our digging.

Then we could run 1" poly-pipe from that spring pipe, to the water storage tank about 100' down the mountain.

And -- BOOM! -- I could hear the water starting to drip into our tank, even in the peak heat of the summer! Very, very exciting.

Then James and I engaged in the rather arduous process of running the poly-pipe down the property. We opted to run the poly-pipe down the draw, instead of down the ridge, so that it is covered from the sun (remember: you want poly-pipe hidden from the sun).

I probably should have buried the entire length of poly-pipe, to prevent freezing and cracking in the winter. And I will most likely do so before the winter cold sets in. But the thought of having to trench 1000' on the overgrown mountainside in the heat of the summer was too much to bear. Instead, we kept the poly-pipe in the center of the draw as much as possible -- because, in the winter, that draw is filled with running water, and covering the pipe with running water should help reduce the chance of the pipe freezing.

So we ran the poly-pipe down the draw, then curving between the driveway and the orchard, and finally to a ledge above the container.

At that point, I installed 3 sediment filters -- 50 micron, 20 micron, and 5 micron, in that order, to help remove any solid media from the flow. Each filter also have a valve to turn off the water supply during servicing. That's one thing I learned -- you can not have enough valves in your system. The more you have, the more options you have for servicing your plumbing, and for manipulating pressure in the line, especially as you start adding in different points-of-use for the water.

Once down at the office, we split the water 5 ways: a water filter, a sink, a shower, a washing machine, and a garden hose. This post has already gone on long enough, plus I don't have any nifty photos of those yet. So, I'll hopefully have some time before too long to talk about how we actually hook this gravity-fed spring water system into the utilities where the water is consumed.

But, with the 1000' run, and 250' drop, we have harvest some really amazing water pressure -- it feels just like city pressure. But, instead of city water, we have our own system, that requires no power, and which provides free, un-chlorinated water. (We did have the water tested for the potential presence of harmful elements; it's clean, except for some e.coli which we are addressing through filtration.)

But I will say one thing: Teflon tape!

If you ever have to work with threaded plumbing connections, you NEED teflon tape to prevent leaks (at least if you have any real pressure). The guys at Grovers didn't tell me. The books I read didn't tell me. And I lost quite a bit of water as a result, until I could figure that out.

That said, these two books were very helpful for me to plan and build out our water system, and I'd recommend either if you're interested in this topic, or if you have to build any type of off-grid water system.

Entitled, 'Delivering the Best Flash HD Video', the talk and code cover the StageVideo hardware-accelerated video playback feature in Flash Player 10.2 and later.

Share and enjoy!

-r

The Conference

First, as a conference, I think all attendees agreed that MAX 2011 was executed almost flawlessly. It seems that running a conference in the same location, for three years in a row, has allowed the team to perfect the experience. There were no delays, no hiccups. The party (in contrast to the past two years) was really fantastic. The production quality of the events in the main Nokia Theater were outstanding. The only thing I'd say is "Kevin, when demoing something that requires solid, stable internet access, there's no shame in faking the experience." The failure of the Creative Cloud to sync, during the day 1 keynote was really the only executional flaw that anyone noted. (Although, whoever picked the food for day 1 lunch is personally responsible for the intestinal distress of thousands of loyal Adobe users.)

So, with that in mind, it's actually pretty exciting that Adobe has announced that MAX will return to Los Angeles for one more year -- expectations are now set pretty high for 2012.

The Content

As usual, I did not actually have the benefit of attending any real sessions. I was speaking on two of the three days, and I spent the rest of the time either prepping my talks, or meeting people in the community lounge.

Several of my employees at Almer/Blank, however, did attend many sessions. And the feedback I got on the quality and information from these sessions was very exciting. Of course, my team focused heavily on the Flash Platform sessions, and the recent achievements of Flash Player 11 and AIR 3 (including Stage3D and Starling) are very exciting for the work we do. The future roadmap for Flash technologies is similarly exciting.

I did attend both keynote sessions. And the story I got from the keynotes was very different than the one my team got in the actual sessions and talks.

Day 1 Keynote

The day 1 keynote was interesting. It was explicitly not about any of their web technologies. They opened with a rather stunning visual and audio piece that really wowed the entire audience. Words can not do it justice -- you can check on YouTube if you want to see some recordings of it.

Kevin Lynch came out and proceeded to address the Creative Cloud, the Touch Apps, Digital Publishing and Subscription Licensing. On the Creative Cloud, honestly, my reaction was that this may or may not be useful to me, depending on how well integrated it is into the Creative Suite workflows. On it's own, the Cloud is simply not interesting to me (especially since Adobe has not yet stated pricing).

The Touch Apps were cool -- there's no doubt about that. And, it was eye opening for me; it was the first time that I saw in the iPad the possibility of becoming a device on which we can execute professional-grade creative work. That was exciting. Photoshop Touch looks amazing, and Proto looks pretty interesting (and worth investigating) -- the other tools, not so much. Overall, these Touch Apps were, for me, valuable for the insight I received into the future of the Creative Suite -- but none of these tools are ready for widespread adoption of real production-grade creative work. In their current version, they looked more like toys. In a couple of years, though, I expect that CS will offer some pretty amazing options for devices.

The Adobe Digital Publishing Suite is awesome. We, at Almer/Blank, are big fans. It's a great way to get expressive, interactive content to all devices -- and you don't need any code or coders, since it's right out of InDesign. Thing is, we've been using DPS for a while now -- it's not new. And they didn't announce any new features or product plans, aside from the new 'Single Edition' subscription level (again, without pricing). So, while I love DPS, there was simply nothing on DPS in the keynote that was exciting.

Finally, on subscription licensing for Creative Suite, I have a couple of reactions. As with DPS, subscription licensing isn't new. We're already moved over to it at Almer/Blank. It's a great solution (very cost effective if you upgrade with each new version, or if you scale your team size regularly). But again, nothing new, and nothing exciting for us. It is cool, though, if Adobe is able to execute as they plan, and move all CS licensing to subscription, which would then (because of accounting rules for public companies) free them up to release continuous updates to their tools, instead of waiting 18-24 months.

To their great credit, Adobe did spice up that part of the keynote, by giving all attendees a 12-month license to the Creative Suite. But, Adobe totally bungled that announcement. (When I gave my talk on Wednesday, the attendees were complaining that Adobe didn't give out any free devices this year. I asked 'well, what about the free license of Creative Suite that you all got?' Silence. Even though they had sat through the keynote, they had no idea that they'd received such a valuable set of software.)

Overall, the content for the Day 1 keynote was obviously sculpted entirely for the press. They packaged together a bunch of stuff that already existed (e.g., DPS, subscription pricing -- even much of the 'Cloud' functionality already exists in Adobe's other online tools) and a bunch of stuff that isn't-quite-ready-for-primetime (the Touch Apps) -- to try to tell a story that they are totally into this device thing, and are about way more than just Flash. In the process, however, they actually ignored ALL OF THE USERS OF THEIR SOFTWARE. Because, when your announcements are re-treads, and not-yet-ready's, there is literally nothing in there for your users.

And, I want to add, that it was obvious that there was some mandate from somewhere in Adobe that the word 'Flash' was not to be uttered on day 1. I get that Adobe is really about much more than just Flash. And I get that Adobe has many more products and platforms to message. Still, Adobe showed a ton of stuff on Monday that was made with Flash and AIR -- the 'Psych' app, and even Photoshop Touch were made with Flash Platform tech. It would have been really nice if someone, on stage, had said something like 'and oh, by the way, Photoshop Touch is made with our very own technology, AIR'. Boom -- that's it, with just a few words everyone understands how powerful Flash is. Instead, silence.

So, while some of day 1 was cool, it did not strike me as particularly useful -- and, in my opinion, Adobe forewent many opportunities to promote Flash. But, that night, in speaking with some Adobe product managers, I was assured that web technologies would get their due on day 2. And, of course, Adobe does have to mollify the press, and consider overall market positioning strategy -- so I decided to be patient and wait until day 2 to react to the content.

Day 2 Keynote

Day 2 opened with the same video as day 1. Still cool, but not nearly as exciting. And then, all of a sudden, the words 'HTML5' appear in huge type on the Nokia Theater screen. And Adobe proceeds to spend the majority of the day 2 keynote talking about all the amazing work they are doing with HTML5. When they finally get to Flash, they show some amazing games running in Flash (all on the desktop) -- I mean, we saw literally jaw-dropping performance in the Unreal engine running inside the Flash Player. That was very exciting stuff.

Overall, however, I was pretty upset with Adobe's topic coverage of HTML5 and Flash in the day 2 keynote. When they spoke about Flash, they only showed games running on the desktop. When they actually showed Flash-based experiences running on the iPad and other tablets, they specifically failed to mention that Flash was involved.

The message from Adobe that I heard was: "use HTML5 for cross-device apps; use Flash for games". (In the words of Emmy Huang, 'Flash will be the console of the web'.)

The Story

This is very frustrating for a few reasons. First, of course, we have to acknowledge the context in which all this is taking place. Apple's refusal to include the Flash Player in iOS, and Steve Jobs' stubborn and public opposition to Flash technology, has significantly damaged the Flash market. In part, this is based in truth (after all, if Flash Player doesn't run on iOS, then it doesn't run everywhere -- and you start needing other technologies to fill the gap). And in large part, this is based on lies -- people assume Flash is weak, or written poorly, or incapable of delivering rich experiences on weaker, smaller devices; or that Flash doesn't run on iOS at all.

It is shocking to me the degree to which this has impacted our market. We, at Almer/Blank, are out in the marketplace pitching solutions to real companies, all the time. In the past six months, we have had clients who have told us 'Flash is slowly dying' (from a CTO of a gaming company with whom we recently worked) and 'we don't use Flash for mobile' (from an executive at a television network here in Los Angeles).

This post is long enough already -- so I don't really want to get into the technical details of why these people are wrong. I just want to say that with AIR 2.7 and AIR 3, that story is totally different (you can read some thoughts on that, here on Almer/Blank Labs).

Now, Flash is the only technology in the world that offers a real, and compelling and practical 'write once, publish everywhere' solution to getting experiences out on to as many devices as possible. It's so powerful, that you can literally write Photoshop for the iPad with it.

And with Stage3D coming to mobile in 2012, that story is going to keep getting better.

The thing is, Adobe needs to tell that story.

You wouldn't have learned anything that I'm saying here, from attending the keynotes. Their refusal to mention the word 'Flash' on day 1, their promotion of 'html5' to top-billing on Tuesday, their relegation of Flash to the gaming world -- all conveyed a sense that Adobe is actually sort of embarrassed about Flash. It was as if they said 'sorry, Steve, you were right.'

If Adobe is not willing to stand up for the powers of their own technology, then firms are not going to select Flash for mobile development. In which case, over the next year or two, other cross-platform technologies will emerge and secure that marketplace, leaving Flash behind.

And, I should add, It's not just firms -- a huge percentage of users of Flash Pro and Builder have no idea that they have the tools and skills to publish apps and content to every major device in the world.

Instead of communicating that now, FINALLY (after two painful years) Flash offers options to get performant content onto all devices -- Adobe chose to use their annual keynote to reinforce that HTML5 (which still, by the way, does not work on over half of desktop computers) is for apps, and Flash is for games.

Yes, Flash does games really, really well (and it's doing them better, as Unreal illustrates). But Flash does way more than just games.

And while the content of the sessions was exciting and informative, it's the keynotes that create the story -- the story on which the press picks up, and which infuses the entire conference. And while I may be among the more vocal attendees, I found a significant amount of agreement from the other attendees I spoke to while at MAX.

In fact, a joke going around the conference on day 2 was "Adobe has become the Flash killer."

So that's why I was so disappointed with MAX this year. It's not enough that Flash works well on these new gen of devices (just as it does on the desktop); it's not enough that Flash offers a write-once, publish-everywhere workflow that beats the pants out of the economics of producing apps with any other technology. Just because a technology is good, doesn't mean it will sell itself.

Just as PDF offers the ability to produce documents faithfully for any screen, so does SWF provide the ability to produce interactivity and engagement faithfully to every screen.

Either Adobe needs to get out there and start promoting the powers of Flash, and actively combatting the misinformation that exists in the marketplace, or Flash will become more of a niche technology (reserved for gaming and similar experiences).

Now, after all, Adobe is about way more than just Flash, and I obviously have a distinct perspective that may not be reflective of their broader market. Maybe Adobe did tell the right story from their perspective. Maybe, given their scope of products, the perspectives of their various stakeholders, and the direction of the company -- maybe the messaging from the conference keynotes was to their benefit.

And that's the possibility that worries me the most.

The Big Orange Slide folks recorded an interview with me last May, up in Toronto, on the subject of the Digital Divide (the video will hopefully be posted soon). As I say in the post, at the time I was just beginning a still-continuing process of setting up a life on raw land in the middle of a remote slice of National Forest in Oregon. I knew I was in for quite a ride, and would have to learn a whole new set of skills in order to succeed in building a home, and even function on a daily basis in such remote surroundings.

As part of this process, I was relegated to 28.8k dial-up internet access for half a year (all the time, running a high-tech software company). And what I hadn't realized was the effect that disconnecting from the information grid would have on me.

I'm back in civilization now for a spell, as I prepare for Adobe MAX. At MAX, I will be giving to talks: one I've been blogging on is my featured talk at Adobe MAX on HD Video.

The other is a talk for the FITC Unconference at MAX.

For this year's unconference, I'll be giving a new talk, entitled 'Disconnecting: Lessons from a CTO Living in a Forest' (Monday, October 3rd, 1P at the FITC Unconference in the MAX exhibit hall).

I meant to write this talk before coming back to LA, while I was still firmly in the forest life. But I'm glad that I waited, because as I've returned to Los Angeles, I feel the mad rush of connected information flowing into my existence -- and this really does help provide some useful perspective on the subject matter of the talk. Because unlike other talks you may have heard on the digital divide in the past, this one focuses more on the effect the divide has on 'us', those who are firmly ensconced in the connected, digital reality (and are, whether or not they realize it, becoming thin-client cyborgs).

I have a special fondness for the FITC Unconference -- the creative vibe, which encourages unusual subject matter, was the venue the first time I delivered my 'Hearing Pictures' talk, which included the ideas that I eventually incorporated into Synthia, my machine that turns pictures into a classical music canon. And I hope to, once again, use the freedom of the Unconference to explore some fun and interesting ideas in a unique way, given the perspective that my 2011 has afforded me.

I look forward to seeing you all at the conference. And, if you're there, please do try to come out to my 'Disconnecting' talk, Monday, October 3rd, at 1P at the FITC Unconference.

Share and enjoy!

-r

Team Adobe kicked butt! One day, five devs, one codebase -- and published to SEVEN DEVICES.

Read all about it on A/B Labs.

Share and enjoy!

-r

I spent a nice chunk of the weekend finishing up the sample code files I'll be presenting along with my talk on "Delivering Best Video Experiences with Flash", which I will be giving at Adobe MAX on October 5th, and LA Flash on September 21st.

This talk covers a lot of ground, from video compression optimization to WMODE settings -- but mostly centers around the StageVideo enhancements in the recent versions of the Adobe Flash Player.

For those who don't know, StageVideo is a new way of rendering video in the Flash Player, that takes even more advantage of Graphics Processing Units (or GPUs, which are generally faster at working with video than CPUs).

With regular hardware accelerated video, the GPU decodes the video, but the CPU then still renders the video in the Flash Player.

With StageVideo hardware acceleration, the GPU decodes the video, and also renders the video, directly to the screen, underneath the Flash Player (and all the rest of your Flash content).

I've included the following graphics on one of my slides to help illustrate this point (click on the image for the full size):

I'll explain more about how this all works in the talk.

When it comes to using StageVideo, fortunately, it's pretty easy.

First off, if you use OSMF (the Open Source Media Framework for coding media experiences in Flash from Adobe), or Strobe Media Playback (Adobe's open-source media player built on OSMF), StageVideo just works for you (OSMF v1.6 and later). Really, it's that simple.

If you are using OSMF, and want to disable StageVideo, all you need to write is:

OSMFSettings.enableStageVideo = false;

In AS3, there is a new API for StageVideo. The new StageVideo class essentially replaces the Video class in functionality (though you still need to use the Video class in your code, as fall-back in case your viewers do not support StageVideo). This means that all the rest of your video playback code (including the NetStream and NetConnection) work the same way. All you need to do is call attachNetStream() on the StageVideo object, instead of the Video object, like so:

myVideo.attachNetStream ( ns ) ;

to:

myStageVideo.attachNetStream ( ns ) ;

Now, the StageVideo class does work differently than the Video class. First, you do not create StageVideo instances -- the Flash Player will create them for you if it can, and store references to them in a vector on the stage called stageVideos.

There are more differences than that, but if you just want to get started learning and using the AS3 StageVideo API, I'm posting one of the sample files from the talk. This is the 'simple' sample file, which demonstrates the basic code to get StageVideo playing, and little else. I've also prepared a more complex demo, including the RENDER_STATE event, the colorSpaces property, and pan and zoom functionality, which I'll be distributing to those who come to my talk (again, that will be at Adobe MAX on October 5th, and LA Flash on September 21st).

I've included the sample code, below, in this post. You can also download it as a zip file.

Again, this code is for the simple StageVideo demo. Just set this as your document class in Flash Professional CS5.5, and of course, update the _videoURL constant to point to your own video:

/* AS3
	Copyright 2011 R Blank
*/
package
{
 
	/**
	 *	This class illustrates a simple StageVideo implementation.
	 *
	 *	@langversion ActionScript 3.0
	 *	@playerversion Flash 10.2
	 *
	 *	@author R Blank
	 *	@since  09.09.2011
	 */
 
	//import the MovieClip, because this class is a MovieClip
	import flash.display.MovieClip ;
	//import the Rectangle, so that we can size and position the StageVideo instance
	import flash.geom.Rectangle ;
	//import StageVideoAvailabilityEvent so we can hear
	//when StageVideo availability changes
	import flash.events.StageVideoAvailabilityEvent;
	//import StageVideo so we can use StageVideo
	import flash.media.StageVideo;
	//import StageVideoAvailability to get the values for the
	//StageVideoAvailabilityEvent.available property
	import flash.media.StageVideoAvailability;
	//import Video as a backup for when StageVideo is not available
	import flash.media.Video;
	//import the NetConnection and NetStream to play our video file
	import flash.net.NetConnection;
	import flash.net.NetStream;
	//import the TextField so we can log values visibly
	import flash.text.TextField ;
 
	public class StageVideoPlayerExample extends MovieClip {
 
		//--------------------------------------
		// CLASS CONSTANTS
		//--------------------------------------
 
		//the location of our video file
		private const _videoURL : String = "../_media/bunny.mov" ;
 
		//--------------------------------------
		//  CONSTRUCTOR
		//--------------------------------------
		public function StageVideoPlayerExample ( ) {
			//call the _init function to startup
			_init () ;
		}
 
		//--------------------------------------
		//  PRIVATE VARIABLES
		//--------------------------------------
 
		//the Video object to play video when StageVideo is not available
		private var _video : Video ;
		//the StageVideo object to play fully accelerated video
		private var _stageVideo : StageVideo ;
		//the NetStream and NetConnection objects to play video
		private var _ns : NetStream ;
		private var _nc : NetConnection ;
		//the TextField object to log informationvisibly in the browser
		private var _tf : TextField ;
 
		//--------------------------------------
		//  PRIVATE & PROTECTED INSTANCE METHODS
		//--------------------------------------
 
		//called by the constructor to startup the player
		private function _init ( ) : void
		{
			//the NetConnection object over which video is delivered
			_nc = new NetConnection ( ) ;
			//connect _nc to null because we are playing video progressively
			_nc.connect ( null ) ;
			//create the NetStream to deliver video over the NetConnection
			_ns = new NetStream ( _nc ) ;
			//define the NetStream client as 'this'
			//where _ns will look for the onMetaData and onCuePoint methods
			_ns.client = this ;
			//tell the NetStream to play our video file
			_ns.play ( _videoURL ) ;
			//create the video object as back up, in case StageVideo is not available
			_video = new Video ( ) ;
			//listen for the StageVideoAvailabilityEvent
			//which is fired as soon as this listener is added
			//and when StageVideo becomes available or unavailable
			//throughout SWF playback
			stage.addEventListener(StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY, _onStageVideoAvailability);
			//create the TextField for logging
			_tf = new TextField ( );
			_tf.height = stage.stageHeight ;
			_tf.width = stage.stageWidth ;
			_tf.mouseWheelEnabled = true ;
			_tf.multiline = true ;
			_tf.wordWrap = true ; 
 
			//add the TextField to the display list
			addChild ( _tf ) ;
 
		}
 
		//called when we wish to start StageVideo playback
		private function _enableStageVideo() : void {
			//if we do not have a StageVideo object reference
			//already stored in _stageVideo
			if ( _stageVideo == null )
			{
				//set _stageVideo to reference the first of our
				//available StageVideo objects (up to 8 available on desktops)
				_stageVideo = stage.stageVideos [ 0 ] ;
				//size and position our _stageVideo with a new Rectangle
				_stageVideo.viewPort = new Rectangle ( 0 , 0 , 320 , 240 ) ;
			}
			//if the _video object is in the display list
			if ( _video.parent )
				//remove _video from the display list
				removeChild ( _video ) ;
			//attach our NetStream instance to our StageVideo instance
			_stageVideo.attachNetStream ( _ns ) ;
		}
 
		//called when StageVideo becomes unavailable
		//and we need to use a Video object as back-up
		private function _disableStageVideo() : void {
			//attach our NetStream to our Video object
			_video.attachNetStream ( _ns ) ;
			//add the Video object to the display list
			//(so that it can be seen)
			addChild ( _video ) ;
			//add the _tf TextField back to the display list
			//so that it is on top of the _video object
			addChild ( _tf ) ;
		}
 
		//--------------------------------------
		//  StageVideo Event Handlers
		//--------------------------------------
 
		//our callback function for the
		//StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY event
		private function _onStageVideoAvailability ( evt : StageVideoAvailabilityEvent ) : void {
			//log the availability of StageVideo
			_tf.text = "Stage Video: " + evt.availability ;
			//if StageVideo is available
			if ( evt.availability )
				//call _enableStageVideo
				_enableStageVideo ( ) ;
			else
				//otherwise call _disableStageVideo
				_disableStageVideo ( ) ;
		}
 
		//--------------------------------------
		//  NetStream Event Handlers
		//--------------------------------------
 
		//the NetStream will look for these two methods
		//on whatever object is identified as the NetStream's client
		//if they do not exist, you will receive a run time error
		//when the NetStream encounters metadata or cuepoints in the video
		public function onMetaData( info:Object ) : void { }
		public function onCuePoint( info:Object ) : void { }
 
	}
 
}

Share and enjoy!

-r

I will be giving the same talk that I will be giving at Adobe MAX, "Delivering Best Video Experiences with Flash".

This talk covers the hardware acceleration enhancements that have come in the recent versions of the Flash Player -- most notably, Stage Video, which enables you to deliver higher quality HD video to all devices on which Flash and AIR run.

I'll cover what Stage Video is, what hardware acceleration means and how it works, how to optimize video for accelerated playback, the new AS3 APIs for Stage Video, and how to use OSMF and Strobe Media Playback to avoid using any code at all! There's really content in this talk for all types of people who work with Flash video -- from designers and developers, to decision makers.

Again, that's the next LA Flash meeting, on Wednesday, September 19th @ 9PM.

See you there!

-r

Adobe MAX is rapidly approaching, and I wanted to take a moment to strongly encourage those of you who are attending MAX, to reserve a slot in my talk, "Delivering Best Video Experiences with Flash", which is scheduled on Wednesday, October 5, from 11 a.m. to 12 p.m..

I haven't yet submitted the final version of the slides (sorry, Thibault! -- I swear they look really good, and you'll get a copy very soon), but I can confidently say that this will be a really, really useful talk, if you work with video in Flash.

Yes, I added a little code to the talk, since I last spoke on this topic earlier this year at FITC Toronto. Specifically, I'm going to cover the AS3 API for Stage Video.

But, beyond that, the content is really for all-audiences who work with video in Flash. Are you a Flash designer who puts video in your work? Are you a Flash coder that builds video players? Do you work with OSMF? Do you not work with OSMF? Do you just encode video, to pass off to some other Flash hands? Do you oversee or manage people who work with video in Flash?

If the answer to any of those questions is "yes", then I guarantee you that you will get tremendous value out of this talk.

In short, while Flash video has dominated the web for over half-a-decade now (oh my god, time really flies), Adobe hasn't rested on their laurels -- instead, with each new version of Flash, Adobe keeps adding new, awesome features, to improve video performance. And now, today, it is not only possible -- but actually quite easy -- to get jaw-droppingly rich HD video playing back on almost every computer in the world! (And, increasingly, you're getting the same video performance improvements in Flash on all sorts of devices, including both iOS and Android).

Learn the increasingly rich (though sometimes complicated) landscape of video-in-Flash, in an easily-digestible format, by coming to this talk.

Reserve your space now, because good MAX sessions have a way of filling up.

Share and enjoy!

-r

As I posted today on Labs, Almer/Blank is very pleased to announce our inclusion on Inc. Magazine's list of the fastest growing companies in North America.

The experience of starting, building and running Almer/Blank continues to be one that is both incredibly rewarding, and constantly shifting in nature. We're doing projects today that we could barely have dreamt of when we started the company. And I imagine that in six more years, we'll still be creating ideas and experiences that we could not have imagined only a few years prior.

It's an incredibly exciting space to be in, and a truly remarkable and outstanding team that we have at Almer/Blank. Thank you to all of my guys at the Company, and here's to several more decades of knocking it out of the park!

Share and enjoy,

-r

I'm getting ready to head out from the office, to deliver "The Truth About Flash and Devices" at one of our clients in South Bay this afternoon. (As a reminder, if you want us to bring our brief, informational talk about Flash & Devices to you, click here to learn more.)

And I've used some time this morning to *finally* edit down and export the capture of my talk from FITC last month, held up in Toronto.

Entitled "Delivering the Best Flash HD Video", the talk is really about the new Stage Video feature in Flash Player, how it works, and how to optimize your content to deliver the maximum quality to your viewers. (I talk more about Flash hardware acceleration in this post.)

I'll be giving a similar talk at Adobe MAX, later this year -- beefed up to address the ActionScript 3 API for Stage Video.

But, for now, if you are interested in learning more about Stage Video, you can check out these two YouTube postings (~20 minutes total) -- they are for all audiences who work with video in Flash. There is absolutely no code covered in these clips.

Share and enjoy!

-r

Part 1/2

Part 2/2

Slides

As I posted last week, I will be speaking at MAX. The title of the talk is "Delivering Best Video Experiences with Flash" (Weds, 10/5 @ 11a) and I'll be posting more about that talk, as I finalize the content.

I'm very excited to be participating in MAX, and honored to be doing so again as a featured speaker.

But I'm also excited about a talk that I will be giving a talk at the FITC Unconference in the MAX exhibit hall. And, in traditional 'unconference style' the talk will be a bit unusual.

The title is "Disconnecting: Lessons from a CTO Living in a Forest", and will be (obviously) based in my experiences of recent months, trying to setup our life in Oregon, while still running a high tech firm in Los Angeles -- all without any real, or reliable internet access.

More than just a diary or a "lessons-learned" talk, this session will try to dive into some of the deeper (and I believe, more important) issues. As I write in the description:

Our use of connected technology is so pervasive, that we barely even notice it -- it seems silly to even mention it these days. As chairman and former CEO of Google, Eric Schimdt says unconnected devices are "no longer interesting" -- we don't even use them to tell the time of day anymore!

As inhabitants of the digital world, we all know many of the benefits that this increasingly connected world brings.

But this persistently connected existence comes at a price: most directly, this connected world alters our sense of time, which can diminish our patience and increase stress. At the same time, we become dependent on connected services, which, while yielding massive benefits, can also lead to a sensation of enslavement to your devices (and all the people on the other end of that connected screen). And, as the digital divide continues to expand, we lose sight of what it is to live without these advances, as so much of the world still does -- including large chunks of the United States.

We can't actually know what affect these devices and services have on us, unless we can disconnect from them, temporarily removing them from our lives. Many see this, though, as impossible -- disconnecting is not feasible, except perhaps for the occasional weekend getaway.

R Blank, co-founder and CTO of Almer/Blank, recently engaged in a project that has required disconnecting from this persistently connected world for several months. This was, of course, made all the more challenging by the fact that he serves as the senior technical officer of a high-tech production agency.

Come join R as he walks you through some of his experiences, and the lessons learned, in this process of disconnecting, and how you might be able to make use of some of these lessons to create a better sense of balance in your own life. At the same time, gain some insight into the reality and implications of the digital divide, and what this means for the future of our industry, as well as the nation.

I'm really looking forward to writing this talk, and seeing what I come up with. At the least, I promise I'll have lots of fun pictures to throw in the mix.

Share and enjoy!

-r

I know it's been awhile since I've posted -- things up in Oregon are just going quite slowly. But I expect to have some cool updates (and even -- gasp -- broadband!) before too terribly long.

But, today, I'm posting because I'm very pleased that I have once again been honored with Featured Speaker and MAX Master designations at Adobe's annual MAX conference, happening once again this year, in my adopted home town of Los Angeles.

The subject of my talk will be "Delivering the Best Flash HD Video with Stage Video", and will cover the Stage Video enhancements to the Flash Player, how hardware acceleration works, how to use AS3 to work with Stage Video, how to use OSMF to avoid using AS3, and how to optimize your video for Stage Video delivery.

I look forward to seeing you all out here in LA in October.

Share and enjoy!

-r

Writing this talk gave me an execute to get better acquainted with some of the details of hardware acceleration in the Flash Player, which led me to post my latest installment in the State of the Flash series. "The State of Flash & Hardware Acceleration" covers the recent advances in how Adobe is exploiting the computing power available in local device hardware, and tries to put them into a bit of a longer term perspective.

The key bit of history:

Again, this has all been relatively recent. Adobe first made hardware acceleration available (via ActionScript) in full-screen mode with Flash Player 9.0.115 (when Adobe also added support for H.264 video to the Flash Player). They added hardware acceleration out of full-screen mode in Flash Player 10 (triggered by setting the WMODE embed parameter to “gpu” or “direct”). They further improved hardware acceleration in Flash Player 10.1, and also made it the default playback mode (unless overridden by another WMODE). And, with Flash Player 10.2, Adobe introduced the Stage Video feature (available via ActionScript, and ensured by setting the WMODE embed parameter to “direct”), which further improves the quality of the video you can deliver, and the graphics and animation that you can support at the same time.

See you next week in Toronto. Until then, share and enjoy!

-r

Entitled, 'The State of Flash & Devices', I try to shatter some of the more popular bits of misinformation currently out there, and decipher exactly what people mean when they say "Flash runs on mobile".

For those who want more information on this topic and will be in Los Angeles on May 11th, check out the free event that Almer/Blank is hosting, “The Truth about Flash and Devices”.

Share and enjoy!

-r

Congratulations go out to the entire A/B team, especially the two stars -- Omar Gonzalez and Michael dela Cruz.

Share and enjoy,

-r