I can give you an analogy. The server for websites/apps (if not native) acts as your RIP. If the image size is larger than needed, it takes more time for the server to serve up the image (RIP the image), so it’s best to keep image sizes as small as possible. The optimization (or downsizing) of images is important due to lack of patience of the user. If the user is spending too much time waiting for an image to load (which could be less than three seconds) the user(s) will exit the site causing loss of site traffic.
There is also the point of bandwidth on the server. If an image is enormous it uses more bandwidth which can lead to significant charges to upgrade a server to optimize the speed of the site. This can be avoided by reducing the size of the image and setting optimization to lower settings, yet keep the integrity of the image.
All of this also applies to the creation of PDF files and their load times.
The question of the thread had to do with the usefulness of slices. To answer that question, you have to consider the alternatives. The only real alternatives to slices is vector graphics. Raster graphics only come in the form of slices.
Flash was slightly on the topic as it pertains to vector graphics on the web, and slightly off topic as to why it failed as a delivery platform. The vector graphic alternatives to Flash are SVG animations (mentioned) and some other plugin-based methods not mentioned. The security risk of Flash had more to do with the plugin, and nothing to do with the graphic format.
Yes it depends on end user(s) intentions. It also depends on service provider’s intentions to reach a larger group of users with a wide variety of user configurations and intentions. Unlike a print piece, a digital media file can adapt to user configurations on the user end in real time.
The optimization for web graphics is multiple tradeoffs. Most people who are stuck in a raster frame of mine already know of the tradeoffs between file size and image quality. Fewer people know about the vector graphic tradeoffs between load time and rendering time. It’s not just about file size. It’s about how much of the image is raster vs vector, and how complex the vector images are.
Monitors aren’t as much of an issue as bandwidth and processing power are on the client side. On the server side, processing power isn’t much of an issue, which is why streaming pre-rendered images is seen as a good short-term solution to lack of processing power on the client side. However, bandwidth is still an issue on the client side, which is why more vector graphics are the more viable long-term solution.
When you print a high quality piece, you have an idea of what the eyes will be able to notice and how easy it will be to turn pages. Imagine if you didn’t know whether or not users would be looking at your prints with a magnifying glass or how powerful that glass might be. Imagine if over half of your users were color blind. Imagine if you didn’t know whether it would take some users 2 seconds or 2 minutes to turn a page. Imagine if most the things you printed were pop-up books and you had to learn the fancy folding and sliding mechanics in order to design or print them. Imagine those mechanical specs had to meet global consortium standards that change every few months. Imagine if you had to worry about whether some users were using fingers to turn the pages or chewing gum stuck to a pencil. Imagine if you didn’t know whether the users would be looking at those pop-up books while driving or scuba-diving.
Maybe we’re not thinking of the same thing when we talk about slicing up images. I’m thinking more of how people used to built a Photoshop layout, then slice it up in ways that enabled them to build the page using mostly images instead of HTML.
For me, building a website has little to do with slicing up Photoshop files but doesn’t depend on vector graphics either (which I’m still 90% sure will remain a niche player on the web for the foreseeable future). Instead, building a website layout means building as much as possible in code, then resorting to images here and there when HTML/CSS isn’t up to the job.
We are thinking of the same thing, but you are referring to a more specific reason for using slices than I am referring to. You are referring to images segmented and reassembled with tables, which has become obsolete with tableless web design. I’m referring to any reason to use slices in general ranging from offline to online, and from interface design buttons to animating part of an image.
Here you might be talking about code-generated graphics on the fly vs imported graphics. Code-generated graphics are also an alternative to slicing. But code-generated graphics are also vector graphics. Your screen is full of vector graphics right now with fonts and code generated-lines. Any graphic that isn’t loaded from a file is usually a vector graphic only rasterized locally in VRAM for your screen.
I’m not thinking of that. By graphics, I’m referring to everything that constitutes the layout of the page and not just the odds and ends that might be either raster or vector, and which might amount to >5 percent of an average layout (minus the photos which will always be raster, of course). Then again, if you count the body text as part of the graphic layout, website layouts have been largely vector since the beginning.
For what it’s worth, I just added up the bits and pieces graphics on the front page of a website I’m currently building. I found that about 50% of those graphics were vector, so I’m probably even underestimating how often I’ve come to use them.
Actually, I just found a file where I tested Hippo SVG animation export back in 2015. I’m losing my memory in my old age. I tried it again last year, but didn’t like it for some other reason. Maybe I was looking at alternatives to ActionScript at the time. I’ll probably give Hippo a 3rd look if I decide not to develop in Unity.
