For queries that Google interprets as pertaining to shopping, it populates a horizontal banner w/ (5 or so) sponsored product images # the top of the search results page (before listing any actual hits).
I use Dark Reader a lot & try to contribute by fixing any especially ugly automated inversions (as the creator merges user modifications daily) as I notice them.
Yesterday, I noticed that some of the aforementioned images were barely visible, I figured that they were mistakenly inverted so I inverted them once more to discover that I was wrong. After disabling Dark Reader, & following a few of the image links, I found that they were purposely made transparent (as in the actual pictures, NOT just the backgrounds). I saved & added a layer behind 1 of them, to illustrate my point...
If they only cut out the backgrounds & left the rest of the images alone, wouldn't the file sizes (& therefore the storage costs) be minimized?
Do they save money in some other way? Or are there any other reasons for why Google would serve images this way?
Related
I'm working in a project of building a responsive website. The painful thing we're having is to deal with the content of the image in different display modes. Please be noted: the image content.
The thing is: in almost pages at PC view, the images are displayed in landscape, with great ratio between width and height. Now when bringing them to mobile view, we have to display it in a different frame. And as you might imagine, now the content of the image was scaled and cropped and then exported to some very weird images on mobile view. Like a wide picture with people are almost in left side, but after being cropped there are only non-sense objects in the picture left.
IMHO, via technical solutions we are only processing the technical attributes of the image (resizing, scaling), we are unable to deal with the image content, that's really a human matter, right?
I'm thinking about 4 solutions:
1 - Despite the customer feelings, we just scale the picture (keep
all content, just resizing it). The output sometimes will be very
ridiculous I guess because of resizing a landscape picture to a
portrait or square one. But that's mostly the easiest way to come up.
2 - Considering to image frame size on mobile view, and auto crop the
picture by picking the center area of the picture. As I said above,
it produced the non-sense picture after all.
3 - Informing customer, whenever they upload a picture, they have to upload 2 copies of it, 1 for desktop view and 1 for mobile view, and they're definitely responsible for the content displaying at front side. Tons of effort need to be spent by customers, but easier for development.
4 - Advanced feature: user can upload only 1 picture, we provide the
different view-ports and a cropper for them to decide how the image
displays on those after being cropped.
I don't have much experience in dealing with these stuff, and not sure how the world out there handling this case. As I see for now Wordpress is only requiring users to upload only 1 picture and it will automatically scale it (my 1st option). Does anyone have experience on this? Can you please share me your solutions and also your thoughts about my above solutions? Thank you.
you can build a simple web application for them to upload the picture and provide your client with a preview of how the pictures with look like for both desktop and mobile. in php, there is the GD library and it is quite easy to use for cropping and resizing.
Apply the 4th and the 1st option so you don't have to deal with it,
Crop and scale with the options you have AND let the customer decide if they want to change it and choose how the image is been displayed.
in case they ask you can say they have the option to fix it, in case they don't want to you already handle the best technological option.
All:
I'm trying to configure a website I administer to be pinnable in Windows 8.1/IE11 with a live tile. The first time I went through http://www.buildmypinnedsite.com and it's documentation and provided the RSS feed, I noticed with some surprise that one of the articles in the RSS feed (the only one which had images in the content) actually used one of the images as a background for the live tile (when that article was displayed), with smaller text at the bottom of the tile, over a translucent dark background.
Check the last image at http://blog.laptopmag.com/how-to-create-a-windows-8-1-live-tile-for-your-website for an example. That article mentions, "as long as your RSS feed has images in it, the tile will rotate through your most recent five articles with images".
I really liked the look of using images instead of a solid color and plain text, so since all my articles have a banner image associated with them in our CMS (though not necessarily actually in the content), I updated the RSS feed to include an <img> tag at the top of the content (<description>) embedding the banner right at the top of the content. I also added the banner as an <enclosure> on each <item>. I added some padding characters to the GUIDs so that it would see the content as "new", but the live tile continued showing four articles with just text and a colored background, and the single article with the same background image.
Several weeks have now passed, lots of new articles posted, and yet still the live tile continues to cycle through the articles just showing text.
Windows 8 prepare site for pinning has lots of good information and links to documentation, which I've gone through, but I can't find any more information about how the images should be "included" in the feed in order for them to be pulled in as backgrounds. Am I missing it somewhere?
Thanks for your time and help!
P.S. The <description> field in my XML contains the full article HTML (just the article, no sidebars, headers, etc of course), wrapped in a <![CDATA[]]> tag, in case you're wondering.
I'm looking into this exact problem too (the main difference: I've a partial feed, not a full-content one).
The only reference I could find is msapplication-TileImage http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx#msapplication-TileImage :
<meta name="msapplication-TileImage" content="images\tileimage.jpg">
This, of course, is just a suboptimal "one image for all" solution.
Ok, I finally got it right.
The key (thanks #james3mg ) was to drop the RSS-based approach completely and go for IE11 specific XML of the tiles feature.
So I used this:
<meta name="msapplication-notification"
content="frequency=60;
polling-uri={$SiteURL}tiles/1;id=1;
polling-uri2={$SiteURL}tiles/2;id=2;
polling-uri3={$SiteURL}tiles/3;id=3;
polling-uri4={$SiteURL}tiles/4;id=4;
polling-uri5={$SiteURL}tiles/5;id=5;
cycle=1"/>
You can see those XML here :
turbolab.it/tiles/1
turbolab.it/tiles/2
turbolab.it/tiles/3
turbolab.it/tiles/4
turbolab.it/tiles/5
The complete list of the available template is here: The tile template catalog (Windows Store apps)
I want a header image in my HTML to be random. I have accomplished this by using this php file, however I would like to do something different. I want to have the random images be a part of one sprite. That way the images can all load at the same time and they user won't have to see the images load when navigating to different pages. I would also like to choose the random factor, i.e. show this picture 50% the others 10% of the time (if there are 6 pictures). Is this even possible and where would an amateur start? Is this the best way to implement my scenario so that the user sees as little image load as possible?
You could have the sprited header style declared in CSS as you normally would, and then simply adjust the xpos/ypos of the sprite in-html. You would be able to recycle some of the logic you already have and manipulate individual header probability.
I'd stick with individual assets though, especially if they are the size of a google doodle. Easier to extend that way and, assuming the rest of your static content has already been cached, any overhead of downloading a new image would be negligible.
I'm looking for good articles around image resolutions, size and quality for web pages, especially around how this affects web sites currently.
I'm working on a web site for a client, and as an honour graduate in arts and design, the client is persistent that her 7mb - 10mb images are sufficient for her web site, totalling in at almost 400mb. I've tried arguing bandwidth limitations and performance but these are not holding ground.
The standard for images are at 72dpi, no larger than your standard screen resolution (1024x768) and above 1mb in size (which is already too large in my opinion). my argument is that loading 7mb+ files into a gallery on page load will seriously hinder the users experience if they have to wait a long period of time for 7 - 10 images to first get streamed into cache before the page is loaded, and even testing this with lazy loading plug-ins (we don't want to go flash) and late-loading has performance penalties.
Does anyone on here have any recommendation around image size, resolution and quality? We don't want to loose the HD quality of the images when users navigate the gallery (obviously we'll have to thumbnail them first)?
i have read guidelines before (when we still used 1Mbps connections or less) and have been following these until now:
high resolution images should not be bigger than 1.5 - 2MB. making it this big is like bigger than the webpage contents itself. try checking http://deviantart.com on how they place big photos in their site and check the image properties using the EXIF if any
dimensions should be enough to be viewable in the browser (and avoid scrolling)
compression is to be tested. it's a case to case basis, no setting is the same for everyone. high quality, high compression without visible quality loss is a practice in web design.
JPEG is best for images, PNG for the layout and GIF for icons.
try loading images in the background when the browser is idle using javascript. that way, they are in the cache before the user knows it.
more on the webpage design, avoid using heavy graphics on the site itself, making the site fast so we only wait for the image.
If you really boil it down you don't have a choice.
You are talking about HUGE file sizes which are not realistic.
You need to download a smaller version. After that you can subsequently download versions with increased quality or offer the full image with an onmouseover or click.
Some general guidelines:
Thumbnails (of course)
Offer multiple image sizes (small, medium, large). While I understand the UX implications of giant images, some people do have fast connections and large displays and/or will be willing to wait for a high-resolution version. But it shouldn't be the only option.
Try different compression levels to see what works best for different sizes. Using one compression level across the board doesn't always work. Again (depending on the source material), there may be a need for near-lossless compression at the high end. For example, images for print, CAD drawings with fine detail, etc.
Use sequential loading techniques if applicable. For example, if you have ten images to load (optimized or not), make sure that the first visible one is the first one actually requested from the server.
When it comes down to it, your client is under the impression that asking to shrink her image represents a 'compromise' that only results in damaging the quality of the image the user receives.
The truth is, of course, that an 8-10MB image is so large that it would take most users many seconds to download, creating a horrible user experience that will increase bounce rates.
Show your client a side-by-side demo of her website loading a handful of web-optimized images, and show her a site loading 8-10MB images, then let her decide. Ultimately, your job as professional is to assist her in making good choices, but she's free to make bad ones if she insists upon it (it's her brand, money, and right).
Something else you can potentially do is detect the size of the window and load larger images if the user is on an ultra-high-resolution monitor or if the window appears to be especially large.
Best of luck!
I wonder what the best trade-off for combining images for CSS sprites is.
Say I have 50 images, but each page only needs 5. The total size of a sprite image is 100kb.
There obviously are a dozen of parameters, how many pages are visited in each visit, the connection speeds of the users, the lag. I'm not looking for a mathematical formula to compute the best trade-off, since I cannot estimate these parameters precisely enough.
So, do you have any experience values on when to combine images to a sprite and when not. (Actually, the "not" is more interesting IMHO).
Do you put all images on a sprite that "could" be needed for a single page, but anything that will only be needed by a second page on a separate sprite?
In my opinion, only group images together in a sprite if they are relevant.
If you have a menu based off of images, I'd make one image with all of the different elements in the menu. If you have a list with icons that appear on hover, make a spritesheet with all of those icons. It does you no good performance-wise to create one huge image when that same image can be combined into three or four smaller images.
It also helps to have only related images together - it keeps your CSS references to the files easier to follow and you have less complex x/y coordinate references.
here is my two cents... I usually try to sprite images for a given path that i am expecting to be hit harder then others. For example; if my sites so i call the critical path is: user logs on, goes to the home page, checks out today's deals, purchase one and logs out, i would like most of the common images sprited (logically grouped if needed) on this path. Having the sprites here will eliminate a lot of extra requests.
If you go google.com you will see a sprite (nav_logo99.png) that has most of the common images you will need on the very likely next page(s).
Also to answer your "when not to sprite", background repeat and CSS sprites does not blend well so i will stay away from those.
The thing I take into account is how many pages my user will visit. You have to remember that you sprite will normally be cached so only ever loaded once.
If your site user runs around a few pages then its fine having a larger file but you are correct if most off your users only visit your home page then your not going to want to load all your sites images in one sprite.
Its best to just go on your own feel off what is best to optimize into sprites