I'm very excited to announce the availability of my Automator Action Packs again. The new packs are fully compatible with the latest macOS versions, including Sierra and High Sierra.

Unlike previous versions, these packs are for sale via my own store, instead of the Mac App Store. There was a long delay in availability as I built a working installer and tested a new service to create a third-party store.

Why am I no longer selling through the Mac App Store? For much the same reasons as other developers, plus I was afraid after much work the apps would just be rejected by Apple. Why? Because Automation Actions are a very different type of animal, and Ben Waldie told me of all the hoops he had to jump through to get the first set approved years ago.

The packs are now priced between $14.99 and $19.99, or you can purchase all six packs as a bundle at a discounted price of $79.99.

If you've previously purchased the packs from the app store, e-mail me a screenshot of your purchase info and suggest how much of a discount you would like. Those who are willing to pay full price after years of use would be much appreciated to help support continuing development.

Note that each purchase is a one-time cost. I've gotten several e-mails which read something like, "I've been using your Automator actions for years and now they are no longer working in High Sierra!" Consider if these actions were only available on a subscription basis. Even at only $2 a month, my revenues would more than double for each additional year of use. I do understand why so many developers are moving to the subscription model!

Over the coming weeks, I will be posting several videos and example workflows to further explain how these actions can be used. In the meantime, Happy Automation!

I'm very excited to be leading a one-day Scripting Boot Camp August 8 at the CMD-D Masters of Automation Conference. Part of a two-day conference held in Santa Clara, California, this class will be an introduction to AppleScript, the powerful tool for automation included on every Mac.

What is AppleScript and why should I learn it?

AppleScript is a scripting language which is sometimes called Apple's best-kept secret. While many scripting languages might be referred to as "programming lite," AppleScript is unique in that it uses English-like syntax to make this automation tool more approachable, even for those without any previous programming experience (like me).

Most users learn AppleScript on-the-fly, meaning they are busy with other tasks in a deadline-driven world. Who has the time to stop completely and learn something else? With AppleScript, a new user might work on a developing a script, then be pulled away by another task for days or even weeks. When he or she returns to the script, the English-like syntax really helps ease the process of getting back into the flow. This not only helps beginners but even veteran users like myself because, hey, I forget things as well.

What are the benefits of AppleScript automation?

One of the primary goals of computers is to automate tedious tasks. Yet for various reasons, we often find ourselves doing the same tasks again and again every day. Again and again. And again. Every single day. Then again.

It gets repetitive.

One solution is to use a macro utility which can record and repeat actions in the user interface, like choosing menu items in a sequence, or recording an action in Photoshop.

AppleScript is much more powerful. Much more. It allows a user to make intelligent decisions based on conditions and needs. Instead of driving the user interface, AppleScript works directly Apple Events, the powerful technology which allows Mac apps to communicate with each other. AppleScript can also speak to multiple applications, chaining them together in a powerful workflow automation.

For example, a user might build a script which watches a folder for incoming files. When files arrive, the script could gather information from the files, add that information to a database, move the files to another location, then create a nice layout of text and images, use that to update a web page and a print publication, and alert others to the finished process bycreating an e-mail with an attachment.

Could the script play a song in iTunes for your enjoyment while you watch your Mac work? Oh, yes. But AppleScript automation is fast, so in most cases it would need to be a short song.

Will the Scripting Boot Camp be a class for pure beginners or people with some AppleScript experience?

Yes.

While targeted to beginners, I will include some more advanced tips as well, much in the same style as Shane Stanley and I used for years at AppleScript Pro Sessions. While no class can cover everything about AppleScript, I'm including lots of resources for attendees to use afterwards. This includes sample scripts with detailed comments, only some of which we will cover fully in class. I'm also including a quick reference guide—a PDF of dozens of pages covering some basic concepts and commands.

I will do my best to follow-up with students after the class, and see about forming a forum or mailing list for us to continue to discuss writing scripts. The main goal: To make sure people have a foundation beyond the one-day class to continue learning more about AppleScript.

Will I learn how to use Script Editor in class?

You will learn the basic of using Apple's free tool to examine dictionaries and create and edit scripts. Towards the middle of the class, I will switch to using Script Debugger, the excellent development environment from Late Nite Software. Script Debugger 6 has so many features which help beginners, including three different dictionary views and line-by-line stepping. These same features help me to do a better job of teaching AppleScript in a classroom setting.

