The definition of insanity should be doing the same manual task over and over again.

Every system administrator deals with repetition. There are certain tasks I do every day, over and over, mostly with little change. So like most of my compatriots, I've become adept at automating. Life is too short to sit there and do the same things over and over—mindless repetition is a mind-killer. Over the years, I've learned that automation is valuable in almost any application. And these days, I get extremely annoyed when I see things that aren't easily automatable.

If an app doesn't have built-in automation options, it tells me that the developers are somewhat short-sighted—if not outright lazy. Automation allows an application or service to be extended; it creates functionality that wouldn't exist otherwise. It gives the people buying and using an app the ability to not only solve problems themselves but to figure out things that the dev didn't think of during development. After all, a dev and a user are different people with different brains looking at things through different eyes. To put it bluntly, a lack of automation tells me that the dev has little respect for their customers' time. They don't see a problem in making someone do the same task over and over for as long as that person uses the application.

Four letters save tons of time

Let's look at the first benefit of automation—extending existing functionality. One of the things that a good automation implementation does is give the user of the application the ability to do things that the dev may not consider important. Every developer has to make choices about what their app will and won't do. But if we aren't restricted to just the UI, we suddenly have options. Consider the Apple Mail of the past and its rather bizarre inability to import its own data. Prior to Mountain Lion (or possibly even Lion, and in Snow Leopard for sure), the individual message files for an IMAP account cache were labeled as .imapmbox files. That's not a big deal in and of itself, but it meant that importing this data back into Mail was rather difficult to do in large quantities. (This makes no sense to me, either. I cannot for the life of me imagine the logic in an application that cannot import its own data. But that's Mail for you.)

Further Reading

This isn't something you run into a lot, but let's say that you're changing mail services. Even if both your new and old service supports IMAP, the sheer size of most people's mail stores and the slow nature of IMAP to IMAP copies makes "just doing an IMAP copy" a losing proposition. Other factors can limit things further—the new mail service could be a hosted service (like Gmail) where you have no direct access to the server. So much for just copying the mail store from server A to server B.

In this situation, it is an option to take the existing IMAP cache and import it locally—just not by copying it from the server, because that would take a lot of time. You could yank the IMAP cache and reimport it locally, and while it would take some space, it would be temporary. The IMAP cache could be deleted once the import is done, and—because this would happen at hard drive rather than network speeds—it would take less time. Significantly less time.

Clearly, this is not a use case Mail's devs thought of, because that's why you use IMAP, right? If you need it, you just get it from the server. It's when you have a case of "the server is going away" that suddenly this limitation becomes a pain. In trying to solve this problem, I looked at Mail's AppleScript implementation, but I couldn't get it done with that. I poked around a bit more and realized that the only "difference" between .imapmbox files and .mbox files was "imap." Score— things became easy.

The solution begins by writing a script that takes the unix find command to build a list of paths to every .imapmbox file in a folder. You then pass that list to the Finder and use a line of AppleScript to change the filename extensions. The time to process thousands of e-mails in different folders? Seconds. Thanks to automation in other apps, the limitations of Mail (eventually fixed starting with Lion) were no longer any kind of problem.

Turning the page(s)

OK, the Mail example doesn't really count. The problem has been resolved and I was automating around Mail, not using Mail's automation capabilities directly. Let's look at another example. For whatever reason, I prefer Outlook 2011 to Mail. But I also really like using Pages for most of my word processing needs. While Pages is quite good at sending things via Mail (as in Mail.app), it's not so good at using a different e-mail application. However, thanks to a solid scripting implementation in Pages, that limitation disappears.

When I'm writing a document I know I'm going to want to e-mail as a PDF via Outlook, the fact that Pages doesn't directly support this functionality in the UI means nothing to me. I have a script that converts the current document to a PDF and opens a new e-mail message in Outlook with that PDF file as an attachment. Apple may one day implement better e-mail client support in Pages, but it may not. The point is that I don't have to care. As long as Apple maintains the automation features of Pages, the number of e-mail clients it directly supports can be anywhere from zero to "all of them." I've already routed around the problem.

Pages is nicer than Word for simple documents like invoices; it's also scriptable. This lets me create a rather nice workflow that I use for invoicing sponsors of my podcast, "Angry Mac Bastards." I have an AppleScript-based service that presents me with a list of current sponsors. I select the one I'm invoicing and the service opens up a new document in Pages based on the invoice template. It autofills the sponsor data into the correct text box. All I have to do is make sure the amounts, period being invoiced, and invoice number are correct, and I'm done. I save the document and run another script that creates a PDF version of the Pages file. This action also opens up a new outgoing message in Outlook for me with the invoice as an attachment. I type a few lines to personalize it and hit send.

For any given invoice, this process saves me a few minutes. But over the course of a year, for invoice after invoice, that time adds up. Instead of me doing the busywork, I'm letting the computer do it for me. I only get involved where appropriate. I'm a fan of Pages because of its scriptability and ease of use for simple documents. In fact, were Pages not scriptable, I'd convert all my Pages scripts to Word and stop using Pages altogether. I have things to do that don't involve hoping a developer decides my feature request is important enough to implement.

76 Reader Comments

Other factors can limit things further—the new mail service could be a hosted service (like Gmail) where you have no direct access to the server. So much for just copying the mail store from server A to server B.

I love automation, it one of the main reasons I like using UNIX-y OSes such as OS X and Linux (I'm aware of Powershell, but I got set in my ways 10 years ago and have no reason to change). I may even be guilty of over-automating my workflow. Last week I spent two days writing a python script to do a task I'm not even sure I'll ever have to do!

Agree with the author, automation in an app is a valuable feature. It shouldn't be all that hard to add some commandline options to almost any program, so I imagine the reason it doesn't happen is simply ignorance of how valuable users would find them.

When I was in high school, a local factory was switching from an old mainframe system to SAP. They could easily get CSV spreadsheets of data from the mainframe system, but it often had to be manipulated or cross-referenced to be imported into SAP. Since SAP apparently charged a fortune for custom import batches, they hired a bunch of teens to manually enter the data using the SAP client, one record at a time.

The photoshop user story is something I've run into personally, although with Canon's RAW converter rather than PS. Canon's RAW converter lets you do tons of adjustments to various image properties to get the final 'in camera' output looking like you want. It lets you save this set of adjustments to a file which it can then load when you open a different image to apply the same set of corrections. This is useful, because for a bunch of photos taken in the same setting (say, an outdoor sporting event), the same set of corrections probably works for a very large subset of files.

The problem is, you have to manually open each image one at a time you want to apply it to, load the corrections file, and then convert to JPEG. Canon lets you batch process a set of RAWs into JPEGs through the tool, but you cannot apply a corrections file to that batch. It's a really, really dumb blind spot in the otherwise fantastic RAW converter they provide, and it doesn't seem like there is really a good reason for it to be there other than some developer didn't think that a user would ever need it. 'Production environment' seems to be a big miss for a lot of developers when they're thinking about user stories.

When I was in high school, a local factory was switching from an old mainframe system to SAP. They could easily get CSV spreadsheets of data from the mainframe system, but it often had to be manipulated or cross-referenced to be imported into SAP. Since SAP apparently charged a fortune for custom import batches, they hired a bunch of teens to manually enter the data using the SAP client, one record at a time.

It was the easiest job I ever had, once I learned how to use AutoIt.

It would terrify you how common this is even now. My girlfriend spent a large portion of her internship at HP this past summer doing basically exactly that, and it was a college internship. That paid quite well.

It's been a few years since a software called Nuke began to dominate the vfx industry.

Nuke is used for compositing moving images, in layman terms: photoshop on steroid having a baby with a 3d software. It also costs an arm and a leg.

It's, in general, flabergasting but the automation possibilities, in particular, are totally insane.

It's available on OSX, linux and windows, it uses QT for it's GUI and I've seen impressive cross-platform constructs.Everything in it is accessible in python and TCL and when you cut/copy/paste things from it, it freaking show as human readable code/script in the pasteboard... You can copy/paste that in a email/IM, the other end can repaste it in nuke and voilà!

Project files are called scripts and are also readable, I would say that's it's more some weird API/DEV thingy with a QT frontend that make it look like a "user-usable" software. It is also multi-threaded: i've seen it running on a obscene AMD quad sockets multi-multi-cores linux workstation and it used all core at 100% (something like 32 actual cores!)

It is overkill for most people but it gives nerdgasms to the rest. Flabbergasting really, it constantly gives me epiphanies about maths/space/time and the fabric of optical reality! Should every piece of software be like that? Is infinite expandability against the KISS ethos?

AppleScript is a life saver for me. It saves so much time it's ridiculous. Since the last installment by JCW, I had to add to metadata fields to my main Photoshop script. In five minutes ( using ScriptDebugger to look inside Photoshop as it's running to get the info I needed) I was able to determine the values I needed to modify the IPTC Core "Owner URL" and "Copyrighted" fields in Photoshop files (tif, jpg, and psd) and can now write the appropriate information into hundreds of files in minutes. To do it manually would take days.

That's the power of automation. Time well spent developing workflows. Now if I could just convince my co-workers such automation would be worth taking time to develop.

AppleScript is a life saver for me. It saves so much time it's ridiculous. Since the last installment by JCW, I had to add to metadata fields to my main Photoshop script. In five minutes ( using ScriptDebugger to look inside Photoshop as it's running to get the info I needed) I was able to determine the values I needed to modify the IPTC Core "Owner URL" and "Copyrighted" fields in Photoshop files (tif, jpg, and psd) and can now write the appropriate information into hundreds of files in minutes. To do it manually would take days.

