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.
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.
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.
> 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...
People make the same mistake again and again with code generation and this goes back as far as CASE tools and Microsoft wizards. The key thing is that you should never use anything where you cannot "debug at the level of the abstraction" as Dave Thomas puts it (Smalltalk Dave, not the pragprog guy). That's why the analogy with a compiler breaks down: You never have to debug the assembly or look at it for any reason except if you are doing real embedded stuff and even there if you end up having to look at or debug the generated assembly frequently then it would be better to work exclusively in assembly. i.e. Its hard enough to map a program into your head, doing it at two levels is impossible to do without making a mess.
People (including me) like to delude themselves though. "I'm not a web/database/embedded developer. Here's a tool that will give me a quick win". But in the end because you find yourself debugging the mess that it generates you have to rewrite by hand anyway meaning that in the long run a quick win turned out to be twice as long as just sitting down and learning how to do it. BTW I think that DSL's could be the next thing that leads people down this path. A great idea but...
Honestly, I don't see how WYSIWYG GUI front-ends for building HTML are at all like compilers for high-level languages. Care to elaborate? I think your analogy will start falling apart pretty quickly.
It's hard (not impossible) to make it work in principle because a printing press doesn't need to infer meaning from the post script or whatever you provide it. A browser does need to, so you'd need to layer the extra semantics on top of your WYSIWYG editor.
Which means asking questions like "this is 36 pixels high: is it a heading,; or is this just a landing page with big text?" etc. So maybe I lack imagination, but I don't see it being that easy a problem to solve from a UI point of view.
There are plenty of semantics in InDesign documents. InDesign is all about character, paragraph, list and table styles – it’s what you use to make InDesign work. You wouldn’t have to add much to make those styles do all the semantic work.
Yeah, you would still be able to just ignore all that – just like you can adjust each headline individually in InDesign – but that would only mean that you are an incompetent user of the software. A good WYSIWYG editor wouldn’t always have to produce great markup but a competent user of the software should be able to easily make it produce great markup.
I’m really not that sure why adding a GUI for semantics would be so hard, especially since existing concepts like paragraph or list styles already map very well to HTML concepts.
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.
I’m not suggesting to slavishly copy InDesign and I’m not saying it’s easy. InDesign would be absolutely horrible for web design. I’m merely suggesting that WYSIWYG for HTML and CSS is not impossible.
Being able to flexibly test (e.g. different fonts, different resolutions, different browsers) would certainly be one of the requirements, as would be the implicit assumption that pixel perfect designs are not possible.
As for style and content? InDesign does actually separate them to a degree. It’s not perfect but neither is HTML at that task. The concept of character, paragraph, list and table styles is central to InDesign. It’s what makes InDesign so great. It even has a bare bones text input mode where all you do is type completely unstyled text. It’s then easy to apply all the different styles you made to your text.
I think a truly powerful WYSIWYG HTML editor is eminently possible, someone has only dare to do it.
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.
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.
For layman person wanting to create a website with static page it is ok. But I am talking about professional web designers who creates templates for dynamic web page. Why the hell they would prefer generator like this? In the long-term it will turn into maintenance hell.
I have some scripts i use to generate my html. i don't have a framework for generating HTML in as broad a scope as muse because that is a bad idea. Beyond a certain level of complexity, you actually need to stop and think about things.
The right way to do a GUI HTML editor is to provide some templates and some customizations.
Well, at least they're using it. It hurts adoption if people perceive Microsoft to be tepid about WPF or Google with regards to Go. But Adobe is clearly dogfooding.
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?