I wonder which would be the best file size (px and kb) to serve screens to mobiles in order not to overload mobile connections, but to present sharp pictures as well? A client likes to have a full background picture in his design.
I simply search for an average. 1000px or 1200px width or more?
Thanks, Andries, but I have hoped for a solution or an average in FW 7 itself from someone who has done it already.
I know that there are many other ways, but I am looking first for the most simple solution, before going into “external” coding.
The background supersizer action is in my testing a very good action when I keep the layout in mind and till now has very good performances with iPhone 5 and 6 even in slow connections.
If you want the background image to animate then the Background Supersizer Action is fine (although I think your pages may get a little bulky with all of that JavaScript on the page).
The trick is to add a style to the background image to tell the browser to cover the item with the image. In this example take a look in Page > Extended for the extra CSS markup.
I’ve also added different sized images to the page at different breakpoints so mobile users (for example) will only ever load in an image big enough for their device. I’ve also made sure that the images (apart from the biggest one for the ‘default’ view) are twice the pixel size of the breakpoint so they look reasonable on retina screens.
Although this solution isn’t ideal (if a user has already downloaded a larger image then we shouldn’t really be loading a smaller version to replace it) it should cover most use cases for you.
Regards,
Tim.
On 11 Nov 2014, at 09:38, sonjanna wrote:
The background supersizer action is in my testing a very good action when I keep the layout in mind and till now has very good performances with iPhone 5 and 6 even in slow connections.
Tim, this is exactly what I was hoping for!
( No animation. The background image should size the page.)
To see it online and in the FW 7 file is more than helpful for me. Honestly, I cannot express my gratidude!
It’s a steep learning curve to FW7 and “responsive”. I have to change many workarounds which have been reliable for many years in clients projects. Suppose I am not the only one ;).
As far as I can see in a quick test it works perfect!
Tim, in iPhone 3 and iPhonesimulator 5 + 6 the background fotos do not fill the whole screen / page as in background super sizer. Nor in portrait neither in landscape.
I’m only just getting back to this after a busy day.
I’ve just updated the demo and the Freeway file. I just needed to clearfix the body tag to prevent the background image getting chopped off.
Hi Hanna,
Uncheck the “Background scrolls” checkbox in the Inspector for each breakpoint. This will prevent the image scrolling with the page and should stop the gaps appearing.
I’ve tested it here on my iPhone, Android phone and tablet and it appears OK on all of them.
Regards,
Tim.
Thank you very much Tim, in a way it does it now. In a desktop browser the background picture scales, but in iPhone Simulator and iPhone 3 the background picture does not scale unfortunately. Displayed is just a section of the picture and pixelated.
You see the difference when you jump to HOME (with background supersizer action and background scroll checkbox on) and scrolls a bit down.
This is the way my client likes to see his background pictures.
You have done already a lot for me and I cannot ask for more!!!
So I address the whole audience now. How can I solve this without having to create several FW7 files for mobiles, tablets and desktops and to make alternative routings in code. Or fall back to supersizer action and one background picture for all devices.
Tim`s solution is so brilliant and easy to set up. Just this little hiccup!
There must be a way to provide it in one FW file.
I am sure, I am not the only one who needs a solution for this. Now and in future….
Just for the records: you want a background image which scales to all
screendimensions? Fluently or adaptive? And the supersizeraction did his
work correct? But then you have one big picture what could be to heavy for
mobile…
Am I correct so far?
Op 12 nov. 2014 14:01 schreef “sonjanna” email@hidden:
Thank you very much Tim, in a way it does it now. In a desktop browser the
background picture scales, but in iPhone Simulator and iPhone 3 the
background picture does not scale unfortunately. Displayed is just a
section of the picture and pixelated.
You see the difference when you jump to HOME (with background supersizer
action and background scroll checkbox on) and scrolls a bit down.
This is the way my client likes to see his background pictures.
You have done already a lot for me and I cannot ask for more!!!
So I address the whole audience now. How can I solve this without having
to create several FW7 files for mobiles, tablets and desktops and to make
alternative routings in code. Or fall back to supersizer action and one
background picture for all devices.
Tim`s solution is so brilliant and easy to set up. Just this little hiccup!
There must be a way to provide it in one FW file.
I am sure, I am not the only one who needs a solution for this. Now and in
future….
The example I originally posted uses a background image of 640 x 480 pixels for the 320 breakpoint. The CSS is scaling the image to the overall page width or height which, for an image of this size, will cause the image to scale up. If the page is taller than 480 pixels you’ll see the background image start to degrade in quality as the image scales up. The solution I would think is just to drop the 640 x 480 image at the 320 breakpoint or use a larger image. You’ll need to look at the overall height of your longest page and use an image that comfortably large enough to cover the screen without it scaling up.
I hope this helps.
Regards,
Tim.
On 12 Nov 2014, at 13:01, sonjanna wrote:
You see the difference when you jump to HOME (with background supersizer action and background scroll checkbox on) and scrolls a bit down.
This is the way my client likes to see his background pictures.
That means at very breakpoint another background file / size + a bit of code.
Here is the problem that the background pictures do not scale properly like in the background supersizer action modus, a blank white space at the bottom appears.
TIM
I hope I understand your suggestion, but I am not sure if this is a practical workaround. First I have to experiment in every page + media width tabs the right size of the background picture. What an amount if I have only 8-10 pages x 4 media width…
Every time the client changes textsizes/pagesizes I need to find out again and open PS, resize the picture, export, import…
Hi,
I should stay with one image if possible. Otherwise you’ll go mad with
every change ;-).
Perhaps the most effort you can get is to make your image as small as
possible in weight, not in pixels and use the background supersizer action.
Just toggle with your jpg settings untill you have an acceptable view…
I found wallpaper images of 2500 x 1600 px at approx. 750 kB, I’ve seen
full screen video’s of 200kB.
There are more solutions in CSS and Jquery but they all expect some amount
of coding-knowledge.
E.g.:
That means at very breakpoint another background file / size + a bit of
code.
Here is the problem that the background pictures do not scale properly
like in the background supersizer action modus, a blank white space at the
bottom appears.
TIM
I hope I understand your suggestion, but I am not sure if this is a
practical workaround. First I have to experiment in every page + media
width tabs the right size of the background picture. What an amount if I
have only 8-10 pages x 4 media width…
Every time the client changes textsizes/pagesizes I need to find out again
and open PS, resize the picture, export, import…
I was thinking that you’d consider the height of your longest page and select an image that would size to fit without scaling up.
Part of the issue I had with the example I did was that I chose a landscape format image so it scaled the image up (and excessively so) when the screen was narrow but high. You can correct this by telling the browser to load a larger image when the screen exceeds the size of the image but, as far as I know, you’ll have to do this manually as Freeway only writes the breakpoint CSS based on the screen width.
Drag the browser window down to the smallest size you can (my Safari goes down to roughly 392 x 170) and then start to drag the widow taller. When you exceed the size of the current image (720 pixels) it should change to the next image size up (1152 pixels). If you wanted to you could stack any number of images in the site and have each load depending on the available browser width and height.
Personally I think I’d be inclined to load the site with three versions of each image and target these at mobile, tablet/laptop and desktop displays. If you squeeze the images as far as you dare and deliver the page in a compressed format then you shouldn’t see the site slow down too much. Also one an image has been downloaded the browser will serve the next instance of it from the cache which will dramatically improve the page performance. If you keep the mobile breakpoint image the same throughout the site the image will get loaded from the cache on every subsequent page on the site.
Regards,
Tim.
On 12 Nov 2014, at 16:39, sonjanna wrote:
I hope I understand your suggestion, but I am not sure if this is a practical workaround. First I have to experiment in every page + media width tabs the right size of the background picture. What an amount if I have only 8-10 pages x 4 media width…
Every time the client changes textsizes/pagesizes I need to find out again and open PS, resize the picture, export, import…
interesting. The second link seems to be the same principel like the background supersizer action. The other one outruns my coding knowledge ;). But yes, there are plugins found in Google…
Many actions/scripts/extensions are updated or better written versions of
earlier scripts. They require smart knowledge of coding which I don’t own
either. So I google a lot…
Op 12 nov. 2014 19:29 schreef “sonjanna” email@hidden:
Thanks Andries,
interesting. The second link seems to be the same principel like the
background supersizer action. The other one outruns my coding knowledge ;).
But yes, there are plugins found in Google…