something in the way

Permalink | Leave a comment  »

Now that Flash on the Beach is over for another year, I thought I would write a quick recap since there were a lot of interesting things revealed at this year’s event. As I sit writing this I am in the Adobe France office recovering from the flu which hit me half way through the conference. Below are some of the highlights from FOTB in no particular order.

People love bytes
On Sunday, I gave a full-day workshop on using the ByteArray class in Flash. Half-way through I started to lose my voice and got a sore throat. Luckily I had Thibault there to help me throughout the day. The workshop was a little rocky in the beginning because I think there were some who didn’t need to do a recap on things like binary and hexadecimal numbers. But this was necessary just so everyone understood the basics. The class quickly got very excited when we started to build some real world examples like creating an FTP client and parsing and displaying a Photoshop PSD file. I think most people left the workshop with a ton of enthusiasm about low-level programming in Flash. Based on the great feedback, I will also be doing a similar workshop at FITC Amsterdam and FITC Toronto.

AIR 2.0 native extensibility
Although I didn’t get a chance to see Mike’s session, I was happy that we finally were able to announce some of the great new features in AIR 2.0. The biggest addition is the ability to call native processes directly from your AIR application. Mike showed an example where he created a screenshot application by communicating with a native process. As part of that application he also showcased another new feature in AIR 2.0 which is the ability to launch the default application for a particular filetype on the user’s system. Another demo Mike showed was the new volume monitoring feature where you receive events when a new device is plugged into the system. In this case it was an HD Flip camera. Go on over and check out the slides to get all the details.

gOptimizations
One of the sessions I was most looking forward to was Grant Skinner’s talk on optimizing ActionScript 3 code and it did not disappoint. Grant is one of the few speakers who can talk about really complex topics in a way that is understandable to us mortals. The talk was filled with great tips on making your code run faster and it was all backed up by actual numbers. I could run through some of the tips here, but it will be much better for you to just check out his presentation slides for yourself.

Ralph leaves Papervision3D
Unfortunately we were en route to Paris while Ralph Hauwert was giving his session but I have heard nothing but great things about from people who were there. One big piece of news is that Ralph has decided to leave the Papervision3D team to pursue other things. Now this should not be taken as a sign that Papervision3D is going away or that it is having trouble. The PV3D team is still going strong and we should still expect to see PapervisionX hit the streets at some point. As for what Ralph is going to do next, we’ll all just have to wait and see.

Flash CS5 gets a real editor
During the keynote, Richard showed a couple of sneaks from the next version of Flash. This was great especially since MAX is less than two weeks away. One of things that I was really happy to see was the addition of full custom class introspection in the Actions panel. This will make it much more enjoyable to write code in Flash for smaller projects and creating demos. I told you all that feedback you gave would make a difference . In addition to that, Richard also showed the new integration with Flash Builder as well. When you create a new class in Flash, it asks you whether or now you want to edit it in Flash or Flash Builder. If you choose Flash Builder, a project is created for you with the current FLA included. Also if you are in Flash Builder, you can create a new Flash Professional project directly and easily jump back and forth between Flash and Flash Builder.

Joa is on another level
Without question, the session that everyone was talking about was Joa Ebert’s session. He talked about some amazing tools he is writing to optimize SWF files. He basically called out Adobe for having a subpar compiler, and after watching his talk, I couldn’t help but agree with him. A lot of what he talked about kind of went over my head but it was amazing to see some of the optimizations he was able to make. All of us at the conference from Adobe left with the feeling that we need to work more closely with Joa in the future to try and get our compiler more up to date. One thing he said kind of hit home for me. ActionScript developers shouldn’t have to worry about doing all of these little code optimization hacks in order to get more performant applications.

Already looking forward to next year!
Lee

Put your ears in control says Sony Ericsson. Their new, one of kind, motion sensing ear phones do just that. Animation by Kristofer Ström. (via not cot).

Depois de Matosinhos (LCD) e de Lisboa (AltLab), a Audiência Zero passa a contar com um novo projecto de criação e experimentação: o xDA, em Coimbra. Todos estão convidados a visitar o blog deste novo espaço dedicado à criatividade e à tecnologia, o endereço é www.xdatelier.org. Mais informação e pormenores sobre inscrições neste link.

"Ghana is the heart of Cadbury Dairy Milks Fairtrade Cocoa and so the track celebrates all things Ghanaian: its people, its rappers, its dancers, its cultural figures and, of course, its cocoa beans.
Buying Cadbury, or downloading the song at iTunes, you'll be sponsoring Charity 'CARE'."

As the ultimate proof of how ubiquitous visualization has become, one can now decorate a fridge with highly stylized information graphics illustrating the recipes of popular cocktails. Next to the refrigerator-sized Cocktail Information Graphics [hu2.com], there is also a detailed Corkscrew Instructions for the kitchen wall, a funny Bath Duck Level for the bath tub, and a Gin Cocktail List for the living room available.

One does not need to stop there, and can choose to adorn each electrical cable and power outlet whith its own infographic Cable Organizer.

