Third String Editor - What Bothers me about Dreamweaver
Dislaimer: Mark absolutely loves Macromedia. If Macromdedia were a woman Mark would have pictures of Macromedia on his closet door (although his wife would think it strange). Mark would be flipping burgers without Macromedia. Mark doesn't want anyone at Macromedia to read this blog and think he's a petulant child stamping his foot or holding his breath. Mark just wants to indicate some of the things about Dreamweaver that make it his third choice as an editor. Now that that is out of the way, Mark will stop speaking in the third person...
Most web developers have an opinion about Dreamweaver. Let me say at the outset that I believe DW to be the best tool to date for designing web sites. DW allows you to have a unified approach to navigation, layout, styles, images and synchronization. With DW you can treat a collection of "pages" as if it were single thing - a web site. That's handy during the design phase. I have often used DW to work with layouts and create templates from a mockup. It makes things like adjusting widths and investigating advanced CSS attributes friendly and accessible.
Having said that, I'd have to say that DW is a very poor tool for working with code. For the following reasons...
Web Sites Vs. Web Applications
The building paradigm in DW is the "web site". By this Dreamweaver means a collection of related pages or content linked together. It is possible to work with just "files" in DW, but DW has all sorts of ways of encouraging you to add a site. In fact, DW works best if you define a local cache and a live site. It expects that you will work locally with pages and files, and when you are ready, you will upload all your changed files to the live server. This methodology works well for pools of "pages", but it is completely useless for "web applications."
In our world we build applications. An application is a collection of "files" - sort of - but that's not really how we think of an application. To us an application consists of "display" stuff (layout, css, and output), event stuff (interacting with user behavior, handling variables and deciding what to do next) and data stuff (updating database tables, checking permissions, running routines, validation and the like).
For example, we don't really think of the add user page when building a security interface. We think of the user application. One of the events of the user application is called add user. The add user event consist of a form for user input, validation and error trapping, inserting a user into the database (a "sub-event" that follows validation) and event feedback. All of that might exist on a "page" but it is far more likely to be a combination of includes and CFC calls. In addition, the same user application probably supports the edit user event and the delete user event. They all use some of the same files (perhaps the form and the event handler), but they use different files as well.
To really take advantage of Dreamweaver would require us to rethink our approach. I will be the first to admit that this may not be a bad idea in some cases. It is also true that we can make Dreamweaver work like we want it to work, with some effort at configuration. But Dreamweaver will never really allow us to work with an "application" using an "event-object" approach. At some point, when design and layout are largely complete, we are going to end up using Dreamweaver like a file editor rather than an IDE. And that brings us to my second problem with DW.
Dreamweaver Is Not "File Friendly"
File management in Dreamweaver is a real challenge for a couple of reasons. The first reason is the single drill down view. A "site" (or a drive location) is open in the upper drop down window. To find a file to work with you have to "drill down" into the file system. Files and folders are intermingled in the same view. Naturally the file tree on some sites can be many levels deep. Dreamweaver doesn't report the path back to you - even on an open file. It's not even in the properties list. So I find myself scrolling back up to the top of the file list to get the location of the file I'm looking at. And in case you are wondering it is quite common for me to have multiple files from multiple sites open. I'm not sure that's even that's even possible in Dreamweaver. What is needed is a folder view and a file list (a la homesite) to make it easier to browse files in folders and still keep track of the folder you are in.
Along those same lines, when you do a search in Dreamweaver, the search pane doesn't report the path either. So you can have 4 or 5 files named the same thing but from different locations listed in the results pane. That's not terribly useful to say the least.
Dreamweaver is Way Too Mousy
As anyone who has achieved a high level of competency at touch typing (60 words a minute or higher) can tell you, a mouse slows you down. It's important to be able to maintain a constant contact with the keyboard. It may seem hard to believe, but if you know the effect that you want, it is faster to type in hand-coded html than it is to work with mouse driven styles and properties. Of course the mouse is useful for the creative process. It's great for experimentation and trying new approaches to design. It's just not so good for coding. You have to "move a bunch of stuff" out of the way to get the code window. There's no split code view. There are many things in Dreamweaver that you simply can't access without a mouse. It constantly drives you to "panes" which are maybe docked and maybe undocked, but in almost every case they have to be resized to make any use of them.
Take the hideous help panel for example. It's tiny with tiny fonts. When you choose a topic a scroll bar often appears, but when you use the mouse wheel it actually switches topics instead of scrolling the text (genius!). The help system really suffers with DWMX. There's nothing wrong with the actual help - just with the container. These folks need to take a look SQL books online for the best example of help I've seen. A close second is Homesite's fully editable and configurable help section. I can easily add new help or edit existing help with my own examples. I'm sure there's a way to do this in Dreamweaver as well, but I might have to set up a new "site" to do it.
Dreamweaver is Bloated as an Editor
It takes 90 megs of RAM to open Dreamweaver - and that number goes up as you open sites and files. Dreamweaver does things "behind the scenes" to cache pages. At least we assume that is what it might be doing (in keeping with it's idea of a "site") - it may be playing online poker with a table in Malaysia. It takes too long to load. It is feature rich to the point of suicide and it's difficult to get rid of them. An "editor" needs to be lightweight and responsive. I want features that are "filecentric" not "websitecentric".
Let's be up front. As a Coldfusion programmer, only about 20 to 30 percent of my "code" is html or visual - sometimes less. Nobody hires me or my company because we are artsy and design oriented. They come to us to write code that does heavy lifting. We use contractors for most of our true design work. What I need is an editor for files with good help features like context sensitivity, tip windows and sample snippets. I don't need wizards and widgets for the most part.
As an authoring tool Dreamweaver is a program that allows designers to extend themselves. It allows them to see and manipulate their creation in an intuitive fashion. But as an editor Dreamweaver is clunky, slow, frustrating and burdensome. It dictates to me - and it won't get out of the way and allow me to do what I want to do. It requires me to change my approach to fit it's assumptions about how I should be programming. It's like a 14 year old drama queen pouting and shouting, "over here! look at me! hey! you aren't using me right!"
When I get my copy of Studio 8 I will be anxious to give Dreamweaver another shot. CF Ecplipse and Homesite (My 2 current choices for editors) have their own set of pitfalls and I'll be anxious to see if DW 8 has come closer to what I need. I'm not holding my breath, but I have a commitment to try it for a couple of days and see if I can shoe horn it into my development life. I'll keep you updated.
19 Comments
-
There is one thing that I utilize Dreamweaver for the most and it's something I have yet to find elsewhere. (I wish I could...)
That feature is the ability for Dreamweaver (with a proper Site setup) to take this file:
/html/cfc/design/layout_template01.cfm
and actually upload it to where it goes.
It doesn't matter how many levels nested it is, it will make it to where it needs to go on the remote FTP server or network drive. If I could find another good program that let's me do this, without picking the remote folder first, I would hardly even use Dreamweaver.
Will Belden
http://commonmanrants.blogspot.com -
Mark, I'd like to link your essay to my partners -- they like to read stuff about how different people improvements in tooling. Would I be accurate in summarizing your points as follows?
"Wants something lightweight, keyboard driven, oriented towards web applications (whether classic webapp or two-way RIA) rather than websites."
Would I have the gist with this summary? or is there a better sentence I could use to orient people to the essay....?
tx, jd/mm -
John, I think your summary is accurate and you are welcome to share the link with whomever you like. Thanks! -
It may seem silly, but the issue with not reporting the full path was the thing that drove me away from DW. I work with a CMS. The CMS is in use in N sites. I'll do a search and get a result, but I can't tell where the file came from. That seemed so silly I didn't believe it at first. I thought I was missing some caption somewhere. -
I'll duck as I say this:
I'm not the "coder" that some are and only spend 20% of my time in code view. And I love Dreamweaver for what it is now and if it wasn't such a great WYSIWYG tool I'd go use GoLive CS2.
And I have 2 Gigs of RAM and a 3.2 Ghz P4 w/HT on XP Pro so DW really doesn't feel all that slow compared to 3D and compositing apps. -
Another thing: DW has never allowed the option to display the full path in the title bar - so if you have three index.(aspx|cfm|htm|php|etc) open, you can't tell which is which.
I got fed up with that and created an extension that adds a bar with the full path in it. Not suite as good as having it in the title bar, and on rollover of the document tab, but it was a start. I'll see if I can release that over. Doesn't help with the search, but still useful... -
The one point I have to agree with you on is the hideous help panel. I always map shift+F1 and ctrl+F1 to the cf help .chm files.
On the other hand, I don't seem to have the problems that you do with the program. I especially disagree with the part about working locally being completely useless for "web applications". What my team had trouble with initially was the idea that we no longer had a development server. All developer workstations become development server coordinated with source control. The previous development servers become QA servers and/or staging servers. We've found that this works better in many ways, including that fact that now every developer on your team knows how to set up and manitain a web environment instead of relying on one or two key architecture individuals.
You can get split code view by hitting f10 and docking the window horizontally. You can also open multiple documents and tile them, but that's only good for two or maybe 3 open files at a time.
The comment you make about the 14 year old drama queen is exactly how I feel about cf coding frameworks. There is every possibility that we could both be wrong. -
It is silly - to the point of insanity. But DW tries to "do it all for you".
-
Jason - I'd love to see that. It would aleviate one gigantic hole in DW.
-
Mike - your comment about the split code view and the idea of each developer being an independent development server really leads into my point about DW "dictating" how we are supposed to work. We already have a methodology that works and includes a dev, staging and production server deployement plan. Why should we shift our paradigm for an IDE? The IDE would have to be markedly better in other ways than what we have - and I'm not seeing that yet.
As for the split code view - your plan works but it doesn't really give me what I want - a split pain with part of the document in the top and part in the bottom.... or does it? I'll have to look. If it does, thanks! -
If you are using win xp pro put /prefetch:1 after your shortcut to launch dreamweaver. It adds it to your prefetch folder under your windows root and should help it load faster. I don't really mind DW's launch time. Once it loads I usually keep it open so no biggie.
You can also turn off DW's Edit>Preferences>Invisible Elements
Server-Side includes "Show contents of included file"
Which should improve performance (tip i recently learned)
I'd like to see something like intelliJ has - smart snippets. Basically there are variables in your code snippets and they use keywords (you define) to activate them. Very useful for blocks of code you write often.
I also dont consider DW an editor, its an IDE and all IDE's are pretty bloated if you look at memory management and startup time. They are trying to do a lot and offer a complete solution for writing code and in DW's respect it is doing much more than just writing code.
I do agree about the tabs and sites thing but as Ben and gang wrote in CFWACK you should have that little comment snippet at the top of your files that tells you what the page is actually doing. But, the tabs are annoying (they just need to add a place to put the path).
If you are writing components that are not site specific (ie reside in a com>sitename) folder and your app is in mysite/myapp it is very irritating to have to switch between sites. I'd consider mapping the root webapp but reading that each time DW loads would be a pain.
I feel your pain with mouse clicks. I love the keyboard and hate clicking around (I think my thumb is getting carpal tunnel).
Another thing I would add is the ability to edit the tag insight priority and default code the tag insight generates. I searched around on how to change them but no luck.
for example it is very annoying to type <cfdump and hit enter and then go back and add in your pound signs.
my few cents... -
Steven - thanks for your comments. They really add to my knowledge, and to the depth of this post.
-
Mark,
While I have my list of complaint against DW (some shared with you) and it did take me a few attempts to switch over I will dispute the following:
Mousey: I disagree, I have mapped all the same keyboard shortcuts as I used in Studio/HS+ and I find I only use the mouse to select new files.
Not File Friendly: Well DW does tend to lean on the Sites, like when you open an individual file (via File - Open) it will open the Site explorer automatically. Unforunately, when you have multiple sites' files open it stays on the last site opened when you switch between the files. It really should move with you. Still, it opens files like any text editor just fine.
Help Content: The best solution I have found for that nastly little help window is to first make sure that the Code Inspector Panel is at the bottom of your coding window. That gives you a nice split screen mode. Then in the Code panel, right click on the Reference Tag and select Group Reference with Code Inspector. Now your Reference Panel will open on the bottom half of the screen. Its much easier to ready and navigate. I also hate that it changes tags with the mouse wheel.
Bloated as an Editor: I agree that is is a memory eater and mine hangs up from time to time, but the artsy features of DW never get in my way any more. I stay in code mode and it leaved me alone. Every once and a while I will even use the table editor to speed up some nested tables. One suggested I have found on improving the speed is to completely close the Application panel. It seems to always be up to something and is not always needed.
Just my humble opinion, but I look forward to DW8 to help make things better as well.
Steve H. -
Steve - thanks for the tips and the contribution to this discussion. Good stuff. As for mousy, I know that I can map and extend lots of things in DW, but It doesn't make it easy, and it's really an "extension" of DW - not the way it was designed. I can make a spreadsheet into a database as well, but that's not really how a spreadsheet is desiged either. My point was that DW is "designed" for mousy users - which is amazing considering that it was probably designed by mac users and they have world's poorest mouse (ha!).
-
Apple has the worse mouse? Not any more...
http://www.apple.com/mightymouse/ -
I really don't agree that Dreamweaver should be a coder's focused tool...and obviously it was not meant to fit that role. We argue that Dreamweaver is bloated, slow and tries to do it all yet you are asking that we add more features?...but make it leaner too right?
That's like going out to buy a Hummer and complaining that the tires are too big and that it guzzles too much gas. You would prefer that it looks and drives more like a Ferrari? Then get off the Hummer lot!
Dreamweaver is a designer's tool. For experienced designers, the lines between designer and coder have been blurring. We have learned to take on more of a coder's role and Dreamweaver has expanded accordingly in that role over time. -
Dreamweaver is touted by Macromedia as "the" development tool for Coldfusion. MM has attempted to make it into the tool for both designers AND developers - at least ones that use scripting languages. I'm surely not arguing that it should be the tool of choice. In fact that is why I call it third string.
You see - I'm not taking a stance against my own preference for DW - or asking for more features. I'm merely stating some of the reasons why it takes third place in my own efforts - in spite of the party line that it's the editor of choice for CF programmers.
Sites to Watch
Aggregators
RSS