What is the schedule?

The Scripting Boot Camp will be from 10am until 5pm local time on Tuesday, August 8. Before you register, be sure to check out the second day of the conference, which goes well into that evening. The speakers will include automation experts Andy Ihnatko, Jon Pugh, Jason Snell, John Welch, Sal Soghoian, and David Sparks. I'm looking forward to learning much!

Last week, Sal Soghoian announced that his position as Product Manager of Automation Technologies at Apple had been eliminated. Today seems like a good day to reflect and say thanks…

I first met Sal when he was an independent consultant. It was 1996 at Seybold Seminars, a print-industry expo.

A tiny group of us from CompuServe's DTP forum were wearing protest t-shirts, asking Adobe to improve support for AppleScript. Sal was already a respected AppleScript authority. When I met him on the expo floor to show him the shirt he said something like, "That's nice. But I'm trying to improve scripting support by working within companies."

At the time I found this answer a little haughty. I wanted him to join in with our protest. Then a few months later we heard he had been hired by Apple. In our small group people thought, "Let's hope he is successful working within Apple.”

By all accounts he was, and the difference was remarkable in only one year.

It is hard to describe how low Apple was in 1996. At that expo, Apple had no booth. A VP hosted one noontime Q&A in a corner of the giant hall, and one reception off the show floor in a small room. Meanwhile, the experts in the seminars I attended all delivered the same message: Apple is dead. The future of publishing is Windows NT.*

That was the sinking ship Sal boarded in January 1997. I made my own much smaller leap of faith that summer, quitting my job and forming Scripting Matters to work full-time as an AppleScript consultant.

At the expo that fall the difference was mind-blowing. Apple had a large exhibit space on the floor. When I entered Moscone West the first thing was a booth proclaiming the great benefits of AppleScript in large letters of Garamond Book. THE FIRST FRIGGIN’ BOOTH!!!

There stood Sal. He studied my brand new business card, asked a few questions, and then gestured for two engineers in the booth to come over.

"This guy, " he said, “This guy is developing AppleScript solutions full-time. Full-time! This what I've been telling you guys about. People are doing serious things with scripting."

The engineers looked surprised and still somewhat dubious. That was my first glimpse of the challenge Sal faced at Apple. He not only had to struggle to get other product managers and and developer teams to take AppleScript seriously, but I suspect sometimes he faced the same challenge with his own team members.

Thank goodness Sal is a fighter. One battle was do-or-die: getting AppleScript into Mac OS X. Rumors were that some at Apple were saying things like, "Why would anyone need AppleScript? They can use perl!”

I played a small role in that battle. Unsolicited, I sent Sal a written report of how much time and money AppleScript was saving one of my clients. It included photos of racks of iMacs running scripts 24/7 for all three shifts. The report gave Sal something concrete and real-world to take around Apple as he fought the battle. And somehow he won: AppleScript survived and transitioned into the new OS.

More adventures followed. As part of his goal to make automation accessible to everyone, he introduced Automator. I've always wondered if some of the shortcomings in its interface and functionality were due to battles fought and lost. Regardless, it was a valiant effort.

Sal also employed a great strategy to at minimum keep AppleScript alive, making sure that various Apple programs and processes were dependent on Apple Events, and getting a couple of incarnations of AppleScript into Xcode.

There may have even been one time when he persuaded an engineer to include AppleScript support in a new product release without the product manager’s knowledge. Once a feature is shipped, it is in.

I don't want to give the impression that I know Sal well. I don't. During the times he came to our AppleScript Pro Sessions he told a couple of stories, and sometimes let a few things slip out. But he didn't dwell too much on the past.

We did recognize him for his battle spirit once. I heard he was a Tolkien fan. At an AppleScript Pro not too longer after the Peter Jackson movies, Shane Stanley and I gave a Sting replica to Sal. We presented the sword on a hotel pillow with Howard Shore’s soundtrack in the background and a few words about how “even the smallest technology” can change the course of the future.

As Apple grew exponentially, Sal continued to be a fighter, but always a rebel with a cause. He hosted his own independent web sites the entire time, which enabled him to easily distribute free automation tools to the community.

Now Sal is gone from Apple after almost 20 years. That’s a long time for any manager to survive at a such a demanding corporation. When the news hit, people started speculating, and quickly descended into opinions of How Things Could Have Been Done Better during Sal's tenure.

