Scrutinizing SPARKLE (Freeway alternative)

On 16 Aug 2016, 1:48 am, JDW wrote:

Richard, not to in any way whatsoever speak ill of your preferred solution, I feel compelled to point out that if one is willing to pay $300 for a web design package, RapidWeaver + Stacks + Foundation (Joe Workman) + other stacks you may need will fit neatly within that price point. Food for thought.

Good morning James,

it’s just $59 for Responsive Foundation Framer (the web-design app that –for me– replaces Freeway); the extra €248 I’ve spend gave me just 7 additional great apps. So … it seems a bargain to me :slight_smile:

Richard


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Richard,

Thank you for explaining.

Since this thread is focused on Sparkle, I must ask you a question. Did you try Sparkle before you decided on Responsive Foundation Framer?

If you did try Sparkle first, what made you decide to choose Responsive Foundation Framer instead?

If you didn’t try Sparkle at all, then the question by “marka” remains, and perhaps Duncan will be kind enough to address that.

Best,

James W.


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Building websites is different things to different people, and there are different priorities and angles to evaluate web building software, web frameworks and the actual websites produced with them. Everybody brings their own experience, bias and more or less hidden agenda to the conversation.

So here’s my point of view.

First, while frameworks such as Foundation and Bootstrap make it incredibly fast to built a “real” responsive website, what you are trading for the speed is a bit of a canned look.

There are many articles about this:

http://adventurega.me/bootstrap/

The gist of it is a web framework is only slightly less template-y looking than a template, unless you delve into heave code customization (yes even in foundation and bootstrap generators).

So coding. If you’re into coding, more power to you. Some things you can’t do without coding (like a webapp, or a very custom design, tinkering with cutting edge css, etc). If you code you’ll probably view everything through the “can I use this to code” lens. If you’re on the edge about learning some, it clearly is your prerogative to decide for or against coding. Just be aware that the minimum level isn’t just HTML/CSS, in 2016 you need to compress images in multiple sizes and formats, implement several techniques for font, script and css loading to pass the speed tests with flying colors and be compatible with a dozen browsers, it really is a full time job, “fixing” your site by asking your friends or stack overflow is looking for trouble. And like with everything that’s DIY, if you built it and it breaks, you get to debug it and fix it, even years down the road.

So considering there are visual editors, why is there a common consensus that you should go with code-based solutions? Plenty of reasons. Perhaps they have a a knack for code or perhaps they have a problem that can only be solved by coding. Often times though I get the impression that by insisting that something is “pure and real” and something else is not, that there’s something ineffable about on solution over the other that only people in the ivory tower can approve, the only solution is a time consuming or expensive consulting service. So buy a $100 app or a $1000/year “real” website from a professional? Hmmm.

Sparkle’s tradeoff is that, in order to preserve a fully visual interface with no jargon, you get a somewhat “less pure” responsive layout (which as Mark mentions actually works just fine), but you have full creative control over each layout and can make your site actually stand apart by not making it look canned.

Take a look at these responsive websites built with Sparkle, do they work/feel ok? Do they look alike in any way shape or form?

http://themonkeykingsdaughter.com (former Freeway user Todd DeBonis here)
http://www.auer-max-film.de
https://www.purelynx.com
http://lioneldarian.com
http://davidpuckett.com

In every case here no “web professional” was involved in the creation of the site, each of them is built by someone who has a different, actual job.

Finally, the code vs. no code discussion is a bit like politics or religion, I’m not going to change anybody’s mind. And that’s why this discussion is just running in circles here.

Nothing hidden about my agenda by the way, in the context of static websites, such as a small business or personal website, I truly believe Sparkle is by far the best solution for anybody that’s code shy (translated: has other work to do), and I want you to buy Sparkle or at least try out Sparkle if that definition fits you. So let’s do this, get Sparkle 15% off here: Pricing — Sparkle (if you come from Freeway and have purchased Sparkle already in the last week or two I’ll refund the 15%). Deal?

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

On 16 Aug 2016, 9:10 am, JDW wrote:

Richard,

Thank you for explaining.

Since this thread is focused on Sparkle, I must ask you a question. Did you try Sparkle before you decided on Responsive Foundation Framer?

If you did try Sparkle first, what made you decide to choose Responsive Foundation Framer instead?

If you didn’t try Sparkle at all, then the question by “marka” remains, and perhaps Duncan will be kind enough to address that.

