I seek to start a discussion here based on the following premise:
I suspect there are only 2 types of users for DWR and they need 2 different pieces of software
User Type A: Coders who use code view 99-100% of the time <- (this is me)
we stopped using BBedit right around 2005, (v 8.2 or so) when we found Macromedia's version of Dreamweaver
we manage sites, write code all day, and use DWR as our launchpad, development and site management suite
we don't care about the design view one single bit
we often fire up SSH to change file Perms when the right click "set file perms" options does not work in DWR
User type B: Designers who are not 'afraid of code', but pretty much shy away from it
they likely use the design view and occasionally swap a color HEX value.
they likely think responsive design and CMS system websites can pass web standards by using a GUI like Photoshop + DWR design view.
they likely call Type A often when things need to be done right, and that's OK, nothing wrong with that.
they likely have never typed "cd" into an SSH window.
"Following Adobe's acquisition of the Macromedia product suite, releases of Dreamweaver subsequent to version 8.0 have been more compliant with W3C standards" [snip Adobe Dreamweaver - Wikipedia ]
=> This natural evolution seems to have stopped with the release of CC 2017 where as a clear conflict of direction and purpose has become evident. As a "Type A" user I loved almost everything about Dreamweaver CC 2015... till CC 2017 came out. Adobe fixed bugs and made improvements on each release while:
Keeping all of the past features
Improving on existing features
Adding some new features.
while managing to never ruin the original intent of the software
That dream has now ended.
I don't know whats going on over there at Adobe, but as a user on the front line using DWR every single day it is pretty clear to me that something internal has happened. Maybe the old development team is gone? I don't know, but I do knowsomething really bad has happened with CC 2017 and I suspect a great many others have noticed this as well. I hope to bring attention to that fact by writing this.
2 weeks ago I updated to DWR 2017, and to my horror I realized I was not using a standard upgrade from a version 2.0=>3.0, no indeed, I was using a piece of mostly untested software with a great many well tested and very useful features removed, features that I used on the daily.
A harsh assessment of DWR CC 2017 could be stated as follows:
"It's as if a graphic design team with no coding experience or prior knowledge of the Dreamweaver family or CC 2015 release was turned loose and allowed to brutally gut out and molest everything - from the intuitive language of interface design to the very core features and functionality itself: CC 2017 has been ruined. Imagine using a Phillips-head screwdriver, and one day someone deciding to replace the tip of the Phillips-head with a hex key and expecting you to believe that it's an improved version... your not going to be fooled."
"Dreamweaver from Adobe is the industry-leading web development tool that lets you efficiently design, develop and maintain standards-based websites and applications. Dreamweaver 8 provides a powerful combination of visual layout tools, application development features, and code editing support." [Adobe]
=> I feel that application development features and code editing support have been ignored in CC 2017 and fear that they will continue to lose support unless we communicate to Adobe that CC 2015 was in the right direction and CC 2017 is the wrong direction for Full Stack developers.
There are easily 1000+ ideas and 300+ bugs in the "feature request forum" that should not even exist as feedback.
Mind you, nearly all of these things in that forum ^ worked fine in CC 2015
What do you think?
Has Adobe decided to simply abandon a progressive version based release model for Dreamweaver?
The other apps (premiere, photoshop, illustrator, ect...) work mostly like they used to and have improved but on examining Dreamweaver CC 2017, the answer seems to be yes...
Do you think that the direction of Dreamweaver for full stack development in the CC 2017 release is an improvement, or a step backwards?
As a full stack developer I think that
CC 2017 is a step backwards
CC 2017 lacks important features that existed in 2015
some of the new CC 2017 features do not belong in Dreamweaver and should be in Adobe Muse instead
Features from Dreamweaver 2015 should be re-instated
Dreamweaver should continue to be a developer tool, or split it into 2 versions
Closing thought: trying to build 1 vehicle that fly's, swims and drives usually ends up doing none of those things very well which is why its better to just have a plane, a boat and a car...
zagarskas thank you for your PM. As a consequence, I have unlocked the discussion.
The arguments that you used in the PM are stronger than the ones that forced me to lock the discussion in the first place. They also overrule the aging content argument.
Wappler is the DMXzone-made Dreamweaver replacement and includes the best of their powerful extensions, as well as much more!
Without reading the contents of the PM, I don't know if unlocking this discussion was a good idea or not, and maybe branching to a new discussion would be better, that though is a decission i will leave for others to decide.
Now to the question of 2 conflicting interests.
I think that there are now 3 conflicting interests, why -
You have the user who wishes a visual web site creation tool, in which they simply click on an icon to apply whatever they wish to do, and drag elements around the screen to place them.
Then you have the user who wishes Dw to do the work for them, but still wishes to retain some control, such as those who use bootstrap, and 3rd party extensions, (maybe also wanting SB's back).
Then you have, not the hard core coder, but the user who does everything in code view, but who wishes 'helper' dialogues/features for elements/css such as css animation creation, media-queries or srcset.
Item1, i think can be done, but if it would be simple enough for such a users requirerments is a big question.
Item 2, well that is what we have now, but with many features added in that those users will probably never fully use as intended by both the Dw team, and those who thought of and developed them originally. Such as pre/post-processors or git.
Item 3, This user is completely ignored, even though one could argue that pre/post-processors and git are for such users, they as implemented in Dw are most certainly not, this last user does not like being told that they must use them, and requires more than the Dw dev team is prepared to admit or include.
The first 2 will i hope be catered for by Wappler to a better standard than Dw is prepared to offer, but that would i think be a great loss to Dw as i think those 2 groups are, or at least where, its main users. The last and 3rd group one could argue would be better using a more dedicated coding environment such as Visual Studio Pro, but Dw also requires this last group as part of its user base, as they are often the ones setting the pace in what is required for the future. Leaving this group of users out of Dw runs the risk of a stagnation in ideas, which unfortunatly one can argue has already happened.
/t5/dreamweaver-discussions/are-there-2-conflicting-interests-with-dreamweaver-s-intended-use/m-p/8708655#M10240Oct 23, 2017
Oct 23, 2017
Copy link to clipboard
Copied
I agree there are two types of basic users for DW, I also agree or think that Adobe has taken DW and gutted, cut, reworked and for the most part lost a highly motivated core audience in its progression since DW 8.2 ( I know a long time ago). They bought a market at that time that was less than professional coders, not really true designers but could provide basic application building via PHP (specifically the Kollection extension ( i know old, antiquated and hard to keep updated) but it worked and it allowed many people to provided basic development for the average business owner without deep pockets.
DW is and always has been a intermediate step below hard core coders, thats a given fact. DW will never be for hard coders we all know that. DW is what it is, and in the past it worked great. DW now is basically becoming just a layout program something like Quark for the Web. In going this route they are throwing away the base and that made Dreamweaver useful to 70% of the web page development marketplace in my estimation. sitestorepro.com keeping saying that Adobe is talking with them to add a collections like extension but those talks have been going on for 4 years now. If they have this they should release it to hopefully recapture some of what DW once had as a client base or ricks losing 80% of the clients they have now I think. Just my 2cents
Whilst i can understand users frustrations with the removal of SB's, and the discontinuation of web app building extensions, I can also understand why Adobe discontinued them and are reluctant to offer users a replacement.
Many users would continue to use them if it was possible, with a number of users still complaining that they cannot do so to maintain old sites, (some wanting to even build new sites with them). This would place Adobe, and the creators and owners of the sites in a dangerous situation, as the Dw user i am certain would use those extensions to create shopping carts and collect a sites customer information.
I don't know what the legal situation is where you are, but in the U/K and the rest of the EU countries, there is a not so small matter or the data protection act, and the sale of goods act. These mean that all collected data must be securerly protected, something that anything using the old mysql php connection cannot do, as its major flaw was in its password feature, (it was unsecure).
The sale of goods act, also applies to the creation and sale of web sites, in that they must be fit for purpose. If you were to have created a site in the last few years and used the mysql connection, there is a very strong chance that the site would be considered as being unfit for purpose at the end of next year. This could allow your client to claim the costs, (or at least partial costs plus legal fees) of the site back from the developer, as it is considered that the developer should know what they are doing and be aware of any and all upcomming developments. Including the fact that php 5.6 will no longer recieve even security updates after the end of 2018, and will effectively become a 'do not use' server side tech -
The only argument against Adobe removing the SB's and extensions from Dw, would be that they should have updated them to use pdo, and stored procedures, for which everyone could file a feature request, (i did about 6 years ago, with no answer from anyone).
pziecina with that argument then nobody should ever build a website ever again for a another party for fear of being sued in 5 years time, at some point they all become outdated to a degree but that does NOT mean they that critical security issues are ignored, they should always be patched immediately.
Unless we all decide to work for free for our clients and update without charge ever single aspect as and when a new version or the latest 'recommended' practises are introduced then there will be and is plenty of ‘older’ code out there. You'll have a hard job on your hands convincing clients to spend £100s or £1000s on a refresh a lot of the time, that’s the reality of it, its just not practical or do-able all of the time, regardless of what you think.
I think you'd be more likely to get sued for not living up to your obligations in the accessibility department in the UK. To scaremonger over the mysql extension is wrong too, with the lack of prepared statements yes the onus was on the developer to be vigilant and audit code. I 100% wouldn't advocate building a new site with the mysql extension but lets not go too far and turn it into the devil all of sudden, a large portion of the internet was built on the mysql extension for some time and I’m pretty sure we got by and I’m pretty sure there are plenty of sites still using it that could ideally do with being updated, that doesn’t mean they are wide open security risks.
Why are people so keen to condemn old features that may be needed from time to time, the SB panel is available as an extension anyway, if you don’t need it, don’t install. But better it it’s available for those that need it on an odd occasion. Also some developers built MySQLi extensions that utilise the SB panel.
I don't call it scare mongering, i call it informing, and anyone building a site in the EU should be aware of them.
As for some developers building extensions that utilise the SB panel/code, i was one of them, (all extensions free) and i also produced my own add-on that produced PDO SB's. That extension was downloaded over 10000 times, (for free) before i withdrew it, the creation of that extension though it only included the updated to pdo basic functions from the SB's also included a basic add-on for reading any php stored procedures so that one could see them for php code creation.
That is why i am of the personal opinion that using the old SB's to add new extensions, was and is stupidity.
My reason for saying that is because it was obvious to me when the removal of the built in SB's were announced, that at some point any access to the old code/features should be removed, and replaced by new pdo code/features. This would NOT be impossible using the code from the old SB's as a starting point, difficult and time consuming yes, but much of the code is re-usable and even though it could be updated, that could have been done on an as required basis, as new features were added, (such as the creation of stored procedures directly within Dw).
That all said, with dmxzone introducing Wappler i think this discussion and any wish for Dw to introduce a replacement for the SB's, is purerly academic.
Even though i do not wish Dw to be discontinued, i am having serious doubts about its ability to survive in a market place where so many editors are now free, and Wappler now targeting many from its main user base.
/t5/dreamweaver-discussions/are-there-2-conflicting-interests-with-dreamweaver-s-intended-use/m-p/8708658#M10243Oct 24, 2017
Oct 24, 2017
Copy link to clipboard
Copied
zagarskas, I really do not understand the logic in splitting Dreamweaver into two programs, set up your panels and workspace up to suit how you work but do not look to penalise other users who use a large portion of Dreamweaver features and do not want to be jumping between two different programs.
Dreamweaver was supposed to be a good all-rounder, if anyone else has another big or radical idea god knows where it’ll end up. So splitting into two programs, as simple as it sounds, no thanks!! If you're a coder and not interested the other features of Dreamweaver then go use brackets, sublime, atom etc. If you're not a coder, no need to use code view but I do think Dreamweaver is a good learning tool for beginners and intermediates for transitioning from a WYSIWG environment to coding.
The last big idea was shoe-horning Brackets into Dreamweaver. I’m pretty sure it took the developers quite a few versions to fix bugs and restore lost features as a result of the poorly planned Brackets integration and I’m not sure they are there yet, linting seems to be a pile of dooh dooh!! I was never a big fan of the Brackets thing, IMO one of the worst decisions, the time and effort wasted on (a) integrated brackets (b) fixing problems c) restoring and building back in features lost as a result of it. SURELY time could have been better spent??
I think in recent years, Adobe has had some bad ideas of what Dreamweaver should be, badly conceived, poorly planned and poorly executed. The biggest culprit IMO is the person or persons responsible for the roadmap and big decisions, maybe the developers have zero say in this but that doesn't excuse them being implemented with all the bugs and problems in each new version.
I would urge the Dreamweaver developers to think carefully before considering another big transformation or feature, instead:
the whole point here is that in DWR there are features designers like to use that are useless and annoying for development, and for Full Stack development there are design features that are ruining the usefullness of DWR as a dev tool.
An analogy:
Putting doors on a pedal bike to make it safer. Thats dumb, just make a car and for anyone riding a bike make a helmet, no need to make a "bike with doors"
for example, these 7 things would have made DWR the ULTIMATE full stack development tool in my opinion:
I've got a really GREAT idea ... if you want to code and don't like all the other stuff that Dreamweaver has to offer, why don't you try eeehhmmm BRACKETS!! Yes that's right the very same editor that's was integrated into Dreamweaver, except with standalone Brackets you'll get a heap more features plus the options of a shed load of add ons.
This idea of splitting it into two when users have been using the all round tools In Dreamweaver for years would be a final kick in the teeth for long-time Dreamweaver users.
Because DWR integrates into the Adobe Workflow and Brackets lacks many of the features DWR already has such as site definitions. I manage 250+ sites, that's alot of STE files, no way im FTPing that stuff
Please consider that the point of this discussion is not to "move away from Adobe DWR". It works, 2015 is great, it was on its way to being nearly perfect... but 2017 was awful, its like a "plane boat car", sure, is does all those things, but none of them very well, where as 2015 was like a really fast stock racing car that just needed some turbo added in and a new paint job, instead, they shoved a boat propeller into it and some wings and now it barely races... Dig?
The question here is simply "Are there 2 conflicting interests with Dreamweaver's intended use?" to which I feel the answer is an astounding YES. Adobe has tried to combine oil and water and as such 2017 now is neither oil nor water and has lost much of it's usefulness.
This idea of splitting it into two when users have been using the all round tools In Dreamweaver for years would be a final kick in the teeth for long-time Dreamweaver users.
Adobe unfortunately kicked itself in the teeth when a decision was made not to update one of DWs flagship features, the server behaviours. This was widely regarded by those who used the feature (including myself at the time) as one of the most important features they required. It fell on deaf ears and since, along with other poor decisions DW has been slowly decending into oblivion or at best just another editor.
Fortunately I made the decision to learn some php/mysqli, probably the best thing I ever did.
Splitting Dw into individual user type products will never work, simply because no one knows what types of users Dw has.
Energize wants the old server behaviours back, (which is his main topic) but he does not realize that by supporting extensions that 'hook into' the old SB's he is delaying any chance of Dw ever being able to add a new server behaviour feature, because it is impossible to rewrite the old sb's and guarantee retaining the functionality of any extensions that do so.
zagarskas wants a coders environment, but does not want a php/js debugger or any of the other features that would be required to make it into an ide, but does want a sql query creation feature.
Dw should have added features like pre/post-processors back in 2012, and decided on just one of each type, not what we have now, which includes everything but the kitchen sink, (maybe that is the next feature they include), git has become too complexed for the normal Dw user in a team environment, as no one below team leader or supervisor would ever be allowed to use 70% of the features included, (requires a password protected allow feature). and should also have been included in 2012.
html, css and javascript requires a massive re-think in what and how they are included, as it is obvious to me that currently they are being advised by people who have never worked in web development for a living, except possibly teachers or instructors only interested in teaching the basics, (anything more advanced those people would have to learn and teach).
The one thing they may as well forget, is the user requirering visual features, as that market is lost. Designers will use programs like Muse, and casual coders will probably switch to dmxzone's offering.
I'm uncomfortable with the idea of splitting DW into 2 products. I'm going to use another Adobe product as an example of why I think it's a bad idea.
Brand recognition of Lightroom has always been synonymous with high end digital Photography. Adobe recently split Lightroom or should I say borrowed it's name to create a new product. So now we have 2 Lightroom products apparently aimed at the same users or are they?
Lightroom CC (cloud based app)
Lightroom Classic CC (desktop software)
Serious digital photographers with multiple TBs of raw image files from various cameras are not going to routinely use a cloud based service with fewer features and a 1 TB max storage capacity. On the other hand, casual photographers who like to post images on Facebook will probably think LR CC is just dandy.
What's to become of LR Classic CC? As we all know, classic usually means there's no future for it. So is Lightroom Classic CC destined to become a shell of its former self? Only time will tell how this unfolds. Right now, I am not alone in thinking it's a confused mess.
I shudder to think what would happen to DW under a similar scenario.
Nancy O'Shea— Product User, Community Expert & Moderator
Dw should have added features like pre/post-processors back in 2012, and decided on just one of each type, not what we have now, which includes everything but the kitchen sink, (maybe that is the next feature they include), git has become too complexed for the normal Dw user in a team environment, as no one below team leader or supervisor would ever be allowed to use 70% of the features included, (requires a password protected allow feature). and should also have been included in 2012.
I actually wonder how many of DW users actually use git. If the forum is representative of the majority of its users they can hardly put one foot in front of the other when it comes to anything web-development related so I wonder if including git was really a 'required' feature over and above say something simple like a pre-processor which is very much 'required' if you are using the correct workflow to produce a modern website these days. Or even spend a little bit more time on a bespoke editor environment rather than looking around for something already existing and trying to shoe-horn it into an environment which was probably more advanced, with a few tweaks, than the one they replaced it with.
DWR has always been a mix between WIG and IDE (doing neither one very well). However, what it does do very well is act as a bridge in Adobe dominated workflow* for full stack development across 100's of sites. The more the program leans toward "design" the more annoying and less useful it becomes (at least for what I do).
Therefore: why not take the final steps toward bonefied IDE, (or, just make it into another 'dog and pony show' Design tool for people who think they can phase out the need for coders).
That said, Adobe already has "design tools" for websites, (for example Edge Re-flow) and as such some of the new features stuffed into DWR, in my opinion, could have better been put into Reflow.
I do agree with your 3 points, "UN FUBAR", (fix, tidy up, tweek) and they were doing that, till 2017 came out. The 2018 release is almost back to where 2015 was for usability, it even has a GIT panel. I would like to see DWR head toward IDE.
* Adobe dominated workflow -
By this I mean getting PSD, AI, IND, and Edge ReFlow documents (all made with the most recent 1 day old CC releases)...
Packed with Adobe Stock collections, typekit and Kuler profiles embedded in them from design firms...
and be expected to turn them into functioning websites/apps within illogical deadlines,
while being able to collaborate with the designers
and on top of all that,
be able to update/revise 100's of times...
across 100's of projects.
My STE folder has over 1000 site profiles in it, at least 1/2 are active.
To give a trivial example of the problems 2017- removal of the ability to filter the site list by typing in the keyboard now makes it take 1-2 min to find a site in the list (which used to be a 3 second operation), do that 100 times in 1 day and serious time is being lost - 2 hours VS 1.5 min | over 30 days | is 60 hours of lost time.
That was caused by Adobe leaning toward "design" and forgetting about good UX and development needs. They removed a feature which does not matter to Designer type users who don't care about the FTP panel or the ability to filter through 750 site definitions and caused a huge problem for developer users.
/t5/dreamweaver-discussions/are-there-2-conflicting-interests-with-dreamweaver-s-intended-use/m-p/8708667#M10252Oct 25, 2017
Oct 25, 2017
Copy link to clipboard
Copied
after reading this long long... very long thread... what result in it is that Dw is split into continuous interest source...
Developers / Designer
Marketing feature / User real needs
Native feature / rely on external application (including open source and extensions)
it's complicate to satisfy each groups... and makes Dw responding to something really usable
- coders look for coding environment and designer for easy drag and drop intuitiv tools... which both doesn't follow the same goal, or needs
- marketing just need new killers title on the box and users sometimes just need to polish and debugging existing feature
- including open source often block the real use (version, library type or gem, and so on) and extensions often cost extra money, that's is completly normal, and I agree but added to the CC subscription it makes the tool more expensive
having a real gouvernance team made of designer, architect, accessibility specialist, web integrator, pure coders, plugins developers, UI/UX technicien, SEO referer, marketing CC products, Dw engineer, dummy new bie, client for final products... and so on... and being only involve in a CAB prerelease... and listen by folks @adobe
because, now
whatever the users profile is... the web site or app produce, always need the same requirement... the site must be based on standard, stay responsive whatever the device, get a usability on top of the current user experience, keeping in mind that it must be fast to create, deploy and maintain it...
well... we all look for the perfect tool and IDE for production environement...
well thought there is some requirement...
this environment must be easly usable from non coders, like I am.... because I don't know HTML/CSS, and won't have any time to learn it
concerning, JavaScript ... I've heard the term once, it is the language used by Java isn't it ... ?
how do you say, PHP... euh is it something running on Android ?.... or exclusive dedicate to Macintosh for iPhone ?
DataBase... do I need a data base ?... for what ... my office rely on Mongo ... is it correct ?///... or perhaps it is Mingus ?
Does the version control Subversion works on GIT... because I've got a book on control version and it is about Subversion... and now I red on the box that Dw use GIT
well I could continue.. but I'm sure that most the people will feal as if was assaulting every non coders ... and believe me... I'm hundred miles from it.... and I'm not in this mood... I'm just trying to get the real bottom line if we need to split DW in two section ?....
so I could take an other sample...
I'm happy, I've got my new tool box for my car repairs... and that's fun, because, now I will be able to rebuild evry trouble, what ever they are... and luky am I ... I won't have to learn any mecanical rules... the new build it yourself in 21 days will do the job.... it is wrote on the tool box
First Birnou, i always select the 'like' feature when something makes me smile, (and would select it twice if i could when something makes me laugh). That is not to say that i think what you say is wrong, but this part did made me laugh -
having a real gouvernance team made of designer, architect, accessibility specialist, web integrator, pure coders, plugins developers, UI/UX technicien, SEO referer, marketing CC products, Dw engineer, dummy new bie, client for final products... and so on... and being only involve in a CAB prerelease... and listen by folks @adobe
90% of those advising the Dw team on Dw's future, have no idea what is happening in the web development world, and most of the subjects listed have no place in deciding what or how features should be included.
As for cab and pre-release, get rid of them, or at least make the criteria for joining relevant to web development in practice.
Note: The question to ask about anyone advising the Dw team on requirerments and how something should be implemented is -
"would you employ that person to build and manage a project for a site costing between £10000 and £20000?"
/t5/dreamweaver-discussions/are-there-2-conflicting-interests-with-dreamweaver-s-intended-use/m-p/8708670#M10255Dec 03, 2017
Dec 03, 2017
Copy link to clipboard
Copied
Update: As of today looks like DWR CC 18 is useful as a development tool again (like 2015 was)
Since this original post and the release of 2018 i've done the following:
Yelled at the screen, complained to peers, posted bug reports, posted ideas, made videos, tried to bring attention to the issues here on the Adobe Forums
Uninstalled 2018 and reinstalled once a week, every week, waiting for it to work
conclusion: almost what Dreamweaver 2018 should have been.., almost If Adobe pulls this kind of nonsense with DWR again, UltraEdit is where i'm heading
PHPstorm, RapidPHP, Netbeans
conclusion: they do not integrate with Adobe workflow "seamlessly"
annoying things like having to use the ancient "Windows Tree" to assign files and folders. bleh...
the FTP process is annoying verity of missing features
(mostly psychological, I suspect they may have had features like DWR but I was not intuitively finding them, for example, pressing shft+ctrl+U to upload or ctrl+W to close only the file your on, ect...)
None of which "fit like a glove" when looking for a replacement for DWR 2015
45
Replies
AdChoices