Posts in Category "Workflows"

Recent news, steady progress

Funny news day — lots of little things popping, some drawing much more attention than others, hard to get perspective. There’s a common theme among them, however. Even though there’s lots of growth in new types of environments, there’s a lot of work in bridging them, too.

One example is how browsers are starting to expose Flash Player local storage… from the FAQ:

“Integration with browser privacy controls for managing local storage — Users now have a simpler way to clear local storage from the browser settings interface, similar to how users clear their browser cookies today. Flash Player 10.3 integrates control of local storage with the browser’s privacy settings in Mozilla Firefox 4, Microsoft Internet Explorer 8 and higher, and future releases of Apple Safari and Google Chrome.”

Letting webpages store more-than-cookie-sized data is a good idea, as recent HTML5 local-storage work shows. But as cross-site tracking and personality databases become more worrisome, it makes sense to expose integrated local-storage to public control however people wish to control it. The good news is that different parties can (and do) work together to bring this about. Progress.

Another example is the Wallaby project… not as dramatic as Techmeme may paint it, but it’s still useful to be able to bring basic SWF assets into a different delivery environment. Fragmentation is natural during fast evolution, but connecting such silos is natural too. Progress.

A subtler example is from the Dreamweaver team this week, about the differences in touch events across different WebKit-based browsers. Touchscreens and scrolling forms, or preventing doubled events when there’s also a trackball controller… natural for fragmentation to occur, and natural to bridge that fragmentation too.

More obvious is the work that Adobe’s Digital Publishing group has been doing… working with major publishers to bridge across all the various islands of new devices rapidly appearing. This will soon help smaller publishers too.

Screaming headlines may clash and obscure significa, but the real pattern underlaying the news is easier to see: we’re rapidly gaining a wide variety of connected digital screens, and the big work is in helping anyone to write to them. There’s daily, incremental progress towards that goal… connecting those silos, bridging those islands.

Blends of native and global

Saw a few blogposts this week asserting “mobile apps must be native-code for each device”… went back and re-read them seeking the “why?” without much success. The most concrete reasons seemed to be that cross-platform work is “an uncanny valley between a web page and app” and remarks such as “I think 80% of our customers use only native”.

Not much of a case, and so not worth the fisking, but it did make me think about various angles to cross-platform work, about trying to get a good connection with a wide audience.

  • Is there often an “uncanny valley” when people encounter a new interface? Sure… lots of them. We’re all using devices which didn’t exist a year ago, new form-factors, new tasks, new operating systems and UI conventions. Whether one app chooses to make its UI “uncanny” to single-OS new users, or to make it “uncanny” to customers already using their app on a different device, that’s one of many such decisions best reserved to the developer and their audience. Their choice, but I think we humans have proven our flexibility by now.
  • Development costs are only the initial upfront costs. If you don’t add significant testing expenses, then your support costs will likely be higher later on. And projects incur ongoing update and maintenance costs as well. “It took only four weeks to port” describes just one small part of the project’s total cost. What will it cost for the version 2.0? the version 2.01? What will it cost to do consumer support for multiple system-level codebases? Much of the “go native” conversation out there seems to talk only about the increase in development time, but not the total costs of the entire project.
  • These “native or global” discussions are reminiscent of the mid-90s multimedia-authoring forums, where some insisted that CD-ROMs made using OS-specific tooling & runtimes, such as Microsoft Visual Basic or Apple Media Tool, would be more readily accepted by audiences than cross-platform Macromedia Director work. The evidence didn’t seem to bear this out.
  • Does localizing to OS-style UI conventions help make things friendlier for people stuck in that OS? Sure. But localizing “color” to “colour” makes things friendlier to those in the UK… localizing the interface’s colors themselves can make things friendlier for those in different cultures… every little bit helps. Not as import as optimizing for accessibility, but in similar vein.

You should do what you find best, to reach different audiences, accomplish your own goals. Watch out for people who take a long time to say that they think you should do what they chose.

“…and, with 60% of precincts reporting….”