It’s just a gut feeling I got when I started working with RFF (I bought the beta after playing around with it’s predecessor Responsive Site Designer); it’s solid, robust, in a way it works the same as Freeway does when working ‘box model’ I am familiar with (and I know, that’s not your cup of tea, it lacks that intuitive way of working you cherish … I respect that). It feels just like an app that is fully ready for the future, you know … despite how reliable Sparkle seems to be. The fact that Coffeecup seems to cover all bases offering this range of apps –for me– made me feel comfortable with that choice. Like I said, an intuitive choice.

–Richard


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

On 16 Aug 2016, 11:04 am, Duncan Wilcox wrote:

Building websites is different things to different people, and there are different priorities and angles to evaluate web building software, web frameworks and the actual websites produced with them. Everybody brings their own experience, bias and more or less hidden agenda to the conversation.

I heartily agree. So let me bring in one angle of less importance:

Say - one day you’ll find following message in your mailbox:

Unfortunately all public servers are full. Humanity showed it’s best face and wasted all available resources (the rest is provided for fighting against aliens). Because of this, from now, no new content can be published anymore.

We, the WGCWS (Web Group Cleaning Wasted Space) hereby decided (beneath some other things) to auto-delete any image higher than 100k. The all-time goal to reach is, that no website is heavier than 1.7MB in weight.

Uff - so what? Crying, mumbling and grumbling? Blaming an application?

Some things you can’t do without looking under the hood. It doesn’t necessarily mean “code”. Pages like this:

is looking exactly the same in Freeway or Sparkle - or any other application. It’s simply done by amateurs who are not aware of the consequences. WYSIWYG is dead - haphazardly building websites as well. Such as this audience did many years as well. So it’s not surprising, that this page is created by a former Freeway user. It’s focused on being pretty (33k - yippee):

Interesting to see, that Sparkle has exactly the same (weird) attitude towards styling and semantics as Freeway has. No H-Tags - but many font-1, size-12 and pos-100 (we are used to call them item-134 and style-78).

But as already said: it’s less important.

Cheers

Thomas


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Thomas, I don’t get your passive-aggressive way of underhandedly disparaging anybody who doesn’t view the world exactly as you do. Not a game I’m interested in playing.

But since you’re criticizing Sparkle out loud in the Sparkle thread I feel the need to defend it.

What Sparkle’s code looks like is frankly completely irrelevant if you don’t need to further edit it, as is the case with Sparkle and for Sparkle users. Not liking the “font-1” css selector is akin to not liking the color of the fuel pipe in your car. I’m sure your mechanic loves you for that.

As per the 33k you fail to mention that by using the rather verbose element (standards committees to thank for that), asset download is optimal for each visiting device. In other words, because Sparkle resizes and compresses images for different devices and pixel densities, an iPhone would be downloading the 150kb jpeg instead of the 330kb jpeg a desktop visitor would download. Sparkle also goes to great lengths to avoid bloat in the bundled javascript, something even many developers fail at doing.

We have thousands of users for whom code simply isn’t an option, either because symbolic thinking (left brain) and visual thinking (right brain) are too hard to mix for them, or because the time needed to wrap their head around some arcane browser bug or CSS “feature” isn’t compatible with their busy life. In fact statistically speaking I’d say WYSIWYG is the future and handcoding HTML is dead, it just isn’t apparent in this particular echo-chamber.

Unlike Freeway, Sparkle isn’t a dead product. You don’t want to use Sparkle? Fine. You don’t think Sparkle is good for you? Understood. Intellectual honesty would have you admitting that Sparkle is simply amazing for its target audience.

So it’s the amateurs who are creating the unique, distinct new websites and the professionals creating the canned-looking ones. Go figure…

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

But since you’re criticizing Sparkle out loud in the Sparkle thread I feel the need to defend it.

I can’t judge a product - and I never did. All I can judge is a result - no matter how and with what it has been created. And you shared results. And I had a brief look into it.

What Sparkle’s code looks like is frankly completely irrelevant if you don’t need to further edit it, as is the case with Sparkle and for Sparkle users. Not liking the “font-1” css selector is akin to not liking the color of the fuel pipe in your car. I’m sure your mechanic loves you for that.

Perhaps - yes. But I’m not sure if semantics in web is really irrelevant. Or for screen-readers?

As per the 33k you fail to mention that by using the rather verbose element (standards committees to thank for that), asset download is optimal for each visiting device. In other words, because Sparkle resizes and compresses images for different devices and pixel densities, an iPhone would be downloading the 150kb jpeg instead of the 330kb jpeg a desktop visitor would download. Sparkle also goes to great lengths to avoid bloat in the bundled javascript, something even many developers fail at doing.

