Microsoft Expression vs. Dreamweaver 222
An anonymous reader writes "Informit has a quick look at Microsoft's Expression suite consisting of Graphic Designer, Interactive Designer, and Web Designer in comparison to Dreamweaver. It seems that Microsoft got tired of relying on FrontPage and is actually going after professionals. From the article: 'What designers might not realize is that Microsoft finally drank the Kool-Aid. The Expression Web Designer application walks the Web standards walk. One caution: Web Designer currently only supports ASP.NET. Microsoft built the ASP.NET platform; it isn't a surprise that Expression Web Designer was designed to support that platform. This is obviously a drawback for those designers who work with PHP, JSP, and other non-ASP.NET platforms, making it difficult for Microsoft to expand its reach beyond the ASP.NET users.'"
ASP.NET ? (Score:1, Interesting)
What does the successor of Frontpage have to do with ASP.NET? I don't see a single thing in the screenshots that point to the connection.
Other browsers? (Score:5, Interesting)
Standards accepted, standard development tools, no (Score:3, Interesting)
The same attitude that leads MS to believe they can ignore standards (essentially, writing their own) is what leads them to believe they can ignore other "standard" practices, like using a variety of tools, platforms, and development schemes.
In other news, Microsoft has decided to start releasing to the world "air," which will be an alternative to whatever it is you are presently inhaling. MSAir will not contain any oxygen, so it may not be of much use to some users.
Designers won't touch Expression (Score:2, Interesting)
Re:neither works (Score:2, Interesting)
Sure some prorgams compare, but at this stage Dreamweaver, IMO, is top shelf. Here's hoping
Check out MICROSOFT's wrongdoing (Score:1, Interesting)
Re:Huh? (Score:5, Interesting)
Web standards pretty much determine the markup output server-side and how that markup is rendered in the browser. ASP.NET 2.0 is a server-side technology that outputs XHTML compliant code that will work in any browser - no ASP.NET stuff ever gets near the browser.
In that respect, ASP.NET is as web standards compliant as any other server-side technology - PHP, JSP, anything - it's virtually irrelevant to what gets output and arrives at the browser.
However, you're right in that Expression looks and feels half-baked. Visual Studio.NET is just fine for putting together 'professional' ASP.NET stuff, so why you'd want to release a product that overlaps is beyond me, especially when pages adhering to web standards can be put together in notepad if you know what you're doing (which from experience a lot of web designers don't).
Re:Long Time Dreamweaver User - Impressed (Score:3, Interesting)
Yeah, because obviously the syntax hilighting will be fantastic with an MS app that only understands VB/C#... Makes me wonder what sort of bastardised CSS this thing generates to support MS' horrendous line of web browsers. I'm guessing it'll actually generate IE specific CSS, and render badly on anything else, as per MS standard operating practice.
Unless you have "Owned by Microsoft" stamped on your ass, I don't see why anyone would choose this garbage over Dreamweaver (disclaimer: I use DW in code view only, so can't vouch for its design abilities).
Re:Too little, too late (Score:3, Interesting)
Re:Difficult? For what? (Score:5, Interesting)
Businesses have this "comfort" mindset that if it is MS software, it will integrate ok. They won't be 5 years down the road saying, "I wish we had done it the other way."
The company I worked for does just under $100M USD per year, so they are not especially small, but also not especially large. MS's main selling point is that a business like that can use MS products because they integrate everything together. There were fears about going onto other platforms because you might (oh my god!) have to hire an employee who knows how to run an enterprise-class software operation. This costs lots of $$ and people who can do that are few and far between.
ASP.NET was brought alone to keep developers in these mid-sized corporations from going to technoligies like JSP, servlets, etc. The problem is no one at the company wants to hire anyone who knows how to do either the open source or windows. It's a catch-22: Can't get the nice customer-integrated website because we don't know Java or C#, but we are taking an awful risk if we hire several people at 70K-120K per year to get this thing for us.
Thus Microsoft has a vast untapped user base that they are trying to persuade to businesses hire those software engineers who can write the killer apps for the company. ASP.NET was the MS answer to JSP, but what MS didn't realize when they spend hundreds of millions of dollars developing .NET that companies like the one I worked for are too small to hire a dedicated Java or C# programmer for web programming. I don't think they're trying to kill JSP- they will never succeed in doing that. Java has many advantages over C# and large corporations that run in heterogenious environments are going to choose Java.
So, with untapped user base = untapped money for MS. They saw a "hole" in their solution for businesses when JSP came out, and they are trying to plug it right now.
ASP.NET? (Score:2, Interesting)
I don't know how many saw the site [medicare.gov] last year (helping a relative enroll in Medicare D, maybe), but it damn near impossible! I can't even imagine someone who is not internet-literate following all everything, the way that it was originally designed (and subsequently changed). But, maybe that was the whole idea.
Re:neither works (Score:5, Interesting)
What I have come to understand is that Dreamweaver is a great app for web development.
What I finally understood, and they confirmed, is that the wysiwyg part of Dreamweaver is not what makes it so great.
They love it for the integration it provides, and powerful management of project (searches, publishing, that kind of stuff).
They don't use the visual editing, because it doesn't produce profesional output, and editing right into the code view is much more reliable.
If that is your case too, plus, you are proficient with common console tools, like grep/diff, and using shell scripts to perform batch jobs like changing jpegs resolutions, you can replace Dreamweaver with Quanta Plus, or the lighter Bluefish. All the help you need for editing html and css. And remember to install ies4linux , so you can see the result on IE, too.
If that is not your case, keep DreamWeaver and try to be happy. But stay away from NVU, that's only useful for mockups or very quick and small stuff.
Re:What I would like to know is... (Score:3, Interesting)
DW creates perfectly clean code, as long as you learn how to use it correctly. It's a professional tool, not a point-and-click application (or rather, it will create functional code if you treat it as a point-and-click, but you'll be producing messier code than you should).
In my near decade of using DW (and homesite and BBedit and notepad and emacs and vi and pico and nano and nvu and Notetab and frontpage and Zend Studio and Coldfusion studio, etc), I've rarely seen the program generate inherently bad/messy code, but I've seen plenty of users who don't know how to operate it correctly blame the program for their bad/messy code. I'd say 90% of bad DW HTML comes from users working in design view and not using the tag selector at the bottom of the document window. The program can fix a lot of overlapping/nesting tag issues automatically, but people making bad manual selections before applying attributes and then complaining that the code has too many tags is pretty asinine. Dreamweaver is not psychic, it can't know what selection you *meant* if you don't make it properly, and it gives you several tools to make them properly.
You can, of course just use it in code view as an HTML text editor with code completion, an extensive built-in code reference and library, and reusable objects. The it's totally up to you how cluttered and logical the code is. You can also customize the HTML/XML/JS that operates the whole program so that it uses your particular coding style, your particular line break methods, and your particular syntax choices, etc. There's nothing code-related in the program that can't be changed to your particular style. You may as well complain that emacs doesn't come out of the box with your particular coding style set by default.
Re:I want to believe (Score:2, Interesting)
Re:Front Page (Score:2, Interesting)
So I use FrontPage for commercial webs in that situation. Never knew until now that it isn't perfect which surprises me for a MicroSoft product but we get along. I've used every edition since the first. The newest 2003 iteration is harder to use than that first try and I see no real improvements!
What it can do is stay in the client's computer and his staff can -- almost always -- handle simple updates or add data such as the current assets for the credit union client. Staff changes are fairly common this close to the farms.
My point is that we need some simple source of code for this type of use. If every WhiskeyWig program dips into advanced graphics our client's viewers will get knocked off. I've never had a complaint that our sites are "old timey" or boring because they don't spin or flash or seek un-natural attention with pop-ups.
Less is more in simpler areas of our world -- and doesn't crash as much!
Re:Long Time Dreamweaver User - Impressed (Score:2, Interesting)
Parent is talking about using Expression suite for HTML/CSS editing. As with frontPage, it isn't intended to write dynamic pages. Unlike FrontPage, you CAN write dynamic pages with it, but the primary purpose is for creating and editing static pages. This doesn't involve any C#, VB.NET, or any other functional language except JavaScript. If you want to add tags for other active server languages, you can probably do that just fine, then use Eclipse or Vim or your favorite other editor to write your server code (complete with syntax highlighting).
Speaking of highlighting, there is far more that that to Expression. You can select a DOCTYPE, and it will offer the tags, properties, etc. that are supported. If you enter deprecated tags/parameters, or use elements outside the current doctype, it warns you. Basically, it can validate your web page as you write it. It also has autocompletion, etc. It will help build stylesheets, or inline style parameters, and they are even (oh shock and horror) W3C compliant. (I tested them, both using Opera and Firefox, and by submitting for W3C Validation online using Markup Validation [w3.org] and CSS Validation [w3.org]). I don't know if it has any CSS3 support, and I highly doubt it covers all of CSS2, but it isn't *only* IE6 compliant... although it does some IE6 workarounds for you, which makes web programming more convenient, at least.
Re:Okay but what if (Score:3, Interesting)
1) Every project has a certain maximum amount of time ($X hours) it can reasonably take to complete. These $X hours can be divided up into design, user testing, and browser fixes, among other things. Every hour spent fixing cross-browser problems is an hour less I can spend on design and user testing, meaning that the standards issues are sucking up time that could be spent on MUCH more visitor-valuable things.
2) The cross browser issues end up forcing us to not take advantage of many useful aspects of the standards, leading to a "lowest common denominator" design philosophy. There are a number of very cool things we could be doing for visitors if only IE (and, very rarely, Firefox) implemented it.
3) Because clients WANT cool pages, we're often forced to implement those features anyway. However, because of the aforementioned lack of standards compliance, we have to use clumsy hacks or workarounds to get the general effect. These solutions are often inferior to the results we would have achieved if we could have gone the "simple" route, and usually cost the visitor, in terms of bandwidth, performance, and interface consistency.
There are other things I could bring up, but I believe I've made my point. The bottom line is that we *do* whine about standards compliance and how annoying it can make our jobs, but it's not always just about us. Lack of standards support costs visitors too. If the standards were followed, the web would be a very different, and much more exciting place.**
* Actually, we design for our clients. Their (often non-negotiable) wishes conflict with the best interests of the visitors with surprising frequency. Attempts to educate clients in this area are often not successful.
** I know not everyone likes flashy, animated, AJAX-ey websites, but native client side support could make a lot of the problems currently irritating web trends far less annoying. My favorite example in this regard is text-shadow. Widely derided by many as a useless and frivolous thing to be in a standard, if you stop and think about how many graphics exist SOLELY for the purpose of giving some otherwise plain text a subtle shadow, we could be saving terabytes of bandwidth per month. Not to mention giving now-static shadows all the benefits and flexibility of a CSS property. Even if you hate drop shadows - having them defined via CSS would theoretically give you the ability to actually turn them off, provided you can figure out how to make your local stylesheet override that particular property on a global level.
Re:do what you like (Score:2, Interesting)
I was used to C# and C++ using
Now We've thrown out
We decided to keep all the codebase ansi c/c++ strict with all the wrappers done in perl for cpan library support and productivity.
Earlier we could just dream about having a mac-version, but now we ported it in 2days due to Trolltechs wonderful QT classes.
I also found that moving from Microsofts compilers to intels compilers gave us a 10% speed boost.
Re:hmmm (Score:2, Interesting)
Development tools - uh, I think the parent is talking about scaling to handle volume of users. Not scaling the size of the development team. In any case, if you're taking on more dev staff, $hundreds on another seat of Visual Studio is the least of your expenses.
Your valid point is that for another IIS box you have to pay for another Windows Server license. In a Windows environment, they expect that anyway as part of the expense of a new box.