Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh, Adobe... read the copy, then view the source.

muse.adobe.com

Post reply on HN
Print view View original

111–120 of 151 posts

Re: Oh, Adobe... read the copy, then view the source.

#111

Post by yahelc »

sunchild wrote: post #22
cloudwalking wrote: post #19

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?

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.

WYSINWYG: What You See Is Never What You GEt.

Re: Oh, Adobe... read the copy, then view the source.

#112

Post by nickolai »

InclinedPlane wrote: post #7
pierreminik wrote: post #6

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... .

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…

Hopefully this issue will get back on the table with increasing mobile internet usage, and people bouncing off because of poor load times. I cant count the number of times I have to hit the back button just because it takes too long to load.

I really do not want to see that 1mb picture of your dog mascot, but i was actually interested in your 5kb product description... Oh well if you dont care about your site, you probably dont care about selling your product either.

Re: Oh, Adobe... read the copy, then view the source.

#113

Post by pornel »

jules wrote: post #96
potatolicious wrote: post #56

Earlier quoted context omitted.

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 t…

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 o…

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

Re: Oh, Adobe... read the copy, then view the source.

#114

Post by stephen_g »

ugh wrote: post #73
sunchild wrote: post #22

Earlier quoted context omitted.

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.

Why? WYSIWYG works perfectly well in InDesign (which is absolutely awesome, by the way), why can it never work with HTML? I don’t really understand. Current and past implementations are or have been bad, sure, but why can’t it work in principle?

One big part is that when something is designed for print, it is essentially always designed for a fixed size page, so you don't have to deal with resizing. Then there is the fact that web sites have to cope with people not always having the same fonts you do - which makes it almost impossible to do pixel perfect designs involving text rendering.

Then there is the fact that something like an Indesign document doesn't really have any concept of separating the style from the actual content. For the time being at least, humans are much better at logically ordering and marking up text, and then adding the style with CSS, unlike programs which add a whole lot of extra markup and CSS to do the same thing.

Those are just a few things which make WYSIWIG work a lot better for print than it ever could for web - and there are more... These things will probably be somewhat resolved as time goes on (ie. with wider support for @font-face and so on) but I think that hand written HTML will be better for a long time to come.

Re: Oh, Adobe... read the copy, then view the source.

#115

Post by gcr »

pornel wrote: post #113
jules wrote: post #96

Earlier quoted context omitted.

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 o…

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

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

Re: Oh, Adobe... read the copy, then view the source.

#116

Post by coliveira »

InclinedPlane wrote: post #51
skrebbel wrote: post #28

Earlier quoted context omitted.

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 gzi…

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 fi…

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.

Re: Oh, Adobe... read the copy, then view the source.

#117

Post by stephen_g »

Tractiol wrote: post #85

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.

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...

Re: Oh, Adobe... read the copy, then view the source.

#118

Post by steele »

acostin wrote: post #103
arnorhs wrote: post #86

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...

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…

Why not CQ5 or ADEP?

Re: Oh, Adobe... read the copy, then view the source.

#119

Post by snorkel »

armandososa wrote: post #47

I recommend reading this post by Zeldman from last year: http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-c... 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.”

No, clean HTML semantics still matters a lot! Forget about programmatic efficiencies like crawlers and page load times. Think about the poor web dev who is handed this steaming heap of bad markup like so:

Management: "We need you to change all the buttons on this web site and enlarge the logo."

Web dev: "OK, these pages were puked out of Muse. Do you have the Muse project files and a copy of Muse for me to install?"

Management: "Muse? What's that? No, we don't have the source files. Can't you just edit the page?"

Web dev: "Sure. After I drink this bottle of Scotch and look for other job postings."

So guess what? HTML is still source code not a machine language.

Re: Oh, Adobe... read the copy, then view the source.

#120

Post by tomlin »

potatolicious wrote: post #56
armandososa wrote: post #47

I recommend reading this post by Zeldman from last year: http://www.zeldman.com/2010/07/05/an-indesign-for-html-and-c... 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.”

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 t…

For me, this is really about code generators in general. No need to center Adobe out here, as I can't think of a single IDE that doesn't generate all kinds of extra code that, to me, is useless 90% of the time.

You also should keep in mind that Muse is a beta and the Muse site itself was actually written with Muse.

In this case, I think Adobe deserves the benefit of the doubt. They're trying to showcase this product with hopes that people like us will come to the table and give constructive feedback rather than point to the past and say, "See, I told you! Damn Adobe!".

Post reply on HN