Where’s Adobe Taking Us?

image: jer thorp's "random number multiple," from flickr

image: jer thorp's "random number multiple," from flickr

So now that we’re all coming off a long weekend, I have a broader look at an issue we’ve all been discussing lately: where design’s marketplace is going.

The short answer to that is: screen-based devices. We all know this. Print is going to continue to become more of a specialized practice area, just like design for motion, like design for the web. Magazine publishing will more than likely continue moving to tablets and devices.

The problem with this movement from print to devices is that designers are not being taught in any way how to create programmed objects in design curricula, period. A keen understanding of the web is hard enough to find in today’s design curricula, and deep programming knowledge is nonexistent. Clearly, tools need to be made to bridge where educational institutions are failing.

The company who designs all our toolsets is in a position where they absolutely must lead the way into the future of publishing. Last week, I had the opportunity to speak with Adobe’s Lea Hickman, who’s the VP of the Creative Suite team, and product manager for the Design and Web segments. I asked her a few questions about where Adobe’s leading publishing and design. Not just the CS tools, not just digital publishing—all of Adobe.

In a nutshell, Lea said that Adobe’s core market is, not surprisingly, visual designers without extensive technical knowledge but broad visual skills. Adobe’s current focus is on making visual tools for people who cannot program. That points to a few things which have happened pretty recently.

Firstly, Muse, which was recently released in a beta form. The tool is pretty decent from my first rough sketch in the site—its code is a bit of a wreck, but not much worse than the kind of automatically generated code from within WordPress or Tumblr, two of the most broadly-adopted tools designers are using. (I expect the code to improve, but not for designers’ benefits.)

Muse is interesting in that it’s the first time Adobe’s generated a purely-visual design tool for the web. Combined with its hosting and analytics services with Business Catalyst, this is new tool that will open Adobe to a whole new segment of the market it currently can’t reach (and this is a benefit to everyone, as far as I can see): the single designer who needs a place to host sites, but lacks the technical knowledge to handle it themselves.

This shift in employment, from designers working inside companies to designers working on their own, is also clearly in effect in Adobe’s new subscription pricing, as it should be. While subscription pricing has generated some heat from the design press, the truth of the matter is: corporate employment is disintegrating, and the economy is becoming a broader marketplace of smaller entities. Adobe’s basic decision here is: keep its eighteen-month upgrade cycle, and continue hemorrhaging revenue to software piracy (because none of us can afford $1800 in a single chunk) or break down the revenue into smaller pieces—so smaller entities can afford to participate.

One effect here that nobody’s really pointed out, except a single commenter on this post, is that if a company goes to the subscription model it can become more nimble and let its department of freelancers grow and shrink as necessary. Lea emphatically agreed with this point.

One thing Lea pointed out that will help us work more nimbly is a sort of listening period, during which Adobe listens to the public, makes a curatorial decision as to which requests are most feasible, and then implements them into tools and apps more quickly than they have been able to in the past.

If you’ve been working in InDesign lately, like I have been, you’ll have seen this happening recently as Adobe’s tablet-based publishing initiative has gotten more ramped up and the interface evolves in response—and, in fact, the entire development cycle of that workflow has been in response to a field trial during which Adobe designed a workflow while Condé Nast decided what they needed. Before digital publishing, this rapid call-and-response development between a company and its clientele was unheard of.

I asked Lea what Adobe’s involvement with the developer community was going to be, moving forward, since the company had essentially eaten its competitor specializing in developer tools. She pointed to Adobe Edge, which I somehow never heard about—it’s a tool which allows coders and developers to work out complex JavaScript, HTML, and CSS3-based animations and programmatic content, taking over some of Flash’s simpler functions. She also pointed out that Adobe’s been actively involved in JQuery’s development, which I was totally unaware of. (JQuery is a widely-used JavaScript library which powers a lot of the animated content you see on the web and on tablets lately.)