It’s been a long campaign, one that many thought impossible, but look what the last few days have brought:

  1. Almost the entire consumer-electronics manufacturing industry has implemented common presentation layers, across devices… you still have native apps when you want to go deep, but the HTML multi-runtime and Flash single-runtime environments are the cross-device ways to bring presentations, interactions, and communications to global audiences.
  2. We’re starting to see workflows which can span print, web, and devices both open and closed… the WIRED Tablet demo migrates existing Adobe design and production workflows into both cross-device AIR and device-specific native code. There is a practical path to delivery.
  3. We’ve also seen the emergence of cross-device app stores, where developers can meet their audiences regardless of which brand of device they prefer. Finally, an opening-up of the consumer marketplace.

The Open Screen Project seemed a near-impossible challenge two years ago… to not only engineer a consistent display engine across workstation, pocket screen and home screen, but also to garner the industry support to implement this at a deep level, integrated with the hardware. I have never seen a software initiative with such ambitious goals, such deep and widespread support from partners, all implementing new things in concert with each other, floating target synch’d to floating target. Player Engineering has done a gargantuan job — no other group understands the new class of devices as well as they. The business coordination has also been amazing. Someday someone will write a book…. 😉

To finally see the results on realworld devices is very gratifying… low-cost tools available to nearly anyone in the world, communicating as they wish with the rest of the world. It’s like the first woodblock printing of books, or the first radio signals… after this achievement, the world will simply be a much different place.

This month we’ve got proofs-of-concept. It will be a little while until 1.0 manufacturing ramps up, until audiences build, until those concepts are refined by the feedback of daily use. There are challenges ahead… we need to not only adapt our existing work for this new class of universal pocket device, but also to develop the new types of applications which will be most useful, once anyone’s screen can call up any information anywhere, can convey voice and video from friends anywhere, where the local environment itself can be augmented by your networked pocket device. I think the next few years will be exceptionally exciting. Getting past the hardest part, of building up to proof-of-concept, is what now lets us start designing for those futures.

It has been a long campaign. Polling may help show probabilities. And the last few weeks of many campaigns are filled with wild rumors and shockers. But election day is the marker which establishes the future. This week we finally saw realworld demos of technologies soon to be in mass production, across the entire consumer electronics industry. There’s lots more work left to do, but this fantastic campaign has finally won through. Presentations, interactions, and communications will never be the same again.

Your new job: What would you like that future to be like? You can start working on it, now…. 😉

Today’s workflows

Last week CSS guru Dave Shea started a workflow discussion by describing how he starts visually in Photoshop, only moving to code as the visuals are approved, and has discrete “handoff” stages where he passes generations of finished visual assets to interaction designers. I thought the comments were notable for the diversity of workflows that others described.

This week Jason Fried at 37 Signals described their approach, which goes from paper sketch directly to HTML/CSS, and comment here again show the diversity of workgroups and workflows. Jeff Croft had a good followup essay showing how the workflow is dependent on the workgroup and the types of tasks each group is attempting: “So who’s right? The answer is simple: we both are.”

One angle that Jeff touched on is how the project’s approval process dictates so much of the workflow… a single-person project doesn’t need to gain consensus on ideas the way that a single-company team would, and the situation is even more complex for a multi-company project, such as an agency achieving approval on an implementation from multiple individuals and teams within a client company. Projects have vastly different needs to explain themselves before completion.

People creating content come from different backgrounds, have different mental models, prefer different ways to bring an idea into reality. Then each different team creating content has different needs, different flows of passing work among the group, building pieces up into a structure. And then atop that, different projects have different constituencies that they must satisfy during development. Individual creation, team coordination, stakeholder approval… layers of variables piling up atop each other.

Back in the early part of the decade Macromedia introduced “the designer/developer workflow”, DevNet and the rest, to unite the different disciplines of serverside applications (ColdFusion) and clientside applications (Flash Player). That was a necessary step, but not a sufficient one, as the three conversations above show. Few workgroups have just a designer component and just a developer component. The process is iterative, and usually involve many more stakeholders than one individual creating interaction logic and a second creating business logic.

I was impressed by the range of workflows, skillsets, and approval needs people added in comments to the essays from Dave and Jason. Adobe has been working in this area for awhile, but it’s a very difficult problem to solve… or, rather, set of problems to solve. We can’t just satisfy a single workflow, but must work to support the range of different ways that groups work together today, all while remaining accessible (in learning curve, cost, and flexibility) as well as open (so your data remains portable, and other components can be plugged into the workflow).

Hard task, but that’s what we’re trying to accomplish here….