How to visually build a Responsive Layout in Dreamweaver

[ALsp]

With less code, more efficiency, and the best support in the business... for life.

The Harmony Page Building System by PVII:

PVIIHarmony Flexbox for Dreamweaver

If straightforward code is your goal, there is nothing comparable.

100% Bootstrap and jQuery free.

We make Dreamweaver better. And we've been doing it since 1998.

Mention this post and receive a 25% rebate off your purchase.

[rayek.elfin]

At first I thought this was a double post. But now I see: this is a response to the new DMXzone Layout extension:

How to visually build a Responsive Layout

It seems the competition is (1) less expensive, and (2) miles light-years ahead in regards to usability and DW integration. The modal dialog approach in your page layout extension is somewhat old-fashioned looking compared.

Perhaps it is time to rebuild yours to stay competitive?

[ALsp]

Perhaps it is time to rebuild yours to stay competitive?

Absolutely not. We appeal to a much different market. We like our interfaces and how responsive they are, along with the fact that they work back to Dreamweaver CS3. This forum, as well as the Dreamweaver community at large, is nearly dead.  Our customer base rarely ventures here, but we think we fulfill their needs quite well, thanks 🙂

[ALsp]

Let me clarify and expand on this a bit...

Our UIs are designed to be very fast with little-to-no overhead in Dreamweaver. And because our extensions are task oriented, we tend to take an Occam's razor approach. The concept behind Harmony is blessedly simple. Create flexbox elements in a list, assigning each one options and attributes to achieve a certain layout. Then, allow users to recall the UI, add or remove elements, re-option them, or re-order them. This is pretty unique and something Dreamweaver has never really offered.

I can't comment on DMX Zone's approach for the simple fact that I have never used their products. I wish them well, but I would never use a commercial tool that is a front-end for Bootstrap. The reason is simple. I understand Bootstrap and, as a result, would never use it.

It's always been a mandate of ours to write tools from the ground up, all the way to the code. We sometimes learn from other peoples code but we would never use someone else's library. Writing a front-end for Bootstrap would simplify our work, but the resultant product would leave us feeling a little empty and perhaps manipulative.

We go back a long way with Dreamweaver, longer than anyone who currently posts on this forum, and we've established a small but loyal customer base. We have no need replace Dreamweaver, only to enhance its capabilities a little.

[rayek.elfin]

In the end whether the DW user relies on Harmony or Bootstrap / DMXzone's BS layout tool either code end result will be biased. The user probably won't care, as long as the result speaks for itself. Hence why Muse was reasonably popular, even though the code it produces is akin to the seven pits of heck 🙂

I dislike BS myself, and would not use it outside of the quick visual prototyping that I do in Pinegrow, or if a client insists (or if I have to work with an existing BS site).

Having said al this, I always check the html code any given visual tool spits out, and I had a quick look at Harmony's and the DMXzone's layout extension's output.

DMX is straightforward BS code. Hate it or love it, it is kind-of a standard, and quite clean and structured, if convoluted at times. Nothing unexpected there. The demo sites on the DMX site are well coded on the whole.

I also checked your projectseven site, which, as far as I can tell, is built in your in-house Harmony tool. I see custom data- html attributes everywhere, and inline styles riddling the page code. And a number of presentational ill-named classes.

Personally, I would prefer the BS code base, because (sorry) Harmony's code wouldn't cut it for me.

Of course, the client doesn't care how the code structure works, or how clean the html and css is. This discussion probably is moot outside of the scope of a few people here.

This is just my personal opinion. I do understand your approach, and both tools have their respective workflow issues and advantages. I myself am always interested in new visual html coding tools to simplify life.

[ALsp]

I also checked your projectseven site, which, as far as I can tell, is built in your in-house Harmony tool. I see custom data- html attributes everywhere, and inline styles riddling the page code. And a number of presentational ill-named classes.

Data attributes are a large part of how the interface is able to do what other interfaces cannot, that is to recall the structure in its entirety and write it back to the UI with the proper options selected so that the user can edit the layout. There are no inline styles ever written in a Harmony structure. If you are seeing any, it is likely you are not understanding their nature, which is likely from another, scripted widget, which is writing to the DOM, and that would therefore not be the markup users would edit. As for ill-named classes, that is a matter of opinion - and dependent on whether you are speaking of a Harmony-generated class name or something we added. While all of our pages employ Harmony to some extent, most of our pages were created manually, years ago, in such a way that made themselves easy to evolve as web standards did - not an easy feat. So, it's hard to say exactly what you are talking about - it seems you re making some assumptions. Tell you what, here is a layout made from scratch with Harmony. Tell me exactly what class names you do not like and perhaps I can explain why we like them, or perhaps we can put your suggestions to good use in a future update.

PVII Document

Do let me know. We are always eager to learn and improve.

EDIT

I think I know what you are referring to now. You must have looked at the generated code in a browser's developer tools window. The inline styles are added to the DOM at runtime by a script. Essentially, the values in the data attribute, which relate to UI options, are translated into inline styles. Nothing at all wrong with that. But the important thing is that the Dreamweaver user will never see that in Code View, nor will he need to worry about it. And the script is not just for translating options, it is also used to feed ancient browsers a floated layout. The only "odd" class name I can think of, would be hmy-noscript. And that is a very interesting case as it allows us, as well as users to write styles to "tame" Dreamweaver's Design View. The noscript class is removed at runtime so you'll need to dig a little deeper in Developer Tools to see that 🙂

All in all I really kind of prefer our approach and class names to Bootstrap's…by a very, very wide margin.

[rayek.elfin]

I had a quick look at the page. I turned off Javascript, and the layout returns to a flat layout with no columns. It seems all the flex children code layout code is attached using DOM manipulation through javascript and inline styles are inserted everywhere - which is a bit ugly, and seems unnecessary: why not attach classes? Why use inline styles in the first place? Or is this done in order to have specific column control?

Still, why use JS in the first place to control these simple layouts?

Presentational classes include: hmy-left, hmy-right, hmy-border-content-left, ...

Data attributes are a large part of how the interface is able to do what other interfaces cannot, that is to recall the structure in its entirety and write it back to the UI with the proper options selected so that the user can edit the layout.

I understand why you use them this way. That said, other visual tools keep track of the structure through the classes that are attached, and having all those data attributes just seem superfluous. As far as I can tell, the javascript code reads those data attributes, then manipulates the DOM by inserting inline styles for each element based on those same values.

In a way, Harmony creates its own styling system, bypassing regular classes, and thereby forcing the use of javascript to read those data attributes, which could have been classes in the first place. It feels arbitrary and a bit clumsy, in my opinion. Rather than working with existing standards, Harmony outputs code that works against good coding practices, just to keep track of stuff for the sake of arbitrary GUI logic.

Compare this to other tools (Pinegrow, Wappler, DMXZone layout) which work directly with the code through classes to keep track of things. And Harmony's layouts break down the instant Javascript is turned off, while BS, Foundation, 960 grid, Google Materialize, and CSS grid based layouts work regardless of this, and perform better and faster because no JS is involved to manipulate the DOM.

To be entirely honest, (and this is meant in the most constructive way) the approach Harmony takes to layout seems to be very... awkward, to say the very least. Whoever planned and coded it this way gave precedence to having it work in DW and for their extension GUI, rather than worrying too much about the final quality of the layout code. It almost feels like the coder invented an alternative for classes, instead opting for custom data attributes to keep track of layout code parameters. It is just really, really, strange looking code.

It would have worked just as well to just forego those data attributes, and work directly with the inline styles: in that case the layout would have still worked even if Javascript had been turned off. Ugly, but no less ugly than having all those data attributes which now litter the output.

Again, my opinion. I understand the coder behind your extension decided to use data attributes to keep track of things. It is a logical coder's viewpoint.

[williamj31276244]

And all of that made in a modal/popup dialog used to build the whole page layout, instead of making it work in a panel next to live view and interacting directly with it. "Impressive"!

[ALsp]

I understand why you use them this way. That said, other visual tools keep track of the structure through the classes that are attached, and having all those data attributes just seem superfluous. As far as I can tell, the javascript code reads those data attributes, then manipulates the DOM by inserting inline styles for each element based on those same values

.That is almost word for word what I said to you 🙂

Bear in mind that javascript disabled is a minor issue here, all things considered. And for the 2 people I know that browse without script enabled, they get all the content.

Compare this to other tools (Pinegrow, Wappler, DMXZone layout) which work directly with the code through classes to keep track of things. And Harmony's layouts break down the instant Javascript is turned off, while BS, Foundation, 960 grid, Google Materialize, and CSS grid based layouts work regardless of this, and perform better and faster because no JS is involved to manipulate the DOM.

That's really not true, and I hope you know it. And as far as JavaScript goes, the number of people browsing with it today is statistically irrelevant, and I really believe most people know that. And I have problems with poor choices some developers make regarding JavaScript, too … such as using it to deliver content. We would never do that. The tradeoff here is that old browsers get a floated layout, users can make their editing environment prettier and easier to work with in Dreamweaver, and the -1% of the public not running javascript see all the content in a linearized display. We like the odds.

Again, my opinion. I understand the coder behind your extension decided to use data attributes to keep track of things. It is a logical coder's viewpoint.

The coder behind our extension? Interesting 🙂

