Adobe XD

UX: Leveraging Return on Experience

Grant Skinner — 02:00 pm 11/23/09

Most users have years of experience working with graphical user interfaces. It makes sense to leverage this experience, making interactive applications easier to use by emulating interfaces users are already familiar with. Most designers already do this intuitively, by emulating the tools and UIs they themselves are familiar with.

However, it's important to make this a more conscious exercise, and consider the context (there's that word again) of the target user's specific experience. An application interface targeted at gamers may differ greatly from one targeted at enterprise users who spend most of their days in Outlook and Office - not just in the design treatments that appeal to each group, but in the specific controls and design metaphors that are familiar to them. You may also choose to make subtle UI changes based on the OS your users are familiar with - these can even be made dynamically, at runtime, based on the detected OS.

Obviously, if your application is replacing a legacy system, or is an alternative to a market leader in the same space, it is important to carefully consider the established UX metaphors. You may come up with a better approach than the existing system, but you have to weigh your improvements against the fact that users already know how to use the old application, and will be biased towards it (unless it really does suck).

Finally, consider your deployment strategy. Deploying to the desktop, it may be more important to mimic the user's OS to provide a better integrated experience. On the Web, you may see a benefit from supporting familiar navigation metaphors like deeplinking, bookmarking, and the back button. Deploying for mobile is trickier, because each device OS has its own set of UI expectations - designing an app for a Nokia flip phone can be very different than designing one for a touch-screen iPhone.

Return on Experience (ROE) considerations are important in making design choices as well. Using metaphors and references from the real world can help convey concepts to users. This is why OSes are populated with trash cans, windows, and menus. Similarly, the language presented to your users is a factor of their previous experience - with a non-technical audience, you may want to describe an XML parsing error in laymen's terms: "A problem occurred while loading your data." It's also important wherever possible to communicate a proposed resolution: "Please wait 5 minutes and try again, or contact your system's administrator." This provides less experienced users with a sense of control, and helps retain their trust in the system.

To see the results of ROE-driven design, look at standard buttons and fields. Things that can be pushed or clicked - i.e. buttons - are usually designed so that they appear to extrude out of the view, and can be pushed down. Fields, on the other hand, usually appear to be punched into the screen. Maintaining this consistency not only leverages a user's experience with decades of digital UI, but also simulates the real-world tactile designs of press-able buttons, and containers to put things into.

Leveraging ROE provides many benefits. Familiarity breeds comfort for users, which in turn translates into trust and productivity. Design is also easier because you have a set of useful reference points for making design decisions. I'd be willing to bet most designers, while tackling a difficult UI problem, have opened up an app, to see how the pros solved it.
ROE considerations are important when making other sorts of design decisions too. You can leverage ROE, for example, by maintaining a consistent design language in your application – by utilizing imagery, language, colors, icons, transitions, layout rules, and controls in a consistent manner.

This is obviously minimally important when creating banner ads or microsites - a user only spends a few seconds or minutes interacting with these. But in the case of larger applications, a consistent design language makes the user more comfortable and productive. It also helps build a sense of trust with the user.

By spending time familiarizing developers with the core design language being used in a project, you can also help the design team by enabling developers to be more consistent in translating their designs into finished application features. (Developers, after all, frequently have to make "design" decisions, to fill in gaps in what designers have given them – and you want to do anything you can to guide them in this.). Also, you'll minimize the developer's need to consult with the design team on changes or missing elements.

UX: Considering Context

Grant Skinner — 02:00 pm 11/19/09

Probably the most important thing to keep in mind while thinking about UX is context.

Context is obviously a key consideration on the macro or conceptualization level, where you must think about the context of the target audience, the brand, and the project goals. These considerations help shape the aesthetic design, the layout, and the functionality. Briefing the whole project team on these contextual factors ensures that everyone will be working toward the same end goals.

Another contextual factor is the technology being used. Developers should obviously be aware of the strengths and limitations of the technology they are working with. But during the conceptual and design phases of a project, you can also help avoid creating false expectations among stakeholders by educating designers and project leads about this technology. Likewise, involving developers early, to review and comment on specs, wireframes, and conceptual designs, can greatly smooth the project path.

It's equally important to consider context on the micro or implementation level. Each time you place a new control, or a piece of content, you need to consider the appropriate context for that element. Is it on the correct view? Is it grouped with related elements within the view? Most importantly, will it make sense given the user's current task focus? Answering this sort of question is mostly an intuitive exercise, and sometimes you can resort to iterative design or applied logic. In larger projects, meanwhile, you might resort to user testing.

One positive trend in RIA design is the move away from full state changes and the overuse of dialogs. Dialogs and state changes yank users out of their current context and impose a new one. Surfacing content on demand, without disturbing context, keeps a user anchored and task-oriented.

Developers should also think about UX context when deciding when to optimize code, carry out expensive operations, or initiate loads. For example, an operation that takes 200ms and runs every frame probably needs significant optimization or rethinking. Otherwise it will lead to a choppy experience. That same operation would likely be fine, meanwhile, if it happened on a user interaction like a button click.

Context also plays an important role in deciding how to communicate status to the user. For actions that take longer than a second, it's good to show some kind of static indication that something is happening. For actions longer than 3-4 seconds, it helps to show an animated distractor (spinning arrows or barber poles are good examples) to indicate the system is still responsive. For longer actions, it's important to show a meaningful progress indicator, so the user trusts that something is actually happening, and can get a sense for how long it will take. In a couple of instances, I've actually had clients and users praise our work in speeding up a task, when in fact all we did was add a distractor or progress bar. Ultimately in UX (and politics) perception is more important than reality!

In the perfect world, applications would be so well-designed and so intuitive to use that it would never require help systems. In reality, help is often a necessity, and it's important to consider how you can contextualize it. Providing help inline, with tooltips, allows users to view contextual information unobtrusively, without losing their focus. Where more detailed help is a requirement, consider opening it in a non-modal overlay, pre-populated with content that is relevant to the user's current view. Let users move and collapse the help window, so they can read it and interact simultaneously.

Keeping context in mind is important to everyone throughout the life-cycle of a project. Doing this will result in more usable, goal-oriented deliverables.

Design and Development, In Collaboration

Remon Tijssen — 04:06 pm 11/17/09

Visual Programmer Ralph Hauwert and Adobe Experience Designer,Remon Tijssen, talk about the convergence of web and desktop applications and the benefits of a close designer/developer relationship.. (4:15)

Really Real, Right Away: A Conversation about Flash Catalyst

David Womack — 04:05 pm 11/17/09

A conversation with Guillermo Torres Troconis.

For those UX designers not already familiar with the Flash Catalyst, why should they check it out?
Flash Catalyst allows designers to start creating real web and desktop experiences themselves from the very beginning of the design process—rather than mocking up comps and then relying on developers to faithfully recreate them in working code. It let’s you start working with the real thing, right away.

Who is Flash Catalyst for?
Any designer who wants to build applications and web sites in Flash. But I think it’s particularly useful for designers who don’t yet know Flash programming. We’re already seeing a bunch of schools who are first using Flash Catalyst as a way to teach the principles of interaction, before moving on to teach them Flash programming. When you’re getting started, you want to set up a basic site structure and have some navigation and basic states of your application and your focus is on having those basic elements work together. These are the things that people who are new to interactive media have to learn. In Catalyst, you can do this really fast and can achieve a lot with simple visual interactions without needing to use code. You learn how a button can relate to different screens and different states of your application. Before Catalyst, it could be pretty overwhelming for the newbie to both have to learn about interaction and interactivity and to start with Flash programming. But we’re still hoping they will learn the programming. We’re hoping that for students starting out, Flash Catalyst is a gate-way drug.

How do you see Flash Catalyst being used by more experienced designers?
I see it as a tool for interactive designers to set up and sketch quick interactions. And we’re going to see it more as a tool for designing behavior. So you can start experimenting with how things work and behave right away, as part of the sketching process. It’s a great tool for information architects or interaction designers.

Were there changes to Flash that made Flash Catalyst necessary?
The issue is that with the introduction of ActionScript 3 it became so complicated to code that a lot of designers were left out—I’m actually in that category. I used to use Flash all the time and when the programming stopped being quick and dirty it just became too cumbersome for me to experiment with. For me, it was more about exploring motion and interaction than about creating robust applications. But Flash also has to accommodate developers that are taking Flash to the next level by doing the huge, complicated projects.