Yep - the picture element. I’m aware of. Well done.

We have thousands of users for whom code simply isn’t an option, either because symbolic thinking (left brain) and visual thinking (right brain) are too hard to mix for them, or because the time needed to wrap their head around some arcane browser bug or CSS “feature” isn’t compatible with their busy life. In fact statistically speaking I’d say WYSIWYG is the future and handcoding HTML is dead, it just isn’t apparent in this particular echo-chamber.

No - the point is, that an adaptive web is way too flexible to see it from a static standpoint. I forgot to mention that VCD (We see design) or Visual Controlled Design would cover this aspect much better.

Unlike Freeway, Sparkle isn’t a dead product. You don’t want to use Sparkle? Fine. You don’t think Sparkle is good for you? Understood. Intellectual honesty would have you admitting that Sparkle is simply amazing for its target audience.

Yes it’s true. And I think Sparkle is the closest match to substitute Freeway. I don’t think that I ever wrote anything else. I’m not application oriented. But watching your promo video “Why Sparkle”, I feel myself named and shamed. A true idiot, just because I do research in web and even read books.

So it’s the amateurs who are creating the unique, distinct new websites and the professionals creating the canned-looking ones. Go figure…

Duncan

Visually spoken - maybe (it’s anyway too hard to judge “design”). But I still see both: The things I see - and the things I can’t (but sometimes wonder).

Cheers

Thomas


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Duncan,

Can you see the code in Sparkle at all? Add html markup and/or edit css?? I love the aspect of visual design, but sometimes I like to push things a little farther with added bits of code here or there. Basically, I’m fine with not seeing the code… Until I need to!

Thanks.
Doty


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Doty, no, Sparkle is visual only. I am convinced that a tool that is visual and jargon free can’t allow arbitrary HTML/CSS editing. And if the tool isn’t jargon free, or allows more advanced features only by editing HTML or CSS, it’s just a thin coat of paint over code and you still need to understand CSS positioning or browser bugs or even the concept of a CSS class, and what’s the point then?

There are plenty tools that try to mix visual editing and code, but as you have probably found they fall short on the visual side.

As to why a truly visual editor can’t allow arbitrary code editing, the reason is quite simple really. Take any non trivial technique, say an image gallery or animation or a lightbox. For each there are as many different techniques as you can count. Unlike a web browser that “executes” the page, an editor would have to understand the intent to go back to visual editing. The intent is never part of the page, and code acts in local fashion, so a change in one place can affect the layout or functionality in another. So to be truly visual an editor would have to understand all of the possible techniques. Finally many techniques are JavaScript based, code which is impossible to analyze by a piece of code for all practical purposes.

Now if you’re ok with an editor that doesn’t quite preview what the final result will be, there are plenty of options, they are essentially glorified web inspectors and expose all of it.

This difficulty in reconciliation of needs of code and visual use cases is incidentally the reason I think macaw 1 didn’t work out.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Thomas, I guess I need to apologize that you feel offended by the Sparkle video. It really is intended tongue in cheek, but whatever.

Yes we do care about the semantics and accessibility of web content (and of the Mac App), and what we don’t do yet we’ll be adding soon. A feature addition that, like any sparkle addition, will require minimal effort for sparkle users to adopt.

I figure you have all been burnt by Softpress’ outcome or by greedy corporations, but we fully intend to make Sparkle a fully visual environment for many web needs.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Duncan, my humble thanks not only for your detailed replies, but for your kindness in extending a 15% discount off Sparkle to us. Once again, for you folks who might have missed it, Duncan (developer of Sparkle) is offering the discount here:

I would also like to add, Duncan, that Thomas is someone whom I consider a “Responsive genius” among us. He used Freeway to accomplish things I could only dream of, and that remained true even after I watched his videos on GridMeister. I’ve been a Freeway user since version 2 back in 1999, but my poor brain is handicapped in that I’ve never been able to figure out how to use Freeway (or rather, how to ENJOY using Freeway) to create truly responsive sites like Thomas, Ernie S., and others here. Those folks may chide me (if not but in their hearts) about my having “not spent enough time on learning it,” like they did. And they’re right. But I lack the time and desire to learn it. I may know how to code in Assembly on a PIC MCU, but that doesn’t mean I want to be a web coder. Not in the least!

