91–100 of 151 posts
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... .
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.”
I'm going to mention something else: fluidity.
It is very easy to patch together a good looking design in Photoshop. But the Photoshoped-content does not move. The window cannot get resized. The divs are not flowing, they are not resized or shrunken as the user moves the window handles.
Also, while CSS has many flaws, it does provide separation of presentation from content.
Many authors prefer writing entire books in Latex. Do you know why? It's because of the What-I-See-Is-What-I-Mean style of writing, which is far better as from a single Latex source you can generate HTML, PDF files and optimized ePubs, for whatever medium you desire and have it look exactly as you intended it to look.
HTML is also about developing input-interfaces.
I did work with Delphi, also with the editor in Netbeans called Matisse, which does a kick-job at defining Swing interfaces. Also worked with Visual Studio and with Adobe Flex Builder -- nothing comes close to the ease with which I work with HTML.
Heck, I'm working on a desktop client right now that just embeds a webkit view with native-hooks, simply because I don't feel like learning yet another sucky GUI-toolkit that will disappoint me in one way or another.
Also, I started my webdev carrier by using Adobe Dreamweaver. It was one of the dumbest things I ever did.
Earlier quoted context omitted.
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 gz…
This . And, not to mention no business owner want to get locked into a solution, they want their "data" transferable and standardized to at least some extend. The code this produces is so horrible you've lost all the time spent with it. Muse dies out, and your time spent in it dies with it.
And, not to mention no business owner want to get locked
into a solution, they want their "data" transferable and
standardized to at least some extend.
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...
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...
The only thing I see is that the jquery is served from a CDN address that has catalyst in the name. Where else do you see something pointing at Business Catalyst?
And if you view a screenshot of the html of the top of the page and compare that with the BC website:
http://cl.ly/2g2w0I3w0L1m1R1j1Z1O vs http://cl.ly/0m3Y0s0J3r0d3H3h4626
When you think of it, it is very possible that the website's theme/html/CSS was built using muse at one point, but then it might have been transformed into a BC theme/template
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…
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?
Earlier quoted context omitted.
The only thing I see is that the jquery is served from a CDN address that has catalyst in the name. Where else do you see something pointing at Business Catalyst?
Also at the top there's this comment: also see: http://twitter.com/#!/bc_obnw And if you view a screenshot of the html of the top of the page and compare that with the BC website: http://cl.ly/2g2w0I3w0L1m1R1j1Z1O vs http://cl.ly/0m3Y0s0J3r0d3H3h4626 When you think of it, it is very possible that the website's theme/html/CSS was built using muse at one point, but then it might have been transformed into a BC theme/te…
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?
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.
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.
Earlier quoted context omitted.
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?
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…
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.
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…