Image Size Best Practices?

RapidWeaver Classic General
1

I’ve been working at re-doing a site, and it occurred to me that maybe my approach was wrong in regard to images. The problem I was having is that some images display too small, others display too big, etc. Then I wanted to use SVG because it is so much cleaner. And click, something said, “Why aren’t I using consistent sizing for everything?”

Of course, everything gets displayed differently (phone, tablet, laptop, desktop), but within any browser there are only limited choices: full width, 2 column, 3 column, 4 column, 5 column. But given that uniformity, shouldn’t we be using that to our advantage? Maybe people are already doing that, and I am just a little slow?

So I guess my question is do people use a rule of thumb for the size of all their images? Should they/can they be created at X width so that whatever we use where, the conversion to the different displays is consistent and predictable, so there is less need to blindly set dimensions in the setting?

Separately, given we are all Mac users, and what makes a Mac a Mac is its consistency, shouldn’t all stacks share the same basic baseline controls? I realize that may be hard for Dan to dictate, but he could set a standard for what stacks should have and flag those that don’t. An ISO 9000 for stacks?

I’m just thinking out loud for some of this.

I find it strange that SVG’s export out of Affinity Designer without any dimensions, but the file size can be different. I am struggling with getting them to display at a preferred size, especially when checking the format on different display. So while it looks clean, aesthetically, the scale is all over the place. Is this a problem with the stack, the theme, or the image itself? I am wondering how others deal with these issues. I assume I am misunderstanding something. thx

2

Mac’s aren’t really consistent. You have 12” notebooks to 27” desktops. You have HD displays(aka retina) and standard displays. You also have Mac mini’s and Mac Pro’s that can have any type of display out there.

Dan has really nothing to do with stacks, separate companies different people. I for one don’t want the “stacks police” setting standards for breakpoints or column sizes. That’s the biggest advantage to RW is the freedom of choice with 3rd party vendors.

When it comes to image sizes, you’re probably designing for more than Mac’s or even Apple. The sizes and types of devices browsing the Internet is literally undefinable and changing all the time.

It’s really not the browser that limits those choices, but the design you choose. I can’t think of ever using 5 columns, but others might have a need and what about masonry design that doesn’t conform to the standard column sizes? What about 4K or 5K displays? Don’t forget even higher density’s aren’t far off.

As for a rule of thumb, there’s people that can tell you what “they do” but it’s not going to be a one size fits all rule. A photographer or graphics designer is going to probably be more concerned about quality than speed and may want to support separate images for the higher density displays. A sight that’s using images as simply supporting the text, background or filling empty space will be more concerned with page speed.

Of course loading an image wider than the maximum size it can be displayed in, is just a waste of bandwidth.

1 Like
3

Hi Doug,
I don’t want Stack police either, but what I meant by consistency is that all Apple capable software shares a common menubar. File>Edit>View etc. There is some variation, but generally all the same controls are in the same place. Stacks are somewhat consistent too, Borders, background image etc., are all in the same place. I was thinking more along the lines of if the image is a stack image, then it should have XYZ functionality. I realize that Realmac has enough to do without controlling others, of course, but given how collaborative the community is, maybe it could develop some sort of best practices within themselves. I was just bringing up the idea.

I’m not sure I agree that the display determines anything of consequence. I agree 5 columns must be rare, and we can design for 3 but it will end up as 1 on a phone. That really was my point. The screen is like a gallon bucket. It will only ever hold a gallon, so the top, bottom, left, right are somewhat predictable, no matter how you stir the elements, they are still in the bucket. Using that can be an automatic advantage. Of course, I have seen sites where you can scroll left and right forever, or up and down forever. They are great fun.

My biggest challenge is that SVG controls don’t seem to exist or be as robust as the controls for jpg’s etc. And there doesn’t seem to be a way to control the size of the SVG when creating it, which is a weird problem given its scalability. It looks perfect, but it’s the wrong size. Jpgs are the right size, but look dodgy. I do wonder if a different theme would make a difference, but the SVG stacks themselves seem underpowered.

1 Like
4

And you have that with RapidWeaver.

That’s true for some stacks. Take a look at the latest from Joe Workman Foundation 6. The hundreds of stacks within that framework don’t have those controls. Why? How often do you change the background or add a border or hide and show the content of a stack? Not very often, but the stacks page must interpret those controls every time you preview or publish the page. That slows down stacks pages for controls that aren’t used very often. The stacks page also wraps each stack with two <div> wrappers to allow those controls, cluttering up the DOM, and burying the content deeper, slowing page load.

Not sure I follow, A iPhone SE is going to hold a lot less than a 27 inch iMac, that’s the point of responsive design. You need to adapt to every possible screen size.

SVG’s aren’t like other images. Scalable Vector Graphics are an XML based markup; they are written instructions to the browser (or other programs) on how to draw the pictures. If those instructions have set sizes then they won’t easily scale.

You can open up an SVG with a text editor and actually change the markup if you were to know-how. It’s just a plain text file so most standard image stacks won’t handle an SVG type image.

There are a couple that I can think of that handle inline SVG’s very well. Source has an SVG stack as well as Foundations 6.

5

BWD has an SVG stack that is adjustable too as part of BluePrint

6

Thank You Doug and anugyan!

I had never heard of Source or BluePrint. I’m learning a lot.

7

Source is a mostly free mini framework.

The basic stacks and theme are free. There’s also some addon stacks that can be purchased.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.