“WYSIWYG” being deemed “dead” or not, I nevertheless want to pour my right brain on the web in as painless a way as possible, yet yielding a truly responsive website result, without bloated code, and with a very beautiful to behold look. Except for the left-brained coders, I think that’s what we all want (the majority of people who need to create or modify websites).

Let it also be know that I am not a full time web designer. Web design is only a tiny part of my job. So even though I’ve been using Freeway since 1999, I’ve never had my job description changed such that I have become a web-designer-only. People who design web sites for a living, living and breathing that almost exclusively, will perhaps think differently than I do. And that’s okay. I am just saying for the record who I am and what I want to accomplish.

Yes, I’ve heard that some full time web designers are called upon by big corporations to create only a Foundation website or only a Bootstrap website. In that case, those full time web designers may need to buy more than one web design tool to help them. But that doesn’t relate to me. I couldn’t care less if it is Bootstrap or Foundation or Thomas’ Gridmeister. I just want a truly responsive site that looks great and is easy to build and is easy to modify. Modify being the key word seeing that I often need to make modest edits fast and get those uploaded with only 5 or 10 minutes to spare.

I have been participating in FreewayTalk for years, but never more than now. Now that Freeway is no longer updated or supported, I am scrambling to decide what to do. And I am not embarrassed or ashamed at telling the world my thoughts. So here they are…

I like many thinks about Sparkle.

I like many things about Blocs.

Pinegrow is only useful to me as a last resort HTML importer that allows feeble-brained folk like me to make minor edits easily.

From what I’ve read about apps other than those 3, I am not in the least bit interested in those.

I am still using Freeway for now, but would like to get started on a fully responsive site soon, prompting me to choose either Sparkle or Blocs.

Sparkle Pro is, for a limited time to us here, 15% off the $79.99 retail price, making it $67.99. Sparkle, to me, is similar to Freeway in some respects and may be a somewhat painless move for some. Sparkle also has a trial app that is limited by number of pages and a watermark, but it is free to use forever. That is very helpful for people really wanting to test the app (which requires more than just 5 days).

Blocs Personal also retails for $79.99, but there is no discount being offered (to my knowledge), and the trial version limits you to a shocking 5 days. It looks a bit easier to use than Sparkle, but then you have less flexibility than Sparkle too. The Blocs UI is lovely to behold, and like Kentucky Fried Chicken, there is something mysterious about it that makes you crave it.

And there you have it.


marka,

Does our recent dialog help? If you or others have any additional questions, let them be known. This thread is about Sparkle. Duncan has been very helpful. And even though Thomas disagrees on certain points, his input is necessary and helpful too. No one wants to merely sing to the choir. We want to hear all sides and examine Sparkle objectively.

Thanks to all who have kindly contributed to this thread to date.

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Hi Duncan,

Thanks for your reply. Okay, I can’t see the code w/ Sparkle. I couldn’t see it with freeway and that was usually okay. But can I ADD code???

In FreeWay, I need to add code in several typical web situations:

  • buy buttons
  • MailChimp or similar signups
  • WowSlider/Amazing slider or some other similar element
  • Music players

That’s off the top of my head, but there are plenty of others. Can I add code via html markup or other similar functionality? Thanks.


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Duncan,

To supplement Doty’s question I must emphasize that Freeway has long allowed us to add a splattering of code here and there via its HTML Markup feature – a dialog box that let’s you dump in JS or CSS as you see fit. And honestly, without that feature, I never would have gotten a search feature of my site to work and look as I like. I have quite a bit of HTML Markup in my Freeway sites, actually.