Do you see Flash Catalyst some day replacing the need for front-end programming?
Working on Flash Catalyst has given me a new appreciation for Flash programming. Being able to code is very powerful and it allows you to explore a lot of different methods and options. But Flash has also become very complicated. Flash Catalyst is trying to fill in that spot for designers who don’t know how to code and mostly need to do stuff that’s pretty simple. There are a lot of things that can’t be done in Flash Catalyst. But then if you really want to get into programming then Catalyst isn’t the tool for you.

What’s an example of functionality you weren’t able to incorporate?
Well one of the main ones is that right now you can’t have dragging interactions. To make something draggable you have to set up the area it can be dragged around then you need to set up what the goal is—the hit area. If the object is dragged and released, then something else has to happen. It’s not just one function, you would have to add a bunch of different conditions. And it’s just too much to handle for Catalyst right now.

Does Catalyst change the relationship between designer and developer?
For those designers that work on Flex app shop, we’re going to take a lot of the UI development away from the developers and bring it to the designer. So the designer builds the interface and all the developer really needs to do is plug it in to the data. The advantage is that there’s very little lost in translation between the designer and developer because the developer doesn’t need to take all these static comps and images and cut up all the assets and bring them in. The designer creates the interface and Flash catalyst makes it possible to export that interface and bring it into a Flex app.

But it occurs to me that the Flash developer may understand the alternatives better than the designer who uses Catalyst. By allowing designers to make the interface without understanding the code, are you encouraging a narrow view of the possibilities?
I think, if anything, it will improve the conversation between designers and developers because there’s going to be more back and forth. One of the things we’re working on is improving the workflow. For Catalyst 1.0 it’s mostly one-way—a designer does some stuff and then hands it off to the developer. But in the future, it’s very important that there be a way back that the developer can provide input and then the designer can change stuff according to what the developer has done.

What has been the reaction from developers?
Very positive so far. In fact, the developer community is at least as engaged with the Beta as the designers are at the moment. By making it easy to create common interactions, it frees up more time for innovation. It takes care of the easy part so developers have more time to focus on what makes their Flex apps stand out from the rest of the apps. It gives them time to develop new ways of interaction and innovation. My experience is that any Flash developer thinks scrollbars are a pain in the ass. That’s something that a lot of Flash developers are doing over and over again. I hope we’re freeing up time for them to focus on the rest of the stuff that Catalyst can’t do.

What was it like to design this interface within the Adobe product landscape?
We’re merging two tools that were originally developed by different companies and a lot of the tools Adobe has are also coming from other places and the same is true of Macromedia. So we still have different sets of UI that take a lot of time to replace. To create consistency, we try to work from a sense of where Adobe apps are going and aim for that future state. Things change as we go along because you also have to be consistent with the OS so as new versions come out. And, because it’s Adobe, the expectations are high.

Blueprint: Bringing Web Search into Flex Builder

Joel Brandt & Mira Dontcheva — 04:04 pm 11/17/09

Can you write code without an Internet connection? Me neither. I noticed this about two years ago when I was trying to do some prototyping while on a cross-country flight. Just as it has changed so many other aspects of our lives, the Web has transformed the way we write code. We use the Web to look at API documentation, to ask experts questions in forums, and to translate cryptic error messages into something we can understand. But most often, we use the Web to find code examples.

Yet while the Web plays a central role in today’s development practices, the Web browser and development tools remain separate. Development tools make no distinction between code you type in, and code you paste in from somewhere else. And the Web browser and search engine remain largely ignorant of your overall task and programming project.

In the last year, we have been exploring how development practices might change if we integrate Web search into the development environment. Could we deliver more relevant search results by looking at the programmer’s context? Could we make coding faster or easier? Could we help you write better code by showing you more examples?

To explore these ideas, we built Blueprint, a plug-in for Flex Builder. Blueprint allows you to search the Web for example code, without leaving your editing window. You might think of it as Web-enabled auto-complete. Blueprint uses Adobe’s Code Snippet search, which returns blocks of example code, rather than individual Web pages. This makes it faster to scan many examples, and thus easier to find the most appropriate example.

Take a look at this video to see how Blueprint can be used to make example-centric programming easier.

Blueprint’s Interface

Blueprint’s interface builds on existing auto-complete interfaces by supporting keyboard-only navigation. A hotkey (Ctrl-B) places a search box (A) at your cursor position. If there’s already code on the line where you initiated a search, that line of code is used as the initial query. This makes it convenient, for example, to use Blueprint to get code snippets about a class you just found through auto-complete.

The search results (B) are example-centric; each result contains a brief textual description (C), the example code (D), and, when possible, a running example (E). There’s no need to click through to the source webpage to evaluate each search result. The search terms are highlighted in the source code (F), which lets you rapidly scan the result set. You can scroll with the up and down arrow keys and paste code into your project by hitting the ‘Enter’ key. Finally, if you find an example particularly good - or bad! - you can let others know by rating it (G).

In addition to the pop-up interface shown above, Blueprint can be docked as a permanent panel in Flex Builder. Docking Blueprint is useful if you want to keep an example around as a reference, or want to look at the code while you type. Blueprint also allows you to follow hyperlinks, to view search results in context, and maintains a browsing and search history.

Evaluating Blueprint: How are people using it?

We released Blueprint on Adobe Labs in June. In the first three months over 2,000 people used Blueprint, making over 17,000 queries. We instrumented Blueprint so that we could measure how people used it by logging queries, clicks, and copy events. Before analyzing the logs, we met with some of our most frequent users and asked them how Blueprint fit into their development practices. We used the intuitions gathered from these interviews to drive our log analysis. Here’s what we found:

Page context is not critical - Since Blueprint strips webpage context from example code, we wondered whether the code examples would remain useful without the page context. Fortunately, we found that for many tasks, code is what is most easily understood. One participant said, “Highlighting of the search term in the code is key. I scroll through the results quickly… when I find code that has it, I can understand the code much faster than I could English.”

Example-code is most useful for reminding and clarifying tasks - One of our users described Blueprint by saying it addressed the “mid-space between needing to jump down into API docs when you don’t know what you’re doing at all and not needing help because you know exactly what you are doing.” He went on to say that, when using Blueprint, he could find what he needed “60 to 80 percent of the time without having to go to API docs.” Blueprint works best when you have some idea of how to do a task, but either need a hint to make sure you’re on the right path, or just want to save time by copying code rather than typing it yourself.

Blueprint is often used in concert with auto-complete - Our interviewees showed us that they often used Blueprint immediately after auto-complete. Auto-complete allowed them to find the exact class that was relevant to what they wanted to do. Then, by hitting one more hotkey, they got code examples that showed how to use that class. In a sense, Blueprint and auto-complete were symbiotic, each making the other more useful. Indeed, when looking at the logs, we saw that roughly three times as many Blueprint queries contained correctly formatted code when compared to queries to Adobe’s Community Help search engine.

Lowering the cost of search changes when people use search - We found that Blueprint users made different kinds of queries in Blueprint than they made in the browser. With Blueprint available, users were more willing to go to the Web, even for the smallest tasks. For example, the query “alert” was made four times more often in Blueprint than in Adobe’s Community Help search engine. Why might this be? Well, alert dialogs are often used in debugging, or as a stand-in for a yet-to-be-implemented feature. They’re often convenient, but not necessary to use. Finding the one line of code to display an alert dialog takes just a few seconds with Blueprint: see (1) in the figure below. Without Blueprint (2), you’d have to switch to a different tool, get to a search engine and construct a query, select a relevant result, and then hunt through several pages of text to find that same line of code. In many situations, this just isn’t worth the effort. We believe this example shows that task-specific search engines like Blueprint can expand the space of tasks for which search is a useful tool.

Take it for a spin!

You can install Blueprint for Flex Builder from Adobe Labs.

Do most of your coding in Flash? Just want to search for code without installing a plug-in? You can use Adobe’s Code Snippet search.

Does Blueprint fit into your development process? Are there ways you think it could be improved? Please, let us know what you think in the comments!

Flex and Flash Builder 4: Web Apps for Everyone

Rob Adams — 04:03 pm 11/17/09

The Adobe Flex framework has always been versatile enough to support the development of a variety of different types of web applications. But with each new version of the framework, we’ve focused on making a particular type of application even easier to build. In Flex 1, we focused primarily on large enterprise applications, apps with complex interdependencies, carefully organized architectures, and massive data requirements. In Flex 2 we continued along those lines, but also introduced component skinning and effects, making it easier for developers to build highly designed consumer-facing web applications. Flex 3 further refined our work in these areas, and now, with Flex 4 and Flash Catalyst, the framework and tool chain have blossomed into a powerful, flexible platform for building richly visual RIAs.

