Workflow Recommendations for Designing Webpages and Assets

Question
1

I’m writing to request recommendations for the best workflow using Affinity apps to design Webpages, and then to export 1x, 2x and 3x raster assets.

It’s my understanding that the W3C has established a theoretical, device independent, CSS reference pixel grid that designers can work to with a pixel density that is 96 ppi, where the various mobile and desktop devices that end up displaying the Webpages will apply a relevant Device Pixel Ratio (1x, 2x, or 3x) to scale the Webpage type, layout and imagery up to cover the actual Device Pixels.

If I understand the situation correctly, I should begin my Webpage designs by opening up an Affinity Designer document at 96 ppi (DPI) with artboards that match the pixel dimensions of my target page (e.g., 1042 x 600), and then use the Export Persona to export assets out at 1x, 2x, and 3x. Does that sound right?

And what about some instances of raster art, like a hero image. Should I work in the opposite direction (i.e., from an Affinity Photo document with triple the dimensions and resolution: 288 ppi), and then export downsampled 2x and 1x versions?

What works best for all you Web designers?

2

@mOehlschlager, Are you aware that in Sparkle you can ask it to pump out 1x, 2x, and 3x your images you place on the canvas? Under Settings / Images. I believe this is similar to what you are mentioning about the pixel density. Duncan makes mention of optimising images in his documentation - https://sparkleapp.com/docs/images.html

3

Sorry not sure what the device independent pixel grid is. Measurement units that mix in physical space are kind of meaningless on the web. DPI, PPI, etc. Only pixels are relevant.

As @FlaminFig says, Sparkle will produce all assets for you.

If you don’t want to think about it, you just can give Sparkle a relatively large image, and Sparkle will produce the different sizes.

However the additional gotcha is that this applies to the size on each device, so a single source image explodes to potentially 15 different image sizes. If you have the webp option checked, that’s 15 jpeg’s and 15 webp’s.

4

@duncan and @FlaminFig,

Thanks for your replies. If I understand you both correctly, Sparkle solves my problem provided that I place raster images with sufficient pixel dimensions that Sparkle can generate 1x, 2x, and 3x alternate images. Is that correct?

To make my original concern clear, It’s my understanding that W3C has addressed the problem of designing for the myriad device displays out there with countless variations of device pixel densities, by letting the CSS pixel unit be defined by a theoretical reference pixel unit – defined by an angular measurement where 1 pixel is equal to 1/96th of an inch as viewed on a display held at arms length (about 28 inches). So, the density of this theoretical CSS pixel would be 96 ppi.

Further, I understand that the browsers and OS’s of the myriad mobile devices out there communicate their unique Device Pixel Ratio (1x, 2x, or 3x) such that Webpages with dimensions specified in CSS px units will be scaled up appropriately to compensate for the higher number of device pixels, thus preventing Webpages from appearing to be too small. So, an image that is specified to display at 100px by 200px (CSS pixel units) would be scaled up on a 2x device to cover 200px by 400px (Device pixels).

If I understand how Sparkle works, one lays out a Webpage in a 1x scale environment, and then, when placing raster images, if one places a raster image with sufficient pixel dimensions 3x the placed size of the image on the page, then Sparkle will generate the alternative 1x, 2x, and 3x versions of the image and serve the correct image to the various 1x, 2x, and 3x device displays out in the wild. Is that correct?

5

@mOehlschlager, Ok you are being very thorough here!

I think more the issue out there is that people are just throwing images onto their web page and letting the likes of WordPress (there are 1000’s others) do the rest and never checking what has been spat out! Then there is the constant changing of screen size, screen density, and the likes of Google and W3C changing things in the background so there is no science behind all of this.

I have pegged back from fluid responsive design to Sparkle’s adaptive responsive design and for the most part I can see how it will be presented though my testing of differing devices before I publish. So far Sparkle is doing a great job (I place a min. of 4400px hero images) because I have had no complaints of image quality or pixelation from my clients.

By placing a large and good quality image on the Sparkle canvas and having selected 1x, 2x, 3x Sparkle goes into bat for me and as @duncan mentions will generate the image assets my website will need in the wild to make a user’s visual experience the best it can be.

6

I’m not really sure what the W3C says about this, WHATWG is the working group for HTML5, but regardless I think you are overthinking it.

There’s no consideration about something appearing “too small”, that’s an intrinsic property of the device, meaning the whole arm’s length reasoning is part of the design of the device and screen size. For example Apple’s desktop screens are consistently in the 110 dpi or 220 dpi ranges, respectively for non-retina and retina. Apple’s mobile screens are in the 163 dpi, 326 dpi or 400+ dpi ranges for non retina, retina and super retina/liquid retina.

