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

31–40 of 151 posts

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

#31

Post by doublesprout »

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

Dreamweaver required you to know quite a bit about HTML. Muse is like InDesign/Photoshop, which people use to do mockups of designs (not UIs/wireframes) today. It cuts translation to code from the workflow. That's a meaningful shortening of the feedback loop for a designer.

As for the rest of us, we don't have to be concerned till Muse starts learning the quirks and features of CSS faster than ourselves.

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

#32

Post by skrebbel »

orblivion wrote: post #29
skrebbel wrote: post #26

Earlier quoted context omitted.

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.

Your argument is against haml, not a gui.

Oh well I also think vi is ridiculous so there :P

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

#33

Post by tiddchristopher »

strager wrote: post #18
tiddchristopher wrote: post #16

Earlier quoted context omitted.

The original does have at least one advantage: preloaded hover images. It's nice for them to improve usability a tiny bit, along with all the bloat. I can't imagine a complete newcomer to HTML and CSS hacking together a page and having it come out nearly as bad. Any designer who can learn design can easily learn to code better than Muse, in my opinion.

Sprite sheets?

I can't tell whether you're suggesting a solution or taking a guess as to what Muse did. I think it's the latter. Sorry if I interpreted your question incorrectly. :)

They're using a hidden div full of elements to load the hover images before they're requested by an actual hover. It's all the way at the bottom of their code code: [Removed for brevity]

Sprite sheets are another option (using the sliding doors technique), but they're a bit more ungainly. They would save a couple HTTP requests, but that extent of optimization isn't necessary on most sites. Unless I've already combined all my stylesheets into one file, I certainly wouldn't start combining images.

What really matters is perceptible lag to a user, and either technique work just as well for that.

I find Adobe's technique kind of neat, and I'll probably use it in some of my future websites.

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

#34

Post by pyre »

jackowayed wrote: post #15
zacharyvoase wrote: post #10

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.

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

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

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

#37

Post by perlgeek »

olalonde wrote: post #36

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?

At least the compilers produce valid assembler code most of the time.

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

#38

Post by barnaby »

skrebbel wrote: post #28
InclinedPlane wrote: post #7

Earlier quoted context omitted.

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…

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…

You're forgetting that when several thousand people access a site per second, even a 1kb difference means thousands of dollars of bandwidth cost and fractions of a second of download speed.... let alone 70KB of difference which would bankrupt your company and turn all of your users away.

We don't write HTML/JS/CSS by hand because it's fun, that's for sure. We focus on code-reuse and delayed loading plus AJAX (plus gzip, compress, CDN, cache, etc.) because the customer focuses on speed and the CEO focuses on the bottom line.

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

#39

Post by tiddchristopher »

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?

Regarding constructive criticism, I posted elsewhere in this thread that Muse generated a div to preload hover images. It's a nice bit of usability optimization, but the code could certainly benefit from a dose of minimalism. Even if Muse initially generates the page with this much bloat, I'm thinking it would be trivial [for Adobe] to run the page through an optimizer that rips out anything without style assigned to it. Then it could refactor the stylesheets, getting rid of redundancies, i.e. styles targeting p.paragraph and the like, and run a second round of optimization. Maybe I'm thinking about it wrong, but it would be worth the effort if they could cut the page into even a tenth the original size, which is a gross under-expectation.

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

#40

Post by tjarratt »

mun2mun wrote: post #24
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?

But first tell me why designers need html page generator? Is learning HTML and css that much hard in google era?

Do you really think everyone has 100+ hours to spend learning the idiosyncrasies of HTML and CSS? That's asking a lot for someone that just wants to put up a landing page for an idea, or to design their portfolio.

Everytime my artist friend wants to put their portfolio online, I suggest they start by writing some simple markup and half an hour later I'm explaining the finer points of the box model while they whinge about how they'd rather be using Adobe Illustrator. The truth is that there will always be a group of people that are able to visualize what they want to create better than they can verbally, or symbolically.

Post reply on HN