But we weren’t content to stop there. We noticed that while we were busy with component architectures and whizzy graphical effects, many customers were quietly building small, focused web applications using our technology. These single developers or small teams were undertaking heroic efforts to build highly functional applications under very tight deadlines. They care about creating great experiences, and love the fact that Flex makes it easier to create such experiences, than it is with HTML and AJAX. But they care less about complex architectures and custom designed controls than they do about productivity - they wanted to build great applications quickly and easily. We felt we could do more to make this a reality.

Rapid Application Development for the Web

In the good old days - the 1990s – many programmers built desktop-based client/server applications using rapid application development (RAD) tools such as Visual Basic and PowerBuilder. RAD tools helped developers build small applications amazingly quickly. But they aren’t as popular as they once were, because the client/server deployment model has fallen out of favor. HTML and the web offer a much better distribution model, but at the cost of developer productivity.

In Flash Builder 4 (formerly known as Flex Builder), we’ve started to bring back that productivity. We began to do this back in the days of Flex 1, through MXML and the WYSIWYG Design view feature. Now, in Flash Builder 4, we’ve made a number of improvements that make it easier to build real applications using design view.

First, we’ve improved Flex’s states feature, both in Design view and Code view. The states syntax is much easier to follow, and design view makes it easy to create each screen of your application as a separate state. States no longer need to be “based on” other states, meaning you don’t need to juggle a complex dependency tree. What’s more, you can easily switch between states not just in Design view, but in Code view as well. When you change the State toggle in Code view, this grays out code that is not relevant to the current state.

Second, we’ve added the ability to generate event handlers via Design view, making it easier to jump from design to code. This feature also saves you the tedium of constantly typing the boilerplate event handler method signature code.

The last improvement is the biggest. In the past, Design view made it easy to drag out and arrange controls on the screen, but it had no ability to work with the most important part of your application - your data. With Flash Builder 4, all that has changed.

Integrating Data and Services

Flash Builder 4 understands data, and can help you get most data sources hooked up to your application. In Flex, data comes through services. Services can be pretty formal, like a web or REST service, or they can be really simple, like an XML file. Although Flex can’t connect directly to server-side databases for security reasons, it’s easy to hook them together using PHP classes or Coldfusion CFCs. Flash Builder can even generate simple ones for you, based on your table structure.

Service support means design view can finally help with connecting your app to data. Once you’ve got a service imported into Flash Builder, connecting it to a data-aware control, such as a DataGrid, is as easy as right-clicking. And the best part is, the generated code is simple to understand and modify.

But making Flash Builder data-aware means more than just sucking data into DataGrids. Now that the tool knows about your data, it can help you build all kinds of common interaction patterns.

Building Complex Interactions

When you look at lots of different web applications, you start to notice the same UI patterns cropping up again and again. This is a good thing, since end users learn these patterns and can reuse their knowledge from one app to the next. For example, many applications incorporate a “master/detail” UI pattern - if a user selects a record in a list, more details about that record appear in a form alongside the list.

In previous versions of Flex, building this interaction was time consuming. You had to build the detail form, respond to the click event, and repopulate the form controls every time. Flash Builder 4, however, is capable of generating a detail form with a few clicks.

In Flash Builder 4, we’ve built a number of useful features that we hope will help you become more productive. However, I do want to stress that data binding and detail forms are only the beginning. Those of you who’ve been around for awhile may remember when we introduced component skinning in Flex 2, and how much of a difference it made when building richly designed applications. But as great as it was, it was only a taste of the design power offered by Flex 4 and Flash Catalyst. Look for similar innovations in Flash Builder in the next few releases.

In the meantime, though, we’d love to hear from you on where we should focus. Do you come across common UI patterns that could be easier to build in Flex? Do you have ideas for how Flash Builder could become an even better rapid application development tool? Let us know in the comments!

The Opportunistic Programmer

Joel Brandt — 04:02 pm 11/17/09

Researchers at Carnegie-Mellon University predict that in 2012 there will be 13 million people in the United States who write code as part of their job, but only 3 million people who call themselves “professional programmers” [1]. So who are the other 10 million, and what are they doing?

Well, given that you’re reading Inspire, there’s a pretty good chance you’re one of the 10 million. These are people who pick up programming as a means to an end: A user interface designer who works in Flash, a content producer who occasionally dives into HTML and JavaScript, or a project manager who builds complicated spreadsheets. We often refer to these individuals as opportunistic programmers.

These individuals don’t fit the mold of the standard software engineer. It should come as no surprise that the tools, languages and frameworks we’ve built for software engineers don’t fit the needs of the opportunistic programmer! Over the last few years, researchers from Adobe and Stanford University (and many other places as well) have been working to understand the needs of this important population. In the remainder of this article, I’ll survey four common themes we’ve observed throughout our research.

Of course, the most common characteristic of opportunistic programmers is how different they are. You’ll likely see something in this article you don’t agree with, or think of something we left out. Please, let us know in the comments — we want to build tools that better suit your needs!

Programs are built by gluing together high-level components

Programmers routinely face a “build or buy” question: should they search for a library that contains a needed piece of functionality, or simply build it from scratch? Overwhelmingly, opportunistic programmers choose to reuse existing functionality. They often build intricate systems by weaving together several high-level pieces using only a few lines of “glue” code.

An expert at this type of development may need a very different skill set than an expert software engineer. Specifically, a great opportunistic programmer needs to be proficient at breaking down large problems into smaller pieces and then knowing where to find existing solutions to those smaller pieces. Often, the best existing solution for a problem won’t be written using her favorite language or framework. So, she also needs to be adept at picking up new languages or quickly learning the conventions of a particular development paradigm.

Web search and code examples play a crucial role

A search box is the Swiss Army knife of opportunistic programming. As mentioned above, opportunistic programmers routinely need to learn new languages or understand new libraries in order to get their job done. Code examples are usually the best way to do this. Understanding and improving the use of code found on the Web has been a major focus of our research group. Rather than going into all of the details here, I suggest you read our article on Blueprint, a plug-in for Adobe Flex Builder that brings Web search into the IDE.

Iteration is rapid

How quickly do you go from writing code to testing, and back to writing code again? In one of our studies of opportunistic programmers, we found that 80% of these cycles were less than five minutes in length and over half were less than 30 seconds long! That’s a lot of testing.

In short, it seems that opportunistic programmers want to check every line of code for correctness when they write it. The reason for this is straightforward: they often are not particularly familiar with the languages and tools they are working with. Checking each line of code as it’s written simplifies debugging. Of course, there’s a downside — it’s really slow! But is this practice inherently bad? Some might think so, but we think it should be embraced. Instead of “correcting” this behavior, we think we should build tools that make it easier to get feedback immediately after code is written.

Code is impermanent and messy, and that’s okay

Code reuse is a staple of software engineering. Software engineers spend days architecting interfaces and fretting over encapsulation before they even write a single line of code. Afterward, they spend days more polishing and documenting their code. Opportunistic programmers, on the other hand, are more like Jack Kerouac. They often just let the code pour out, with little regard to organization or documentation. And that’s great!

Most opportunistic programmers, we’ve found, treat their code as “throw-away.” As long as it runs once, it’s good enough. We think this is something that software engineers could learn from: all too often, “prototype” code works just well enough that it never gets thrown away or rewritten and ends up in a shipping product.

The big downside of writing throw-away code is not that the code gets lost, but that the process doesn’t get captured. Details about process—like why a library was chosen or how a nasty bug was fixed—are traditionally captured in comments inside the code. Process capture is invaluable, but clearly this approach doesn’t work for the opportunistic programmer. Instead, we find that the best opportunistic programmers often keep a separate notebook or blog where they document things. Going forward, tools that opportunistic programmers use should make it easier to capture this information independent from code.

Thanks for reading our 30,000-foot overview of opportunistic programmers. I’m sure you have lots more insights – please let us know in the comments. If you’d like to learn more about our group’s work, please visit http://hci.stanford.edu/opportunistic.

-

[1] C. Scaffidi, M. Shaw, and B. A. Myers. "Estimating the Numbers of End Users and End User Programmers." Proceedings of VL/HCC 2005: IEEE Symposium on Visual Languages and Human-Centric Computing, pages 207–214, Dallas, Texas, 2005.

Learning to cope with code

Matt Hamlin — 04:01 pm 11/17/09