That's the power of automation. Time well spent developing workflows. Now if I could just convince my co-workers such automation would be worth taking time to develop.

You see, if you're the only one that knows it, that's all the less work and all the more time you have compared to them.

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

PS: The only problem I have with automation tools in programs that especially in the past they generally forced you to use the most horrible languages ever invented ("just because every other programming language for non-programmers miserably failed at this goal, doesn't mean *this* one will fail") - hello AppleScript and VB.Luckily the last few years that has gotten much better..

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

I justify this three ways:

1. I learn things during the process of scripting it, either about scripting in general, or the scriptable features of the tools I use, or about the process itself, which I can then apply to other projects2. It reduces my level of frustration and monotony, which is priceless3. It reduces the rate of error

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

I justify this three ways:

1. I learn things during the process of scripting it, either about scripting in general, or the scriptable features of the tools I use, or about the process itself, which I can then apply to other projects2. It reduces my level of frustration and monotony, which is priceless3. It reduces the rate of error

1. I learn things during the process of scripting it, either about scripting in general, or the scriptable features of the tools I use, or about the process itself, which I can then apply to other projects2. It reduces my level of frustration and monotony, which is priceless3. It reduces the rate of error

4. Documentation. Take the script(s), mount on [your online repository here], maybe add some README ... then when I hafta remember "how did I do that?" I know. At least, I've got somewhere to search :-)

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

