I thought I’d start posting the weekly Element videos here as we’ll be making a full switch to this new/old forum in the coming months. We’re just preparing everything now, so hopeful this dual forum shenanigans will be over soon.
In this weeks Dev Diary I do a bit of a deeper dive into the Image Element and demo auto image resizing based on breakpoints, I also show off a crazy web page design along with the new font shadow feature. It’s a bit of a long one this week, sorry!
Grab a cup of tea and enjoy.
We want your feedback?
So, what did you think? Share your ideas and feedback in the comments below or on our YouTube channel. Your feedback is invaluable; together we can build the best web design app on the Mac.
Thanks @dan for addressing the ‘will all sites look the same question’. The responsive images feature is looking great, but I have a couple of questions:
Will it be possible to provide alternate images for art direction at different screen sizes, and/or alternate formats for browsers that support them (ie: webp, avif, etc). This is all enabled via the <picture> element in HTML, and it would be wonderful if that could be supported in elements?
How are the images being compressed currently when they are being resized, and will we be able to specify specific settings for various images/formats?
OMG! I chuckled when you opened today’s web site. It must have been hell for you to create that. But a good opportunity to show how you can change a site’s look in seconds. A point has been made
The break points and images was interesting and made me think about a foto site where you could have an area for subscribers who get to see a high res image and lower res images for non subscribers. Which brings me to right-clicking images. Will there be a gizmo that lets one apply at least a basic no right-click policy where wanted?
Well @dan you made my day - I was laughing and cringing!
I do not see any mention of how this would work with images warehoused on a site. Or will warehouse images even be supported?
It seems like the approach would discourage the use of images warehoused on the server, correct?
For some of us, this might require serious redesigning our existing sites when we port them to Elements. But then again, there might well be something I’m missing. I’d like a definitive answer as to whether images in a warehouse will be supported. If so, how would all of the awesome resizing that Elements will do work?
The alternative images at different breakpoints is not something that is enabled right now, but I’m chatting to @bon to see what we can do on that front. Stay tuned.
The section Element supports different media at different breakpoints, so you could have an image in the background on Mobile, and then switch to a background video on desktop (for example).
Not currently, we’re just doing some basic conversion to get users 90% of the way there.
Okay…having written the above replies, it’s got me thinking we really do need to support alternative images at different breakpoints. That way if the users want to super-optimise their images with an external app for each breakpoint, they can.
Looks like we have a little more work to do on this Element!
“Wharehousing” will not be supported, we looked at it and could find very little reason to implement it. Originally, Warehousing came about because stacks does a terrible job of managing images.
Elements is different, the new “Resources Browser” makes managing images as easy as using the Finder. Element projects load instantly, filenames are respected, it all works seamlessly.
Hope the news is not too disappointing, but honestly once you start using Elements, you’ll see this is a much better way to work.
We’ve been chatting internal about Warehousing again, and want to make sure we’re doing the right thing. Could you briefly outline how and why you warehouse?
Keen to also hear from other users about the how and why’s of warehousing.
Hi Dan. Since a long time I am only using image stacks which either directly support one of the Stacks-based CMS solutions out there (mainly Easy CMS / Total CMS) or which at least give me (or better: my clients) the possibility to exchange images on the server by themselves (either by hand or by using stacks like Repository or s.th. else). Never had a client project in the last years where exchanging images remotely wasn’t mandatory. I know that the mentioned stacks won’t work with Elements, but IMO you should think of some solution to make it possible to change images remotely.
And here we are again: being able to store images remotely (= warehousing) would be a basic requirement for such cms-like things – at least I think so. So maybe in the development stage you currently are in it would be advisable to at least integrate some kind of a basic foundation for CMS-like functionality (so that future cms-elements would be possible). Again: each of the about 50 sites I built in the last years did require a CMS, so being able to warehouse images (and text and other stuff) should not be underestimated…
I’d like to throw a vote in for warehousing ability too @dan. A few examples on how and why to warehouse images:
Saves server space - There are still a lot of web hosting providers out there that limit a user’s disk space allotment which can negatively affect users who have media heavy websites (photographers, videographers, artists, etc.) who need to showcase their works in full-resolution. And for web hosts offering “Unlimited Disk Space”, there are indeed “soft” limits in the background. I previously worked for 3 different web hosts, they all offered unlimited disk space but had unspoken “soft” limits that if a user surpassed, we sent them a “fair usage” warning and asked they take steps to reduce the disk space. Warehousing was one of the first things we suggested.
Makes website migrations easier - When media is warehoused on an external server it makes migrating the core website easier for a user when they want to change web hosting providers. cPanel tends to choke on large backup files which led us to have to manually resync migrated sites using something like rsync or wget via SSH to make sure all the data was successfully migrated over and nothing got left behind. It slowed down the migration process for the user.
More performance and optimization options - A lot of the companies where users warehouse their images offer more optimization and performance features than a web hosting provider will. For example Cloudflare Images, Amazon S3, Digital Ocean Spaces, etc all offer some really great performance and optimization features for stored media files, resulting in faster loading and better performing websites.
I’m going to add a BIG +1 to ‘warehousing’ (I’m not familiar with that term specifically), as I routinely store images, video/audio, .zip archives, pdfs, etc in Cloudflare Images, Cloudflare R2, Amazon S3 (not so much anymore), etc. and would really appreciate the ability to add these resources/endpoints to an Elements site, and then incorporate these resources into various pages, styles, etc. through Elements wonderful visual interface.
Being able to add/remove/manage and then sync these resources visually via Elements would also be a massive workflow improvement, instead of having to configure and use rsync, wrangler, Transmit/Cyberduck, etc.
Lastly, and unrelated. In addition to being able to use resources from buckets such as Cloudflare R2, AND being able to publish an Elements site directly to Cloudflare Pages (it’s S3 compatible) would be most welcome. Not having to use the wrangler cli, or push to and deploy from GitHub would make life much easier. It’s also essentially free, fast, and secure hosting via CDN with very little set-up.
Oh, and one more thing… if you’re thinking of stretch goals for later, being able to add serverless functions to static sites hosted on services such as Cloudflare or Digital Ocean would a very nice to have feature for simple scripts and such.
The following response elegantly spelled out my reasons for using warehousing. So I won’t repeat them.
I primarily use the excellent Repository stack to manage my images. I find myself often editing the file names for consistency. It is then easy to edit the URL where the image is being used.
Now if your resource management system supports these requirements then all good.
Warehousing is a nice way for customers to upload images and they are then used in a gallery, for example. So a florist can have seasonal changes, photographers can show off new daily/weekly/monthly images - all without us needed to import images, add them to the site and publish the page.
I’m just thinking about this now, so haven’t really thought it thru, but that’s never stopped me before.
Would it be possible when you upload a site that the user could say - send these files here and the other files there?
One could have an FTP type wrangler that allows you to manage your cloud storage centers and then when you are making/editing , as you import images etc., you can spec where it’s stored. You could also have placeholders stored on your machine that allow you to edit faster…
I missed somehow this episode even though it was a very interesting one.
The “new” handling of photos is compared to what we currently have in Rapidweaver/Stacks a big step forward. The photos can be automatically resized by Rapidweaver! That is really the direction to go! Also the automatic naming of the pictures. Fantastic!
But as I am working half of my time with Wordpress I would like to suggest some additions as Wordpress (with a plugin e.g. ShortPixel Image Optimiser) handles pictures in the meantime very well and is from my point of view the benchmark.
I understood that when I am uploading a JPG or a PNG it always stays as a JPG or PNG. It is only scaled by size. What about an automatic generation to WebP and an automatic process to use the WebP when supported by the browser. And if not supported using the JPG. That would save a lot of time in the development process! And would make the pages faster.
When you are uploading a picture in Wordpress, you can then manage the ALT-Text, the description, the file name etc. directly in the media manager. When I am using then later on the picture, it automatically takes this data with the picture, what means you do not have to key in the ALT-Text all the time when you are using it. A big timesaver when you have some Galleries. And the Alt-Texts are consistent all over the site.
My last point is regarding what you said in the video. You are “only” converting the pictures to retina. As you said, most people are using retina devices anyhow. That’s maybe true in the Apple world but in business environments? I would doubt that and would reconsider this decision. Who cares at the end when a photo is saved a couple of times on the server?
I just checked for one of my Wordpress blogs and some photos are existing in 18 different sizes and file formats. But at the end the blog is very fast (Google Page Speed above 95) and I do spend only minimal time in the picture handling and optimising process.
