
Oh, Adobe... read the copy, then view the source. - josscrowcroft
http://muse.adobe.com/index.html
======
pierreminik
Please, tell me this is Adobe _trying_ to mock IE. It has to be, right? I
mean, they've always sort of not valued source code, but this is beyond
torturing it.

This is so _inspirationally_ horrible someone spent hours remaking it, like it
should've been: [http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-
dem...](http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/).

~~~
InclinedPlane
Indeed. The inefficiency here is astounding, especially considering the
relatively straightforward page layout involved.

Original: 1496 lines, 77.9kB

Your version: 104 lines, 4.75kB

I'd thought we'd progressed beyond the state of a decade ago where Dreamweaver
or what-have-you would build you a cumbersome and baroque html splooge to
match whatever you had done in the designer, but I guess we haven't advanced
that far. Just goes to show you that front-end devs are still as necessary as
ever I suppose.

~~~
skrebbel
How about we've progressed to the state where HTML is the bytecode you don't
want to see anyway, and designers can use modern tools to manipulate it? If
the generated markup works, cross-browser and cross-platform (I don't know to
what extent it does, but let's assume so), then what's the problem?

For many purposes, optimizing the HTML nerd out of the process is a much
bigger win than a 20k download (don't forget gzip) is a loss.

I know this is going to get me downvotes, but I think the dogmatic "HTML shall
be written by hand!!1" attitude all over this thread is just people clinging
to the past.

~~~
InclinedPlane
In this case it's a 78k download, of just text. That adds up over enough
users. It adds to page load times, it adds to page _rendering_ times, it adds
to bandwidth costs.

And then there are the higher level issues. What happens when you get a bug
report about how the page is rendered in a specific browser/OS? Do you want to
wade through 1500 lines of html or 100 lines? Which do you think will be
easier and faster to fix? Which do you think will be easier to inspect for
correctness from the start? What happens when you need to figure out why your
page is rendering too slowly? Which is easier to analyze, which is easier to
speed up? What happens when you want to change the design? What happens when
you want to take the design and use it as a UI for a web-app?

Using a tool that generates such crappy HTML may allow an inexperienced person
to create a web page with a decent appearance, and it may even save an
experienced designer a few minutes upfront. But over the lifecycle of a
project it ends up being an enormous drain. If you're an enthusiastic teen
putting up a web page for your mother's knitting circle, it's fantastic! But
this is not in any sense a truly professional tool.

~~~
coliveira
I think you are not considering the many websites for which this inefficiency
doesn't matter. Sure, if you're write Google's main web page, every extra byte
counts. But there are not many web sites where this is even close to be true.

For example, there is no big difference in functionality if the Adobe web site
takes a few extra milliseconds to load. Customers just want to buy a product
and get out of the way. And Adobe is a big company... This is even more true
for their customers, thousands of small websites that just want to publish
content as quickly as possible.

~~~
SoftwareMaven
We aren't talking milliseconds, we are talking seconds to 10s of seconds. At
that point, you are risking bounces, which any business-oriented site should
fear, even Uncle Bob's Burger Bar.

------
armandososa
I recommend reading this post by Zeldman from last year:
[http://www.zeldman.com/2010/07/05/an-indesign-for-html-
and-c...](http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-css/)

    
    
        Says Nack:
    
        As I noted the other day, “Almost no one would look
        inside, say, an EPS file and harrumph, ‘Well, that’s not
        how I’d write PostScript’–but they absolutely do that    
        with HTML.”

~~~
potatolicious
There's a good reason for that - clean HTML is not just the territory of
pedantic/obsessive designers, it has tangible and important benefits to many
sites (note: many, not all).

Sure, if you want a personal homepage, or put up an ode to your dog Scruffy on
the internet, tools like this may very well work for you. But in those use
cases, we've _already_ had capable tools for _years_ , many of which produce
cleaner code than this.

For anything bigger/more professional, dirty/bloated HTML/CSS means a few
things:

\- Bigger downloads for your visitors, wasting _their_ bandwidth. But
whatever, you're not paying for _that_ , right?

\- More data transfer for you and your host. That you _do_ pay for.

\- Increased latency (sometimes massively) and decreased accessibility for
people with slower connections. Given the awesomeness of American broadband
performance, that means _most_ of your customers/visitors. More latency = more
bounces = fewer visitors buying stuff from you, reading your ad copy, etc etc.

\- Increased rendering times. See: bounce rate.

And these aren't negligible effects. The difference between a 10KB and 100KB
file is _very_ significant, and you don't need millions of uniques a month to
find out the difference.

Dirty EPS files are not the same thing - because unclean PostScript suffers
from none of these deficiencies except bigger downloads - which for EPS files
has little to no consequence in the typical use case.

~~~
jules
Just like PNG output from Photoshop, soon HTML+CSS output from design
applications will beat most humans, or at least be reasonably close so that
this complaint doesn't apply any more. It's not very hard to do a lot better
than the source code of this web site.

Will Google design their homepage with Muse? No, they want to hand optimize
it. Will people design websites for small businesses that get accessed a
handful of times per day with something like Muse, when its output gets
better? Yes. It might not make nerd-sense, but for a lot of sites it does make
business-sense to have an increased page size in return for saving a lot of
design and development time. Think of it this way: of all the things a person
designing a website for a small company might spend their time on, is reducing
page size the most profit increasing activity?

~~~
pornel
PNG output from Photoshop is just as bad as Muse's HTML (PNG optimisers cut
"Save for web" sizes in half).

~~~
gcr
PNG optimisers are still automated though. I think parent was referring to
hand-tuning the parameters yourself.

------
arnorhs
This software, Muse, was not used to build that website.

The software used is _Business Catalyst_ (<http://businesscatalyst.com/>), an
enterprise CMS (all-in-one solution _urgh_ ) Adobe bought 2-3 years ago. And
yes, the semantics are very bad.

In fact, I disliked this piece of software so much, I wrote a post about it a
few months ago: [http://arnorhs.com/2011/01/19/11-reasons-why-business-
cataly...](http://arnorhs.com/2011/01/19/11-reasons-why-business-catalyst-
sucks/)

~~~
acostin
Hi Arnorhs, I am Alexandru working for Adobe, and I recently took over
Business Catalyst.

We did read your review and took it at heart - it wasn't easy as you were very
direct. However, there is a lot of truth in your review and there's a lot for
us to improve. And believe me, that's our goal - to improve the product until
customers love it and we have folks like you give us much better reviews :) -
because you would actually like the product.

I'd love to chat with you and try to show you where we're going and get your
perspective on what should we do differently. Your feedback would be very
important for us.

If you're interested, please contact me at acostin@adobe.com

Sincerely,

Alexandru

~~~
arnorhs
I'm sorry if I hurt somebody's feelings (though, that was not my objective).

There were a lot of positive articles on-line when I was evaluating BC. But I
later found out that most of them are written by various BC-partners (a good
business decision there) - but that also meant that they were a bit biased and
skipped over the bad parts.

I'll send you an email. I'm pretty sure Adobe is able to make it better (I'm
an avid adobe fan mind you)

~~~
mashmac2
This. Is one of the things I love about HN. When you can write a critique of a
product, and hear from someone directly involved in it, that's a fantastic
thing. When they're a fellow-HN reader, even better.

------
jeffreymcmanus
Particularly amused by <p class="paragraph">

~~~
lean
OOCSS says to never specify elements in the CSS, right? :)