From the web page point of view there are just screen points (not to be confused with text measurement units, which are pretty messy). Each screen point is a single pixel on a non retina screen, or 2x2 pixels on a retina/hi-dpi screen.

There are various techniques to send the images to the device to get best performance, compatibility and quality/crispness. Sparkle takes care of generating the images at the best compression ratio, at the optimal size and with the proper “responsive image” setup in HTML, CSS and JS. It is a pretty complex topic and spans progressive enhancement, accessibility, compression and page load performance matters. We have put a tremendous amount of energy into making this work right, and while there is some wiggle room for improvement we’re very happy with the current setup.

From the Sparkle user point of view there’s one metric for handing Sparkle the correct image, for the time being only visible in the image element settings. We hope to add it in the box background image settings as well.

That’s the “resolution meter”, which tells you how much leeway you have, for example here I dropped a relatively small image on the canvas, the image settings says this:

image

this means the image won’t really be very good in 2x. Though if I make the image frame smaller in the canvas, the resolution meter will go up, you can actually see the resolution meter move as you resize the image frame in the canvas:

image

Here I dropped a huge image on the canvas:

image

What this means is the image will always be a good source for generated images of any size (at the current canvas frame size).

So the conclusion of all this is:

  • by dropping a pretty large image in the canvas I have the flexibility to resize it freely, so it’s generally best not to export artwork from a design app at the exact final size
  • the above is even more true if you consider that if you design in a multi-device setup, at the 960 device size the frame will have one size, but at the 1200 device size the frame will be larger, so you need “more pixels” from the source image
  • if you drop the biggest and largest image size you have, maybe too large for even the 3x density on the largest device, that larger image will be part of the Sparkle file and will make it bulkier… this adds up, so not a problem for an average project, but maybe something to think about if you have an image heavy and large project file

Full width images on box backgrounds need slightly more consideration because as mentioned Sparkle doesn’t yet show the resolution meter for those, and by stretching the image you need a little more source material. @FlaminFig’s suggestion of 4400px is good if maybe slightly over what Sparkle will generate, but having the source image be higher res is good.

Finally, it’s generally unnecessary to have Sparkle generate 3x images, the perceived quality improvement is usually very minor.

3 Likes
7

@duncan

Thank you for the detailed response.

You wrote: “There’s no consideration about something appearing “too small”, that’s an intrinsic property of the device, meaning the whole arm’s length reasoning is part of the design of the device and screen size. … From the web page point of view there are just screen points (not to be confused with text measurement units, which are pretty messy). Each screen point is a single pixel on a non retina screen, or 2x2 pixels on a retina/hi-dpi screen.”

I understand your reference to “screen points” to be analogous to the CSS reference pixel (i.e., a base unit of measurement from an assumed 1x display raster density), and that the device’s self-reported Device Pixel Ratio (1x, 2x, and 3x) is what determines whether or not a “screen point” corresponds to a single device pixel, or to 2x2 device pixels, or to 3x3 device pixels.

I assume that this scaling of webpage elements is an automatic function of the rendering engine of the device, applying it’s Device Pixel Ratio to the supplied CSS coding (i.e., an iPhone 8 will automatically map a 10x10 CSS pixel box element to 20x20 device pixels, and an iPhone 8 Plus will map the 10x10 box element to 30x30 device pixels).

And then regarding raster images linked to the webpage, the HTML and JS code generated by Sparkle will query the device for it’s Device Pixel Ratio (1x, 2x, 3x) and then supply the correctly sized raster image for the device’s device pixel density.

Is that correct?

I love the graphic “resolution meter” for images in Sparkle. Thank you for that feature. I’m glad to hear that you plan to make that available to box elements with image backgrounds.

One final question related to the “resolution meter” and the 1x, 2x, 3x image generation feature of Sparkle:

If a user supplies an image that is only sufficient for 1x display, and the user has gone into the Sparkle settings and indicated a preference to generate 1x, 2x, and 3x images, will Sparkle upsample the 1x image, or will Sparkle generate just the 1x version and decline to generate the 2x and 3x versions?

Thanks,
Mark

8

Something like that. High performance requires a declarative style, so HTML (for images) or CSS (for box backgrounds) contain all the images, and the browser will pick the right one based on knowing the device features.

Upsampling is left to the browser, so the 1x is sent when the source image doesn’t contain enough pixels for 2x and 3x. No additional information is added when upscaling, but the image sizes grow, so it would be just wasteful to send upscaled images.

1 Like