Thnkx Romain!

User Experience Design (or UX for short) has exploded on the software scene carrying a blazing torch of freedom and promising to guide us to the holy land. We are now dedicating time and resources specifically to user experience design. This emphasis on actually designing user interactions and the experience of our applications is a fantastic effort and I applaud all those that wave the UX flag and sing its praises. But I have one problem: UX is making me a worse software developer.

An unfortunate byproduct of the UX revolution is the misinformation that developers simply can’t design good experiences. We see article after article explaining what happens when you leave developers in charge of UX design. People laugh at how stupid developers can be, that they just don’t “get it” when it comes to designing things well. These articles should highlight the importance of explicit thought when designing interactions in applications, they should not strip developers of their confidence and creativity. And yet that’s exactly what I’ve noticed happening to me.

Let me relate a brief hypothetical example. On our software project I am the lead clientside developer. We have a UX Specialist (aka UX Guy) that is responsible for the design of wireframes and mockups that explain how the user navigates through the application. During the UX pass, our UX Guy listens to us (developers and business guys) explain what the problem is and what we think we want the software to do. Then UX Guy goes off and comes back with a set of wireframes for how the application will work. We discuss, bring up problems, send back the wireframes for further iteration. Repeat that process until everyone is satisfied with the wireframes, then move on to actual development of features.

But then during development I have found myself getting the following question from my manager: “Hey Doug, how come you can’t do Feature X in the app?” and I have found myself actually saying this (shudder): “Oh, I guess that wasn’t included in UX Guy’s wireframes, you should ask him.” That’s a bullshit response. I’m not a neutered incompetent mindless developer. If something doesn’t work or was forgotten, I can figure out how to fix it. That doesn’t mean throw the code in without thinking about design. That means pausing my code writing, thinking through the problem carefully, designing a solution that will be sleek and elegant, and then continuing on with development.

And yet in my mind I have the unconscious prejudice that I, as a developer, cannot be allowed to make “UX” decisions. Fuck that. We are all responsible for designing the experience of our software. We are all responsible for carefully thinking through every interaction. We are all responsible for making things beautiful, making things simple, making things elegant. And more than that, we are all capable.

Since it's a few weeks into September and I'm involved in design education—teaching a class in the graduate program at Pratt and another at the School of Visual Arts, both in New York City—I thought it appropriate to write a little about design students and the notion of Intent.

Intention is one of those pivotal terms in design. Many have used it to delineate design from art (bo-ring), arguing that design has a different kind of intentionality. (I'm not sure I'd want to be in a bar with a bunch of fine artists, accusing them of a paucity of intention, for the record.) But there does seem to be something to the notion that designers are intentional in a more-or-less deductive way; that the fruits of their labors (or at least the labors themselves) are somehow "logical" or necessarily so given a number of circumstances. Those circumstances can be insights from design research, for example, or manufacturing constraints, or market factors. This kind of deliberateness or intentionality finds a safe haven in the minds of designers, who, for all their paradigm-busting reputations, seriously need constraints in which to operate (I am about the millionth person to remark on this; faves are Charles and Ray Eames and Ralph Caplan).

For design students, though, the idea of being "intentional" is far from prosaic. Indeed, it needs to made explicit. Let me explain.

If you give a set of design students a design problem, the first thing they do is design something. They don't look at the design problem as a problem at all, usually, but rather as a canvas on which to paint "something they like." You hear them use this expression verbatim, actually, especially when you ask them about what's not there: "Why didn't you mock up the design you talked about last week?" I'll ask. "Well," they'll respond, "I didn't like it." This exchange has played out so many times in my years of teaching (16) that I find myself getting relatively exasperated...even driven once to retort, "It doesn't matter what you like! Liking has nothing to do with this!" Now, admittedly, I lost it right then, but what this illustrates (or at least illustrated to me that day) is that very often, a designer's response to a problem is a personal one—not driven by constraints, or research, or rigor, or objective value. And you'd think this would be a good thing for a creative person, that expression of a personal point of view. But a lot of the time, it can very much get in the way.

So you actually have to spell it out for them: "I think your design work would be stronger if your intention was more obvious, or made more obvious," I'll offer. They look at me with a blank stare. What do I mean by that?

"I mean that it's clear that you were actually going after something. That you were deliberate, intentional, methodical, [and okay, deductive] in the design process. And that we can see the design problem in the design solution."

Sometimes this makes sense to the students, and sometimes it doesn't, but I know deep down that right at that moment they are pitying me for being ignorant of—or at least shortchanging—their personal vision. At least the grad students are, anyway.

And yes, the irony here is that you need to spend just as much time hammering students to put more of their personality into their design; to have a point of view, and to not be afraid to express it. But if not the yin and the yang of the thing exactly, then these are at least two sides of one of the coins of design pedagogy: students need to be more intentional—objectively. But they also need to have a voice—subjectively. And that's where a healthy dose of prejudice comes in, which we'll pick up on next.