------
cloudwalking
People on HN love ripping on Adobe. I agree that the code is gross, but can we
get some _constructive_ criticism? What's a better way to programmatically
write good HTML?

I'm willing to bet everybody on this thread writes their HTML by hand. How
many of you have a framework for programmatically writing HTML? How many have
a framework for writing HTML as broadly as Muse can?

~~~
sunchild
WYSIWYG for HTML is just never a good thing. You spend more time learning the
idiosyncrasies of a crippled GUI when you could just get busy in a text file.

~~~
skrebbel
I agree! I also think compilers are ridiculous. You spend much more time
tuning their output and learning their arcane options and switches and pragmas
than you would need just writing ASM by hand.

~~~
InclinedPlane
If modern compilers were as inefficient and horrid as html design tools were a
lot of people _would_ code directly in ASM.

Also, HTML is not ASM, it's a very high level language. The ability to code a
scant few hundred lines and nevertheless have that become a full-featured,
rich, beautiful, and complete layout for a web page or a web app UI is
tremendously powerful, and it's no wonder that high end web devs and designers
take advantage of that. Until web design "compilers" approach anywhere within
spitting distance (even within a factor of 2) of hand coded designs in terms
of maintainability, cross-browser compatability, performance, and code size
that's not going to change.

~~~
coliveira
> If modern compilers were as inefficient and horrid as html design tools were
> a lot of people would code directly in ASM.

