Posts categorized “workflow”.

A Stupidity-Preserving Interface

Googling is one of those things that has so saturated my life that it now seems trivial. How did programmers operate before Google? Images flit before the mind…IRC, books, co-workers…but seriously, for someone who searches hourly, the mind boggles.

If you live with Google for a while, the controversy about the Web’s inclusivity–how can we sift the smart from the dumb?–is useless. When I was a stupid programmer, I found a lot of slightly-less-stupid blog posts, tutorial and articles that spoke to the stupid in me. When I become less stupid, other voices beckoned. The web grows with me.

Lately I’ve been wondering whether the web should preserve even more stupidity. When I really look at the hours I rack up programming, far too many of them are consumed with stupid mistakes, especially when starting fresh on a new kind of task, language or project. Google is still helpful then, but all too often I find myself grinding through some stupidity alone.

This is partly due to the fact that the set of smart, conceptual mistakes is a minor subset of all possible mistakes. “It’s” v. “Its” is downright hi-concept… “accommodate” v. “acommodate”, “accomodate”, “accommadate” is nearly random in comparison. Not even the web can preserve all the permutations of sheer error.

More… »

Faster development with AS3?

I was talking with my boss tonite about a big project coming up. He was explaining that a client was thinking of building a new site in AS2. I was dismayed. After developing with AS3 for a while, I was doing some AS2 work and hating it. After AS1, AS2 was a godsend, but after AS3, AS2 is a huge pain in the ass.

He patiently explained to me that my personal likings were not the only factors to consider. There was a lot of AS2 code that could be re-used. AS3 developers were rare and expensive, and training takes time. Etc.

In truth, weighing all these factors is above my pay grade. He is probably right in this case. But, of course, that’s not what I said. Instead, I threw out that AS3 development is just faster.

More… »

why sitechecks are lame

At Flash sites, the busiest forums discuss code rather than design.

This is odd considering the number of Flashers who straddle the developer/designer divide.

One explanation: 1) It’s hard to discuss interfaces in a way that can be represented in a forum. In fact, it’s hard to prototype interaction period. (In order to discuss an interface, you basically have to build an interface…at which point you are committed.)

Another explanation: A lot of design is proprietary: your client would not care a whit if you post a snippet of code you are using on her site…but she sure as hell would care if you offered its design for public scrutiny.

I’m not sure how to overcome these obstacles. As it is, I don’t bother posting in the sitecheck forum. Once people show their sites, all the major decisions have been made, and the only polite thing to do is niggle.

a pang for Flash innovation

Until I looked at Flex this weekend, I didn't believe Jesse Warden when he predicted that Flex would retire Flash into a Director-like, niche position.

Well, now I believe. And I feel a pang for Flash. Not because I give a damn about the technology–there will always be another technology–but because I hoped Flash would be a uniquely powerful tool for creating new kinds of interfaces, whether in art, education, or entertainment.