The most interesting thing Lea told me in the entire hour we had together was this: for the Muse development, the InDesign team members were instrumental in helping Muse developers abstract away confusing coded items that don’t mean anything to designers. While that sentence is a small one, it’s absolutely packed with meaning. It means that the future designer will be simultaneously more involved and further removed from technical code, especially on small jobs. And most importantly, it proved that there are valuable lessons to pass between static and interactive design disciplines.

Related Articles:

ADD A COMMENT

11 COMMENTS

  1. I’ve been using Muse since it dropped. Great tool, destined only to get better. My clients LOVE it because I can design site structure and even content while they sit next to me or at a meeting. Code?  Who cares if it works? Seems to be working fine to me.

  2. I’ve been working on the web and in graphic design since before the mouse and WWW, in the 70′s, programming on a Vic 20 and Commodore 64.i’m reading here and disgusted by the arrogance of coders who consider beauty secondary to the code. I don’t give a rat’s ass how nice code is. I want, and I want my site visitors to experience, what satisfies them.
    Good on Adobe for moving toward visual design accessible by non-coders. Expanded content is king. If a site doesn’t work well people can leave it. Simple. Coders, get off your pedestals and move into software or take some art classes. You’re living in the 20th century. Get a new t-shirt and move into the future. 

  3. The quality of Muse’s code is not particularly relevant. Good code, bad code, no matter. Muse and other visual layout tools promote the idea that it’s possible to lay out a website exactly as one would lay out a page in InDesign: drop a paragraph on the left, scoot the headline over to the right, increase the spacing, and—et voila!—you’ve got a finished piece.

    Not so.

    Interaction design inextricably involves designing for change.

    Browsers change. Maybe the screen’s just two inches wide instead of 24 inches. Maybe the person reading the site can’t see at all, and is perceiving the web through text-to-speech tools. Maybe the site suddenly has to accomodate twelve new articles. Maybe the site changes because a visitor comes along and taps a button.

    I’ve got no objection to visual thinking. The notion that you can create fixed artifacts for the web, though, is folly, destined to create websites that are failing the moment they’re done. They promise control where, in the end, the designer has little.

    Design, in this ever-shifting interactive world, isn’t about making artifacts – it’s about crafting the systems that make the artifacts, be they software systems, typographic languages, or methods for making images. Let go of single pages. Let go of tools like Muse. That’s when the magic really begins.

  4. “Muse is interesting in that it’s the first time Adobe’s generated a purely-visual design tool for the web.”
    Let’s not forget Adobe Pagemill. Adobe’s first attempt at visual design for the web was far from great… Muse appears potentially much more superior, but is in fact, Adobe’s second attempt. I have very high hopes for it. As a designer without much brainpower for code/logic/math/etc … I’ve learned as much as I could to limp along in Dreamweaver… but I’ve been yearning for a modern and robust (yet easier) option.

  5. “muse’s code is also clean, semantic, and standards compliant.” — If you think that statement is true, then you have zero idea what clean, semantic and standards-compliant actually means.
    Here is how Muse renders bulleted lists:
    <p id=”n30″>• E-commerce </p> <p id=”n32″>• Customer databases</p> <p id=”n34″>• Customer acquisition and retention  </p> <p id=”n36″>• Inventory and order management </p> <p id=”n38″>• Shipping and payment </p>
    That is just ridiculous – SEMANTIC markup would just use an <li> tag like a sane IDE!
    My other personal favorite is:
    <h3 class=”heading-3″>
    That’s just redundant and plain stupid.
    And why do simple links in menus require JavaScript to function?!? Try viewing a site made with Muse with JS disabled – it is an exercise in futility.
    Look, a car designer can design a car all day long, but it still has to run. One could make a car look like anything they wanted, but if not everyone could sit in it or if it got 1 mile per gallon, it would really be more of a novelty than a useful mode of transportation.
    That is Muse to me at this point – it is good for making pretty concepts, but that is all. I have no problem with the concept of Muse, but it saddens me greatly that Adobe would put something like this out there and have all the print designers in the world thinking that since Adobe made it, it must be great – it is not.
    “Adobe’s current focus is on making visual tools for people who cannot program.” — That is the reason I’m using Netbeans more frequently now. Adobe has lost its way when it comes to the web.

  6. I think that applications like Muse need to be further developed and pushed into ways that revolutionize the way designers make websites.Digital devices are also too new to really decide whether they are what all media is going to be viewed on in the future. Take into concideration the environmental impact manufacturing these mobile devices have on the environment vs paper. It would cost more for our society to shift everything to mobile devices instead of paper as well. Think about the cost of producing them, the cost to power them, market them, employ people who know how to put publications out for them. 

  7. It’s true. Print is dying. Marketing budgets are increasingly weighted toward electronic media.

    Muse builds “clean” code. Big deal. I did some usability testing of the MUSE online samples. They are incredibly bloated pages. One in particularly had a 4MB home page. Gak! The software cannot compensate for understanding fundamentals of good visual asset strategy or optimization. Speed is the biggest barrier –especially for smartphone and tablet websites. Beauty is secondary in value.

    Ordinary vanilla skills in HTML and CSS can run circles around MUSE. The Adobe Emporor has no clothes. MUSE is frustratingly ineffective for producing good user experience. It will be beautiful. But will it be usable? Not the way Apple and Google are. It still can’t protect a designer from raw stupidity. It is a money sink for desperate designers who see their livelihood evaporating or going to developers.

    IBM recommends 20K pages and Apple 25K for mobile sites. MUSE can’t even begin to help in those extreme strategies. Adobe wants to help produce “paper-behind-glass” pixel-perfect websites. These aren’t meant for mobile or tablet consumption (cross-device web). Save your money.

  8. “muse’s code is also clean, semantic, and standards compliant.”
    i beg to differ. it’s not that semantic at all. empty links, meaningless containers (paragraphs, spans, etc) when really you’d want to use proper hierarchical elements (h1, h2, etc). it creates the visual illusion of a well-marked up site (and oh, it validates of course…but the validator only checks the syntax, not whether or not it actually makes semantic sense). in particular, this sort of meaningless, non-semantic code causes serious accessibility issues (extreme example of users with screen readers, who rely on well-structured markup to properly use and navigate sites) as well as having an impact on other automated markup-consuming tools (for instance, search bots that use semantic information to better rank/categorise pages for search results).

  9. Design curricula are failing to teach students how to work programmatically, and the best response, then, is to make software that tries to compensate for designers’ lack of knowledge?

    I can’t agree.

    I question the assertion about design education. Courses that deeply examine code are becoming increasingly common, particularly among younger faculty. I come from a traditional print-oriented graduate school, but half of my colleagues were coding or building electronics as part of their work. Students fill the code-oriented courses at the art school where I teach now, and those students flourish.

    I’ll grant that code-oriented courses remain a rarity, for the moment. Even so, better software does nothing to help students learn to think about programatic design, interactivity, or systems. Visual tools help with production, but they do nothing to promote design decisions that account for interaction as a medium. Falling back on easy tools denies students access to the power of new media.

  10. muse’s code is also clean, semantic, and standards compliant.
     
    also, like the code wordpress’ mechanized menu system spits out, it’s not incredibly intuitive to figure out what the div naming actually means. that naming is what i was referring to. muse has to make the same sorts of decisions.

  11. “…but not much worse than the kind of automatically generated code from within WordPress…”: can you explain this in more detail? In my experience using WordPress, it generates very clean, semantic, standards-compliant code. In fact, the core team seems to really pride themselves on being excellent coders, right down to WordPress’s tagline, “code is poetry.”

    To compare Muse to WordPress is to compare an unripened eggplant to a lucious, perfectly-ripened watermelon: the former is created for visual people with no coding experience whatsoever and no desire to learn. The latter is created to make publishing content to the web easy and to allow the separate creation of beautiful and unique interfaces.