Already there is much discussion of one sentence from Sal: "If user automation technologies are important to you, then now is the time for all good men and women to reach out, speak up and ask questions."

I won’t speculate on that in detail now beyond one thought: I bet the future death of AppleScript will be discussed for the next 10 years. I have no more details to support that than people speculating otherwise. But you only need to read a little further at https://macosxautomation.com/about.html to see Sal’s optimistic conclusion.

Regardless, none of this discussion about AppleScript’s future would be taking place if not for a guy boarding a sinking ship in 1997—a bigger risk than many of us have ever considered taking. Thanks in part to that risk, I’ve made a decent living and helped a lot of people with AppleScript for two decades now.

Thank you, Sal. If you’ve still got the sword, I hope you can mount it on a wall and let it rest now.

"Why on earth would anyone want to script a drawing program?" I'll admit that was my first thought when years ago I heard about a plug-in to add AppleScript support to Adobe Illustrator. I could understand how scripting support was essential for page layout programs. But Illustrator was a program for creating art, involving many design decisions that only a graphic artist could make.

I wasn't alone in that thinking. In this interview, Mark Alldritt of Late Night Software recounts the story behind adding scripting support to Illustrator and getting people interested:

Below, I've included some summary comments about what Mark shared in the interview.

Fortunately, I soon changed my mind about Illustrator after Shane Stanley showed me what could be done to create charts and graphs using AppleScript. I was a Freehand user at the time, but that information led to one of my first Illustrator automation jobs: creating charts for the publications of a state government agency. That project was almost 15 years ago and involved Excel, Illustrator, Photoshop and an early version of InDesign. Here is a short demo of the Illustrator portion of the automation:

Since then, I've done many projects using AppleScript and Illustrator, mostly for the financial industry and with far more sophisticated charts than shown above. But I've also used AppleScript and Illustrator for a variety of other workflows: color replacements in hundreds of documents, importing text and graphics for sophisticated database publishing, preflight and clean-up routines for checking many files, and much more.

Most of my Illustrator projects have been developed under non-disclosure agreements since my clients consider Illustrator scripting to be such an important competitive advantage. The state government job remains the one which I can show. Success stories in automating workflows in Illustrator are remarkable. Most companies recoup the cost of development within a year, and then go on to save a great deal of money and time. Thank goodness Chuck Sholdt saw the potential early on and got Mark interested in developing AppleScript support. We should also thank Adobe for its early interest and continued support over the years, as well as Shane Stanley for all of his example scripts.

More on the interview and Late Night Software

Mark's product, Script Debugger, is simply the best AppleScript tool available and is now in its 21st year of development. His long history as a successful independent software developer is covered in an excellent blog post.

In the interview above, Mark provides many interesting details:

He originally looked at developing scripting support for Aldus Freehand, but the program's APIs did not offer enough interaction. That was fortunate, considering Freehand didn't last much longer after being acquired by Adobe.

Making sure the plug-in worked on Windows was of primary importance since at that time Apple was considered to be near death.

He showed a preview of the plug-in to Sal Soghoian, then new to Apple as AppleScript Project Manager. Sal was "blown away," asking "is this real?" or was it just manipulating layers. It was all real.

Sal showed it to Steve Jobs, who then decided to let Sal demo the plug-in at a MacWorld keynote. That got Adobe's attention, and Mark signed a letter of intent with Adobe behind the curtain during Sal's keynote demo. Great story!

Funds from the sale to Adobe allowed Mark to continue development of Script Debugger, even though at that time Apple's future was very questionable, to say the least.

Besides the money, work on the plug-in led Mark to develop the basis of one of Script Debugger's best features: The Dictionary Explorer. Because he was "too lazy" to write scripts to test all functions, he needed a live way to look at an AppleScript dictionary.

Script Debugger 6 development is ongoing, with a general plan to release it after Mac OS 10.11 becomes available. Yes!

With Adobe Illustrator, we see once again that when a developer chooses to add scripting support to a program—even a drawing program—users can end up doing remarkable things.

Apple introduced a great variety of new automation features and updates in Yosemite. I've written up a quick summary below with links to more detailed information.

AppleScript

AppleScript users have been requesting a built-in progress indicator for years. In Yosemite, Apple delivers. New AppleScript properties allow script developers to show and control a traditional progress bar in applets. In Script Editor, progress is shown at the bottom of the main window. For the Scripts menu, an "Automation" menu appears to show progress.