Ten years ago, it was easy to make a good living specializing in graphic design for print. Today, specializing in print design won’t earn you enough to pay for an iPhone’s data plan. This is not shocking news to any decent designer. For years, freelancers have seen job requirements become more and more technical. This is true in fields ranging from basic web design to IT, to HCI training, to Flash animation, to web development and so on.

Being a designer means you must be more comfortable with technology than ever before, and the best jobs available require designers not just to make their content look and feel stunning, but also make it interactive. Interactive, on a surface level, so that users can navigate content and play with objects, and interactive behind the scenes too, so that content can be pulled from other sites, remixed and reimagined.

But to do this, you must be able to read and write computer programs, in languages like JavaScript, PHP, or ActionScript, just to name a few.

As a former graphic designer, who doesn’t program, and sometimes gets tripped up by basic things like Wiki markup, this is beyond frustrating. Because I can’t read and write in a language designed for computers, I am being shut out of this new and exciting world of interactivity.

This begs the question, how can creative applications give users the power to create code, without that process being so painful for so many of them?

Coding in Flash Professional

This year, I've been working with my colleagues on the Flash team on improving our product, so that ActionScript 3 code will be easier for our users to work with. I want to emphasize the “easier to work with” part for a moment. For the past 30 years, academics, government institutions, and private companies like Sun, Microsoft, and Adobe, have attempted to create applications that enable users to program without having to learn to read and write a programming language. A lot of efforts have been made to remove programming from the experience of creating interactive experiences. None of these efforts have been used heavily outside the classroom. I can’t think of any major project created by one of these alternative development environments.

I’m positive that this will change. Some new efforts in the area - notably Adobe’s Flash Catalyst – will no doubt succeed where many others have failed.

But the approach we on the Flash team are pursuing is different. We're not trying to get rid of the need to work with code. Rather, we want to enable users to use ActionScript 3 code, and leverage its power, before they really know it. Then, we also want to help them get, gradually and with as little pain as possible, to a point where they feel they have mastered AS3 to the extent they need.

There are many reasons why we are going this route, but one of the main drivers is that by teaching people how to work with the code, we empower them far more than if we kept coding a mystery. We’re also attacking the myth that working with code is the domain of only left-brain people. That coding is something only a small percentage of people can do.

We naturally avoid tasks that are hard, and often, our imaginations create a false sense of how hard an unfamiliar task is. When we do this, we tend to shy away from tackling such tasks.

...

The first thing we must acknowledge is that our target audience is distinct from the group of advanced users who are already comfortable using ActionScript:

 The target audience writes dozens of lines of code, not hundreds or thousands.
 The target audience wants ActionScript to add value to their existing content; for advanced users, ActionScript code is their content.
 The target audience doesn’t know the concepts or principles behind coding ActionScript; for advanced users, this knowledge is essential to their jobs.

We have articulated three objectives summarizing changes we can make to the culture of working with ActionScript code, to allow more customers do so more successfully:
 Make ActionScript more accessible, by providing easy, tailored access to code samples for use in key situations.
 Make ActionScript more comprehendible, by providing, in an imaginative visual presentation, the information necessary to understanding what code does, and how it works.
 Make ActionScript more composable, to promote tinkering with, and remixing of, code samples.

Of course, we have a lot of talented and loyal customers who don’t want to work with code at all. No amount of reimagining the code experience will make these customers into coders. These customers are stubborn in their behavior, and attempting to change that behavior is a fool’s errand. So we need a fourth objective, specifically for these users:

 Make ActionScript escapable, so that interactivity can be created without code. But build a bridge of familiarity to ActionScript, if they ever decide they’d like to work with it directly.
In this article, I’ll discuss the first objective.

Make ActionScript more accessible

Today, ActionScript code must be inserted into a frame on the timeline using the Actions Panel. The majority of users insert code they’ve written themselves, or found on the Web. Very few use the in-product tools for constructing ActionScript. The Actions panel is a large interface element that is generally placed on a second monitor, so it can be easily accessed and does not obscure the user’s content.

ActionScript code is what enables Flash Authoring users to create interactive presentations. To allow non-experts to do this, we need to give them access to fully functional chunks of code. Not having these in the application is like giving Illustrator illustrators a color wheel that’s blank when they open the application—thus forcing them to supply the colors themselves.

It would be intriguing if Flash Authoring had a highly visible entry point for entering commonly used chunks of ActionScript code. This would be similar to the in-your-face drop-down that Excel users can use to view, choose, and insert commonly used scripts, and get information about them, including tips on how they can be used.

When inserting code, we should not require the user to shift his focus away from his content. instead, we should allow code to be inserted via smaller, lighter-weight interfaces. These smaller code-editing windows could be designed specifically for the dozen or so lines of code the user works with. Behind the scenes, we can aggregate all the code in the file, so it can be present to the user in a single nicely organized list.

Once a code sample has been inserted in the Actions panel, certain words should be highlighted automatically—these are reserved keywords in ActionScript, which means that they have a specific function in the language, and can’t be changed, or the code won’t work.

We should also develop and implement a new set of rules for the typography of ActionScript code. Why is code presented as black text on white background, with reserved keywords highlighted? Why don’t we use a combination of typefaces and styles, within a chunk of code, to help the user more easily identify what needs to be wired up? The easier the user can read the code, the quicker he is on a path towards learning how to use it.

Code is so important to creating interactivity, and can be so labor- and thought-intensive to create, that many advanced users maintain text files for storing frequently used chunks of code. We should make it easier for all users to store, manage, reuse, and share their code. What is needed is an iTunes or Delicious.com for code. Fortunately we already have some significant intellectually property invested with our Tour de Flex product—perhaps this framework could be leveraged for this purpose.

We would be remiss if we did not involve our advanced users in helping to get our new users up to speed, and that means tapping them to submit some of their useful code samples for sharing with others. Which means we need a clearinghouse or marketplace for users to go to when they’re looking for code. Adobe doesn’t have to own or run this. We could appropriate the RSS model, where Code Sample authors place a badge on their site that allows automatically downloading of samples to the visitor’s machine. The point is, code is all over the net these days, and Google just doesn’t do a good enough job helping you find the ride code chunk quickly and easily.

Finally, we need to help advanced users that have code scattered throughout hundreds of file folders on their hard drives. We need to give them the ability to find what the code they need, rather than having to recreate it. That means we need to provide some sort of Google-type indexing for ActionScript code that’s on their machines. Again, we have some awesome intellectual property with the Blueprint feature, it’s just a matter of fine tuning it for searching the desktop instead of the Web.

This was just a sketch of how we might implement the first objective: make ActionScript more accessible. In future articles I will discuss our ideas behind the other three.

Why UX Matters to Everyone

Grant Skinner — 03:00 pm 11/17/09

I've been working in the interactive space for about 12 years, and have done many different jobs during that time. I've been a designer, an interactive director, a server-side developer, a client-side developer, and a manager, and I've dabbled in information architecture. I've worked on multimedia CD-ROMs, banners, casual games, mainstream games, mini-sites, portals, applications, installations, and experimental pieces. The common thread linking everything I've done has been UX.

User Experience (UX) defines the gestalt of a user's interactions with a system. It includes anything that affects a user's experience, unifying everything from aesthetics and layouts, to functionality and transitions, to content and flow. Along with metrics - sales, click-through, etc - it establishes the goals and outcome of any interactive experience, be it a banner, a mini-site, an application, or even an art piece.

At it's core, UX is really about value, or return on investment, for both the end user and the client. It weighs the cost of undertaking a task against the payoff for achieving it. To a client, this can largely be quantified through cost and time versus metrics (purchase conversions, views, interactions, time on site, etc). Quantifying it for the end user is somewhat more ambiguous, but can include their investment of time and learning versus payoffs that include intangibles like novelty, beauty, and entertainment as well as more tangible value like utility, time savings, and task completion.

As such, UX can serve as the shared focus and common language among the different professionals involved in an interactive project. Unfortunately, many designers focus only on making things pretty, and many developers only worry about making things work. Besides producing better, more usable software, a shared focus on UX improves communication between groups, gets developers involved earlier, and can result in a shorter project timeline with less hiccups.

UX is a topic I consider to be important. But UX is frequently undervalued. Over the week, I'll be writing a few brief articles on simple but useful UX concepts that will hopefully benefit anyone involved in creating interactive content, but especially designers and client-side developers. Feel free to chime into the conversation at any time in the comments.

Lessons from Green Graphic Design

Eric Jensen — 08:15 pm 11/12/09

