Scrutinizing SPARKLE (Freeway alternative)

I can only add to what Doty and Scottin asked by repeating what I said multiple times earlier in this thread. SITE SEARCH.

I’ve spent a lot of time with Walter Davis in the past trying to get my search field to look and work just the way I like it. (Bless you, Walter, for that kind help too!) To do that, I had to add code in Freeway via the HTML Markup dialog and via Walter’s Protaculous2 action (“DOM Loaded Observer” button). Without that action and without HTML Markup in Freeway, I wouldn’t have a search function today. And obviously if I ever build a fully responsive site, I want to not only retain search but make it look modern, something akin to the way Apple implements their search field atop apple.com. (Take a look there right now if you don’t know what I mean. It’s an awesome way to implement search, in my opinion.)

I guess a lot of people don’t add search because it’s either too hard or they feel their site doesn’t need it, but my website users have come to rely on it. In the past I used Atomz, and after Atomz died I switched to Google Custom Search. A bit of a pain to setup, but with Freeway, I accomplished it.

And so, just like everybody else here on FreewayTalk, when I evaluate a “Freeway replacement” I must evaluate it in terms of what I need to accomplish on the web. In other words, the kind of content I have now (site search or otherwise) is the same content I would want to build in a Sparkle website.

But in Sparkle since there are no plugins (I fully understand the reasoning) and since there is no HTML Markup dialog (again, I understand the explanation given), then I am rather stricken with fear to embark on a web design journey with Sparkle. Other people may buy Sparkle to toy with it; but the question is, will Sparkle become their main web design app?

I do not seek to speak disparagingly of Sparkle – not at all. Anyone who read my previous post can clearly see the praise I gave it and the same praise I continue to give it. It’s just that the bottom line is that I need a web design tool that works for me now, not a promise of a better future tomorrow. And so I continue to ponder Sparkle as I ponder my existing sites, realizing some changes and sacrifices must be made, but also realizing that some things cannot be sacrificed. That’s pretty much what Doty was saying and it seems like Scottin is saying the same.

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Scottin, once again Sparkle begins and ends with what you see, that’s both the upside and downside of a visual environment. Some things might be less visible, though a checkbox for preventing map zooming is right there in the map inspector.

I’m sure you’ll always find something missing that could be done with code. There’s no question that with code you can do anything. The point is, and will always be, that a vast majority of people in the world just can’t do it. Today Sparkle’s limited featureset helps many people build their own website without needing to resort to any coding or understanding of what css positioning is. That’s a major win IMHO.

Every passing month we add features, with a visual UI, that raise the bar.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

James, I fully understand that you need site search. It is on our feature list, at some point we’ll add it.

Duncan


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Thank you, Duncan.

James W.


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Hello all and Duncan in particular.

I have been following this discussion since it began and have found out a lot about the possibilities offered by sparkle.

Its been a generally helpful discussion so thanks to all for that.

Can Duncan confirm if sparkle can create horizontal submenus at all? I gather from reading the documentation that only a menu with one level of submenu is currently possible in sparkle but I didn’t read if this submenu can be assigned to be horizontal or vertical.

Let me know as its a current issue for me with a project and I can’t yet find a freeway solution which works in a responsive site.

Many thanks

Anthony


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Question for Duncan as well, unless anyone else knows:

Images with Sparkle: Looking at their documentation, am I confused regarding images. In the past with Freeway I tweak my photos in Photoshop and size them exactly as I want them to be and use Save for Web (Photoshop) so they don’t take long to load. Sparkle says it takes my photo jpg and resamples and exports the image to the correct size for the element. Why? If I decide what size the photo is going to be on a given page, why can’t I do the work in PS and upload it to Sparkle and have it left alone? What am I missing here?

Thanks much!


freewaytalk mailing list
email@hidden
Update your subscriptions at:

redfeather, you are speaking about Freeway’s excellent “pass through image” feature. I’ve done exactly the same thing for all my images for years, whether they be PNG, GIF or JPG. I created/modify in Photoshop, then save the 144ppi retina image in either GIF or PNG or JPG format (whichever is smallest and looks best to my eye), and then I sketch an HTML box in Freeway and import. That tells Freeway not to recompress the image or change the format, but to just export the graphic as is. And the reason why I use Photoshop instead of Freeway to compress my images is because, as you already know, PS does a much better job.

So obviously, we would want the same kind of “pass through image” feature in Sparkle.

Best,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:

On 26 Aug 2016, 3:56 am, redfeather wrote:

Question for Duncan as well, unless anyone else knows:

Images with Sparkle: Looking at their documentation, am I confused regarding images. In the past with Freeway I tweak my photos in Photoshop and size them exactly as I want them to be and use Save for Web (Photoshop) so they don’t take long to load. Sparkle says it takes my photo jpg and resamples and exports the image to the correct size for the element. Why? If I decide what size the photo is going to be on a given page, why can’t I do the work in PS and upload it to Sparkle and have it left alone? What am I missing here?

Thanks much!

Perhaps something I can answer.

Sparkle guys are here very enhanced. They’re wrapping images in the HTML5 element. Within the picture element, you can use a so called “srcset”. The source set allows you to define images for lower breakpoints.

So say you define your basic image on a width of 1920px, you won’t serve this for tablet and mobile. For tablets and mobile you’d like to serve alternative widths and resolutions (and therefor file-sizes) such as 1200px and 600px.

This is looking something like:

<picture class="img-2">
<source srcset="images/tmkdbooks4x-908-310.png 1x, images/tmkdbooks4x-908-620.png 2x,     images/tmkdbooks4x-908-930.png 3x" media="(max-width:479px)">
<source srcset="images/tmkdbooks4x-908-464.png 1x, images/tmkdbooks4x-908-928.png 2x" media="(max-width:767px)">
<source srcset="images/tmkdbooks4x-908-725.png 1x" media="(max-width:959px)">
<source srcset="images/tmkdbooks4x-908-908.png 1x" media="(min-width:960px)">
<img src="images/tmkdbooks4x-908-310.png" alt="" class="js img">
</picture>

So Sparkle’s core engine is doing something which is (nearby) impossible to re-create in Freeway. In fact very cool - and if a browser doesn’t support the picture element and srcset?

There is the fallback for.

Hope this helps you out.

Cheers

Thomas


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

Can Duncan confirm if sparkle can create horizontal submenus at all? I gather from reading the documentation that only a menu with one level of submenu is currently possible in sparkle but I didn’t read if this submenu can be assigned to be horizontal or vertical.

Hi Anthony,

Sparkle doesn’t currently support horizontal submenus.

Duncan


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

Images with Sparkle: Looking at their documentation, am I confused regarding images. In the past with Freeway I tweak my photos in Photoshop and size them exactly as I want them to be and use Save for Web (Photoshop) so they don’t take long to load. Sparkle says it takes my photo jpg and resamples and exports the image to the correct size for the element. Why? If I decide what size the photo is going to be on a given page, why can’t I do the work in PS and upload it to Sparkle and have it left alone? What am I missing here?

Hi Redfeather, as Thomas mentions, Sparkle creates a picture element, or in the case of a box background, Sparkle uses media queries to load a different image at different breakpoints, or in the case in the forthcoming webp support in 2.1, different CSS rules to load different compression formats (webp saves about 25% size and is used by Chrome 25+ and the upcoming Safari 10, and more importantly, their mobile variants).

The gist of it is, like for so many other things, making the appropriate image size in Photoshop and putting it into your web page is something you need to unlearn. It was the recommended thing to do for so many years, but already in 2010 with the introduction of the retina screen on the iPhone 4 it was dubious. In 2016 the picture element and other techniques ensure that in a responsive website each device downloads the smallest image they need to show a crisp image for their pixel density. This means your images folder will contain many image files for each image in your page, and this is a good thing (if you don’t have to prepare them all yourself).

By the way the wording in the documentation may seem to suggest Sparkle resamples the image when enlarging it, this is not the case. Sparkle only creates high resolution variants of an image if the source image has enough pixels in it, otherwise it only leaves the lower resolution version. But by giving Sparkle a high resolution source image you can ensure that your site looks great on my retina macbook pro even if you’re creating it on, say, your non-retina iMac.

Duncan


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

On 26 Aug 2016, 7:27 am, Duncan Wilcox wrote:

Hi Anthony,

Sparkle doesn’t currently support horizontal submenus.

Duncan

Thanks for the clarification Duncan.
Could a horizontal submenu be achieved by using an externally created script added in to a sparkle page?

Just keen to know more about such possibilities.

Anthony


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

Thanks for the clarification Duncan.
Could a horizontal submenu be achieved by using an externally created script added in to a sparkle page?

Presumably yes, we have users integrating animations built with Hype, so why not. However it requires some development skills which you’d need to have.

Duncan


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

Thank you, Duncan & Thomas!

So Duncan, when you say “by giving Sparkle a high resolution source image you can ensure that your site looks great on my retina macbook pro even if you’re creating it on, say, your non-retina iMac.” What is high-res to Sparkle?