The bottom line is that I've been coding for over 20 years, and I'm sure you're not trying to diss our product for the sake of dissing (that's a troll's thing, right William?). But I guess my opinion is that our code is prettier, and infinitely better than Bootstrap's in many different ways.

I just cannot see your points.... especially where it concerns generated markup. I guess you don't use  any jQuery plugins?

[ALsp]

An important point worth making here is that we have a fairly large customer base and many of them use Dreamweaver CS6 or earlier. All of our extensions are written to support CS3 through CC2019, and some are even written to support Dreamweaver MX 2004. While the regulars here (all 5 of them) probably think we're nuts, that's our customer base, and satisfying them is very important to us. If we wrote extensions that required CC2018, our UI design approach would likely be a little different, though not much.

So thanks for a mostly pleasant discussion 🙂

[rayek.elfin]

.That is almost word

.That is almost word for word what I said to you 🙂

I hadn't seen that response while writing my response (I was called away for a bit there). 🙂

Compare this to other tools (Pinegrow, Wappler, DMXZone layout) which work directly with the code through classes to keep track of things. And Harmony's layouts break down the instant Javascript is turned off, while BS, Foundation, 960 grid, Google Materialize, and CSS grid based layouts work regardless of this, and perform better and faster because no JS is involved to manipulate the DOM.

That's really not true, and I hope you know it. And as far as JavaScript goes, the number of people browsing with it today is statistically irrelevant, and I really believe most people know that. And I have problems with poor choices some developers make regarding JavaScript, too … such as using it to deliver content. We would never do that. The tradeoff here is that old browsers get a floated layout, users can make their editing environment prettier and easier to work with in Dreamweaver, and the -1% of the public not running javascript see all the content in a linearized display. We like the odds.

What I meant is that the base responsive grid layouts in those other frameworks/grid systems keep working with or without JS enabled. Obviously Javascript is as much part of web page delivery as is html and css.

The coder behind our extension? Interesting 🙂

The bottom line is that I've been coding for over 20 years, and I'm sure you're not trying to diss our product for the sake of dissing (that's a troll's thing, right William?). But I guess my opinion is that our code is prettier, and infinitely better than Bootstrap's in many different ways.

I have no idea whether you yourself or someone in your company/team develops the plugins.

You asked me for more feedback on Harmony's code output, and I gave you my personal opinion as a front-end developer. We can agree to disagree, of course.

Not dissing your product. Merely comparing the output of your layout extension with other visual tools.

Anyway, I agree that users and your clients won't care one bit about all this code nitpicking. You and I can bicker over the markup and semantics of html code, and I feel that's a healthy and interesting discussion.

I just cannot see your points.... especially where it concerns generated markup. I guess you don't use  any jQuery plugins?

JQuery? Yes, I seem to recall JQuery. Last I heard, it passed away some time ago, I believe?

[osgood_]

rayek.elfin  wrote

JQuery? Yes, I seem to recall JQuery. Last I heard, it passed away some time ago, I believe?

Add php to the list, so I'm informed by the current bunch of wannabes

[ALsp]

It's been in our company morgue for quite some time, alongside Bootstrap (which is due to be moved out to Boot Hill soon), but I'm just saying... there are many ways to skin a fish (I like cats). I can't argue with your comments about our class name and data methods, I can only disagree, as you are certainly entitled to an opinion. I can, however, at least raise the point that progressive enhancement, which not too long ago was nearly a religious movement, is now an afterthought. With acquaintances involved with the W3C still teasing me about browsers possibly getting an intravenous dose of something very similar to jQuery within the next several years, which would then be made available to the CSS working groups, well... hell's bells. The game could take a very surprising turn.

[osgood_]

Turn javascript off when using Wappler and the  result is not likely to be pretty if you take advantage of its main selling point, their own js framework. The same for Vue and React, Angular. Bootstrap is disfunctional without js, virtually nothing works these days without js. More and more websites html structures are being delivered solely by javascript, like it or not its whats happening now. Good or bad, you choose - its a runaway train wreck at the moment, a free for all being driven by developers who dont know what they are doing or why they are using what they are - apart from its current.

[Nancy OShea]

What people really want is the holy grail:  a tool that  prototypes with the speed and ease of XD while generating human consumable code that can be ported into any editor for further development.   IMO, Adobe & 3rd parties have failed to deliver the whole package. 

For those who don't know about XD, It's a design, prototyping & sharing tool.  However, the XD prototypes must be handed off to experienced developers who can actually write the code.   It's a little like being invited to a dinner party where the host serves an appetizer but no main course so you go home wanting more.

[ALsp]

Holy grail is good, Nancy. I'll take a sip  whenever I see it 🙂

In my opinion, though, the bottom line is this forum is dead and Adobe has no idea who is actually using Dreamweaver. So I guess it's all academic 🙂