Well, compilers may be good for languages such as C++. But for most languages
such as Python and Ruby, the code executed is just plain terrible compared to
ASM. I don't see anyone writing Ruby code and complaining about that waste,
though...

------
X-Istence
Since everyone is saying look at the source, might I suggest taking a look at
the CSS that is produced for that specific page ... yes, I said page. Each
page has its own CSS file that is REALLY big.

------
rrrazdan
The sense I am getting is that GUI generation of markup code is as inevitable
as was the first compiler back in the old days. Whether that point is now or
not remains to be seen. Back then we had a combination of increase in RAM
sizes/processor speed and democratization of Computers beyond advanced
research laboratories, that prompted this change. It no longer was necessary
to worry about that extra 10 KB or so of cruft that the compiler added. I see
similar concerns about file sizes here, whether the point of not caring for
bandwidth is here remains to be seen. And could this be the second wave of web
democratization? I'd love to see my mum design her website with this.

~~~
mattmanser
Are you too young to remember front page?

We've already trod this path and it lead us to dark places.

~~~
rrrazdan
Like I said the correct time and the correct product will be the beginning of
a new era. It definitely wasn't time then, and it may not be now, but isn't it
kinda inevitable, that we would someday move to a layer of abstraction above
the html code?

------
nfm
That was _worse_ than I prepared myself for!

Almost the entire page is duplicated within a `<!--[if lt IE 9]>` block...

~~~
antimora
I was shocked too. I couldn't believe the commented section was that long.

------
olalonde
I'm definitely playing the devil's advocate here, but didn't assembly
programmers have the same kind of reaction regarding compiler generated
assembly not so long ago?

~~~
Deestan
Assembly is low level; practically machine code. It is hard for humans to
read, and writing a program concept in assembly must go through a lot of
layers.

HTML is high-level and designed for humans to read and write. It maps
_directly_ to the concepts it conveys.

~~~
cksk
I registered just so I could say this. People keep comparing HTML to Assembly.
Come on. HTML is probably the highest level you can get when talking to a
computer, at least for the foreseeable future.

I think the more appropriate comparison is to those software generators, or
whatever they are called, in which you drag and drop buttons and text fields
and have arrows (or something) to convey action.

You don't see a lot of good software made with those, now, do you?

HTML is not Assembly. It's not even C. It's Python, or Ruby.

------
josscrowcroft
"You can design and publish original HTML pages to the latest web standards
without writing code" - WTF

I think compounding all this inefficiency is how they have "<!-- group -->" on
EVERY SINGLE DIV.