And how do I know what dimension to make the photo? Is it the largest size I determine I want for my layout?

Thanks much,
joette / redfeather


freewaytalk mailing list
email@hidden
Update your subscriptions at:

So Duncan, when you say “by giving Sparkle a high resolution source image you can ensure that your site looks great on my retina macbook pro even if you’re creating it on, say, your non-retina iMac.” What is high-res to Sparkle?

Well the question is really what is high-res to your layout. In the image inspector there is a resolution meter that shows how your image resolution fits with the current on page dimensions, for example: http://sparkle.cx/docs/images/pasted-image-280.jpg

In general I’d say 3x pixel density is overkill but 2x is very common, so the image could be twice the width and height of the image’s largest size, and all other images will be downscaled from that.

Duncan


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

Well, I’m a print designer and tend to think in terms of dpi. I don’t know what dpi “3x pixel density” would be. Help.

Is this new way (to me) of handling images due to responsive layouts be one reason so many sites load so slowly these days? Are the majority of people using photos that are overly hi-res?

thx!

joette/redfeather


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Well, I’m a print designer and tend to think in terms of dpi. I don’t know what dpi “3x pixel density” would be. Help.

Since the size of pixels on screen is dependent on the screen resolution and size, there’s no way to consistently translate from pixels to inches, and by extent to dpi.

If you want to think in dpi terms for simplicity for a minute, you can pick a specific screen size and think it through with that. The dpi values would still be irrelevant in print context because it makes sense to pack pixels denser based on how far the screen typically is from your eyes. So for example the original iPhone’s screen was 163 dpi, more than a computer screen’s 72 to 96 dpi (or whatever) but very discernible pixels.

The 3.5” and 4” screens starting with the iPhone 4 doubled the horizontal and vertical pixel density, hence 2x, to 326 dpi. The reason it is referred to as 2x is the HTML coordinates and typesetting references are the same as those of the original 163dpi phone, but each point is a 4x4 pixel grid. Web content still addresses 320x480 points (or 320x568 for the 4” screen), and the pixels are on half-point coordinates. Or in the case of images, they’re shrunk to half size so each of the image pixels lands on a physical screen pixel.

The iPhone 6/6s 4.7” screen have a natural point size of 375x667, but the screen has double density so 750x1334 pixels (326 dpi like the original iPhone). The 6+/6s+ on the other hand have a 5.5” screen and 414x736 points, but Apple opted to use a grid of 3x3 pixels for each screen point so 1242x2208 pixels, so 3x retina, except they then downsample that to the actual screen resolution which is 1080x1920 pixels, so ultimately 401 dpi which isn’t quite 163x3. And interestingly there’s no way you’re going to get a perfectly sharp image (but your eyes won’t be able to see it).

This is an interesting guide to points, pixels and screen sizes in iPhones. There’s more with iPads and of course a hugely more varied scenario on Android.

On laptops and desktops 2x is generally in the 220 dpi range, which is considered retina (indistinguishable pixels) because they stand further away from your eyes than a phone or tablet.

The gist of all this is, it’s only practical to think of what the devices are capable of, and what a browser running on one of them will request, rather than thinking in terms of inches.

Is this new way (to me) of handling images due to responsive layouts be one reason so many sites load so slowly these days? Are the majority of people using photos that are overly hi-res?

“Slow” can mean a lot of things, often:

  • the page references an asset on a slow server (or is itself on a slow server), often a render-blocking asset like a stylesheet or a webfont, so your perception is its slower than it actually is (but it makes no difference actually)
  • the page is fed by a database of sorts, often a puny mysql which is overloaded (classic for non professionally run wordpress/joomla/drupal sites)
  • the page is actually downloading a shitload of stuff, which can either be lazy/dump optimization or huge ad/tracking packages (typical for sketchy news sites)

If properly built, the responsive image setup is actually no different for a desktop device and a lot faster for mobile devices. Amateurishly coded websites/webapps sometimes do have oversized images, though frankly it is one of the easiest problems to fix, it’s more about carelessness.

Duncan


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

I found the answer on Google. I haven’t had to update any of my personnel sites in a while! Good to know. If any other print people come across this 1x, 2x, 3x issue, here’s a good link to see what’s what:

Thx all!


freewaytalk mailing list
email@hidden
Update your subscriptions at:

And… I just realized Duncan had the same link in his very detailed post to me. I didn’t see it because we apparently posted at the same time!!

Thanks Duncan, I very much appreciate your explanations and it has helped very much. I’m getting it!

Downloaded Sparkle and will take it for a spin.