This week I read the book Green Graphic Design by Brian Dougherty.* The book outlines ways in which graphic designers can help to create greener designs by really considering the impact their design will have on the environment, their client's image, and the target customer throughout the creation, production, and distribution process, and by gathering feedback about the effectiveness of their design choices.

Although this book is clearly focused on graphic design, I found some interesting parallels to software design. One of the key themes is that a designer needs to move beyond a strict definition of their position to learn about the processes that will follow their design once it is “finished” and work backwards with those constraints in mind. For example, by understanding the downstream constraints in printing and shipping materials the designer can make environmentally friendly choices. The better a graphic designer understands what will happen with their design as it is implemented and delivered, the more impact they can have.

One memorable example from the book outlines how adding a pocket for loose sheets to the back of a folder meant the flattened folder could only fit on the page twice (2-up), resulting in a tremendous amount of paper waste after trimming. Redesigning the pocket for the next version allowed the folder to fit on the page four times before cutting (4-up), with a much less wasteful result.

The parallel in software design is that there is a similar cost in wasted development time. Choosing the correct feature set based on the needs of the target user and carefully focusing on those elements can help to make sure that the developers aren’t spending time building less important and costly features. In the book, Dougherty points out that the cost savings from well-thought out, impactful design can more than compensate for the additional costs for environmentally friendly inks, paper, packaging, and delivery methods. I believe that the same thing is true for software development – the savings realized by reducing and focusing the feature set can more than compensate for the time required to build “nice to have” features. If these savings are exposed to the customer, it validates the role of the designer in a collaborative process that produces an effective, efficient and desirable result.

Another key point was the need for feedback in design. Dougherty points out that for a variety of reasons graphic designers either lack the opportunity, don't take the time, or aren’t rewarded for getting external feedback after their design is completed. This means that they may not be aware of how successful their product was in reaching the desired customers or controlling the impact on the environment. Without this feedback, there is not a motivation to change their design processes or to consider novel ways to approach future projects. In software design this feedback loop is also critical to make sure that the software being delivered has the desired capabilities and results for the end user. Fortunately, in many product groups feedback and validation is already part of the development process through usability testing, beta testing, on-site customer visits, and other research efforts.

Overall this book was an intriguing way for me to look at design through a parallel approach. Are there other parallels that you have encountered? What non-software models do you think are interesting to consider in improving software design and development?

*A video interview of the author and Gaby Brink is posted on Inspire go to video

Blueprint Demo

Adobe XD — 08:09 pm 11/12/09

See how Blueprint, a plugin for Adobe® Flex® Builder 3, allows users to query for Adobe Flex and Adobe Flash code examples found on the Web directly inside of Flex Builder 3. Blueprint's creators give you an inside look at its development in Blueprint, Bringing Web Search Into Flex Builder.

What’s going on now in the Japanese Flash world?

Mariko Nishimura — 02:00 pm 11/10/09

Particle sample of SMOKE, from wonderfl build flash online

At FITC Toronto 2009, speaker Takayuki Fukatsu called on Japanese Flashers to be take an active part in the community on his site, JActionScripters, which shows cool Japanese Flash work.

Not only Fukatsu, but also Masakazu Ohtsuka of Kayac, have turned their sites into playgrounds for the Japanese Flash community, and more and more, these sites are serving as great tools for Japanese Flashers to publicize their work. Check out Ohtsuka's Wonderfl, and be sure to look at Checkmate, built using Saqoosha's FLARToolKit, which was featured in the MAX 2009 keynote.

Well, next my dream is having Japanese speakers session at major world-wide conference and to invite cool speakers to Japan from all over the world. I hope to have more to share on this soon! YOROSHIKU!!

Community power & Adobe MAX

Mariko Nishimura — 02:00 pm 11/09/09

(Thanks to Shawn Pucknell of FITC!)

One of the great thing about the Flash world is the power of the Flash community. There are active, talented Flash creators and developers, and exciting Flash conferences and gatherings, everywhere in the world.

I wondered how we could take advantage of the vibrancy of this community to help Japanese Flashers connect with their peers around the world.

Thanks to the help of Shawn Pucknell, the founder of FITC, we were able to do this, by organizing FITC sessions at Adobe MAX Japan 2007 & 2009.

Joshua Davis, Erik Natzke, Ralph Hauwert, James Paterson and Shawn all attended, and made these sessions a great opportunity for Japanese Flashers to meet their colleagues from other countries. And FITC members, I think, had a great time in our country, both at MAX, and while visiting Shibuya and Tsukiji Fish Market, and trying karaoke and izakaya.

This opportunity helped Japanese Flashers feel more confident in showing their work to the world – and in its wake, Shawn put two "Cool Japanese Flash" sessions on the program at FITC Toronto 2009. Featured were:

Masakazu Ohtsuka, Kayac of Wonderfl
Takahiro Abe, Progression framework
Takayuki Fukatsu, Fladdict
Tomohiko Koyama, FLARToolKit
Yoshihiro Shindo, Spark project

Japanese Samurai Flashers

Mariko Nishimura — 09:00 pm 11/05/09

We Japanese are well-known for being experts in creating great products, and the same is true of Japanese Flash developers. But the language barrier and Japanese tradition of modesty has kept them from being as widely known as they should be.

In recent years, we've seen amazing work from individual Flash creator-developers as Grant Skinner, Colin Moock, and Mario Klingemann. Geoff Stearns, meanwhile, created SWFObject, a set of libraries that's now used around the world.

Are Japanese Flashers doing the same quality work? Yes! But they need help getting the word out, and sharing their creations with the world – the incredible content presentations, applications, libraries, and frameworks they've built.

In Japan, we tend to follow the rule "the more capable one is, the more modest one tends to be" – but to let the world know about the great Flash work being done here, we had to get beyond this habit. And fortunately, that's beginning to happen. More on that in my next post.

What is the experience of reading a newspaper?

Andrew Day — 05:04 pm 11/05/09

This question, which newspaper publishers face every day, as they try to figure out what to cut and what not, is, it seems to me, fundamentally an experience design question. In deciding what content to give their readers, in what form, editors and publishers work from a notion of what their readers want - that is, what experience those customers will pay for, and how stripped-down or changed that experience can get, before those customers will stop paying. If we make a certain set of changes to our product, they also ask, might it provide an experience that would appeal to people who don't buy what we currently offer, but would then start doing so? And so forth.

Or at least that's how they should think. Too often, they think in a different way, as they shape and reshape their products. They work from a traditional notion of what a newspaper is, and thus, in their mind, should always be.

Even the New York Times, the most forward-thinking and innovative of traditional publishers, can fall victim to this sort of thinking. Consider the way NYT editor Bill Keller thinks about the future of the paper's sports section, as recounted in this piece on shoring up the company's finances, by NYT editor Clark Hoyt:

"Radical moves, like dropping the sports section, have been rejected because they would undermine the quality of The Times or would not save much money, Keller said."

Would cutting sports really not save much money? And would it really undermine the paper's quality? As economist Tyler Cowen points out, stating, what to sports fans, is the obvious, "the NYT sports section isn't even as good as USA Today."

Certainly there are institutional and social factors at work here - Keller would feel awful telling Harvey Araton he was out of a job. But what I suspect is more important is that Keller can't imagine a newspaper without a sports section - after all, in his memory, every daily newspaper has always had a sports section. Yet the NYT sports section, if it's being mentioned in the context of Hoyt's column, must be a big money loser. And for the millions of NYT readers who now read it primarily online, or using Times Reader, having a "newspaper" that contains a "sports section" is an archaic notion. They read the Post's sports if they're from New York, and, for no doubt the overwhelming majority of them, if the NYT stopped covering sports, their Times-reading experience would not change a whit, and might well improve, if the company devoted the savings to delivering more of the content they want.

Inspire(d) by…

Ralph Hauwert — 09:14 pm 11/03/09

After two days of me jabbering on about the way I look at the design-development workflow, and about my personal journey through the tools we use in our craft, in my final post, I would like to share more about what has inspired my work over the last years.

Of course, at first, it was coming into contact with the awesome Flash community that inspired me to do Flash. In 2000 and 2001, this happened when I visited Flash Forward London and Flash Forward New York. For me, back then, this conference was the pinnacle of all things Flash, and I still treasure the memories of those meetings, as well as the friends I made there. And in 2000, FF was also the place where I decided I really wanted to focus on Flash.

