If you click on Kitchen 1 at RealDealKitchens.Com you will be presented with 20+ pictures in a scrollable format.
These pictures live inside a SITE IMAGE by YourHead Software that lives inside a CONTAINER by Foundry. All of the containers live inside a LINKBOX by Stacks 4 Stacks.
The LinkBox is pretty cool. You can click anywhere you want on the page and this will take you to an Annotated Version of Kitchen 1.
This is the page where you get some training germane to the images you saw on Kitchen 1.
I have set it up this way because wading through all this text is tedious on a smart phone if you are just trying to find Picture 5.
I think what I would like to see is something similar to this LinkBox albeit with an anchor point built in that could take you a specific spot on the second page.
QUESTION 1: Does using a two page format like this create duplicative resources that would engender SEO penalties? My understanding from a Yourhead video is that SITE IMAGES minimize occurrences of resources within the software we use to build the site. Does this also extend to resources served on a browser?
QUESTION 2: Does anybody know of any image stacks that also constitute clickable links to specific parts of a web page ( I think this is called an anchor)?
QUESTION 3: If you were buying a kitchen from me how would you like to have the information served to you? Would you want to have an abbreviated page that just shows you pictures or would you want the images organized like an information kiosk at the zoo?
Just one thing that you maybe need to be aware of, if you are not already; the link you supplied takes the visitor to a page which is more than a 9Mb heavy. That’s a lot.
The page is slow to load and mobile users will hate you for it.
You are on the right track by thinking about the user experience and how your site can help you to craft a more effective customer interaction, but that starts right at the beginning with making your pages fast to load on devices and simple to process visually with very little cognition required on the part of the visitor. Quote often the less you give them to do the more they’ll do it…
I can answer question #1: As long as you use Site Images then there will only be a single image published to your site – so all the SEO will be focused on that images one URL. That’s probably a good thing – although page-rank is a bit of a black-art, no one really knows what helps for sure, but more links (especially from external sites) are generally a good thing.
I’m afraid I don’t know the answer to question 2 – and I’m fortunate enough not to be in the market for a new kitchen makeover.
If you useLinkBox with AnchorPoint (link above) I think you can get to what you want.
Put each picture (site image) into its own LinkBox.
on the second page put AnchorPoint stacks above each picture, give them a unique Anchor name
on the first page you will need to set the link in LinkBox to go to the anchor point on the second page.
The easiest way would be to link to the full URL and then add the # with the anchor name
The Instructions are given right in the Anchor point stack
The sales cycle for prospective customers is going to be different than “training” customers or going over details for pre-sales and post-sales support.
A.I.D.A. Sales Model
Aware - Customers must be made aware of the product Interest - You need to make the customers develop an interest Desire - You then need to create a desire for the product (trust) Action - Make sure the customer can easily take action
Thanks for that input Indrid. I was wondering about that. I’m not savvy enough to source (or interpret) a diagnostic chart such as you included.
The 37 images on that first page are a replication of my current iWeb site that seems to load relatively fast. Those images were run through a compression filter called “Webcrusher”. This new test site runs them through an image compressor called “Squashed”.
What would you do differently to enhance load speed? Are there just too many images or are they too big?
My current thinking is that I was supposed to reproduce every URL (70+) that exist on my current site in order to maintain the continuity of links (from external sites) that I have built up over the years. There are several kitchens in that gallery that I would ordinarily jettison except for this mandate.
I get a lot of external traffic from places like Pinterest. A lot of my images are also credited on blogs about kitchens from the 1920’s etc.
My thinking was that when the new site was completely rebuilt (and all the redirects in place) I would terrorize the Pinterest community. Those guys are complete anarchists and I think would pingpong the images around a lot to my benefit.
Should I break these into several smaller galleries that launch from a smaller gallery initiallly?
One thought that just occurred is that activating LINKBOX is not intuitive. You have to click on the image pretty decisively in order for a mobile device to disassociate it from a swipe.
Which is, of course, not “simple to process visually with very little cognition required on the part of the visitor” as per IndridCold’s admonishment above.
Thanks Doug for the Anchor Data. I will look at that closely as soon as I have more time.
You are right about the difference between educating customers and selling to them.
I educate a lot more customers than I ever sell to.
Is amazing though how many of the ones I talk with have read every word on my site.
I only sell direct to end users. I do not sell anything through general contractors.
My typical customer will stay up till midnight in their pajamas going over Pinterest because they really really want to get it right and they are hungry for information.
Contractors on the other hand very rarely ever even look at the site. They don’t like to be inconvenienced in any way.
I want to clarify something: Site Images only publish ONE single image to the website.
This is not just to minimize resource load when building a site but it actually minimizes how much image data travels back and forth between the website user and the server?
Correct. The most important part of it is that when you use the exact same image on multiple pages, the web browser will just display the ones on the 2nd and 3rd pages they visit from it’s cache and it will not download it again. Those pages load much, much quicker.
I would use a smaller (thumbnail) versions of the images on the kitchen overview page. If the images are only going to be displayed at a max width of 250px on this page, then only use images that are 250px wide. Loading all of those at 1200px causes too much download data.
Use the full-size images on that kitchen’s detail page. If you use a gallery on that kitchen’s detail page, that page will load quickly too. It’s not until they actually want to see a few larger images (from the gallery) that you even download the full-size images.
You are going to want two image sizes. Thumbnails that are probably 250px wide, and your full-size versions that are 1200+ px wide.
This is sound advice. There may be a small advantage to having a single image on the multiple pages – but a faster loading primary page is worth way way more.
How were you able to ascertain that my images were 250px wide?
Is there a RapidWeaver Analytics page somewhere that provides this information? I have not gotten around yet to looking into this. RealDealKitchens.com is hosted on Chillidog. I wonder if they have something like this?
This segues into another post that’s been rattling around in my head. Sometime ago I posted about how to make all of my images appear symmetric on the grid and it was suggested that I handle this with my Lightroom Export.
So the protocol I have been using for the gallery page is to export a 4X5 image which is then compressed with the Squash. I picked 4x5 because anecdotal information suggested that was a standard size for Instagram.
I have few thousand images archived in various hard drives. Many of these were from my early days in photography. I didn’t really know anything about any kind of camera back then but was smart enough to capture everything in RAW. A lot of these images are shots that have been rescued in post processing.
Part of me thinks there will one day be an Instagram campaign in my future. I figured that while I was cleaning up the images I would try to build a library of data to make that a sustainable endeavor. That world seems to be ruthless in it’s expectation for new content and I figure I could make a stand recycling 1000 images.
It’s probably beyond the scope of this forum but if anybody can suggest where to learn more about Instagram requirements I would be most appreciative.
Thanks again for the heads up about pixel size.
I will look into that when I have more time.
So images of different sizes constitute different images from the perspective of Site Images
I am guessing Site Image differentiates images by file name.
Some of my hard drives got corrupted over the years and the naming conventions are all mangled.
My thinking was to name each image according to Kitchen Number and Position on the Page. So there would be
1-1.jpeg
1-2.jpeg
1-3.jpeg
7-1.jpeg
7-2.jpeg
etc
Is this a viable naming convention for Site Image?
I first checked to see the size the images you were loading and saw they were all 1200px. You’re displaying them 4 per row inside a container that’s 1140 px wide, so I knew there’re being shown much smaller than that.
Using Safari Developer Tools, I right-clicked on an image and looked to see what size it’s shown at. I just rounded to 250px.
You can enable developed tools in Safari’s Advanced settings (Show Develop menu in menu bar). You can see your images and the size of the files that are being downloaded on the Resources tab in developer tools.
A Site Image is very simple and has no smarts built-in at all. A Site Image is just a link to the Image Resource in your RapidWeaver project. Your project resources get published without resizing or modification.
This means that if 3 different pages use Site Images that display the same image – that image will just get uploaded once to your projects resources folder on the web-host – and each page will just link to that single location.
Is this a viable naming convention for Site Image?
From my experience, file names contribute nearly nothing to your page rank. Although I’m not certain it’s absolutely zero, I am certain it’s awfully close. The links to the images and if the images themselves are linked – the text inside of those links and immediately surrounding those links is very very important. That text is how Google decides what is in the images and whether it’s an important part of the web page.
Which is to say – any file naming convention that works for you is probably fine. My personal feeling is that consistency is the only real important bit.
Stacks doesn’t actually publish these images, your RapidWeaver project handles that bit. So any file naming conventions would have to be handled there. Stacks merely links to the files that the project publishes.
As far as I’m aware RapidWeaver treats image file names as-is – only modifying them to make them more web-friendly, like removing disallowed characters.
You can change the resource properties in the RapidWeaver Resources window. Try opening the Resources Window and right-clicking (or ctrl-clicking) on one of the resources.
