These are all very good points, and you make them well. I don’t disagree with any particular point if the output of your process is a static Web site. But the work that I do is primarily in Ruby on Rails, where each “page” is a complex assemblage of tiny HTML + ERB “partials”, Ruby business logic, and data from Postgres, Oracle, or MySQL. When I make a picture element, I’m probably writing something like this:
<%= image_tag @product.image.file.url %>
and a visual editor is not going to help much with that.
I got my start in designing for content management systems long before there was such a thing, when my technical partner was writing the dynamic bits long-hand in VBScript. We discovered the hard way that Freeway would happily overwrite all of the code he had inserted by hand in the pages, considering those changes to be ‘damage’ to its original static HTML output. I soon started to learn more about how Freeway was generating the pages, and how to get my dynamic code into the output directly through Markup Items and Actions. This was a very long time ago.
When it came time to learn programming for myself, I chose PHP, and stayed within Freeway for the layout. Using Actions and a lot of patience, I wrangled together a workflow that carried me forward for a number of years. I would hand-write any business logic in include files, and generate the visual design partials in Freeway, and because of the Actions I was using, Freeway would assemble the entire package and upload everything to the server. This worked pretty well, but as I started learning more about programming and the technical sides of HTML + CSS, I started to see the edges of the tooling.
Freeway makes it really easy to make a site that looks a particular way. As long as you can stay within that box, and are comfortable with the affordances it provides to change the layout and details, you can be enormously productive there. But if you want a visual style that can’t be accessed through its interface, you have to “get out and push” using the Extended and Markup interfaces. There you are thrust head-first into the actual HTML and CSS code, in stark contrast with the rest of the tool (where as often as not, naming and labelling follow the DTP conventions rather than the CSS you will see in any book or tutorial). The more times I ended up in these edge cases, the more I discovered that for my own sanity, it was simpler just to write the whole thing in one context, and one “language”.
Where a purely visual tool like Freeway will let you down hard is the case where you want to create a lot of similar objects on a page. Want to make a grid of images, or story previews on a blog landing page? Great. You get to touch each of them, or at the best, make one that you like and then step-and-repeat it, changing the content as you go. Now you want to make those identical elements look different at one or more breakpoints in your responsive style. Just switch breakpoints, and touch each of the items and adjust it using the Inspector or direct manipulation. Click, click, click. Contrast that with adding a common classname to each of them, and updating the CSS. With a live-preview tool and a browser open in another part of your screen, you can see each change in the context of all of the elements on the page at once. The productivity upgrade is massive.
I have been a champion of (and occasional apologist for) Freeway and visual design tools for my entire career, which was started with the initial betas of Freeway 1. Your argument here rings very true, and I am sure I have made it more than once. But you never step into the same river twice. I am not the same designer or developer I was in 1997, or 2003-6 (when I was the Softpress Webmaster), or even last week. In response to this growth and accretion of experience, the tools I use now are a lot simpler in some ways, and more complex in others, than the ones that taught me how all this works.
Walter
On Aug 9, 2016, at 6:02 AM, Duncan Wilcox email@hidden wrote:
I’m a Sparkle dev but would like to wear my “experienced web dev” hat for a minute here.
Unfortunately I think there are two basic flaws in your argument Walter. It’s a deafening echo chamber, a comfort zone for some, everybody’s repeating the same things so it rings true.
The first flaw is that there is something inherently “better” in hand-coded pages compared to generated markup. The point of a web page is exclusively to communicate content with all the different layers of annotation that come with it, with markup that ranges from visual to semantic to accessibility and all the other metadata. Browsers are agnostic to the CSS selector naming conventions or organization. There’s nothing more “production ready” of one over the other.
Generated content will most likely not follow your coding convention, but the same can be said of SASS->CSS or CoffeeScript->Javascript. Choose your poison?
The second flaw is to think that as a hand coder you have any chance of keeping up with a tool (visual or not).
When a tool learns to create a for you, it will do so consistently and correctly every time. When it adds webp, every site from there on has webp images along side jpegs (and Safari 10 is adding webp, so better take note). I pick the responsive image example because it’s a hairy mess, as this alistapart.com http://alistapart.com/ article says, "Automation is your friend; if your page is going to include massive code blocks referencing numerous alternate versions of an image, you’d do well to avoid authoring everything by hand.” Responsive Images in Practice – A List Apart http://alistapart.com/article/responsive-images-in-practice
And then there’s webfont loading for high performance. Are you familiar with the (rather complex) best practices? A Comprehensive Guide to Font Loading Strategies—zachleat.com https://www.zachleat.com/web/comprehensive-webfonts/
Load-blocking CSS, are you familiar with critical CSS? Understanding Critical CSS — Smashing Magazine https://www.smashingmagazine.com/2015/08/understanding-critical-css/
And then there’s DOM access efficiency, untangling kitchen sink frameworks, optimizing for HTTP/2, serving the billion Android 2/3/4 browsers that will never update, accounting for browser caching… the list goes on.
The paradox is that probably only a “hello world” site is faster to build correctly by hand coding it, anything of greater complexity is bound to take significantly more than by using a tool that has been debugged and tested for the specific issues, and I say this as a developer with 30 years of experience who’s pretty proficient with the command line and most editors out there.
There’s a reason nobody has ever coded billboard ads in Postscript (and since I have written some Postscript I can say thank God). Imagine if instead of InDesign, graphic designers were using a cobbled together toolchain of Postscript manipulating tools, arguing that hand coded ads were superior.
Granted, generated content has its downsides, mainly when you want to integrate it with a hand coded web app, but when it works I can’t think of why you wouldn’t use it.
And by the way, “art” it is not. Broken and slow websites definitely aren’t thought of as “art” by users, and expensive painstakingly crafted websites aren’t thought of as “art” by whoever pays for them. Everybody’s just solving the same broken box model or browser hack problems over and over again, painful to watch really.
Duncan
On 09 Aug 2016, at 03:05, Walter Lee Davis email@hidden wrote:
Someone who is skilled at making sites by hand, someone who has practiced that art, is probably going to be faster to production code than a generator, because they will start from a design and a content outline, and proceed toward a reusable solution. If they have developed their toolset to the point where they can stare into the distance and type, yes, they can be faster. They will end up with one style sheet for their site, not one per page, and the page load will be faster and designer time for post-live revisions will be measurably shorter.
I will never argue about the need for (or speed of) a visual design tool if you are starting with neither a design nor an outline, and are going to use Lorem Ipsum to lay out a prototype for client review. But at that stage, you don’t care what the code looks like, as long as it looks right in at least one browser.
When it comes time to turn that one or two page demo into production code, and you do care about reusing styles so everything is consistent, then Freeway (not sure about other tools in this category) will actively slow you down, making you reverse-engineer its process in order to gather your styles (and even then, it will fight you tooth and nail, generating exact duplicates of style rules because it uses IDs in place of classes to name them).
Walter
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk
freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options
