I've been asked by Creative Bloq to write a hands-on review of Adobe's web design tool Muse. This isn't actually it - that will come tomorrow. First, I thought it best to give a proper overview of where Muse has come from, what problems it's trying to solve, and where it's going in the future.
Because let's face it, if you're not already using it, there's a quite lot to get your head round...
Long time coming
Let me start with this: dang, I wish Muse was available in 1995! And frankly, I don't see any good excuse for it not having been here circa 2000.
But, it wasn't. Around that time we design types were thrust into the position of producing web pages for our employers or clients, which to our shock, included the need for programming. Why should we have to code, this was never needed for print work?
For many of us this was training under fire, because there were real threats of losing one's job if we couldn't make the switch from print to web production.
Many did lose their jobs, and found themselves vying for an ever-shrinking pool of old media jobs. They were replaced by people that could make their way through HTML and other foreign languages. These new media folk may not have been as good at design, but in all candor, design is easier to fake than programming skills are.
The need for a tool
Let me repeat this line, as it will be important later in this article: "design is easier to fake than programming skills". It's the difference between an interior designer, and an electrician. There's no absolute right or wrong with design, but you will most certainly know when your lights aren't turning on.
Given all that, one would get the impression that today, 20 years into the age of web, that nearly every designer is up and running with web dev techniques, right?
Well, it appears that is not the case. There are in fact millions of creatives out there that were simply never able to get up the learning curve of all the coding that good sites take to make work. And Adobe has finally realized this.
The penny drops
Adobe realized that the options it had offered the market over the past decade didn't cut it for a huge number of folks. Dreamweaver, for all its additions in recent years, is still predominantly a tool for those that can call themselves 'developers'; it needs you to know code.
Flash solved many designers' needs, but it had issues of its own. Its interface is a bit idiosyncratic for some, especially those coming from a print background. And it was really designed for animation, not websites. Plus, while Adobe (and Macromedia before them) continued to add pre-fab code objects to Flash to accomplish most of what you would otherwise need programming for, some knowledge of its Actionscript language was needed for lots of things.
Finally, someone at Adobe must have began to pay attention to something that kept happening. People were continually asking for ways to create web pages from their InDesign program. And why not, it makes perfect sense, right? Why not use a page design/layout program to, well, design and layout pages? Why should we care if its destination is paper or pixel?
The InDesign option
To this end, over the last handful of years Adobe has added a range of export options to InDesign, which include HTML, SWF, PDF, EPUB and XML support. How cool is that, right? All fun to play with, and if you hone your workflow and have very specific needs that those exports can handle, you have a great thing. But I don't think I'm being unfair to Adobe when I say some of these export options were rather limited in scope. In other words, no, you are not really going to develop an entire website within ID.
But here's the thing, the fact that there were so many page designer types asking for this feature must have tipped Adobe off to the fact there is a real market for a program that would be an easy transition for ID users. They began to respond.
Enter Muse.
Muse is not only Adobe's first 'doesn't need you to code' program, but actually 'doesn't even allow you to code'. It is so designer oriented and so not developer/coder oriented that there has actually been a cultural backlash for it within the web dev community.
Backlash
Even on this very website, we can read of developers who are speaking of this new program in terms anywhere from mildly disparaging, all the way to ripping it apart at the seams. This began at the onset of Muse's release. Why all the angst and anger at Adobe? Why the claims that Adobe has lost its soul and is not properly serving its market by releasing such a program? I wondered.
Most of the comments centered around the fact that Muse is code-free. The divide sharply splits from that point on: Adobe, and obviously many of its designer customers, feel code-free is perhaps Muse's biggest selling point. Adobe has come out to say, and I paraphrase, "The days of coding are over!" Cue applause.
The nay-sayers in the audience can be heard rustling, booing and maybe throwing a tomato or two in the direction of Mountainview California. They talk about how delivering a program for the web without control and access to the code is so terribly short sighted, non-functional and generally selling something that will inherently just not work. And how the code that it generates is terribly written and bloated.
Between two camps
I find myself in an odd place between these two camps. With a design and art background and no formal programming training, I have taught myself a fair amount of what I call 'interactive/multimedia' coding skills. So I learned Director Lingo in its day, and Flash ActionScript 1-3. And I've enjoyed coding, though I am dog slow at it, and a programmer friend once told me that I know just enough coding to get myself into trouble. True.
So I get both arguments, and will go so far as to say that the nay-sayers are technically correct in what they say. But only within a certain framework of practicality. This isn't unique, we see similar arguments in other areas of life as well. Have you ever spent much time in a home improvement center? There are generally two types of people there, the do-it-yourself homeowner, and the professional builder.
A contractor is overheard saying: "You see those idiots? They're using that cheap press-tile flooring instead of the better vinyl rolls and glue guns. What fools, it'll never last them more than five years." He may also be heard to end with, "...they should have just hired me to do the job the right way!".
Technically the contractor is right, it won't last more than five years. But maybe that's just fine for the job at hand, and maybe they simply can't afford to hire a contractor. Muse isn't very different, really. Yes, it's a compromise compared to developing with a programmer providing hand-tooled code.
When it's right
But let's get past the question of what is better, and get to the right question which is: What is most appropriate for the particular job in front of us? What is the cost versus functionality needs of this job? Is a coder needed?
Determining if coding is needed for a job or not isn't always an easy thing to do. More often than not however, the scale of the project will dictate it for you. The size of the client, it's needs, and ultimately the budget will often draw fairly hard lines in the sand on what you MUST deliver, and what you CAN deliver.
The other factor is that the type of shop you run will dictate this as well. Muse is targeted towards the shops that simply do not have easy access to coding, or a programmer on staff. But even with one on staff, I can share that I would often think twice before handing it off because if I could knock out some small code myself, it just kept production moving along at a better pace. Muse will most definitely keep production moving along at a better pace!
Design is easier to fake than programming.
When it might not be right
As the nay-sayers have said, Muse is not the answer to every job. And while programmer types may be able to fake some design skills without the world coming to an end, there are things that Muse cannot do programming wise. And that we design types simply cannot fake in apps like Dreamweaver.
To beat our home improvement analogy to death, sure, maybe you can put in a new vanity and redo that kitchen floor all by yourself. But you probably want to think twice before you start doing any electrical work or run any gas lines, right?
Website projects that deal with larger and more complex sites may not be a good candidate for Muse. Sites that need heavy ecommerce or database driven content for example, are probably best left in the hands of expert coders. I've even heard of smaller sites having problems integrating PayPal commerce buttons, or various conflicts that arise.
Constant updates
The bottom line is that Muse should be viewed as a new technology in itself, and most things you may want to do need to be tested. This is a bit hard given that Muse is intended for creatives that are not prone to testing and are unlikely to have quality assurance procedures in place.
Additionally, there will be levels of functionality that are currently not built into Muse, and thus unable to be added. Adobe is adding more drop in functionality all the time and Muse imports animation files from Adobe Edge Animate. Still, heavily customized projects might best be done elsewhere. This may include a variety of rich web applications and content needs.
So while we may have a way of avoiding the drudgery and hair pulling associated with programming, do not kid yourself into thinking Muse solves everything, nor does it remove from our duties the need to test-test-test. In some ways, it will actually increase that since there will be things that have worked wonderfully out of Dreamweaver, that now do not work with Muse.
Hands on
In this overview, I've explained where Adobe Muse has come from, what problems it's trying to solve, where it's going, and where it can and can't help you on your design projects.
In part two, I'll get hands on with Muse and see what it's like to actuually use it in practice. I'll explain what features work well, what needs improving and what kind of results you can expect from your efforts. So don't miss Creative Bloq tomorrow to catch part two of my investigations!
Words: Lance Evans
Lance Evans is creative director of Graphlink Media. He has written books on 3D, and produced the 3DNY Seminars for Apple and Alias.