Most of the speakers from those conference are still active, and many are industry leaders. In my more recent work, I find that I've come closer to what this community is doing, and many of these highly inspirational people have become my close friends. The more I get to hang out with this amazing group of people, the more I'm awed by both their amazing diversity, and their talent. Getting together with them at conferences is one of the biggest influences on my current work.

One very vivid memory is when Amit Pitaru and James Paterson took the stage at Flash Forward and Amit started off by playing jazz on the stage piano. Initially confused, I learned how music tied in with his and James's work. Since music has been the red thread through my life, this was a highly inspiring session to me as an aspiring Flash developer.

These days, I'm even working with James and Amit, on Rhonda Forever, a renewed iteration of the Rhonda project, which they founded. This 3D drawing tool is simple in concept: draw and sketch like you'd normally do, but now in 3D. Yes, it's more complex then that, but this is what I think Rhonda's charm comes down to.

Of course, I'm only a small piece of the Rhonda Project. With people like Zach Lieberman and Zach Gage working alongside James and Amit, this is a well executed project, which I'm proud to be part of. Please take a look at the Rhonda Forever site, and sign up for the beta!

Over the years, I find I've changed my way of looking at other people's work. Instead of trying to decompose things from source code, I find that I more and more read research papers as inspiration for my work. Paul Devebec's research has been particularly interesting. When I started out working with Papervision3D, and while building the 2.0 version, particularly the shaders, Devebec's work in environment mapping and obtaining them was more then invaluable. Also great is his work on reflection mapping

Debevec's work also influenced me through this stunning demo of HDRI lighting, which it inspired. Back in 2003/2004 when I first saw that technology demo, it blew me away and it has inspired me to try and aim for the same in Flash ever since. Actually, I still think that demo's visual quality is mindblowing.

Another huge inspiration in the field of 3D has been the combined work of Michael Abrash and John Carmack, of iD software fame. If that doesn't ring a bell, Wolfenstein, Doom and Quake should. At the beginning of this year I was working on The Anne Frank virtual house project, for which had been commissioned to build a 3D engine. There's a video of the making of the house available now; the full digital version of the house will be online in 2010. Large chunks of what I learned from both Michael and John found their way into this project. Particularly important was Abrash's book "The Graphics Programming Blackbook," which is not only full of technical tips, but also written in a personal style that makes it very inspiring.

Finally, one huge inspiration for my work, and the reason I've always loved "visual programming," has been the demo-scene. It's very hard to quickly describe what it is, so I'll defer to Wikipedia: "The demoscene is a computer art subculture that specializes in producing demos, which are non-interactive audio-visual presentations that run in real-time on a computer. The main goal of a demo is to show off programming, artistic, and musical skills."

As a young kid, I saw these early demos and intros as the top in computer programming. I watched them on the trusty old Commodore 64, and when I finally acquired my Commodore Amiga 1200, my main goal was to run demos and to figure out how these "sceners" did all that stuff. This inspired me to learn programming, and learn how computers actually work.

I've never been much part of the actual scene, but have followed it for a long, long time. Currently, one of the most inspiring members of that community is Inigo Quilez. His work "Elevated," a 4-kilobyte (as in 4096 bytes) intro can be seen on YouTube, but as with any demo, can only be fully appreciated by running it as an executable.

As I've now spent around 3 kilobytes purely on the text of this article, I'd like to thank you for taking the time to read it. And I hope that my three guest posts on Adobe XD's blog did what the title of the blog suggests: Inspire.

Mastering the tools

Ralph Hauwert — 02:02 pm 11/02/09

One of my earlier inspirations in life was a big book of Maurits Cornelis Escher works that my parents had on the bookshelf. This Dutch artist had a very exact graphic style, and combined with a good dose of math, he created such iconic masterpieces as "Up and Down." In this piece, an optical illusion of stairs is created, where it looks like the men walking on the stairs can walk up into infinity. Looking at his work, the combination of seemingly effortless use of the tools available to him and the mind-boggling graphics effects he achieved, this was an amazing feat for me as a young kid. Later on in life I learned that Escher's effortless use of the tools wasn't that effortless at all. He had studied using his techniques for graphics for many years, and it wasn't until later in life the more steady stream of masterpieces started to come from the tips of his fingers.

In his later work, math started to play an increasingly big role, and he once said, "By keenly confronting the enigmas that surround us, and by considering and analysing the observations that I have made, I ended up in the domain of mathematics. Although I am absolutely without training in the exact sciences, I often seem to have more in common with mathematicians than with my fellow artists." I think he was on the forefront of a field which didn't even exist as a real field back in the day, which also explains his uniqueness as an artist in those days.

Being quite fond of math myself but also not having any formal training in higher-level math, that quote has also always been something I could relate too. But as math plays a big role in my current work, I'm "forced" to make this tool one of my own. It took me a while to figure out that math was just another brush in the box of tools we can utilize. Although I can't say I feel like I understand the math I need for my work to the extent I would like, I've become more and more capable at using this tool in a practical way. More importantly, I'm now able to play and experiment with it. The great thing about this particular field is that whenever I feel I understand something better then before, it just unlocks a whole new box of things to be understood. It's wonderful and the learning process and possibilities feel as infinite as the men walking over the stairs in Escher's "Up and Down."

Most of my learning and understanding comes from experimenting with the tools. And just as I play with math, I play with the Flash platform. Every time you learn something new about using it, new possibilities and challenges arise. It's a wonderful world in which we can explore, tinker and experiment. I see this property in many of my fellow developers and friends within the industry. Looking at the mindset of most famous and established Flashers, they all seem to share the desire to experiment and play with the tool. From an outsider's perspective, this tinkering might seem less useful then it actually is. It's fundamentally the same as what Escher did in his earlier years. Experimenting with the tool to master it to an extent where it becomes a practically applicable tool.

I think the one of the truly unique qualities of the Flash community is that we use Flash because we love playing with it. How great is that? I can honestly say my passion became my job. I learned Flash because it felt open to play and experimentation, and during this process, I mastered using it as a tool. I'm now at a point I can see my Flash skills are sufficient to do most of the things I would like to do with it, and this leads me to think what the next step in my journey is. As I mentioned in my previous post, I'm not much of a graphic artist. But with the skill set I've obtained over the years, I'm now getting at a level where I can help building new tools for others, convey some knowledge, and hopefully help allow others to play and tinker, and thus master the new tools.

A week’s worth of cool links

Adobe XD — 01:55 pm 11/02/09

A new high (or perhaps a new low), in publication design, from a most unlikely source.

Infographic genius: one nation, seven deadly sins, from geographers at Kansas State University.

LA, 1932.

Laika lives, as a typeface.

Web experience design no-nos, a laundry list.

The horror of pollution in China.

The horror of Microsoft TV ads.

"How can an X chromosome be nearly as big as the head of the sperm cell?"

Believe the HYPE

Adobe XD — 04:03 pm 10/30/09

Joshua Davis and Automata's Branden Hall are superstars in the Flash world, and HYPE, their new collaborative creation, shows why. If you haven't heard of it, here's the word, from the HYPE website:

"HYPE is a creative coding framework built on top of ActionScript 3. A major goal of HYPE is to allow newcomers to Flash and ActionScript to creatively play and express themselves while they are learning how to program.

To get started, the user needs only the most basic knowledge of programming – variables, conditionals, loops, and functions, for example.

As the user learns more about programming they can extend HYPE and thus grow their skills, while at the same time inspiring the next generation.

Now, that's not to say HYPE is just for people who are new to programming. Instead, HYPE is for anyone, regardless of skill, who wants to play with code. Fundamentally, the point of HYPE is to make Flash fun again. We made HYPE to help bring back the playfulness that once defined our community.

HYPE - come out and play!"

Can matchbook design bring rural India into the modern world?

Adobe XD — 04:07 pm 10/29/09

At The Next Billion blog, Richard Woolbridge notes that matches are the most widely distributed product in India, reaching 97% of the country's population. The least widely distributed? Information. And since matchboxes have the potential to carry information, primarily in textual form, he asks, why shouldn't they be used to do so?

"Imagine the possibilities," he writes, "of spreading new health/educational information or advertising to 97% of rural families on a monthly basis. Simple pictorial designs would pique interest and accommodate India's vast differences in literacy rates and languages. Awareness of important topics such as the installation of chimneys to reduce smoke inhalation or cleaning and covering water containers to prevent stomach ailments could be spread to households across India, and potentially save lives."

Of course there are questions about how many of the recipients of these texts could read them, and how receptive they would be, but this is a fascinating idea - and a great challenge for designers to tackle.

Capturing beauty in Technology and Design using Flash

