That isn’t something controlled by the stack(s) themselves. The Stacks plugin creates a new image when it processes them and names them itself. If you’d like to see that work differently be sure to contact Isaiah at YourHead Software with a feature request for that.
I believe that DLH meant that by using warehousing of images, you have exactly the control you get by maintaining your image filenames. Warehousing of images does not rename the image names. As opposed to the current system in Foundry which is to use the Stacks image well, which renames every image to a random image name.
If I misunderstood—my fault.
Adam didn’t completely misunderstand.
Yes, I do think it would be good if Stacks allows stacks to keep the original file names of images. In some ways it does. The stacks that allow images to drag and drop to the stack (and not into the settings pane) allow you to specify a file name. Ones were the image is set in the settings don’t allow that. I can see that this could be confusing for novice users. I think that the existing method is best for novices. They don’t need to worry about names or anything else.
We’ve seen, however, that once a novice finishes their website, they then start looking at things like SEO. They start to learn about image optimization and page load speed. As SteveB points out, using the same graphic on multiple pages (like banners/footers) greatly improves the whole site’s loading speed. You need warehoused images for that. Having warehoused images in Foundry would allow them to tweak their website by switching key images to warehousing.
3 Likes
Some months on from your last comments on the whole warehoused image thing @elixirgraphics. I’m wondering given the onset of time and developments elsewhere in the RW world, if your stance on warehousing images is likely to change anytime in 2018?
In short, as someone who uses warehoused images thru-out with no interest in changing (going backwards IMO) I’m asking, as I start to use Foundry for commercial projects, should I look for alternatives to image based Foundry stacks or is it likely that they will support warehousing at some point this year?
Would be really keen to see this happen too. Is the one really big thing missing from Foundry in my opinion.
I know @elixirgraphics is keen to keep Foundry simple for new users but, as soon as those new users begin to investigate things like seo / speed etc then they will discover countless voices advising the use of warehousing (only to then discover that Foundry doesn’t support it). I don’t think the addition of an optional warehouse link to the stack settings will affect usability for new users anyway.
Absolutely. I cannot understand how this would add complexity to the image stacks as all that would be visible would be a single check box in exactly the same way as nearly every other Stacks developer does it and has done so for years. The lack of image warehousing remains the most talked about issue in Foundry on this forum.
For me it makes no difference that I go outside Foundry for my image stacks but some unique stacks such as Shift and Jumbotron are IMHO, crying out for warehouse support.
I currently have not changed my way of thinking on this particular subject… with that said…
To quote a very smart developer I know:
While this isn’t a 1-for-1 comparison to our current topic, I think that it still fits this conversation.
I know that many of you are experienced users who know your way around RapidWeaver, Stacks and even hand code some of your own stuff from time to time. But a majority of the user base in the RapidWeaver community is not at that level. While you may assume others are also on your level, you are not seeing my inbox from day to day.
Simplicity is integral. Not only to making Foundry as friendly and easy to use as possible for everyone, but also in making it not be a burden to support. I would like to, and I think you all would agree, that you’d rather see me producing and updating products more than spending my time answering the same support question(s) time and again.
With all of that said, a while back I made some feature requests to Isaiah regarding the Stacks API that would allow me to provide something like you all are looking for, but using some of RapidWeaver’s built-in functionality to do so, making it much easier for everyone to use, whether you’re a novice or a veteran of RapidWeaver.
It isn’t that I don’t want to provide a feature that you all want to have, it is that I want to do it in the best possible way for everyone involved. I hope that makes sense.
Well, that sounds hopeful, I think.
I just hope the direction you go isn’t anything like the approach RW took for a while, mixing warehoused URL’s with resources, or something like that. Not sure if it survived beyond beta, but when I looked at it, it was confusion personified.
Personally, I still don’t get how the inclusion of a warehouse URL tick box option will confuse anyone, beyond the normal levels of confusion (and so support requests) for the novice user, but there you go, I shall yield to your greater experience.
Well if there is anything we can do to reduce this, just ask.
For example, even though the Foundry Documentation is by far the best available, it suffers from not having a Search which can make finding a stacks documentation more difficult that it should be. E.g to find the Container docs, you have to open up the dropdowns to find the Container section.
The other thing that is missing is not from the documentation, but is missing from every stack. There are no tooltips which give useful information.
E.g. if a new user is using the Container stack, there is no in-stack explanation of what Fluid is and if you select Fluid, there is an option to remove the side padding. However, without a tooltip and no explanation in the Container docs, most users would need to fire off a support email. I.e. what value is the padding and how do I adjust it? Some tooltips here would be of great benefit and also throughout all Foundry stacks.
The golden rule is that if you get the same support question twice, then that product support needs changing.
There is nothing you can do. I appreciate the sentiment. I’m not complaining about my support load. In fact I feel it is pretty light compared to many as I take the time to document things and provide tutorials. I’ve been doing this for over 10 years now and have learned to make products that are as self explanatory as possible and try not to introduce things that would cause the user to get get tripped up. I’ve made my fair amount of mistakes in this way in the past, but have learned from it. Those lessons have taught me that empty fields for entering code is a bad idea that will lead to problems.
It is not only confusion that is the concern.
With what I said above in my previous post, I’m going to go ahead close this thread. If and when the feature requests that I put in with Isaiah come to fruition I will implement them into Foundry.
2 Likes