Someone should use the Tilt extension to visualise this page in 3D
([http://hacks.mozilla.org/2011/07/tilt-visualize-your-web-
pag...](http://hacks.mozilla.org/2011/07/tilt-visualize-your-web-page-in-3d/))
and screen cap it.

~~~
bherms
<http://dl.dropbox.com/u/661094/tilt.png>

~~~
william42
Now do it for the remake posted up in this thread.

~~~
bherms
I tried it, but for some reason the plugin/my browser had a big problem with
the remake. There were very few layers, but it was overlaying my calendar onto
the image or something strange. I restarted the browser and tried again but it
kept messing up.

------
alfiejohn_
Bridge to Engine Room: We need more DIVs

~~~
jjm
Cap'n, Engine Room here - We've diverted emergency DIVs to sensors, increasing
noob sensing range. We'll need more add-ons if yer want mowr DIVs!

~~~
terinjokes
I read this in my "Enterprise problem of the week" voice.

------
mambodog
This is a great example of following the letter of a standard, but not the
spirit.

------
zacharyvoase
Has anyone seen the video? They're trying desperately to map print paradigms
to the web. It's a major fallacy which many developers (and product managers)
fall into.

~~~
jackowayed
So it will sell well to companies with a lot of money, then? Sounds like a
good product.

~~~
pyre
It will sell well to companies with a lot of money by telling them what they
want to hear, rather than what they need to hear. It depends on your
definition of a 'good product.'

------
azulum
Muse (code name) Design and publish unreadable HTML because you don't write
code.

------
epo
On a casual inspection this is just bloated ineptness, exactly what I have
come to expect from Adobe.

One passage consisted of a string of empty divs of the form <div
class="wrap"></div> which a decent 'code generator' would simply have omitted.
In fact the bulk of the bloat appears to be divs which add nothing to the
page.

I strongly suspect one previous version of this code generated tables, then
they got the "tables used for layout are bad" memo and did a simplistic
translation to nested divs.

Perhaps, to be charitable, they have debugging turned on.

------
QuantumDoja
Q. How many of your visitors look at your pages source code?

Q. How many times do you inspect the compiled assembly to see what it
generated?

One day these tools will be perfect, it's just a shame for me that Adobe have
copied what I've done for the second time:
[http://blog.gameweaver.com/2011/08/16/has-adobe-copied-
anoth...](http://blog.gameweaver.com/2011/08/16/has-adobe-copied-another-one-
of-my-ideas/)

------
RobLach
I wouldn't recommend Muse purely because this is how that page renders for me:

<http://i.imgur.com/c7tBl.png> <http://i.imgur.com/6DUW0.png>
<http://i.imgur.com/sfGmv.png>

~~~
chaz
Which browser / OS?

------
beatpanda
This is a great product, insofar as 10-year-olds will steal it from BitTorrent
and use it to get their first taste of web design, then stop using it once
they get serious, then reminisce about how terrible their first projects were.
Just like lots of us did with FrontPage.

------
kysol
580 . . . Need more . . .

<div id="yo-dawg"> <div id="i-put-div-in-your-div"> <div id="so-you-can-div-
while-you-div">This site built in Muse (code name) by Adobe®</div> </div>
</div>

------
jmitcheson
There is company that makes a Photoshop plugin that converts to
HTML/CSS/Images too

<http://www.medialab.com/>

I don't know what the output is like, though.

------
cbs
Oh heavens! An ugly html file? We can't have one of those dirtying up our
monstrosity that poorly attempts to turn a document into an application.

------
corry
I agree that coding your design into HTML/CSS is a waste of time generally.
I've had good luck with PSD-to-HTML services.

So instead of Adobe automagically converting my design to HTML/CSS/images, you
get humans from India (or wherever) doing it by hand.

For $100 - $200 you can get clean, cross-browser, easily tweakable HTML/CSS
and images. And you get it in 24 hrs.

I've used www.psd2html.com a few times and the quality was quite high.

------
secoif
I have seen far, far more bloated code generated by Drupal (esp. Using panels
module)

------
RyanMcGreal
Characters: 32,767

Characters after stripping HTML, javascript and CSS: 1,464

------
apricot13
div soup is better than table soup!

------
mcauser
Makes ColdFusion look efficient by comparison

------
leon_
So they use tables. Big deal.

I don't get that CSS snobbery. Tables do work on even older browsers. That's
something you want for a tool that generates code for people who don't
want/can't put up with writing HTML themselves. For them the product has to
work and look good in most of the browsers.

~~~
intranation
It's not CSS snobbery. It's HTML snobbery, which to some people still matters,
for the usual accessibility reasons as well as wanting to write the correct
code for the job.

~~~
leon_
Sure, but if you're hired to write HTML code then I guess you won't be using
tools like this. You know how to work around browser perks. But Joe who just
wants a website made probably doesn't - and he doesn't care.

------
Tractiol
Hilarious how many people on Hacker News care what the HTML looks like.

You really are idiots if you're worried about 'that much text' going over the
internet. You have no concept of data.

~~~
stephen_g
Some people here actually run popular web sites. When you're serving millions
of requests a day, a few KB of difference in page size can make quite a bit of
difference on how much you pay for bandwidth...

Not to mention that when a browser doesn't render the page correctly, some
people don't like wading through thousands of lines of div-soup when they
could be debugging one hundred and fifty lines of markup instead...

------
realize
That is one of the most horrible things I've ever seen. Adobe, please stop
having such bad taste. Whenever there's a right way to do things, you seem to
commit to the OTHER way.

------
josscrowcroft
Wow, looks like you really _can_ create striking sites with Muse:
<http://maxart.s3.amazonaws.com/muse/index.html>

