UI for lossy/aggressive optimizations

[imageoptim]

UI for lossy/aggressive optimizations

[kornelski]

@henrikdahl‎ sent me a nice suggestion

Moving of "again" button to the top bar frees up space, so that may be a better starting point for addition of any lossy optimization options.

[kornelski]

Brainstorming!

I really want to make clear when optimizations are lossy, and that the default is lossless, so that users can trust the application and nobody accidentally ruins their work.

Maybe the main window could somehow be switched into "lossy mode" that has quality slider, destination folder option, etc.

The standard tab control is obviously uuugly…

Maybe the current UI could be kept, but lossy optimizations were run from menu:

or from a button that also serves as a reminder whether lossy/lossless mode is on:

but that makes the UI slightly cluttered. Nicer variant: https://code.google.com/p/imageoptim/issues/detail?id=67

How about "upselling" users on lossy optimization? "You've saved 3KB on this file, you can save another 15KB with lossy option!"

Maybe for every file dropped insert two entries into the table - one for lossless and another for lossy?

I'm looking for other proposals.

[kornelski]

Maybe a separate window to drop files into for lossy optimization, sort-of like Chrome's Incognito window?

[henrikruscon]

That suggestion is no longer the actual one, we've since discussed and this is now the current one:

[sulkaharo]

Would it make sense to allow users to use different settings for thumbnail size images and larger files? I'm currently optimizing a large batch of jpegs for which it'd make sense to use much more aggressive compression for the files where max(height,width) <= 1024 than the tool currently allows.

[sulkaharo]

I'd avoid UI that exposes all the tools ImageOptim uses under the hood, or requires knowledge about the tools. I have no idea what the strengths of each is despite being a pretty advanced user, and I doubt almost anyone else does either.

Giving an estimate on space saving on lossy vs lossless sounds like a great idea.

Wonder if there's any open source libraries that could be plugged in that'd give an average per pixel delta on the lossy vs lossless, that'd allow detecting the loss level, and catch the scenario where the lossy compressor screwed up?

Wonder if terminology other than Lossy vs Lossless work. As in, the tool allows "safe" lossless compression, but also more "dangerous" / "aggressive" / "strong" compression on the lossless. Using a grading other than simple lossy / lossless would allow for multiple levels of compression where Safe = lossless and the other end of the spectrum being a strong lossy compression with metadata stripping. Make any sense?

[pathawks]

👍
I like "safe" lossless vs. "aggressive" lossy terminology. I also like the clear "Quality: 100%" button pictured in the mockup.

[kornelski]

@sulkaharo There are libraries to estimate loss, I've even written one :) However, estimates are not always accurate, and I don't think they can ever replace human judgement. Sometimes required quality doesn't even depend on content of the image, but context: a screenshot in troubleshooting guide can have rough quality as long as text is readable, but a screenshot of a latest Apple application needs to look shiny and pixel-perfect :)

Different name for lossy optimization may be a good idea. What JPEG does is widely understood, right? How do people call that?

I'd stay away from terms like "dangerous" and "unsafe" as they sound like something to avoid, while lossy optimizations are a great idea.

Maybe some name that alludes to removal of superfluous quality?

[kornelski]

@pathawks would you need combination of lossy and lossless optimizations? When would you change between the two options? If the button wasn't in the main window, where would you expect to find that setting?

[pathawks]

@pornel There are times when I want lossy and there are times when I want lossless.

There have been times in the past when I wanted lossless, and then noticed that I had JPEG quality set to 80% in the preferences. 😧

I like that the same settings are applied to all of the files in the window; per-image lossless vs. lossy options would only clutter things up, I believe.

I like to apply lossless compression to images I'm importing from my camera before I archive them.
I often apply some measure of lossy compression to images that I will use on the web.

While in many (most?) cases it would be overkill, I really like the way ImageAlpha does things:

• You can slide the quality (number of colors) bar down as low as you want
• There are a few reasonable options related to the algorythm presented in an unintimidating way
• You can toggle between the modified and original image to see just how much quality was lost