From left to right, how the new progress indicator displays in applets, in Script Editor and the Automation menu (run from the Scripts menu)

AppleScript users have been able to access the power of Objective-C since the introduction of AppleScriptObjC five years ago. Originally, script developers had to learn to use Xcode to take advantage of this feature. In Mavericks, AppleScriptObjC can be used directly within regular scripts, but only through the use of separate script library files saved in a special format.

In Yosemite, separate libraries are no longer needed: AppleScriptObjC can be used directly in any script. Shane Stanley has released an update to his book, Everyday AppleScriptObjC, which covers how this works. As usual, Shane's book contains a lot of powerful sample scripts with detailed explanations. In the introduction he writes, "…in Yosemite, AppleScriptObjC is available everywhere, all the time. Truly Everyday AppleScriptObjC…Welcome to the modern world of AppleScript."

For power users of AppleScript, streamlined AppleScriptObjC access is the most significant new feature. But Yosemite also brings some improvements to AppleScript handler parameters, do shell script, as well as bug fixes. See the full release notes for more information.

Automator

Otto is getting some love in Yosemite as well. Workflows can now be saved as Dictation Commands, a new feature in Yosemite which appears to be an improvement over Speakable Items. A post by Christopher Breen at MacWorld covers how to turn on Dictation Commands and then start a workflow with a spoken command. (Red Sweater developer Daniel Jalkut discovered that Dictation Commands can also launch scripts.)

Sal Soghoian has released a set of new Automator Actions for Keynote. These are not included with Yosemite, but are available as a free download. The set includes many cool actions here, including Present Slideshow with Narration and Add Charts with Numbers Table Data.

Two of the new Keynote Actions available for download.

Automator in Yosemite has a new Run JavaScript action allowing Automator users to call custom code written in JavaScript for Automation (see below for more info). This new action works in the same way as the existing Run AppleScript action.

New scripting support in iWork applications

Pages, Numbers and Keynote now all provide scriptable access to placeholder text objects, including a tag property for specifying a custom script tag to make it easier to change objects via scripting. Pages has added the ability to assign a tag for placeholder text in the user interface with the "Script Tag" field shown below.

The new Script Tag field in Pages makes it possible to assign custom tags to placeholder text for easy access via script.

To demonstrate these enhancements and provide some cool mail-merge/database publishing capabilities, see the new Pages Data Merge application. A demo movie provides more information.

As an automation developer, I'm always looking for better scripting support in Apple's own applications. Even with all this news, I find the new Script Tag field in Pages one of the most encouraging automation improvements in Yosemite. It is great when Apple adds any new objects to a scripting dictionary, but to add a user interface element specifically for working with scripting automation is huge. Let's hope we see even more of this in the future.

I've examined the scripting dictionaries of all three iWork applications, and beyond placeholder text and cosmetic improvements I see one new feature: Numbers has scripting support for the new Transpose feature.

JavaScript for Automation

There is now a new choice in writing scripts: JavaScript for Automation (JXA). Every application which supports Apple Events can also be scripted via JXA, which works via the scripting bridge.

Past attempts by Apple and third-party developers to bring Apple event support to sophisticated scripting languages such as Ruby and Python have not seen widespread adoption. But JXA has two big advantages over previous efforts: 1) JavaScript itself is hugely popular, with a great number of users developing for web browsers and other purposes. 2) Apple has integrated support for JXA directly into Script Editor.

You can use Script Editor to view dictionaries detailing an application's commands and objects. Like AppleScript, JXA can access Objective-C and Cocoa frameworks. The latter feature has led to some excitement at the prospect of using JavaScript in Script Editor to develop native Mac OS X applications with rich interface elements. While the idea of avoiding Xcode to develop applications certainly has appeal, I'm interested to follow what kind of success JXA developers have with writing Mac OS X apps without Xcode.

AppleScript users have had access to this feature for years, but other than the good work by Doug Adams at Doug's AppleScripts for Itunes, I have yet to see many AppleScript users adding interfaces this way. Instead, Automated Workflows and other developers have used AppleScriptObjC in Xcode to develop full-featured applications, perhaps in part due to the availability of Shane Stanley's excellent book on the subject, AppleScript Objective C Explored. I would advise JXA users wanting to develop apps to read this book. It has an excellent summary of the most important Xcode features, and much of the information about when classes (coming via the scripting bridge) need to be coerced is applicable to JXA as well.

Extensions in Yosemite

Automation in the AppleScript world has often been about scripting multiple applications to interact with each other. For years I've been using AppleScript to build scripts which grab data from apps like Word, Excel or FileMaker, generate sophisticated charts and other graphics in Illustrator, use InDesign to combine it all together in a sophisticated page layout, create PDFs and then distribute the final product via e-mail, FTP or other means. AppleScript can make this into a one step-process.

The ability of Mac applications to interact with each other faced some new challenges with recent OS X sandboxing restrictions. In Yosemite, we are seeing a new effort by Apple to standardize how applications can interact: Extensions. Alex Guyot with MacStories has an excellent article covering Extensions in Yosemite. (He also discusses JXA.)

Currently, Extensions allow for some UI-centered interactivity between applications. Automation developers may find immediate use for FinderSync Extensions and possibly other types of Extensions. Will Extensions in the future allow new ways to automate complex workflows? I hope so, but much remains to be seen about how developers will employ Extensions, and if Apple will open up the technology to scripting.

The future of automation

With so many improvements I've only see one errant assumption made by a few people: With JXA, Apple is finally replacing AppleScript, some say. Wrong.

There are many reasons why AppleScript will continue in the future, but a single point is enough to make it clear. Note all of the improvements to AppleScript in Yosemite described above. Why bother if AppleScript was being replaced? Case closed.

Perhaps the more interesting thing to watch is whether JXA will see widespread adoption. I can see many users developing solutions with JXA in Script Editor. And a few going on to develop full-fledged applications in Xcode. But AppleScript developers have many great tools for development that go beyond using a basic editor while avoiding the challenges of Xcode: Late Night Software's Script Debugger, Satimage's Smile, and ASObjC Explorer are all useful development environments with different features. I'm interested to see what third-party editing and development tools will emerge for JXA, but often a strong user base must emerge first.

Regardless, with new features available in Yosemite, the future of Mac OS X automation is strong, and AppleScript will remain a big part of that.

Automated Workflows now has a company account on Twitter: @scriptsmatter

It's my first venture into Twitter-dom, and I owe many thanks to Anne-Marie Concepción. Her excellent Twitter for Business course at lynda.com was very helpful. I’ve viewed several of Anne-Marie’s courses over the years, and they were all outstanding.

Anyone who has followed Anne-Marie’s career at Seneca Design, InDesignSecrets and elsewhere knows that she is extremely knowledgeable about the publishing world and covers some other fields as well. I’ve seen her give conference presentations on InDesign and would rank her among the best.

Confession: I have a very critical nature. Show me an Apple keynote and I’ll list 20 things which could have been done better. I’m so critical that when I’m leading a seminar I think, “Please, please don’t let there be anyone in the audience like me.” I don’t want to see that person's feedback form.

Still, there are many top-notch presenters and trainers deserving of praise. Among lynda.com authors, Anne-Marie is the best. What makes her so special?

Then I realized…Anne-Marie as the Vin Scully of lynda.com. Yes, I love baseball. And although I’m not a fan of the Los Angeles Dodgers, frequently I will tune into a Dodgers broadcast just to listen to Scully call the game. He’s simply remarkable, broadcasting the entire game solo as opposed to the two- or three-person crews covering most other teams. The rest of the announcers have conversations with each other throughout the game. Somehow Scully manages to have a conversation with the viewer.

That’s what Anne-Marie does at lynda.com: she has a conversation with the viewer. There are some very good lynda.com authors, but it is obvious many are reading from a script. Not so with Anne-Marie. She comes across as having something to share with you—the viewer—and she wants you to know it because it is important, as if she were talking with you at a coffee shop. That's very challenging to do when it is just you and a computer in a recording room.

In general, I find lynda.com a great resource, well worth the monthly fee my business pays. Imagine all the various Mac programs which people ask me to automate. Knowing a program well is just as important as knowing a scripting language. How can I keep track of the ever-changing features?

I could turn to documentation, books and web searches, but the written word often goes to torturous lengths to describe an interface, with long descriptions and screenshots spread across multiple pages. Videos are so much better for this type of learning. What about free videos on YouTube and elsewhere? A few can help, but the lynda.com courses are far more consistent in quality, and the interface has some very helpful features, such as the complete written transcript (love it) and the new ability to save notes.

With all that being said, not everything at lynda.com is great. I can’t recommend the AppleScript course, even as an intro. And the most common problem is authors talking way too fast. As in I've-got-so-much-to-tell-you-but-want-to-keep-this-section-under-x-minutes-so-I-will-cram-in-so-much-that-you-will-retain-almost-nothing. Critical me.

Back to Anne-Marie. I've received nothing but positive feedback when I’ve recommend her courses to others. Don't think she does this well just because she is a natural. A lot of hard work goes into each video course, to say the least. At last count, she appears to have done 22 videos on social media and Adobe products. In my mind, that’s the equivalent of writing 22 technical books. Wow.

I don’t know the inner workings of lynda.com, but I would hope there is some type of internal course for first-time video authors—something every presenter must view before developing a course. If there is such an internal video, by all means it should be done by the best: Anne-Marie Concepción.

Full disclosure: I’ve met Anne-Marie three times at events, and about 10 years ago she was kind enough to make a home-cooked dinner for me and a travel-weary Australian in the land of Chicago. A memorable meal.

As another consultant in the automation world, I've long admired Ben’s work at Automated Workflows. He is far more than just an expert developer. He has been a great advocate for AppleScript, Automator, and other Mac-based automation technologies. Through presentations, articles, books and app store products, Ben has shown what great things can be done with Mac automation.

I also happen to know that Ben and his wife Jen are just really nice people. I’m sure great things await the Waldie family in California. In accepting the new job, I know Ben had concerns about making sure his clients and products would continue to be supported.

That's where I step in. My main goal is to provide the same great custom-developed solutions and prompt service to existing clients. I also look forward to continuing to maintain and enhance the company's excellent products, as well as taking a larger role in serving as an advocate for automation technologies.

Filling Ben’s shoes would be a difficult task for anybody. Fortunately, we share the same commitment to quality service and much of the same technical expertise. I've been working with AppleScript and other Mac automation technologies for over twenty years, and have also worked with other languages and applications. I’ve even done some iOS programming, creating an early iPad app which was recognized as New & Noteworthy by Apple.

If any tasks are outside my area of expertise, I have a network of skilled developers and consultants. A long-time associate is Shane Stanley, who many recognize as an expert in this field. Shane wrote the book on AppleScript Objective-C programming, and more recently has branched into Objective-C development with his own application, ASObjC Explorer.

As a trainer, I organized and co-taught AppleScript Pro Sessions, a five-day in-depth training event. I've led seminars for Adobe and Apple, including a very successful European tour focused on automating InDesign, Photoshop and Illustrator with AppleScript. I enjoy teaching and sharing videos with helpful tips and techniques.

Like Ben, I've been able to create some very sophisticated custom solutions for a wide range of purposes, helping individuals, small businesses, and Fortune 500 companies. I look forward to continuing this role through Automated Workflows. I've told students and clients that automation is often only limited by the imagination. I have years of experience in coming up with creative solutions to some difficult workflows.

Contact me today about saving time and money through automation, and let’s get to work!

It’s our pleasure to introduce Ray Robertson as the new owner of Automated Workflows. Ben has accepted a position with Apple Inc., and we are relocating to sunny Cupertino, CA this August.

You may know Ray from Scripting Matters and Scripting Events, LLC, where he has provided professional AppleScript consulting services and the wildly popular AppleScript Pro in-depth training sessions. Ray is an extremely talented Mac developer and industry expert, and we have complete confidence in his ability to continue providing top-notch productivity services and workflow solutions long into the future. He’s an outstanding guy, and we can’t think of anyone we’d trust more with our business.

Thank you to all those in the Mac community who have supported us these past 11 years, purchased our products, hired us as consultants, read our articles and books, attended our presentations, and so on. We appreciate your confidence and support. Stay productive and best of luck with your workflows! Now, please lend us a hand in welcoming Ray!

Let’s say you’ve got a really cool Automator workflow that saves you tons of time but takes a while to run. Do you really have to sit around, twiddling your thumbs while waiting for it to finish? Wouldn’t it be nicer if you could go get a latte instead and get an alert on your iPhone when the workflow is finished? That’s just one example of the kind of thing possible with the latest version of If This Then That (IFTTT). [Read more on Macworld.com...]

Automated Workflows worked closely with Valspar to develop and deliver a suite of custom software utilities that help designers quickly and accurately organize and visualize colors for the web and print. As a result, Valspar’s designers are now able to keep up with growing partner demand, while continuing to devote time and attention to creativity and color. [Learn how Valspar uses automation...]