New Landing How can we help? Atelier The Long and Short of It

Viewing 6 posts - 1 through 6 (of 6 total)
  • Posted in: Atelier
  • #211379
    alibey
    Member
    Post count: 179

    I decided to have my woocommerce catalog images set at 640 x 400 px with no crop

    I also had my product thumbnails set at 120 x 75 px with no crop

    These dimensions appear, however, to be completely ignored by Atelier — as Atelier overwrites them (or so it appears) with its own image sizes.

    The product pics I display are needlepoint canvases
    They have to be large, as anything smaller than 1200px wide (usually 700px or so h) suffers
    from the moire problem that is endemic to mesh-related images
    this means that the Atelier image setting is too small for my purposes
    of course I run my image through tinypng before loading, btw so the hit is not too bad, they are usually less than 300 kb each

    However, I have found that setting the Theme Options → Shop to 2 columns works okay with most of my pics

    but this does not work well at all with those few canvases that are much larger vertically than horizontally

    for example I have an image of a Bengali Tiger that is around 300 px w and 1200 high

    this looks okay in the product page (for the Bengali tiger, obviously)
    but it gets cropped in the catalog page, so that all you see is the middle part of the image

    I have the thumbnail regenerate plugin and specifically reran it against this tiger pic

    However, what is happening is that the catalog image pic is getting cropped (when I would have expected it to fit nicely in a resized way into the 640 x 400 bucket I specified) — so it appears then that thumbnails are only used in the gallery view, which i do not use

    As a result, I am more than a little confused by how the Woocommerce product display settings work in relation to the image settings seen in the catalog (I have also noticed that many other users have this difficulty)

    Essentially, what I want to have happen is that responsive image for the catalog be generated that includes the ENTIRE tiger pic, resized proportionally, and be able to directtelelier or Woocommerce or whatever to use that image specifically (which may be different from an image I wish to use on the product page, in terms of size)

    On a side note, is it necessary to “Add Media” a product pic in an administrative Product page?

    It seems the woocommerce / atelier catalog picks up only the Featured Image, so including one in the main panel (of the Product Admin Page) seems redundant and serves no useful apparent purpose, but as usual I am never really sure if this is a woocommerce or atelier thing… then again, I could be completely missing something CRUCIAL in all of this

    so… to recap… how can I ensure that the Bengali Tiger appears resized proportionally within the standard Atelier image bucket for a two or three (or whatever) column catalog page (given that this is a narrow portrait-style image)?

    Many thanks. Your kind help is always appreciated!

    ps you can see what I am talking about here

    needlepoint.land
    id test
    pwd @%#4ezL8h3dzD!tvIp^9Hf&d

    #211606
    alibey
    Member
    Post count: 179

    ?

    #211859
    alibey
    Member
    Post count: 179

    given the lack of response, i will restate this question more succinctly, so i am closing the topic.

    #212296
    David Martin – Support
    Moderator
    Post count: 20834

    Hi,

    Apologies for the late response, when you update a ticket it get’s pushed back up the list and we answer the older tickets first.

    What display type are you using to show your products? The aspect ratio of the uploaded images will indeed mean their size can be different for different columns/browser widths and product display types.

    For example the masonry display will dynamically try to resize your uploaded issue depending on what thumbnail size you choose.

    `if ( $masonry_thumb_size == “large” ) {
    $classes[] = ‘col-sm-6 size-large’;
    $width = ‘col-sm-6’;
    $thumb_width = 800;
    $thumb_height = 650;
    } else if ( $masonry_thumb_size == “tall” ) {
    $classes[] = ‘col-sm-3 size-tall’;
    $width = ‘col-sm-3’;
    $thumb_width = 400;
    $thumb_height = 800;
    } else {
    $classes[] = ‘col-sm-3 size-standard’;
    $width = ‘col-sm-3’;
    $thumb_width = 400;
    $thumb_height = 320;
    }`

    If you would like your entire image to be displayed, can you check you do not have the “Hard Crop” setting enabled within the WooCommerce => Settings => Product => Display settings?

    The “Add Media” button on products is something we do not alter/control with the theme.

    Thanks,
    David.

    #212379
    alibey
    Member
    Post count: 179

    the issue of Atelier/Woocommerce image sizes was rather confusing for a long time. i was not sure at first how these were being controlled exactly. using firebug and constantly resizing my browser window for the catalog and product and home pages eventually helped me identify more or less exactly what was going on behind the scenes.

    my main problem is that my client’s product pages all have a mesh background. this lead to a moire effect (ie, pics having an ugly sooty wavy background), unless careful steps were taken in (a) taking the photo itself and (b) how it is resized (moire can be introduced in pics that are originally non moire but can become so when sized down, due to extremely technical reasons involving how digital cameras work in general and how different brands and models try using various techniques to handle / reduce moire).

    In addition, these products all have wildly different sizes. some are very tall and skinny, some are very short and fat, some are round, and some are square. it was a requirement that the mesh under the painted design (these products are handpainted designs on 13 and 18 mesh canvases that are sold to needlepoint stitchers) and on the exposed (ie non painted) canvas show clearly in all pics in order to be attractive to the viewer/buyer.

    mesh clarity was highly dependent on “studio” light conditions and distance to the object being photographed — even minor differences in this led to the pics looking unattractively different from one another on the catalog page.

    i should emphasize here that my client’s products are individually hand crafted works of art, not, say, mass produced t-shirts, and required unusual level of attention in rendering images of them correctly and attractively while not sacrificing performance.

    my initial solution (which was to uniformly resize very large pics taken with a Samsung S5 under particular lighting condition to 1200px wide, save these in a PNG format — which I like to use due to its support of transparency and the fact that it is lossless — and leave the image settings as recommended in the Atelier documentation) did not work in terms of image placement issues on the woocommerce shop page.

    They just looked screwy (sometimes they were inappropriately cropped, sometimes they were blurry, sometimes they were gigantic, etc), and it was taking too much time to figure out the associated CSS controlling their display. I also do not particularly care for the overuse of !important to override native styling, with resultant code maintenance complexity, but that is another issue.

    In addition, the catalog became extremely slow after about 50 pics were loaded. Rendering a single product page was also became very slow, especially when it had to also display 3 or 4 “related” pics that were averaging 1MB each.

    Google Page Insight revealed issues with (sorry to mention this) woocommerce/atelier HTML/JS coding (in particular with JS non deferred script loading), but this I could not control. Essentially there was on average a 1.3 – 3 sec wait time as the HP waited for the scripts to load. This of course can be fixed using various techniques, but this was outside the scope of my project, and I did not want to touch any PHP or go through the hassle of creating child themes since my client is completely non technical, and I will not be around to fix things once the project goes live, as I am moving on to another project shortly.

    However, I worked extensively with Siteground (the hosting providers) to fine tune the server configuration, make sure no plugins were slowing things down (e.g., I got rid, alas, a plug in that allowed me to display the beautiful custom SVG logo I had developed for the client using Inkscape), but still the site was slow, and the images were displaying unevenly on the shop page — it was always unpredictable how a given canvas would end up being rendered.

    In addition, I was having problems with center-cropped thumbnails, and I had another puzzling problem involving two columns only being displayed when using Chrome in the shop page when I had specified 3 columns (this while working fine in IE, FF, and O) in Atelier shop options.

    So what I had to do was come up with a way to radically optimize my product images and have them appear uniformly on the shop and product pages in responsive mode.

    I finally came up with a solution that worked and solved most/all these problems, not perfectly, but well enough. I will summarize them here for any readers who spent, like me, days trying to figure this vexing problem out.

    1. Keep all pics in jpg format — PNG is just too heavy for a catalog consisting of large pics
    2. resize all pics using gimp to be 600px wide.
    3. for pics that are very tall (ie, whose height greatly exceeds their width), or very wide, resize to fit using gimp, on a white 600 x 600 background layer. meaning, add a layer of a proportionally resized product pic above the background layer, then merge down.
    4. Set the shop and product woocommerce sizes to 600 by 600 px and the thumbnails to 120 by 120, with hard crop checked. you do this by going woocommerce –> setting –> product –> display
    5. run each original ~3000px w pic through http://jpeg-optimizer.com/ — set the optimize dial to 40 (calibrate if necessary, to achieve different levels of optimization, which can change depending on things like moire, color brightness etc)
    6. run the resulting image through tinypng for an additional size reduction – this can add an additional 20 per cent reduction in image size, while maintaining reasonable quality
    7. attach the final highly optimized jpg image to the featured image “bucket” or section of the product page (leave the main pic panel empty: it is not needed, and may slow down things.)
    8. write some simple html to eliminate (ie make invisible or hidden) the second image and associated text that appears in the product page below the fold. remember to use !important.
    9. Use a much larger width (say 900 to 1200px) on the HP for any products displayed there, and specify the swiftbuilder row to be full width. this is the heaviest hit your site will take, but what you are sacrificing in terms of performance here (and only here) you make up for with dazzling product images (which can be animated using Sitebuilder).
    10. add what I called a Quicklook page (ie a page that using the mini products element off Sitebuilder) link as a submenu off the main menu bar shop menu option on the hp to allow user the option to quickly view a thumbnail list of all the products in the catalog (could not figure out how to eliminate the round image display of these here, but the client will live with this) – remember to use the regen thumbnail plugin when changing product images.

    These exact steps led to a massive reduction of pic size from several MBs each to well under 50kb in many cases. In the case of very dense pics (from a mesh/paint design perspective), this procedure was still successful in reducing 3MBs pics to an average of 100 kbs, while maintaining clarity and without introducing moire.

    The product page and the catalog load time became noticeably faster, and all the pics were correctly centered and sized more or less regularly in the catalog, no matter what the size of the display device or browser at any given time during testing.

    The only minor drawback was in the case of very tall or wide images: the cart/wish list and on sale or out of stock flags appear to float by themselves slightly away from the product img against a white background (but still contained within the 600 x 600 confines of the image settings, as described above).

    Now that this problem has been solved, the client is now prepared to load the rest of the catalog (loading a catalog is a non trivial matter, and should only be undertaken after the client is satisfied with the design and performance of your solution), and go live next week, as the STRIPE plugin testing has also been completed successfully.

    Thanks to Atelier, the end result is an ecommerce site that is intuitively simple to use (I had the good fortune of having some of my client’s B&M customers provide early feedback on how Atelier performed on desktop, tablet, and mobile envs, which was crucial in terms of things like fine tuning font sizes and color and product descriptions, the need for the resume shopping button in the cart/checkout area to return to referrer page — which i solved by writing a simple custom js function) yet compares favorably in terms of design sophistication to the competition in my client’s vertical.

    For example, I was able to add a unique (this was custom css3 animation with no js, not provided by Atelier obviously) animated needlepoint canvas on the HP to use as a product marketing tool, and also use things like parallax and lightboxes (which are provided by Atelier), in order to further differentiate my client’s site in what is a very crowded and competitive space.

    I did not use Quickview (for a variety of reasons), and decided on using the Swift Slider in only one section of the site that did not require a cart (I wrote a css solution for the woocommerce short code cart addon, but it looked ugly, despite much effort to prettify).

    I hope this brute force but effective “recipe” will be of help to any future users of Atelier who may be encountering some of the same problems I did.

    Now that everything is working correctly, I will leave anyone who has taken the trouble to read this far with a slightly modified copy of the golden 5 rules of ecommerce (which I did not originate, but agree with completely):

    Rule Number One
    Auto backup your site often, both database and full code (especially before any installs). Nightly backup your clients order flow or write some cron job that does this. Your client will thank you forever in the event of a disaster recovery scenario.
    Rule Number Two
    Once you have a stable store, never, ever update any module – not a plugin, not wordpress, nothing.
    Rule Number Three
    Try as much as possible to minimize plug in dependencies, and stay away from plug ins that look like they are not being supported or not likely to be supported in the future. Buy directly from an established vendor when possible, but don’t expect much by way of support due to the classic fingerpointing dilemma. Never expect your client (typically a non technical shop owner) to start fiddling around with things like child themes and PHP, and only allow them to add plug ins at their own risk.
    Rule Number Four
    Never, ever update your live site. Always test exhaustively in a Test environment
    Rule Number Five
    Do not believe claims that fully tested secure high performance ecommerce sites can be up in a week, and never tell your client that you can deliver anything in under a month for a site that has more than a few virtual products.

    Re #4, Siteground only offers a separate dev env for an added cost, which can be prohibitive to many startup ecomm retailers.

    The order flow backup and Rule #2 are critical: always have your orders exported to an excel or libre spreadsheet, just in case, and, once your client has signed off on the site, never update anything, no matter how attractive it may sound in the plugin description, unless the client understands and accepts that something new (even a minor rev) can break the site and that it might be very costly to isolate and fix or restore the previous version. This rule of thumb of course does not apply to essential security related fixes. Scope creep is not your friend, btw, and the client will end up resenting you unless you lay down the ground rules early.

    Well, that summarizes my solution to this image-related problem in particular, and my overall experience working with Atelier in general for a talented who wanted a sophisticated site up in a month at a very low cost!

    cheers,

    ali

    #212396
    David Martin – Support
    Moderator
    Post count: 20834

    Hi Ali,

    Thanks for your feedback and useful steps for image optimisation, it will hopefully benefit others also.

    – David.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in and have valid license to reply to this topic.

License required for the following item
Login and Registration Log in · Register