I don't know Flex at all, really, but I've seen enough to know that its strength relies on HTML-like standardization of interface components. Sure, I bet (though I don't know) that Flex is a great tool for fashioning new components, and high-level AS coders will be able to find work tweaking Flex and bringing it beyond itself…but that won't go to the essential strength of Flex.

Standardization is a win-win for developer and users: develops can develop more quickly, and a la Nielsen, users can use more quickly.

So what's to gripe about? Nothing, I suppose. In the years since Flash 5, when complex interfaces became possible, has Flash become a great font of interface innovation? For instance, what has the opportunity to create your own widgets added to the broader vocabulary of interfaces?

The preloader progress bar used in iTunes music store? Occasional spasms of industry self-congratulation notwithstanding, there's little to celebrate.

What's to conclude from this failure? Well…the people who specced out HTML really hit the nail on the head. (When something Flex-like kills HTML, we should say, the king is dead, long live the king.)

Or…progress in interfaces is much, much slower than progress in technology, because it's cultural. Designers have to get beyond their assumptions, and users have to form new expectations.

Unfortunately, after Flex, the institutional impetus for innovation will be momentarily stalled. Flash developers will become Flex RIA developers, HTML will get tweened transitions…and the Flash designers left behind will be the least able to deal with interactivity.

Just to be obnoxious, I'll designate their Flash "L.A. Flash" because it is mostly produced by advertising agencies and movie studios. It's basically Flash meant for broadcast. One damn thing after another.

When I was at the Jobstock (that's a L.A. Flash job fair), all the employers that presented said they required Flashers who avoid "flashturbation" and thought interactively…then went on to show their material, which was 99% "flasturbation" with a pinch of interactivity.

I don't blame them; it's especially difficult for people who think in pictures or moving pictures to think in interaction…but it's hard for ANYONE to think in interaction. We are at the beginning, I think.

One slight reason for hope is the pressure that On2 and broadband will put on Flash designers. So much of what they do is basically crappy faux video…but when Flash can port high-quality video over broadband, what's the point? Let the After Affects people do their thing…and then Flash designers can focus more on interaction, and hope their best work will be integrated into Flex.

Flex, Flash made easy

I have to admit that the official description of Flex always left my head spinning with buzzwords and corporate breathlessness: RIA…bundled technologies…enterprise scale…presentation tier…standards-based.

It took this short video (the Kuwamoto one), in which a Macdobe engineer builds (in about 15 minutes) a visually arresting application that searches Flickr and fades in the resulting pictures, to bring me to face to face with the astonishing truth of Flex.

After seeing this promotional video, I bet that Flex will ultimately displace HTML, whether "Flex" remains an Adobe technology, or is superceded by a rival company's technology or (optimally) an open-source format.

Why? Because it's EASY. I'm sure that it's not as easy as that engineer made it look, but I'm sure it's not much harder, either.

Here's a rough cheatsheet on Flex:

MXML (the XML markup language that produces swfs in Flex Builder)==HTML
Actionscript==Javascript + (parts of PHP and CSS)

If you focus on the differences between MXML and HTML (like, you know, MXML is worlds more powerful), you miss the point of the comparison: MXML seems as easy as HTML to learn (WYSIWYG-able mark-up) and develop (a stable set of components, a quick way to permutate swfs).

Yes, Flash Made Easy does make sense for "desktop on the web" (no page refresh, resizable windows) and enterprise-scale projects (dynamically generating different swfs, like PHP dynamically generates HTML)…but looking at this video, I sensed a more grandiose ambition.

If Flash can be made this simple, why can't Flash be made simple enough to fit into Dreamweaver, and the power of connected multimedia be made available to individuals and small companies? That seems like the logical next step.

work habits as component

Last week I had my first freelance Flash gig, and it was more educational than I expected–or wanted–it to be…

The fault lie entirely on my side. The mission specs were vague and the timetable insane, but I understood that going in…and ultimately failed to adapt.

As a Flash hobbyist and learner, I've developed a consistent work process: ponder, plan, execute. Under the pressure and excitement of my first gig, I threw this process out.

This was a mistake. In the context of this particular gig, whether this process is optimal or not just doesn't matter, because it's my current process, and I can't swap it out for a new one with the ease of Keanu Reeves learning kung-fu in the Matrix.

The trick will be to adapt my current process to the task at hand. I should treat my work habits like components, throwing them into projects and parameterizing them accordingly, rather than trying to revamp habits, a longer-term undertaking.

Now I know.

FlashDevelop, at the speed of thought

My months-long Goldilocks-like search for a decent AS code editors recently came to a blissful conclusion here:

FlashDevelop

I was in a long, bad marriage to the Flash editor, which I couldn't leave, because I was on OS X and the alternatives were buggy (the SEPY port to Mac, ASDT in Eclipse), expensive (FDT) or undeveloped (XCode, FAMES).

Reading about FlashDevelop (here) pushed me over the OS X edge: I got hold of a copy of VirtualPC, downloaded FlashDevelop (and the Microsoft.NET framework, which installation requires) and began coding…

The experience was trance-like. Now I understand why people get so attached to their editors. This one has all the usual features (code completion, class libraries) plus the almighty F4: press F4 while your cursor is over a word, and the editor brings you back to its origin (function or variable declaration or class definition), automatically opening files if necessary.

Typically coders laud editors because they save them time; FlashDevelop made me rethink their acccolades.

How much clock time does it actually take to scroll back to a functon declaration or open a class file? Yes, it adds up, but does it compare even remotely to the time you spend rubbing your temples or scribbling diagrams?

Rather tools like FlashDevelop make you more efficient by automating tasks that other otherwise interrupt the flow of your thoughts. They allow you to concentrate purely on the task at hand–the programming logic, for instance, not that ugly heap of conditional brackets.

More generally, the need for speed should be understood as a need to think clearly. The speed of Google helps me think: What are the best search terms? What, exactly, am I looking for? Conversely, waiting for a sluggish program to open up, I lose more than a few seconds, I lose the time it takes to re-establish my train of thought (if I can at all…I'm easily confused).

Random exasperation: swfs could be faster and more intuitive than html pages, so why are they almost uniformly slower?