I justify this three ways:

1. I learn things during the process of scripting it, either about scripting in general, or the scriptable features of the tools I use, or about the process itself, which I can then apply to other projects2. It reduces my level of frustration and monotony, which is priceless3. It reduces the rate of error

It's not just about time.

Also, once somehing is automated you don't even have to think about it anymore. You can just schedule it to run automatically using whatever frequency you want.

I love automation, it one of the main reasons I like using UNIX-y OSes such as OS X and Linux (I'm aware of Powershell, but I got set in my ways 10 years ago and have no reason to change). I may even be guilty of over-automating my workflow. Last week I spent two days writing a python script to do a task I'm not even sure I'll ever have to do!

Automation is not just for repetitive tasks, but for any task you might need to replay. "Scripting-first" is a valuable habit to cultivate.

Even if you only do it once, you wind up with a script that tells you exactly how you did it, and if you do ever need to do it again, you don't have to reinvent the wheel.

Especially for server setups and software installation or configuration, if you write a script for everything you can, you'll have consistent, predictable results, automatic documentation of your actions, and a life-saver if and when you have to rebuild a system.

My own rule of thumb is to stop and write a script before I do something a second time, because at that rate there will likely be a third, fourth, fifth...

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

You don't have to use a tool just because it is available. It also helps if you understand when it is appropriate to use a particular tool. Say you have a data set that can be filtered or cleaned up using a scripting language or a feature that incorporates regular expressions. Both represent automation even though the latter is not a programming language. If a piece of software drops the former, it is sacrificing flexibility. If a piece of software drops the latter, it is sacrificing flexibility. If a piece of software drops both, it is sacrificing both by making a human do the job of a computer.

When I was in high school, a local factory was switching from an old mainframe system to SAP. They could easily get CSV spreadsheets of data from the mainframe system, but it often had to be manipulated or cross-referenced to be imported into SAP. Since SAP apparently charged a fortune for custom import batches, they hired a bunch of teens to manually enter the data using the SAP client, one record at a time.

It was the easiest job I ever had, once I learned how to use AutoIt.

I did something similiar with Delta Dental for an internship 2 decades ago, and they fired me when they found out why I was being more efficient. To this day, I refuse to use or be part of anything involved with Delta Dental.

Applescript support has long been a real conundrum for developers. It's absolutely great when it exists, but often it's the first thing cut when budgets or time get tight. Probably for good reason, seeing as a tiny, tiny minority of people use Applescript.

Sure, those people have an outsize impact on other users, since they are the power users, and typically the ones answering the "which ___ should I buy" from other, less-savvy people. But still, if I were a developer and I had to choose between major feature A and Applescript support, I'd probably choose the former every time.

Applescript support has long been a real conundrum for developers. It's absolutely great when it exists, but often it's the first thing cut when budgets or time get tight. Probably for good reason, seeing as a tiny, tiny minority of people use Applescript.

Sure, those people have an outsize impact on other users, since they are the power users, and typically the ones answering the "which ___ should I buy" from other, less-savvy people. But still, if I were a developer and I had to choose between major feature A and Applescript support, I'd probably choose the former every time.

Who said anything about monotonous? Reading comprehension fail there, bub.

I was just criticizing the author for wanting to automate everything. There's something to be said for doing something manually. There's a "zen" like quality to it (for a lack of a better word.)

I, too, wanted to automate everything when I was young and foolish. Now I see that there are lots of things that shouldn't be automated even though it wouldn't be hard at all to do so.

For example, a dirty floor in an apartment. You could get a Roomba, or you could use a vacuum cleaner, or even a broom. I prefer to use the vacuum, but for small messes, I'll take the broom if you give it to me.

Cleaning the floor and keeping the house tidy has a certain "mindfulness" to it.

Who said anything about monotonous? Reading comprehension fail there, bub.

I was just criticizing the author for wanting to automate everything. There's something to be said for doing something manually. There's a "zen" like quality to it (for a lack of a better word.)

By definition you can only automate tasks that don't involve creativity, that are repetitive and don't vary much or at least have simple rules to decide what to do next. Now go and look up the definition of "monotonous".

For example, a dirty floor in an apartment. You could get a Roomba, or you could use a vacuum cleaner, or even a broom. I prefer to use the vacuum, but for small messes, I'll take the broom if you give it to me.

Cleaning the floor and keeping the house tidy has a certain "mindfulness" to it.

People relax in different ways, while you may prefer to cleaning the household (I used to clean my apartment in the mornings after nights of heavier drinking; very relaxing), others may prefer to save the time and go for a walk or meditate instead. Who's to say what's the objectively right thing?

It's not about automating everything, but only certain tasks that some individual finds bothersome.. and especially with computers these kind of tasks come up a lot. Nobody will agree on where exactly to put the boundary, but it certainly exists for everybody. For example while cleaning your normal-sized apartment once a week may be relaxing, having to clean a whole factory floor every day may quickly lead to you wishing for an automated solution.

From a Windows/Office perspective, VBA in Outlook, Excel, and Access has allowed me to do some pretty amazing things that would simply have not been possible without it. I created a small scale inventory control system in Excel that leverages an Access DB for records, and uses Excel for reporting, and I am not formally trained in programming anything (used MS BASIC on my TRS-80 Coco back in the day, and then self-taught the VBA)

From a Windows/Office perspective, VBA in Outlook, Excel, and Access has allowed me to do some pretty amazing things that would simply have not been possible without it. I created a small scale inventory control system in Excel that leverages an Access DB for records, and uses Excel for reporting, and I am not formally trained in programming anything (used MS BASIC on my TRS-80 Coco back in the day, and then self-taught the VBA)

Totally agree - while it may be not the fastest or most elegant language (never ever use an Excel UDF if you want something to happen fast), but it's easy to learn and has very deep access to the "plumbing" of the Office applications. We are totally dependent on it for the Excel workflow of all our analysts, particularly for case and scenario management. I know that proper programmers tend to hate it, but it has saved me countless hours over the years.

I have always found it shocking how many developers seem to think that it is perfectly reasonable for you to have to repeat the same sequence of mouse clicks 10s, 100s, or even 1000s of times in order to use their application. Every time I evaluate a new CAD or EDA tool, the very first thing I ask about is, "Can it be scripted?" If the answer is no, that's as far as my evaluation goes and they are politely shown the door.

The second thing I ask is, "Does it use ASCII databases?" A "no" here doesn't exclude the tool, but they better have a very good reason for using a binary data format. The problem is that even with scripting, the developer often forgets to script all parts of the operation so the only way to achieve scripting is to hack the database directly.

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

PS: The only problem I have with automation tools in programs that especially in the past they generally forced you to use the most horrible languages ever invented ("just because every other programming language for non-programmers miserably failed at this goal, doesn't mean *this* one will fail") - hello AppleScript and VB.Luckily the last few years that has gotten much better..

http://xkcd.com/1205/On the topic though, I've been automating a lot of small things in windows, but as people say it's most certainly not a pleasent experience compared to linux (got a rasbpi) and you often end up using a lot of cmd.exe (unless your using pshell) and multiple 3rd party softwares (autoit anyone?) to do things that should be perfectly doable through command line options. I do think software has gotten a lot better at including and adding options for both automation and more/better command line though (compared to 5-10 years ago).

There's also the other side on the whole automation craze though - every professional programmer I know - all intelligent and clever people - sooner or later has spent half a day implementing some script that saves her maybe 10 seconds per day. Break-even point: Somewhere around 2030.

And god I know I'm just as guilty of that as anybody else.

I justify this three ways:

1. I learn things during the process of scripting it, either about scripting in general, or the scriptable features of the tools I use, or about the process itself, which I can then apply to other projects2. It reduces my level of frustration and monotony, which is priceless3. It reduces the rate of error

It's not just about time.

Yeah, even the one-off scripts have long term benefits. If bumming a script takes the same amount of time as doing a task manually, I'll write the script. I build my experience, and I add to my collection of useful handlers that can be dropped in to future scripts.

Having been a Windows user for decades, a programmer and a former MS telephone support engineer on the Windows team, I have slowly learned to hate the OS.

I consider myself a Microsoft 'fan', I write apps on their stack and truly believe their developer tools and engineering technologies to be the best out there.

Never did I think as a teenager that I would have kids and be going grey while still seeing the same problems in Windows. I never believed a company with so much wealth, both financial and human, could become so lazy, or so tight-fisted about the radical change needed in their apps.

That they'd try to run Win32 for the rest of eternity, and get away with it.

Very quickly, this situation has caught up with them and they find themselves struggling in the modern computing era. It's poetic but it saddens me.

However, I invested my life and career in their technology stack and have reached a point where I face a hard decision to re-train myself as an iOS developer. That's a shame since I don't particularly like Apple, the company.

Windows 8 is my last hope. If it fails, the platform on which my career is based also fails. So far, with Windows RT on Surface, I see many of the same UX mistakes being made and I feel powerless, voiceless. They haven't helped people like me help them.

Unlike their dev stack, which is truly great, benefiting from an accessible Redmond team, feedback and bug reporting options built right into tools themselves, as well as a UserVoice portal for each major SDK, Windows has nothing. This incredibly important product suffers terribly because of this.

Apple doesn't need such things (yet), they already have a culture of obsessive axe-wielding perfectionists. But Microsoft has shown it cannot compete with esoteric products borne from their ivory tower, and that they need to open their eyes and ears. They need to empower their user-base.

I want people to fill it with suggestions and problems, vote for each other's suggestions and then maybe Microsoft will have to ask me to hand over the keys. I will gladly, but if they shut it down, I'll finally know their position on the matter.

I want Microsoft and its people to succeed and I want them to make great products. I want other people to feel they have somewhere to go to say, "Synching my keyboard layout setting between a US and a UK Windows device, is a terrible user experience!" and I want my kids never to have to see a desktop.ini file on their tablet.

OS/X has a choice of Unix shells available - the 'Terminal', see http://support.apple.com/kb/TA27005 which are powerful, documented and have a lot of support. I wish Windows' Powershell were as good.

Actually PowerShell is probably the best mainstream shell out there at the moment, quite some advantages when compared to bash or zsh - not something you'd have expected from MS after their decade long reliance on cmd.com, was quite surprised myself.

The real problem is the horrible console they still ship it with - what good is the best shell if you get it in a console that was already horrible and inadequate more than a decade ago?

PS: The only problem I have with automation tools in programs that especially in the past they generally forced you to use the most horrible languages ever invented ("just because every other programming language for non-programmers miserably failed at this goal, doesn't mean *this* one will fail") - hello AppleScript and VB.Luckily the last few years that has gotten much better..

I was thinking about the old Amiga-days throughout the whole article and this comment especially reminded me that Amigas (at least the leater iterations) had a fabulous system called ARexx to automate all kinds of things and let apps communicate with each other, so to say, making it possible to create workflows. Once again, they obviously were ahead of their time.I *think* ARexx had a C-like syntax and it was dead easy to use. I was horrified though when I saw that abominable creation named AppleScript. While it's usefulness might be high, the ugliness of its code was always higher, imho.

OS/X has a choice of Unix shells available - the 'Terminal', see http://support.apple.com/kb/TA27005 which are powerful, documented and have a lot of support. I wish Windows' Powershell were as good.

Actually PowerShell is probably the best mainstream shell out there at the moment, quite some advantages when compared to bash or zsh - not something you'd have expected from MS after their decade long reliance on cmd.com, was quite surprised myself.

I'm a die-hard CLI guy, and I have to say, I second this comment. PowerShell really does have some amazing functionality, with immensely deep hooks into, well, almost everything.

Want to convert a CSV to an XLSX file, complete with formatted headers, alternate color rows, or some such? PowerShell can do that.

Want to batch convert files to PDF? PowerShell can do that.

Want to have nearly all the functionality of a real shell like tcsh? PowerShell can do that, and in fact, mine does. Nearly every unix command I use regularly has some equivalent in PowerShell, and for those that don't, small commandlets aliased to the unix names work perfectly well.

You really have to try it again, if you haven't in the recent past. It's pretty amazing, all things considered.

When you run into problems like these, you can also just fix them yourself.

Examples: Photoshop didn't have scripting??? Wow. Gimp had them from day 1.Binary file format? Those are considered very bad form in the OSS world. The Way of Unix states: "All files are text files."Need a secure mail client (or entire operating system)? No problem in my world.Automation - Bash and Python are AMAZING. Add SED and it will blow your freaking mind.Bulk file processing - cake.Converting file formats - cake.

Since we're doing anecdotes, I'll offer this one on the file formats:I had an AVI clip that I needed in an animated GIF with different size and needed to clip to length. It also had a rather insane color depth so I knew I'd have to substantially reduce the palette.Since all we have at work is stupid useless Windows computers, I saved the file to a flash drive, and at home I used FFMPEG on my Linux box. It took me 30 seconds to get the first GIF, then all of 20 minutes to optimize all 3 parameters.

Why is this possible? We developed the principles you are striving to define, gosh, that was 43 years ago.22 years ago we shed our proprietary shackles.That solution is called GNU/Linux. Try this one.

When you run into problems like these, you can also just fix them yourself.

Examples: Photoshop didn't have scripting??? Wow. Gimp had them from day 1.Binary file format? Those are considered very bad form in the OSS world. The Way of Unix states: "All files are text files."Need a secure mail client (or entire operating system)? No problem in my world.Automation - Bash and Python are AMAZING. Add SED and it will blow your freaking mind.Bulk file processing - cake.Converting file formats - cake.

Since we're doing anecdotes, I'll offer this one on the file formats:I had an AVI clip that I needed in an animated GIF with different size and needed to clip to length. It also had a rather insane color depth so I knew I'd have to substantially reduce the palette.Since all we have at work is stupid useless Windows computers, I saved the file to a flash drive, and at home I used FFMPEG on my Linux box. It took me 30 seconds to get the first GIF, then all of 20 minutes to optimize all 3 parameters.

Why is this possible? We developed the principles you are striving to define, gosh, that was 43 years ago.22 years ago we shed our proprietary shackles.That solution is called GNU/Linux. Try this one.

You know, GIMP and FFMPEG are also available for stupid useless Windows computers.

There's a certain consensus in the domain I work in: GIMP is a heinous POS that make every artists sadder to use linux. It's far from a panacea.