I'm not sure exactly how that could apply to JPEG lossy compression, and it's likely beyond the scope of ImageOptim, but I have often longed for such a tool when I'm really trying to make web assets as small as possible.

[pathawks]

@pornel That would be a very good visual cue, yes.

What exactly are you trying to achieve by introducing lossy optimizations into ImageOptim? (I say that, not because I think it's a bad idea, but because the why affects the how.)

When I know the changes made to the file don't impact image quality, all I'm concerned about is the Savings column; the higher that number the better! I love when I click the Again button once or twice and see that Savings go up just a little bit higher.
When lossy changes are involved, I'm concerned with more than just file size. Any improvements to the file size would leave me concerned (just in the back of my mind) "I hope that didn't screw up my picture beyond recognition."

I'm certainly not opposed to lossy compression; quite the contrary, it is often necessary when trying to make a website just a touch faster. I just know that my personal workflow for lossy compression is a bit more involved than when I just dump a bunch of PNGs into ImageOptim.

[kornelski]

The ultimate why is that lossy optimizations reduce file sizes much more than lossless ones can, so ImageOptim can do better than it does currently.

Users of ImageAlpha are asking for a batch mode (and users of ImageOptim generally don't know ImageAlpha :))

Interesting case is conversion from GIF (or sometimes even JPEG) to PNG. It won't degrade the quality, but it's still not as safe as other optimizations: if you rename the file it may screw up links in related HTML/CSS/JS (and fixing URLs in them is another can of worms), and if you don't rename the file it may cause weird compatibility problems (e.g. PHP has imagecreatefromgif() that won't read PNG).

So I need a place to ask the user whether GIF should be left alone (maybe they know what they're doing), converted to PNG in place (if they're optimizing a website and don't want hassle of changing all <img>) or converted and renamed (if they don't want misleading filename extensions).

"I hope that didn't screw up my picture beyond recognition."

True, that's a massive concern. With ImageAlpha I went to the extreme where you can carefully inspect every pixel of the image, but some people have 500 images to optimize and ImageAlpha's workflow doesn't scale.

(and btw, technically it's easier for me to add ImageAlpha features to ImageOptim than vice versa :))

[pathawks]

Perhaps it's just me, but I am much less concerned with options that affect the file without affecting the quality of the image than options that might noticeably degrade the quality of the image itself.

For GIFs, maybe an option in Preferences to try creating a PNG image of the same quality. To me, this seems to be in line with preserving EXIF or file permissions as an option I would probably set and forget.

If not in preferences, perhaps adding an optional column in the main window with a button that conveys "Make this non-animated GIF 15% smaller by converting it to a PNG." An extra column in the main window could also work for conversions that would only slightly affect quality, like "Click here to convert this 24-bit RGB PNG to a high quality JPEG."
Perhaps that wouldn't scale very well to 500 images, though.

Options to "Make this image 40% smaller by converting it to a smudgy looking highly compressed JPEG" should be treated with much more caution, I think. Tools like JPEGmini are not bad if you just want to email a few photos to some friends, but users must be made to understand that they shouldn't do this before they send a photo off to their friend who is a whiz with Photoshop, that sort of super-aggressive compression should only be the very last thing you do with a photo before publishing it.
Even resizing an image should be done before rather than after optimizations that work with perceived quality.
It's maddening when users complain about how you can totally spot the quality degradation in JPEGmini optimized images when you blow them up to 6x their original size.

[zakj]

The beauty of ImageOptim is that I can rely on not thinking about it; I just feed it a directory full of images before checking them in, pound "again" a couple of times, and know that I've got significantly-smaller images without any loss of quality.

That said, I sometimes end up with giant images that ImageAlpha could do a much better job of compressing, but I never want that process to be automated. ImageAlpha's UI is fantastic for comparing the visual loss across its compression algorithms. For me, the best of both worlds would be for ImageOptim to do its thing, then update its UI to include a column of checkboxes (one per image). I could check the images for which I was willing to accept lossy compression, then click a new button in the bottom bar to get started. Each checked image would be opened in a new window almost identical to the existing ImageAlpha UI, where I could adjust settings until I was satisfied, or cancel the operation.

ImageOptim might even ease the process by initially checkmarking images above a certain file size threshold.

[pathawks]

@zakj “The beauty of ImageOptim is that I can rely on not thinking about it”
👍

[johngb]

@pornel Thanks a ton for the work you've done on both ImageOptim and ImageAlpha. Both are very useful applications. My expertise is primarily in UX, and so I'll try to give my honest opinion on how it can be improved, specifically for batch conversion.

Part of what you have do decide on is the philosophy that you want to take in terms of trying to prevent users from inadvertently damaging their original files. It comes down to two (sane) choices. The first is to remove the possibility of them altering their lossless files with lossy ones, and the second is to make is clear what is happening, but give users the ability to replace their lossless files if they explicitly choose to.

The only real option for the first approach is to force any batch conversion to create new files in separate folder and/or with modified filenames. In many ways this is the simplest and the safest approach, but it looses some functionality.

The second approach is significantly more complicated as you then need to give users options as to how they would like their converted files to be handled, but it has the advantage of being more flexible in terms of workflow. Pngyu does a fairly good job of solving this particular use case, but it has room for improvement (besides the general look and feel, which I wont go into much if at all).

For reference, this is the UI for Pngyu:

1. The button selector labels for the output option could be improved. While "Overwrite the original" is clear enough, "Custom" is not. Here I would suggest the labels as "Overwrite Original", and "Create copy".
2. As per @pornel 's suggestion, colouring the unsafe option as per warning signs would be another useful cue. I would also suggest including a warning sign icon with the "Overwrite Original" option as a visual indicator.
3. The compress option, selector should be replaced by a dropdown selecting the method of compression with any optional settings shown below that. This would be similar to the "Custom" view for the Compress Option, but without the space taken up by the button selector.

---

Overall, I would suggest going with the second philosophy, as you will never prevent a user from doing something silly. In general I believe it's best to be clear about the result of an action, and let them make their own choices.

If needed for clarity, I can draw some wireframe mockups for what I would suggest for the interface.

[kornelski]

@johngb Thanks for the analysis. Are you suggesting to make similar UI in a separate window, or extend current main ImageOptim window somehow? I'd love to see wireframes.

[visualpharm]

Are you planning a way to rollback the lossy optimization? Maybe I could press spacebar on an image to evaluate the quality and if it's not satisfactory, press kind of Undo button to switch it to lossless?

[kornelski]

@visualpharm Technically I could revert files to lossless.

However, I don't think it's possible to add custom buttons to QuickLook preview pane, so option to Undo would have to be elsewhere (where?)

If lossy optimization is configured to save lossy files to another directory, would you expect losslessly-optimized files to be copied as well?

And if lossy optimization is configured to rename files (e.g. *.optimized.png or *.lossy.png?) would you expect losslessly-optimized files to be renamed as well?

[visualpharm]

With quick preview, there are two options:

1. Make undo button in the list.
2. Make your own quick preview and put the button there. You could even split it to show past and current versions. I like this option more.

[visualpharm]

About moving and renaming the optimized files.

I don't like the idea of placing results in a different directory (or under different file name). It means spreading the copies all over the hard drive. Quickly you have problems recognizing which is what and start making errors.

I prefer to put backups in a different directory instead, some preconfigured one. You work with your files and you're fine with your work 99,9% of the time. In case if you discover the quality is bad (and you missed it initially with quick preview), then you take original out of the backup.

That's the principle of version control systems, that the current version is on the top and the previous versions are buried somewhere. This principle is adopted by iPhoto, Mac OS X Lion file version history and even Trash can.

[johngb]

@pornel I don't see any reason to add in another window when it can be achieved in a single window. The way that Pngyu handles it is very close to what I would recommend.

I'll see what I can do about some wireframes this week.

[visualpharm]

I believe checkbox is a rather bulky control for the toolbar; I'd prefer a sticky button there

or it's more fashionable glowing variation

[visualpharm]

Mmm, well than.

[kornelski]

Here's a crazy idea. How about showing a "folder" with lossily-optimized files:

Use could drag that folder anywhere. That would be used instead of asking user up-front where to save the files.

[kornelski]

I've been using ImageOptim with lossy PNG for a while now and filesize savings are amazing, but UX is terrible:

• I can no longer trust the tool to preserve quality, so I have to double-check the output. That completely changes the workflow: it's not fire and forget, it's a tool you have to babysit.
• Quality slider makes me want to tweak the settings, but without realtime preview that's awkward - batch optimization and tweaking don't mix (I'll probably limit quality setting to just "low/high" or such).
• "Open with ImageOptim" in Finder uses previously set quality setting, so I end up first opening ImageOptim myself, then checking what quality has been set, and then back to Finder.

This makes me think that ImageOptim should remain lossless by default. Lossy optimization shouldn't be a setting, but an action or mode.

e.g. how about adding button that means "Optimize images again, but this time using lossy optimizers"? (or disguise it as "Save as lossy"). You'd have to always press it, so "Open with ImageOptim" from Finder will never surprise you with lossy setting. Not sure how drag'n'drop into window should behave after some lossy optimizations have been done.

Any other ideas?

[pathawks]

+1 For being terrified of the "Open with ImageOptim" finder menu.

[rjmunro]

IMHO, ImageOptim should remain 100% lossless(*). It could warn if an image looks suspiciously big and could do with some lossy compression (e.g. PNG color reductions, JPEG quality lowering, coverting from one format to the other), but any kind of lossy compression should be done by separate apps, such as PNGMini. Such apps should always show the image and let you accept the loss before you save it. The UI for that is completely different.

(*) That is lossless for the actual image data, not metadata etc.

[kornelski]

@rjmunro How would you show the warning?

[mems]

Why not simple dedicate ImageAlpha not ImageOptim as a lossy compression tool (which actually used as is for transparent paletted PNG) where the main area is used to see the visual effect of lossy compression ?
With that, you could choose the right tool and the compression level for a targeted loss of quality and weight (exactly the same we do it actually with transparent PNGs).
The final file size is not the only one effect that the lossy compression affect.

[rjmunro]

@pornel I would show the warning by highlighting the file in the list of files in the main ImageOptim window, perhaps with an icon and by changing the color of the line. Hovering over the line would say what the problem was. Clicking the icon could pass the file to another tool (i.e. ImageAlpha) if installed, or take you to the web page to download it.

[Crissov]

ImageOptim is a fire-and-forget tool indeed, and should stay one.

There are many approaches to reduce image file size in a “lossy” way. Choosing the appropriate one depends very much on the intended use of the image. It may be okay to …

• … flatten layers (not relevant for currently supported formats).
• … remove embedded previews.
• … delete animation.
• … dither to use less colors.
• … reduce the pixel resolution.
• … convert to a different file format.
• … lose some details, i.e. lossy in a strict sense.
• … do anything to get the size below a certain threshold.

I would suggest a settings selection in the main window (with some presets, lossless being always selected by default), which can only be accessed once lossless compression is done. It would be accompanied by a settings editor in preferences or an external one.

[kornelski]

So, 10.10 happened…

Or to be completely hip (that looks terrible :)

[kornelski]

My current thinking is that lossy quality can be simplified to just two settings: almost imperceptible (cautious setting) and good enough (smallest file).

For symmetry, I could also add pair of settings for lossless optimisation speed: quick vs thorough.

For simplicity I'm leaving out everything in between, and I don't care about combination of speed & lossy quality together (lossy PNGs become small enough that it doesn't matter much).

Now, just thinking out loud: This could be presented as a slider, or maybe a row of radio buttons.

Perhaps then I could also indicate how well compressed files are and what is their quality:

and finally maybe the two indicators for quality and compression optimisation could be combined into one thing, e.g.

fully quality, fully optimized:
half quality fully optimised
and full quality, but not well optimised

Although the indicator is not very intuitive :(

The upside is that I could have a progress bar circle in this style.

Now I'm waiting for your counter-proposals.

[henrikhelmers]

I think you are spot on with those use cases. There are three ways in which I optimize:

1. Reduce file size and keep full quality.
2. Reduce file size and sacrifice quality (as long as I cannot see the difference).
3. Reduce file size as much as possible (perhaps I need to base64 encode it).

Having one executable for #1 and another for #2 and #3 makes sense to me.

[Jellyfrog]

@pornel

I can no longer trust the tool to preserve quality, so I have to double-check the output. That completely changes the workflow: it's not fire and forget, it's a tool you have to babysit.

For this you could add a "slide to compare" feature, something like.. http://demosthenes.info/blog/819/A-%E2%80%9CBefore-And-After%E2%80%9D-Image-Comparison-Slide-Control-in-HTML5

[kornelski]

How about a popover with a whimsical switch?

[pathawks]

Is a popover loud enough that one would never leave "lossy" on by mistake without noticing?

[kornelski]

I was thinking about resetting lossy setting to "off" every time ImageOptim starts, so you would have to turn it on every time you want lossy: that's the reason for the popover to exist - to make it easier to do.

[kornelski]

Another take:

but I don't know when to hide the popup. Some people will hate it there, and requiring them to close it adds another step.

[johngb]

@pornel If you intend to limit the compression options to two value (100% quality and 80% quality), then it would be best to include the slider switch directly into the status bar (or whichever name you want to call it). You gain nothing by hiding it behind a settings icon when those are the only settings options.

[kornelski]

The popover gives me more space to explain what it is.

I'm also wondering whether I should have an option to add ".min." to the filenames, so it'd go there as well.

[kornelski]

I could add options to the drop area:

but then it's not obvious how to get back once you drop files. Plus, it looks cluttered.

Maybe it wouldn't be too bad if it was a sidebar?

[henrikhelmers]

One question that I keep coming back to is «what does lower quality mean». Today I will take a collection of (usually similar) files and drop them into ImageOption, or run them one-by-one (with the same settings) through ImageAlpha.

I would probably like to compare original / lossy versions for one or more files by eye to see if the loss is acceptable, before processing. That is what I love about ImageAlpha. If that could be made part of this process it would be nice.

Choosing lossy compression is not something I would do without checking the result.

[kornelski]

@henrikhelmers OTOH ImageAlpha users often ask me for a batch mode, so I think there's also a use case for fire-and-forget lossy optimization when somebody has too many files to tweak every one individually.

I plan to add a more steamlined process to ImageAlpha for tweak-review-save manual process, but I'd rather not add a preview window to ImageOptim, that would be too much of a change in UI and workflow.

[henrikhelmers]

I will join the request choir then; a batch mode in ImageAlpha would be great. As for this issue I think I still would really like a preview. Maybe I am the the odd one out?

With PNGs, if I configure it for lossy to mean «256 colors dithered» I think that is fine, as it would yield more or less predictable results. But what if I drop a SVG in there and it breaks? That would be unexpected.

I think the segmented control in #17 (comment) is probably the most clear. It would allow batch processing just like today, and also means that each mode could have different UI. I imagine the «lossy» mode might need warnings or extra controls.

[Crissov]

I strongly believe the setting/selection usually has to be done per image and not per batch. So this is the workflow I propose:

1. Compress all files losslessly. Save files.
2. When done and idle, compress all files lossy using a preset. Save as temporary copy.
3. Let user go through files (↑ and ↓ keys), show preview (full size QuickLook-like with space bar) and maybe highlight losses on demand, let them choose between default lossless (←) and preset lossy (→) versions. Keep alternative as copy until the user quits the application or hits Cmd+S.
4. Each row shows an ellipsis button (…), maybe just on hover, at the right end. It allows the user to select advanced lossy options at their discretion.

PS: Holding down Alt (option key) when adding files to ImageOptim could switch the default from lossless to lossy.

[radex]

PS: Holding down Alt (option key) when adding files to ImageOptim could switch the default from lossless

Alt when dragging files already means "copy" in a lot of places, so I would use a different modifier to avoid confusion.

[kornelski]

@Crissov that's a good UI, and I plan to add something to ImageAlpha, but this IMHO doesn't fit ImageOptim.

ImageOptim has one window, the window can be small (doesn't have to fit any image), and it's a mode-less UI.

Adding a mode for previewing would change all these basic properties. It would essentially turn ImageOptim into ImageAlpha.

So for ImageOptim specifically I'm only interested in solutions that don't involve showing and reviewing images.

I do like the idea of Alt for enabling lossy drop. That could be a "power-user" feature. Might be hard to implement for drops from Dock though. And still needs a normal version of UI to be discoverable by new users.

[rjmunro]

Please don't add lossy conversions to ImageOptim, it will massively devalue the product.

Right now I can say to designers "Put your images through ImageOptim before you add them to the git repository". That is it, no questions, no possibility of them doing it wrong. Even if it's a hidden option that no one knows about, the fact that it is possible to change the image content with ImageOptim will ruin that.

Adding a feature that lets you break your images is not an improvement, particularly as, by default, ImageOptim overwrites the original file.

If you really want to base a lossy compressor on ImageOptim's code, rather than basing it on ImageAlpha, or starting a new project, that's fine, but fork and rename the project first, or use some sort of compile / build time switch to produce 2 different apps.

[kornelski]

@rjmunro I share your concern about overwriting originals with lower-quality versions.

Do you think it would be OK if lossy versions were always saved under another name? e.g. image.jpg as image.min.jpg?

[rjmunro]

It would certainly be less bad if lossy versions were saved under a different name (unless the user deliberately overwrites the original using the save as dialogue, as you can do with ImageAlpha). Another option might be to add .orig to the filename of the original file. Of course, often the best lossy transform is to convert from PNG to JPG, which means both files exist anyway, so how to handle that gets a bit confusing.

What would be great is if it can say "You can make your files smaller by lowering quality" (as in the example screenshot above), and clicking that opens (or prompts the user to download) ImageAlpha, or a similar future app. It could do this, e.g. for PNGs of more than 256 colours, or JPGs of more than 80% quality.

[johnmontfx]

I wanted to chime in and say we miss the previous behavior (that the lossy setting doesn't revert). Our tests found that consistently saving jpeg images out of Photoshop at 100% and then a 90% lossy compression using ImageOptim was a great workflow. And produced better looking images at smaller file sizes.

We would write out files, overwriting the original...and it worked every time for us -- publishing hundreds of images on our sites. Having to go in each restart and adjust the setting makes the app not as usable for us. I'd prefer this setting to stick.

I understand that you need to listen to a lot of different viewpoints, but just wanted to mention it.

[johngb]

@johnmontfx From a UX perspective, there isn't any good reason for settings to not be saved between sessions.

@pornel Was this a conscious choice, or is it simply a feature that needs to be re-implemented?

[kornelski]

I see your point. The current solution is not good enough, and I'll be trying other solutions.

Currently not saving lossy preference is a workaround for opening from finder being unpredictable.

[johngb]

@pornel A reasonable solution to both problems would be to have a "save as defaults" setting in the application. That way, if someone wants to always open a lossless version from Finder, they can have that, and if someone wants improved workflow by having their lossy settings as default, they can do that.

Additionally, as one would have to actively set it as a default, if one's default were lossless and for some reason one needed to use lossy for a single job, the next opening of the application (wherever it is from), would still be the safe version.

Without users selecting a default, I would default the default to the safest option (i.e. lossless).

That should be fairly trivial to implement settings wise, and should solve both issues.

[henrikhelmers]

I think the concern @pornel has is that if a user changes the default to lossy and then later fires up ImageOptim for a set of images, they will be irreversibly modified without prompt. Since ImageOptim has (up until now) always given lossless results (if you discount metadata), this behavior could be unexpected.

Given that ImageOptim is pretty far into power user territory, I think adding such an option may not be all that dangerous. Perhaps place a notification in the UI so the user is aware he is driving with his seatbelt off.

[johngb]

@henrikhelmers If you've chosen a setting and specifically asked to make it a default, you can't really claim that the action is unexpected.

However, I think your suggestion of giving some visual notification (I'd add that it should probably be red or orange) in the UI letting people know that they have a lossy setting is a good idea, and doesn't compromise usability.

[kornelski]

Here's a test build: https://imageoptim.com/ImageOptim1.6.1a2.tar.bz2

Dropping images while holding Alt switches on lossy mode*. Does that improve things?

*) it's a quick hack, so in that build it works only on the first drop.

The trickiness with alt-drop:

• Impossible to discover for new users. How would you fix that?
• What UI should look like once the file list is visible?
• What should happen if the list already contains the same file, but dropped in a different mode?

[johngb]

@pornel Although this may seem like a simpler solution, I believe that it's exposing unexpected behaviour to users due mostly to its poor discoverability.

What do you see as being the problem with allowing a user set "default settings"? This is common behaviour in many apps, and I've yet to hear of an issue with it - even with a mainstream app like iTunes (with the encoding settings, which can be lossy or lossless).

It has the advantage that a user has to actively switch it to a lossy setting, without any real excuse that they didn't know what it was doing. Yes, they could forget what they had it on, but that can mostly be solved by using @henrikhelmers suggestion of placing a notification in the UI.

[johnmontfx]

Wow...thanks for the comments in response to my post. And even a test build. The Alt drop works, but I do feel it's a bit obscure. I tend to agree with @johngb regarding a user determining default settings.

I read the reasoning behind the workaround regarding opening from the Finder, but I still feel as though this doesn't conflict with "setting as default".

[kornelski]

@johngb I've written about it before.

iTunes analogy doesn't hold, because iTunes doesn't overwrite files on the ripped CD :)

It's only a "default setting" if you only ever do one type of optimisation. However, if you switch between different projects with different requirements, then there's no satisfactory default, and the biggest problem is that you have to remember that setting or you may accidentally ruin your files.

My hope was that an auto-reverting setting would free you from having to remember it — now at least you know it'll be off (a safe option) when you launch ImageOptim. But it is a pain if you want it on.

For the next version I'm going to try settings on the initial drop view and perhaps a "start over" or "clear" button that takes you back to the initial drop view:

(I've previously experimented with having Again button dual-purpose and switch to other button based on context, but it was a confusing mess)

[johngb]

@pornel Valid point regarding not overwriting the data on the CD, however the point was more than having a default setting is common practice among many apps.

Referring to the use case of someone doing many different tasks. That person then wouldn't change the default settings, and would keep them on the safe (lossless) default default settings. Then they would know that every time they open the app, they are safe unless they want to change it for that one task / project while the app is open.

However, it enables the many users who want to always use the same settings not have to remember what they are and change them every time.

By forcing safe (lossless) setting by default, you're making the UX poor for many competent users in an attempt to make it safe for less than competent users. Given that this is an app mostly for power users, that seems like a poor tradeoff to me.

[iefdev]

Yes, if you could please revert the (new) “default” setting, that resets on each restart. Not that it is necessarily a bad thing, but it makes the work process so much harder/inconvenient. If I would like to use 80-85% on jpegs, I now have to first open IO, open prefs, select tab, untick the box and then I can process the file …instead of just using the contextmenu to process the image instantly.

Eg. the defaults should be up to me.

Or perhaps add a couple of default write, like hidden settings.