joette/redfeather


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Duncan is right to recommend “2x” (144ppi) at the largest pic size you will display. Three years ago I tested retina graphics extensively and found that 72ppi images look blurry and awful on retina iOS devices and Macs, but 144ppi looks very good, and 288ppi is great but almost too sharp. So 144ppi is the ideal in terms of look and filesize.

I usually can compress 144ppi JPGs to 44% in Photoshop without really seeing compression artifacts when displayed on a retina screen. But if there is a lot of tiny red text, I may need to take it up to a 50% compression to make it look nice. And when I need transparency, I tend to use PNG more than GIF because the filesize is smaller, and I use TinyPNG to compress my 24-bit PNGs into 8-bit files without noticeable loss in visual information.

So it seems that Sparkle will use your original pic as is, like a Freeway pass-thru image, when Sparkle displays that image at it’s actual 144ppi size, but Sparkle (or rather, the browser) will shrink the image when that same pic scales down on a responsive page, and Sparkle will present a lower rez 72ppi version of the pic when Sparkle wants to display it on non-retina machines. But how fuzzy or sharp that 72ppi image will be is not something I’ve tested in Sparkle, nor do I know if 8-bit PNGs will remain 8-bit PNGs (and so on) when Sparkle does it’s image manipulations. What I find in Photoshop is that if I make a 144ppi image to be 72ppi, it needs a little sharpening to look its best, unless I use the “sharper” resize antialias setting in Photoshop. So an extensive test in Sparkle would be necessary for one to know exactly graphics are output to both 72ppi and retina devices.


freewaytalk mailing list
email@hidden
Update your subscriptions at:

Duncan is right to recommend “2x” (144ppi) at the largest pic size you will display. Three years ago I tested retina graphics extensively and found that 72ppi images look blurry and awful on retina iOS devices and Macs, but 144ppi looks very good, and 288ppi is great but almost too sharp. So 144ppi is the ideal in terms of look and file size.

As mentioned “dpi” is an incorrect term. You might want to use it as a label but it’s rather abstract, 1x/2x/3x seem easier to remember. 3x would be 216dpi by that metric.

I usually can compress 144ppi JPGs to 44% in Photoshop without really seeing compression artifacts when displayed on a retina screen. But if there is a lot of tiny red text, I may need to take it up to a 50% compression to make it look nice.

The optimal JPG compression really depends a lot on the content, absolute figures like that aren’t a good rule of thumb. Optimal compression is still a bit of a research topic, Google built this tool which is a “psychovisual estimator" somewhat like mp3 uses psychoacoustics to compress best for music:

GitHub - google/butteraugli: butteraugli estimates the psychovisual difference between two images https://github.com/google/butteraugli

That said the smaller the pixel size the smaller and less noticeable compression artifacts are, the more you can compress the same image, so if you’re compressing the non-retina 1x jpg at 60% you might compress the 2x at 50% and the 3x at 40%. For example http://silev.org/test/Retina-resize.html http://silev.org/test/Retina-resize.html shows this.

And when I need transparency, I tend to use PNG more than GIF because the filesize is smaller, and I use TinyPNG to compress my 24-bit PNGs into 8-bit files without noticeable loss in visual information.

GIF is definitely a file format that should not be used anymore, for any reason including animation. 8-bit PNG only has 1 bit for alpha which most of the time really looks ugly.

So it seems that Sparkle will use your original pic as is, like a Freeway pass-thru image, when Sparkle displays that image at it’s actual 144ppi size, but Sparkle (or rather, the browser) will shrink the image when that same pic scales down on a responsive page, and Sparkle will present a lower rez 72ppi version of the pic when Sparkle wants to display it on non-retina machines. But how fuzzy or sharp that 72ppi image will be is not something I’ve tested in Sparkle, nor do I know if 8-bit PNGs will remain 8-bit PNGs (and so on) when Sparkle does it’s image manipulations. What I find in Photoshop is that if I make a 144ppi image to be 72ppi, it needs a little sharpening to look its best, unless I use the “sharper” resize antialias setting in Photoshop. So an extensive test in Sparkle would be necessary for one to know exactly graphics are output to both 72ppi and retina devices.

Yes Sparkle is applying light sharpening when resizing images.

Ultimately I have to wonder if all the hard earned knowledge is something that is worth clinging on to. I just came across this yesterday:

http://monkeyphil.co/blog/i-used-to-build-websites http://monkeyphil.co/blog/i-used-to-build-websites

So essentially the £5k and up website market is gone. And that figure is falling, fast.

Duncan


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