Ralph Hauwert — 03:39 pm 10/28/09

This year marks my 10th year working with the Flash Platform. A long and great ride, and after 10 years I'm still not done exploring the capabilities of creating beautiful experiences with the platform. A lot has changed in that time. In my early days of being involved in the platform, I carried the title "Flash Programmer". AS2 wasn't even on the horizon and "programming" meant using those tedious add and subtract buttons to add and remove code to your Flash 4 MovieClips. It was a common misconception that I was the go-to guy for your skip-intro animation. It took some time for the platform to evolve, and for clients to get to the point where they understood that a Flash programmer wasn't the same as an animator / designer for the same platform.

I'm not much of a visual designer anyway. I'm colorblind and couldn't draw a straight line or any type of line with a regular drawing tool if I wanted too. But I do love visual beauty. As such, my current self-given job title is "visual programmer". An odd title to explain, since a common pitfall in this industry seems to be to stereotype our functions to the description. It's overly comfortable to exclusively classify someone in the bucket of design or technology. Sometimes this idea comes from the job title we carry or maybe even from the tools we use. When your title overlaps both qualities, it's hard to clearly define where the border of the 2 disciplines lies in your specific case. If your tool is a text based code editor, it's hard to explain you are building technology for visual beauty. And how do you define that towards your peers?

The peers within Flash community are easily one of the strongest points of the platform; it supports a lot of different disciplines and this reflects in the community being made up out of Artists, designers, programmers and experimentalists. The beautiful reality is that we do not find symbiosis in the tools or platform, but by working together. The platform and it's distinct properties merely brings us together by giving us the opportunity to do so. It's the same type of cooperation you find in other fields of the creative industry, such as music; the cooperation between the engineer, producer and the musician. I've frequently talked about Pink Floyd as being one of the core inspirations to the way I like to work. The band got assigned Alan Parsons as their recording engineer and worked with him to record one of the albums I'd personally put up in the top 3 of best albums ever, "The Dark Side of the Moon". Together, while taking the technical limitations of a recording studio back in those days in considerations, they not only put down a master piece of true aural beauty, but also managed to create something which was way ahead of it's time, by creatively exploiting the studio equipment and using the technology to create something additive. I think this is a big distinction from using technology only to capture a performance. It's in this distinct area of work where I find that true beauty in technology and design is also being created.

As great as it is that I don't get called upon anymore to just animate a corporate logo, like back in the days, I hope that the boundary condition between being a developer and a designer will remain to have it's diffuse overlap. See, the reason I loved the Flash Platform from the beginning was this exact symbiosis of design and technology. Back in the day there were few who could do both, and with the evolving of the toolset in very distinct directions it's even fewer now. It's a natural progression as the platform becomes more complex and developers and designers a-like can specialize more into using the toolset most suited for their own discipline. But taking the analogy of the recording studio, it seems a natural progression, where the specialization of the disciplines can be a true additive to the experience. I, myself, strive to learn and evolve into one of the Alan Parsons of the Flash Platform, to the best of my engineering capabilities. A high goal to try and capture, but what is life without goals ? As always goals come in small steps, so mine now is capturing beauty through technical symbiosis with the visual artists. Hopefully, one day, I will be part of creating the digital equivalent of "The Dark side of the Moon".

It’s complicated

Andrew Day — 02:57 pm 10/26/09

I became interested in Russia in part because of the stark, direct beauty of Soviet propaganda art. I was in college, and while the Soviet Union was still a going concern, Gorbachev was smoothing down the rough edges, so one day as I walked across campus, and happened on a guy selling reproductions of 60s Soviet space-program posters, I didn't have any great moral dilemma about buying a couple, and then putting them up in my dorm room. Later, when I first went to Russia, as a grad student in Russian history, I bought several books featuring posters of the late 'teens, 20s, and 30s - horrific years, nearly all of them, across the Soviet Union - and it was only after having pored over these books dozens of times that I began to feel odd about my love for this art. For these posters didn't communicate the sly calls of advertisers, begging people to spend a few bucks on a pack of cigarettes or a movie ticket. Rather, they delivered the orders of a brutal dictatorship. Civil War-era "Peace and Land!" posters made a great promise to beaten-down poor peasants - but made clear as well, to anyone who saw them at the time, that there would be no peace for those who wanted to keep title to their own land, when the Red Terror came to take it away. Even the poster shown here - "Strengthen the friendship of youth of socialist countries!" - is at best a clumsy reminder that the Soviet state wouldn't put up with kids spending their free time doing something else, much less, say, forging their own friendships, with kids from the non-socialist world.

I put the posters in storage and over the course of my years living in Russia, I came to share the views of my Russian friends - all of them children of Party members - that this sort of art was at best impressive kitsch, its skillful execution undercut by its fundamental political wrong-ness.

And yet... Looking at this poster, and the others featured on this page - thanks for the link, Dan Walsh! - it's hard not to appreciate their beauty. And they are beautiful. Is it time, I wonder, for me to look past their purpose, and appreciate them as great design, and indeed, as great art - the same way I can appreciate, say, Kalatozov's film Yo Soy Cuba, or Fadeev's novel The Rout? I'm not sure... but in the meantime, I'll keep paging through the posters on Grain Edit, and try not to think about the past.

A week’s worth of cool links

Adobe XD — 03:30 pm 10/23/09

Inside the design of the world's most expensive SUV.

Porn that's safe for work.

Redesigning a room for $10.

Destructive and non-destructive ways to convert photos to B+W in Photoshop.

Designers, what's your story?

Drawing beautifully, and realistically, by drawing crudely.

The Web is mostly words - why don't Web designers design for words?

What Americans looked like, to a 1950s European.

Did design really "make a difference" in transforming Medellin? Hmm....

Against "against branding."

Super 8, 1974 (Thanks, Leah!)

Designing the future of publishing

Andrew Day — 06:27 am 10/21/09

In his video conversation with XD VP Michael Gough, O'Reilly Media founder Tim O'Reilly argues that now more than ever, publishers need to focus on "curation" - carefully choosing what content to produce for which users, and presenting it in forms that suit those users' needs. He calls curation the essence of publishing, and indeed, publishers have always succeeded or failed based on how well they do it.

But the e-publishing revolution has made curation much more complex. Customers have many more ways to spend their time and money, and so have become much more demanding, and traditional publishers have seen their markets both shrink and fragment. O'Reilly has done a better job than most of coping with these changes. In large part, this is because, unlike many of its peers, it hasn't stuck to publishing in one format - in its case, physical books - just because that's what it knows how to do. Rather, it puts out most content items in multiple media and formats, choosing each medium-format combination to suit the "job" the content will do, for a particular group of users - the jobs being educating, entertaining, or serving as reference material. Following this strategy hasn't led O'Reilly to abandon books. But now it's also a leading publisher of videos, websites, blogs, and e-books. And it's been highly successful in getting content to users via a broad array of conferences and seminars.

Signal vs. noise

O'Reilly's success suggests that other traditional print publishers will need not just to move into e-publishing, but also give their customers content in a variety of electronic formats. And as they do so, their designers will face an array of challenges and opportunities.

Design has always been a critical component of print publishing. Print designers package and present content in ways that make it easy and pleasant to read and to have. This will continue to be design's role as print publishers expand their digital offerings - and indeed, that role will be more important than ever. The next few years will no doubt be a period of experimentation in this space – the creation and deployment of all manner of e-reading apps and devices, and e-publication formats for content that's traditionally been published in printed form. Designers' contributions will go a long way toward determining which succeed and which fail. And in this, they will play an important part in shaping the future of publishing, both as an activity, and as an industry.

Tim O'Reilly notes that "picking signal from the noise" is an apt analogy for publishing's curatorial function. Publishing designers do this too, in crafting presentations - most notably, periodical layouts - that feature certain content, with other content smaller and harder to find. The size and prominence of each item can be seen to depend, roughly, on the designer's estimate of how many users will consider it to be noise rather than signal. Print designers focus too, of course, on ensuring clarity of signal - choosing the most readable, attractive fonts for text, the right margins, the best reproduction formats for visuals, and so on.

To see how this works, look at any publication, electronic or print - consider, for example, the array of type sizes and fonts, and the layout, on the homescreen of the New York Times Reader.

Periodical publishers have already begun to tackle the signal vs. noise problems involved in redesigning their content presentations for electronic media. But book publishers have, in the main, not yet done so. They’re used to designing not just for print, but for a presentation medium – books – that generally contain nothing that couldn’t be construed as signal.

For them, the biggest design challenge, in moving to digital, will be one their industry already faces: dealing not just with noise, but with an exponentially expanding amount of it. With so many available media choices, users are increasingly picky about what content they'll accept as "signal," and what they'll treat as "noise." For an industry producing products whose use requires a significant time investment, this is a serious problem. This will be even more true as it moves to make those products available via devices that provide users with an array of appealing, easily accessible other means of spending both their time and their money.

Again, book houses will need to follow O'Reilly's lead, and begin publishing in multiple formats. This could mean converting some of titles to hybrid text-video format, breaking others down into buy-by-the-chapter pieces, and with others, trying out different repackaging and reformatting strategies. But what about titles in those genres - novels, serious non-fiction narrative works, and the like - that still need to be published in text-heavy, book-length packages, meant to be consumed as integral, standalone products? After all, sales of these titles are this industry’s lifeblood. How can design make them palatable, to enough consumers, to enable that industry to transition successfully to the digital age?

The e-reader of the future?

This is more a device-design problem than a software or presentation-design problem. A huge block of text is just that, and other than picking the right text size and font, and providing easy navigation, and such features as bookmarking and commenting, there isn't much to the basic problem of designing a text e-book, or the software to read it.

Which brings us to the problem of crafting a next-gen e-reading device - a topic about which plenty of people have been spilling plenty of ink, and e-ink, for some years now. Can a device designer, by solving the "signal vs. noise" problem, create an ideal e-reader, and thereby save the book industry?

Our designer would no doubt start by targeting serious readers. These users would want a fairly big screen with clear text reproduction, and those input controls they'd need to load and make their way through e-books, e-magazines, and other text content. Since sustained reading, for this type of user, is the rule rather than the exception, our designer might well go with a black-and-white screen and a minimally functional processor, to make the battery last as long as possible. The resulting device would no doubt look a lot like Amazon's Kindle - which, for serious readers who don't mind reading onscreen, delivers a fairly clear signal, and a great signal-to-noise ratio.

Of course, our device would be optimized to suit only one type of reading – of novels, historical biographies, and other content that contains only text, and requires sustained, intense focus.

Moreover, designing a device for readers doesn't necessarily mean designing it for only the act of reading. After all, serious readers talk with others about what they've read, and share books, magazines, links to articles and blogposts. Many are also writers, and like to share what they’ve written, either informally, with friends, or by publishing it.

To meet their needs, our device designer might well go a different route. The result would be a device with a more powerful processor and input controls, to support it doing more than the Kindle. The display screen might be just as big, to support displaying, in addition to the content viewer, controls for publishing and sharing, windows to display metadata, messages from other users, and so forth.

Or the screen might be smaller, on the assumption that even the most serious readers don't just sit on a couch for hours and read Tolstoy. They also read shorter works, in all sorts of places, and at least some of them would likely value a highly portable device over one with a big screen. And if our designer’s boss insists that most people don't want to carry multiple portable devices, she'll also build in a phone and camera, and make sure her processor can run not only an e-reading application, but plenty of other software too.

This device sounds pretty powerful – and at this point, it's not really an "e-reader," but an extremely portable computer. In one version, it could be an iPhone or Blackberry, with a larger screen, not to mention longer battery life and more power.

Congratulations to our designer - and to the engineers who've managed to build her device. Their product certainly seems to be a dream e-reader, satisfying the needs of everyone who'll want or need to read on a device that's as portable as a book or a magazine.

But in fact, it isn't our ideal e-reader, at least not for everyone. To make it "broadly appealing," our designer introduced what, for our first group of readers, will be little more than sources of noise, interfering with the signal of text on the screen. Consider too that for these readers - without whom traditional publishers wouldn't survive - reading is, in many ways, about the pleasure they get from freeing themselves from the noise of life, and immersing themselves in the intense experience of engaging with a text.

Could this sort of reading really be done, comfortably and enjoyably, on a device that affords easy access to computing and communication functionality? No. Distractions become distractions because they're annoying, tempting, or both - and such a device would be rotten with the tempting sort.

Let a thousand e-readers bloom. And a thousand presentation formats, and a thousand publishers, and…

What does this mean for the future of the e-reader space? Will we see a bifurcated market, with our first group buying gussied-up descendants of the Kindle, and the second preferring tablet-style computers? It's hard to imagine that this won't happen. Designers, and device and software makers, can’t create a product that simultaneously includes all the features that keep social and casual readers happy, while at the same time leaving those same features out, to give serious readers the serenity they crave.

What about presentations formats? Will the dominance of physical books be replaced by the dominance of e-books? Not likely. More than likely, book house that transition successfully to digital will follow O’Reilly’s lead, by turning many or even most of their “book” titles into all manner of content items, many of which require the user to invest much less money and time to buy and consume. Yes, novels and so forth will remain integral, and be available in standalone digital form – perhaps with many coming out in print as well. But it seems likely that there will be a myriad of digital presentation formats for text-heavy content, and, at least during a near-term period of experimentation, none of them will be as dominant as books once were.

Finally, the publishing industry's ongoing fragmentation shows us that there will be no dominant company in this space either. No doubt we've seen the last of "publishing" residing in a several square-mile chunk of Manhattan, and it’s hard to imagine that it will suddenly re-coalesce in some other spot. Indeed, with blogs, Twitter, and the like enabling millions to become content producers and distributors, the notion of a "publishing industry" may come to seem almost quaint.

Many publishing traditionalists look at all these changes and see chaos, and worry about what will happen to the endeavor to which they’ve dedicated their careers. But there’s another view of what’s going on in publishing, one that Tim O’Reilly shares. One that focuses on the next few years as a time of great excitement, with opportunities abounding for creative "book" publishers, writers and other content creators - and the designers who'll shape the way their works are packaged and consumed. While it’s difficult, if not impossible, to say now what their work will lead to, we can say for sure that it will play an enormously important, perhaps foundational, role, in creating a new sort of publishing, for the digital age.

Questions for Shawn Pucknell, Part 3

Shawn Pucknell — 06:40 pm 10/19/09

Questions for Shawn Pucknell, the Director and Founder of FITC (Formerly known as Flashinthecan), and Chris Heimbuch, the Senior Design Manager, Creative Development, at Adobe XD. Part One can be found here and Part Two here.

Chris: Where do you see FITC in the future?

Shawn: Well, geographically we are constantly researching new cities and countries to hold FITC events. Groups and individuals contact us constantly to bring FITC to them, and we consider them all. I'm currently looking into how to bring FITC to South America, and a few other interesting locations. Some places that I personally am trying for are Tel-Aviv, Dubai, Singapore and China. All of these are being looked at, among others. FITC does have a big announcement coming shortly, as we have confirmed our most exotic location yet for 2010, but i can't share the location yet.

Chris: What about content and programming for FITC events. Do you see that changing?

Shawn: I expect it to change. But i don't necessarily know what that will look like. And thats ok. Its exciting. The industry is changing rapidly, and as much as i consider myself in-tune with it, i don't pretend to know the future. I think as long as we are booking presenters that are interesting, relevant and engaging, we are on the right path. The biggest complaint I hear at our events is 'There are two things that i want to see, happening at the same time! How do i decide?'. As much as we try very hard to create a balanced schedule for everyone, this does happen. To a certain degree, its our goal...to create an overwhelming amount of content at our events that our attendees want to see. On the flipside, I've been to events where the opposite is true...I've looked at the schedule and have seen 5 tracks of presentations happening at once, and i've not seen anything that I'm interested in seeing. So i'd much rather have what we have now, than to have that. But back to the question; i think we will continue to see new and exciting combinations of art and technology. This includes new ways of interaction, be it physical or screen based, as well as new tools and techniques for creating content. But it also includes more traditional mediums being more integrated into our industry, such as 3D, motion graphics and audio. They all have their own industries, and they are a part of our industry, but i expect to see them play a bigger part of our industry in the future.

Chris: You launched FITC Mobile recently in Toronto, and FITC produced a motion graphics event called 'Pause:ideas in motion' in 2008. Do you have plans on other events like this?

Shawn: Definitely. FITC Mobile was a great success. One of the reasons i loved it was that it was technology and platform neutral, which allowed for a very diverse program. And Pause was a lot of fun, and i'd like to do another one in the future, city and timing TBA. In addition, we have just recently confirmed that FITC will be working with 360 conferences, the producers of 360Flex and 360iDev, which is exciting for us. And in addition to that, we are currently in talks with a few other organizations, as well as some of our own ideas, for future events.