Here are some examples of how its done in Freeway:

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Doty, Sparkle does have an embed element, typically used to embed the HTML code for paypal or shopify buttons (for example in http://kralikarna.com/A/ http://kralikarna.com/A/), or an ecwid.com http://ecwid.com/ shopping cart. I’m pretty sure mailchimp or the self hosted sendy have been integrated as well.

More complex embedding such as WowSlider probably aren’t as straightforward, though I have never tried myself. You can add simple code in Sparkle, but integration of a whole folder of assets the best route is probably to export say the WowSlider HTML to the web host and integrate it via an iframe in Sparkle. This is what customers who are integrating Hype-generated content do.

I’m not familiar with different music players, Sparkle has plyr.io http://plyr.io/ built in for mp3s and soundcloud embedding works (or needs minor tweaking), for others we’d have to look into them.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

The problem with dumping JS or CSS anywhere is the behavior becomes unpredictable.

One one hand it’s impossible to provide a WYSIWYG rendition of that code (for the reasons stated previously, an editor is either all visual or it exposes HTML concepts). We don’t want Sparkle to become a container for gray boxes. Also we don’t want sites built with a sprinkle of code to be a notch above sites built without, or there goes the visual nature of the tool.

On the other hand we want to guarantee that the page loads fast under all circumstances, but if you put a link to a CSS file, a script or other render-blocking code, the page won’t be as fast.

In a more under the hood way, we want to be free to significantly change the generated code in the future, say we switch to flexbox and the markup ends up being entirely different, any code that significantly interacts with the code that Sparkle generates today is going to break, and it’s going to be a nightmare to move forward. So we draw the line at “self contained piece of code”, like say a Google map or a Youtube embed (which we support directly, but they are good examples).

This means that some things today in Sparkle can’t be done. The good news is we release a bunch of updates throughout the year, and we’re happy to talk and integrate what makes sense to fit in. favicon is definitely ridiculous to have to set up manually, it’s in Sparkle since the original release.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Is there any notion of an “Action”, the way that Freeway allows you to interrupt the publishing cycle programmatically, alter the code about to be generated, and then carry on as though nothing else happened? I am thinking here about my Inlay Action, which does nothing more except decorate an element with a data- attribute, which means that Freeway users can use my CMS without having to “code”.

I would love to see Inlay appear as native as possible on as many different static HTML generators as possible, since that is how it was designed and intended.

Walter

On Aug 17, 2016, at 9:43 AM, Duncan Wilcox email@hidden wrote:

This means that some things today in Sparkle can’t be done.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Walter, Sparkle doesn’t have any form of plugin. On one hand it’s to be leaner and quicker by avoiding dependencies. On the other hand, app stores really don’t like plugins so that makes it tricky.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Gotcha. So any form of adding data-attributes to individual page elements would have to come through post-processing?

Walter

On Aug 17, 2016, at 10:34 AM, Duncan Wilcox email@hidden wrote:

Walter, Sparkle doesn’t have any form of plugin. On one hand it’s to be leaner and quicker by avoiding dependencies. On the other hand, app stores really don’t like plugins so that makes it tricky.

Duncan


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

Yeah.

On 17 Aug 2016, at 16:43, Walter Lee Davis email@hidden wrote:

Gotcha. So any form of adding data-attributes to individual page elements would have to come through post-processing?

Walter


freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Duncan,

Perhaps I should have added a caveat to my question… For example, I recently added flexbox to a FreeWay site that I designed. You can see the result here and here. In each of these situations, the WYSIWYG aspect of FreeWay is limited. But I understand that. I’m asking it to do more than what it is built out of the box to handle. So the trade off I’m making is the visual look of FreeWay is not totally what it is after it’s uploaded, but it is close enough for my purposes.

For beginner FreeWay users, keeping things exactly WYSIWYG is important. It’s too confusing otherwise. But once people get a handle on things, the questions come… “how do I do thus-in-such in FreeWay,” often the answer is either a plugin or special code pasted somewhere.

Sometimes, that code needs to be placed in two places, in the section, or before /head section AND wherever the code is to appear. It was necessary to do this "two place pasting of code on this page for the slideshow, and on this page for the “sticky” nav menu. Those are a couple of examples of what I’m talking about. They were tricky for me to learn the first time, but once tackled, I want to be able to use such elements on future sites. I want to add to my toolbox as I gain more skills as a designer.

Another example is, if I want to add CMS bits of code with Pulse or Perch, or Inlay, can I do that in Sparkle. iFrame is not ideal when it comes to responsive sites and I’ve been trying to avoid it as much as possible for several years. If a bit of Pulse code has to be inside an iFrame for my client to edit their site I’m afraid that would lead to all kinds of problems. In freeway, I just wrapped this special code in a

all it’s own and then moved on with my day. YES, the code does not appear on the FreeWay document itself. I don’t need it to. I just need the ability to paste it where I need it. I know you were getting at this in Walt’s question above, but I didn’t really understand the answer or if it would work for my purposes.

I realize the excessive use of sliders and whatnot can slow a site loading time down. But sometimes that is exactly what the client wants. I’m dealing with that on the slider example I gave you. It’s less than ideal when it comes to loading time, but it is exactly what the client wants and sometimes at the end of the day that is the necessary trade we have to make.

I know Sparkle is trying to keep things simple, but are these more complicated elements supported? Out of the box, Sparkle looks great, but I’m afraid if I can’t stretch it’s capabilities here and there I will feel very limited.


freewaytalk mailing list
email@hidden
Update your subscriptions at: