March 28, 2018

Will robotic process automation take your job away?

Filed under: Automation,General,Macro Recorder — Marcus Tettmar @ 2:25 pm

TLDR: No! That’s not what we’re here for. Robotic process automation is here to help you.

We often get called in to help a company automate a process. Many times this involves automating something that an end-user does. To make macros that make their job easier, less painful, and make them more productive.

Initial Resistance to Change

Sometimes, at the outset, we (or the IT department proposing Macro Scheduler as a solution) detect a little resistance from the end user. If not properly briefed they may be concerned that what we want to do is take work away from them, and they may be concerned that the macros, or software robots, are about to take their jobs away.

Epiphany!

Nothing could be further from the truth and by the time we’re done, the end users love us to bits and usually give us a long list of other things they’d like us to automate! Often they discover how easy it is to do it themselves with tools like the Macro Recorder and other code wizards.

I’ve written thousands of macros for hundreds of companies. I’ve never worked on anything that was designed to take a job away from an employee, other than one the employee didn’t like doing and didn’t have time to do without it impacting on their core purpose. In every case the macros we wrote were there to make the employees’ jobs easier, or to allow them to be more productive in more important areas. For example: removing a tedious admin task from an already overstretched clinician, allowing them to see more patients.

I suppose you could argue that the many over-night data-entry style macros we’ve written could have been done instead by a team of data entry personnel. But such a team didn’t exist to start with, or would have been cost prohibitive, or too error-prone to be considered in the first place.

Improving Productivity

So to answer the question, no, I don’t believe robotic process automation is about taking jobs away. It’s not about replacing staff. In my 21 years of automating user interfaces this isn’t what I’ve seen. Instead, I’ve been rewarded with making people’s lives easier, removing cumbersome, painful, processes, or using macros to simplify and improve an existing process.

March 15, 2018

Saving You Time and Money With Robotic Process Automation

Filed under: Automation,General,Macro Recorder — Marcus Tettmar @ 3:24 pm

Before Macro Scheduler existed I was a junior member of an IT department. As part of my job I built small tools to automate specific tasks. At the time I was using VB. Each time I had to automate a task I had to reinvent the wheel a little.

The whole point of Macro Scheduler was to simplify the task of building automation routines, or software robots. To avoid having to reinvent the wheel.

There’s no reason why you can’t automate your Excel-to-SAP/WEB/ERP/ACME-Desktop-App by writing code using C# or C++. But it’s going to take you longer than using Macro Scheduler. Macro Scheduler functions like “SendText” and “UISetValue” encapsulate some pretty low level and quite convoluted code. The code wizards and macro recorders which help you use them are even more complicated.

One of the main purposes of Macro Scheduler is therefore to enable people to automate things more quickly and more easily than could be done with traditional programming tools. It makes it possible for non-programmers but also simplifies and speeds up automation for developers.

Over the last 21 years – yes 21, Macro Scheduler was first launched in 1997! – we’ve helped people with a lot of automation tasks. We offer consultancy and have been into people’s offices and also helped over the phone and remote desktop. Most routines take us a few hours to create a macro for. Some take a day or two. Rarely do we need to spend more than three days on one process, though there are some projects which involve a series of automation routines that may therefore take longer or be done over a few sessions.

To do the job from scratch with C#, C++ or VB might take weeks. Many people who approach us seem to be imagining that to automate their task may take days or weeks. They are often very surprised when we tell them it’s a few hours not a few days.

We are all about saving time and money. That’s what our tools do and it’s why we built them. Our tools mean you don’t have to pay developers lots of money to spend weeks or months building custom solutions.

The only down side to this from our point of view is that we routinely disappoint large consultancy businesses and potential partners who are used to selling IT contracts worth hundreds of thousands. They approach us thinking that there’s a huge opportunity and that we’ll pay them a large cut of a big consultancy project.

But rarely does a job require so much time, and that’s the reason we’re here. Sometimes I sense these people want us to “flesh” projects out. They think we’re “too good” at what we do. We should slow down, make things more complicated and thus charge for more time.

But that isn’t us. That’s not why we’re here or why we created Macro Scheduler. The whole ethos of Macro Scheduler and MJT Net Ltd is to save time, to find more efficient, less expensive ways of doing things that were once thought impossible or too expensive to do, and to enable people to automate without specialised knowledge.

That said we’re happy to work with companies on an on-going basis. I have found that most businesses approach us with one specific routine in mind and then when they see what can be done they realise how it can be applied across the organisation in other departments, for other teams. Saving a team one hour a week may not seem like much, but do that for 500 other teams and it adds up to a huge efficiency saving for the entire business.

If you would like to talk to us to find out how we could help your business, whether on an ongoing basis or just for a one-off job, please drop me a line here.

May 7, 2015

Self Documenting Macro Recorder Snapshots

Filed under: Announcements,General,Macro Recorder,Scripting — Marcus Tettmar @ 1:22 pm

Did you know that since Macro Scheduler 14.2 the Macro Recorder can store snapshots of windows and objects that you click on as you are recording?

This feature makes it easier to work out which bit of code does what as you can see the screenshots inside the script:

Note the thumbnail images in the script. To view a full sized version – as in the example above – double click on a thumbnail.

This feature is on by default but can be switched off before you record a macro by toggling the “Take Window Snapshot Images” option on the macro recorder settings dialog.

November 7, 2014

Macro Scheduler 14.2 – Python, JSON, XML and Auto Documenting Macro Recorder

Filed under: Announcements,Macro Recorder — Marcus Tettmar @ 1:34 pm

I am pleased to announce that we have today released Macro Scheduler 14.2

Amongst other things this new version includes the following great new features:

  • Self Documenting Macro Recorder with snapshots of Windows/Objects being Activated/Clicked on
  • The ability to run Python code within your macros!
  • A native JSON Parser
  • A native XML Parser using XPath

Here’s an overview of these main new features, but for a more complete list of improvements view the history list here.

Self Documenting Macro Recorder

Ever recorded a macro and then tried to edit it but couldn’t figure out which bit did what? Well, now when you record a macro the macro recorder will take snapshots of windows that are activated and objects that you click on. These will be inserted into the script as image comments, right above the line of code they refer to. So, now, it’s easier to see exactly what your macro is doing and which bits you want to edit/copy.

Run Python Code Inside your Macros

In 14.2 there’s a new function called PyExec. It allows you to run real Python code and get back the values of any Python variables you specify. You’ll need to install the Python 2.7 DLL to your Macro Scheduler folder (or compiled .EXE folder) – there’s a link in the help file to a zip file with all the files you need.

You can run any Python code and even use third party Python imports. This is pretty wild IMO – the possibilities are endless. Here’s a simple example:

/*
First ensure Python27.dll and imports are in your Macro Scheduler program folder.
Download and unzip this file:
https://www.mjtnet.com/software/python27.zip
*/

Let>url=http://ip.jsontest.com/

/*
python_code:

import urllib2
import json

# grab data from http://ip.jsontest.com/ - see www.jsontest.com
response = urllib2.urlopen('%url%')

# load the json
dict = json.loads(response.read())

# get the ip member
myip = dict["ip"]

# make a nice string representation of the dict
sdict = json.dumps(dict)

# Anything we print to IO is returned in the PYExec output var
print "All Done"
*/

//Load the Python code to a variable
LabelToVar>python_code,pcode

//Run the code and request the values of the sdict and myip variables ...
PYExec>pcode,output,sdict,myip

//Display the IP address
MessageModal>Your pubic IP is: %myip%

Parsing JSON

In the last few years JSON has become a very popular way to transmit data objects. Most web services now use it so it cannot be ignored. While you can parse JSON using string handling/regex having an easy to use native parser is essential. Enter: JSONParse

In the above Python example we used Python’s own JSON handling to extract an IP address from some JSON retrieved from a web service. Here’s how we can do the exact same thing using native MacroScript code:

HTTPRequest>http://ip.jsontest.com/,,GET,,JSON
JSONParse>JSON,ip,myIP
MessageModal>Your pubic IP is: %myIP%

And here’s an example which gets data out of a more complicated structure:

//Requires Macro Scheduler 14.2

/*
MyJSON:
{ "uid" : "1234", 
  "clients" : ["client1","client2","client3"],
  "people" : [{"Name":"Marcus","Age":"21"},{"Name":"Dorian","Age":"18"}],
  "color" : "red",
  "size" : 14 }
*/

LabelToVar>MyJSON,sJSON

JSONParse>sJSON,uid,result
JSONParse>sJSON,clients,result
JSONParse>sJSON,clients[1],result
JSONParse>sJSON,people[1].Name,result

Parsing XML

Of course XML is also still very popular. Up til now we’ve had to parse XML using substring handling/regex or use Microsoft’s XML object via VBScript – which is a little over-complicated IMO. We now have a simple to use native XML parser function – XMLParse. Here’s an example:

//Requires Macro Scheduler 14.2

LabelToVar>XML,sXML
XMLParse>sXML,/bookstore/book,val,numBooks
Let>k=0
Repeat>k
  Let>k=k+1
  XMLParse>sXML,/bookstore/book[%k%]/title/text(),val,len
  MessageModal>val
Until>k=numBooks

/*
XML:
<?xml version="1.0" encoding="UTF-8"?>




  Everyday Italian
  Giada De Laurentiis
  2005
  30.00



  Harry Potter
  J K. Rowling
  2005
  29.99



  XQuery Kick Start
  James McGovern
  Per Bothner
  Kurt Cagle
  James Linn
  Vaidyanathan Nagarajan
  2003
  49.99



  Learning XML
  Erik T. Ray
  2003
  39.95



*/

How to Download/Upgrade

If you have a valid maintenance plan you can download the update from your account here. If your maintenance has lapsed you can also purchase upgrades and renew maintenance from within your account.

Trial versions can be downloaded here.

July 24, 2014

Success Story: Automating Certificate Exports for a Bank

Filed under: General,Macro Recorder,Success Stories — Marcus Tettmar @ 6:32 pm

My recent newsletter with the screen-cast of the old Windows 3.1 Macro Recorder prompted the following email from long time customer, Ian. In his email he reminisces about how he originally found and used Macro Scheduler to solve a thorny problem for his employer which had previously stumped Microsoft. It’s a good story so I thought I’d share:

Hi Marcus,

I wanted to take a moment to say thank you for the upgrade to Macro Scheduler you sent me this afternoon. I’ve installed it and had a look at the sample scripts – I think I’m going to have fun with the image stuff J

Since it’s been so long, I think I am now able (if you are not bored silly) to explain how I used Macro Scheduler to save the bank a bucket of money…

I joined [large well known international banking group – name removed] as a ‘technical discovery analyst’ in the XP roll out project. No one ever explained exactly what my job was, but it turned out to be ‘sh!t catcher’ – anything that couldn’t be sorted elsewhere ended up on my desk and I had to find a fix (often in less than a day!).

The bank used a well known credit checking agency to do credit checks. In those days [well known credit checking agency] used Security Certificates in Internet Explorer to track billing data – each cert was a unique valuable entity, and we had two options; export them from the machines prior to switching them out, or reissue 10,000 certs! This is the task that Microsoft came in to do (they left about a month before I joined). The problem was that the certs are designed not to be exportable automatically, so that they cannot be programmatically stolen. And so they arrived on my desk.

Since I knew that I had to get a lot of people to run through a complex export procedure (much clicking and saving in the right place), I thought back to the Macro Recorder in Win 3.1. I knew that it wasn’t in NT or 2000 (which was in use at the time) and a quick Google brought me to your site. I popped downstairs to ask my boss for a hundred pounds for a proof of concept (!) and she gave me her bank credit card :-).

Once I had the software installed on my workstation I began to hack through the samples and the manual. By the end of the first day I had a pretty good idea of what I had to do, and at close of play on the next day I had successfully exported and reimported certificates. I was able to go back downstairs and say that I had a viable solution. Much Brownie Points for that conversation!

The export script had 19 versions by the end, and the import one had 11 (the users ran the export first, then the import on their new machine). I’ll attach the last version so you can wince at my cludgy code!

I also wrote a script to find out how much file data was on local machines since it was going to be dumped onto FP servers. That one’s an even bigger bowl of spaghetti code J

Anyway, I’m sure that’s enough for now! Thanks again and I’ll continue to spread the word about Macro Scheduler.

Take care, Ian

July 15, 2014

The Google Dance

Filed under: Macro Recorder,Uncategorized — Marcus Tettmar @ 2:45 pm

I’ve never really worried too much about SEO for mjtnet.com. We’ve certainly never done anything black hat or spammy.

All we’ve ever done really is made sure we have contextual content on the site that caters to human beings and does all the obvious things like make sure we have our important key phrases in the text of the page.

But earlier this year I became aware that our organic search traffic had declined. And looking at the trend over time I realised that our rankings for keywords like “Macro Recorder” had taken a tumble just after Google’s Panda update in 2011 and then again with Penguin in 2012.

I felt a little silly. I should have noticed at the time. But I guess I was focused on other things. I remember reading about Panda and Penguin and sniggering quietly to myself whenever I heard that someone who had employed dubious SEO methods had been penalised. Little did I know that somehow we’d suffered too!

I’m not really sure why this is. Like I said we’ve never done anything black hat. We’ve never bought links.

Our domain has existed since 1997. We’ve been around a long time in Internet terms. In the early days of the web there was no Google. There wasn’t even a proper search engine. If you sold software what you did was upload your trial (or shareware) versions to a number of download sites. That’s how people found our software.

Over the years we’ve continued to list our software on download sites but their importance has diminished while search engines, and more recently Google, have become the most important way to be found.

Many of the download sites have suffered as a result and have resorted to dubious means, such as forcing downloaders to use their own installers which bundle downloads with adware and browser extensions.

I wonder if we have been penalised for our association with these sites. Once our software is out in the wild, we have little to no control over who lists it, so it seems a bit unfair if it is the case that our rankings have suffered because of these sites.

In the mean time competitors have appeared who seem to rank better for some of our key phrases, despite having fewer back links, and less longevity and in some cases less context for the key terms.

We’re doing our best to fix that but there’s not a huge amount we can do other than keep writing content and keep helping our customers and hope that they share and bookmark our web pages and blog posts – hint hint ;-).

Frustrating. But that’s life these days I guess. We dance for the Google god.

July 3, 2014

Remember The Macro Recorder in Windows 3.1?

Filed under: General,Macro Recorder,Pointless but Fun — Marcus Tettmar @ 1:17 pm

Who even remembers Windows 3.1?  Yes, before Windows 95.  Yes, there was a Windows before Windows 95.  And it had a built in Macro Recorder.

Just for fun I dug out an old copy of Windows 3.1 and installed it into a VM.  Here I am recording and replaying a macro using the Windows 3.1 Macro Recorder:

As you can see it was pretty simple. Useful though. And then when Windows 95 came along the Macro Recorder was gone! Luckily along came Macro Scheduler with it’s own Macro Recorder 🙂

Yes I’m human. You’re paranoid.

Filed under: General,Macro Recorder — Marcus Tettmar @ 9:39 am

Remember the good old days of corner shops? Long before we went to enormous super markets. The days before aisles and aisles of products that we just help ourself to? Back then you’d walk into a store and the shop keeper, who was probably the owner, would be stood behind a counter and he’d greet you with a polite “Good morning? Anything I can help you with?”. Those were the days.

Things are a little different today aren’t they. In some ways. In others not so much.

Quite likely the majority of on-line stores and websites are run by small businesses. The owner of the business sat at a desk dealing with email enquiries and so forth. Why shouldn’t that person offer to help one of his website visitors? Just like the good old days.

We do exactly that. We run a live chat system on our web site. It has the ability to offer a proactive chat window to people who have spent some time on the page. This allows us to offer them a hand.

The majority of people we’ve spoken to absolutely LOVE this.  They love getting the proactive help, before they have to ask for it. It usually gets people what they need really fast. And we enjoy chatting to people. Overall it’s a win for everyone.

But a large minority of people appear to be very suspicious.

Notice the “Yes, I’m a human – try me!” statement in the window above.  I added this because people would often say something like “You’re a bot!”.

I’m not convinced it helps.  Some people either say “Ha ha, you’re not human!”, followed more often than not by something rude, or they’ll take the challenge and give us a Turing test, ask us a mathematical question or something.  This can be amusing some times but when you have lots of people to help it can also be a bit of a time sink.

Yesterday while Dorian was on live chat someone asked if he was an employee of the company. He said “Yes, can I help you?” and the response was “I don’t believe you”. Yet on our about page you’ll see his bio. Sigh.

I find this all quite sad, but I suppose it is a reflection of the world we live in today. Perhaps it is due to sneaky pop-ups and pop-unders which were often used to generate traffic or get you to sign up to something. Google has largely put paid to most of that now though. And anyway, I would have thought that a pretty clean looking window like the one above which appears INSIDE our web site and offers help would look far more legit than those sorts of things.  Or maybe it’s just because we sell automation software, so they think we’ve written a macro to talk to them!

You do get some funny things. The other day someone in Australia used the live chat window to ask me for a crack! I couldn’t believe it. I asked if him if he really though the founder of the business would give him a crack for Macro Scheduler. He then told me he thought it was a bot and was very embarrassed. Embarrassed? He wants a crack.  He appears happy to download something obtained using a stolen credit card (no one actually *cracks* software any more – it’s easier to buy stolen credit card numbers apparently – but that’s another rant) but feels uncomfortable asking the person who was defrauded. And I’m not sure what he thought a bot would tell him anyway.

It’s frustrating that a handful of people are so suspicious when all you want to do is help.  The way I see it we’re just doing what the old store keepers used to do.

What I don’t get is why people who think it’s a bot bother to write anything at all and don’t just ignore it or close it.  Wait, I get it – perhaps they WANT to talk to a robot! Maybe we should offer them a choice – “Do you want to talk to a human or a robot?”.  After all they are probably at our site because they are looking for a Macro Recorder! 🙂

Anyway most people love it. We love it. We’ll continue doing our old-school shop keeper routine. It’s all part of the service!

June 27, 2014

It’s a Macro Recorder, It’s a Windows Automation Tool. It’s Macro Scheduler!

Filed under: Macro Recorder,Uncategorized — Marcus Tettmar @ 8:22 am

I usually write about technical stuff here in this blog, but today I have my marketing hat on and I’m thinking about how we describe our favourite piece of software.

Up in the sky, look: It’s a bird. It’s a plane. It’s Superman!

A while ago I asked in the forums how people described Macro Scheduler. Do they call it a Macro Recorder, Windows Automation Tool, Scripting Language, or something else altogether?

Interestingly the winner was scripting language! followed closely by automation tool.

The forums are mostly read by existing users and those who responded to the question were mostly old hands.

I suspect if we asked relative newcomers, they would be more likely to answer Macro Recorder, or Windows Automation tool.

Does it matter? Well, to existing users, those of us already benefiting from the tool, what we call it probably doesn’t matter too much. Personally, I prefer the term Windows Automation Tool. But from a marketing perspective it matters more.

You see, far more people search Google for Macro Recorder (and similar terms) each month than Windows Automation based phrases. An order of magnitude more. Both terms describe a tool for performing automation, so both terms attract people who would benefit from the software.

And since more people search for Macro Recorder related terms it is important that we use those terms on our website. We all want more people to benefit from the software don’t we? We all want the community to grow. And we want the business to grow and be here in another 17 years (yes, we’ve been continuously improving and supporting Macro Scheduler since 1997 and we are still going strong).

We use an email support system called Help Scout (it’s brilliant by the way, if you’re looking for a way to support your customers we recommend it).

When Help Scout started out they wanted to build an email only, personalised support system which treated customers like people not numbers. So when they started out they didn’t use terms like Help Desk or Ticketing System. In their minds it was quite different. They didn’t think of it as a ticketing system.

However, when they started trying to get the word out and marketing it they realised they would have to use terms like help desk and ticketing system or no one would ever find them. And at the end of the day it IS a help desk. Just a different one. A better one.

Macro Scheduler, at its most basic level, is a macro recorder. Just a different one. A far more capable and flexible one with many more features to aid automation of software.

When it comes to marketing it seems it’s not how WE describe it that matters, it’s what people are looking for that is important. Assuming of course we have something that solves their problem.

I suspect that many of those who answered Windows Automation or Scripting Tool in the forum may well have originally found us way back by using more common terms like macro software or macro recorder.

What do you call it when you tell others about it? If you had to describe it in two or three words? And do you remember how you found us?

June 19, 2014

Load Testing – Measuring Elapsed Time

Filed under: Automation,Macro Recorder,Testing — Marcus Tettmar @ 12:02 pm

In a support email recently I was asked how to record a macro to perform load testing.

While you could certainly use the macro recorder for much of the process, in most cases you are probably going to want to insert some code to make the macro more dynamic in waiting for events to complete. Your load testing is going to slow things down and what you want is to measure how long things take. So you’ll need to be sure you’re waiting for “readiness” and calculating how long that took.

The macro recorder by its very nature records the firing time between distinct events like mouse clicks and keystrokes exactly as it happened at play back. It does however insert “WaitWindowOpen” commands when new windows appear and these will be dynamic – they will wait however long is needed for windows to open and close.

But more often than not you’ll want other forms of waiting. My personal recommendation is to use WaitScreenImage to wait for a visual cue on the screen. This is closely analogous to how a human uses the application – she uses her eyes to see what’s on the screen and determine “readiness”.

If you’re load testing then you’re probably going to run lots of macros – or virtual users – at the same time and are going to slow things down. This is exactly what you want to do – you want to see what the effect of adding more users is – and you’ll need to measure elapsed time. So you’ll need the macro to wait exactly as long as necessary.

The easiest way to do that is with Image Recognition. By all means use the macro recorders to record the simple bits – the bits that send keystrokes into fields. Or use the UI functions and the handy Find Object Wizard.

Also use the Screen Image Recognition wizard to record your waits. It’s real easy. Just capture the thing on the screen you want to wait for and it will spit out the code to do that.

So once you’ve done that you have a macro which will carry out the process and wait for things to complete and be ready before continuing. Now you will want to gather statistics to see what the elapsed times are and compare with different scenarios.

You might do this simply by looking at the log file for the macro. The log file outputs the time each command executed. So you could calculate the elapsed time between starting a step and when it completed. I’ve known customers simply open the log files in Excel and add their own formulas.

But I would make use of the Timer function to have the script itself measure the elapsed time of specific events. You might then output this elapsed time to an Excel or CSV file or store it in a database. It’s up to you.

Here’s a simple bit of code which sets a timer, runs Notepad, waits for it’s main window and then calculates elapsed time, storing it in a CSV file.

//start the Timer
Timer>startTime

//Run Notepad as an example
Run>notepad.exe
//wait for it to be ready
WaitWindowOpen>Untitled - Notepad

//How long did that take?
Timer>endTime
Let>elapsed=endTime-startTime

//elapsed is in milliseconds - write it to our CSV file
WriteLn>c:\temp\test_1.csv,wRes,STEP1;%elapsed%

This is really just to show you how the Timer function allows you to measure elapsed time – you’ll likely have a bit more going on and if “readiness” is not signalled by a new window as it is here then WaitScreenImage might be a better option.

Older Posts »