One feature request that I received many times for Simon was the ability to organize tests into folders or groups — especially useful for people with lots of tests, or simply want to collect all tests relating to a particular server or client together.

Tests can be grouped together however you wish. It’s easy to create a group: simply choose the New Group command in the File menu or the + pop-up menu, then drag the tests into the new group. Even easier, you can just select some tests and choose the New Group with Selection command to make a group and move those tests into it in one step.

Groups appear with disclosure triangles, enabling them to be collapsed. The group row shows a summary of the contents, with any common values displayed for easy reference. And similarly, the info pane shows a summary of the contained tests.

Groups can even be nested, if desired — you can have an unlimited number of groups within other groups, if that helps organize them.

But wait, there’s more! While grouping tests is perhaps one of the most-requested features, I didn’t stop there: you can also group services, filters, notifiers and reports in the same way!

When these items are grouped, they appear indented in the Kind pop-up menu in the test editor, so you can keep related items together:

I hope you enjoy this feature.

Simon has a feature that many people have asked for over the years: the ability to hide the app from the Dock.

By default, the Dock icon is shown, but there is an option in the General Settings to hide it.

Why might you want to hide it? Maybe you want to keep your Dock as sparse as possible. Simon’s Dock icon can display the most interesting status, but maybe you don’t need to see that all the time, or you’re satisfied with seeing that only in the status menu. Since you’d probably want to keep Simon running all the time, treating it as a background-only app can make a lot of sense. Now you can!

If you turn off the Show the Simon icon in the Dock checkbox, the app icon vanishes from the Dock, and also from the Cmd-Tab app switcher. Note that if you have chosen the Keep in Dock option in the Dock menu, the icon will linger, in an inactive state; you can disable that or drag the icon out of the Dock to remove it.

When Simon is hidden from the Dock, you can still activate the app via the status menu, if you have that enabled — and the app will automatically turn it on when you turn off the Dock icon, as a convenience. If you don’t want the status menu, you can turn it off again… in which case the only way to activate the app will be to click on one of its windows, if any are visible, or open it from the Finder.

One thing to note is that as a necessary side-effect of hiding the Dock icon, Simon will no longer have a menubar. It’ll truly be a background-only app. When you display the Simon Monitor window, the menus won’t change from whatever other app you were using. This isn’t a problem for most functions, as the toolbar buttons and sort drop-down menu options cover most menu commands. But for app functions like checking for updates, accessing preferences, etc, when the Dock icon is disabled a special action menu is added to the toolbar. For power users, the keyboard equivalents still work, too — so you can press Ctrl-Cmd-1 to switch to Preview mode, for example.

I know that this is an exciting feature for many customers. For anyone who wants Simon to “disappear” into the background, try turning off the Dock icon. You can always turn it back on again. No restart required.

Simon includes a password feature, that can be used to require a password when Simon is launched or activated. This provides some level of security to prevent unauthorized people from accessing the app. It doesn’t encrypt data or any other changes, it’s just a simple access control.

By default, a password is not required. If you want to require one, open up the General Settings. Notice the Choose Password… button and the text to the left indicating that a password hasn’t been set:

Click the button to display the password sheet. If a password hasn’t already been set, the first field will be disabled (and display “None”). If one has been set, enter the existing password there. The next two fields are for the new password; enter the same one in both, or leave them both blank to disable the password feature. If entering a password, you should also enter a hint that will remind you of the password (without being too obvious):

After setting a password, the text in the Settings window will change to indicate so:

When a password has been set, whenever you activate Simon it will display an unlock sheet, asking for the password. It includes a Quit button to quickly stop Simon, and a Cancel to deactivate Simon. After two failed attempts, it will display the password hint (if any); after two more failed attempts, it’ll disallow further attempts until after you quit or cancel:

I expect that most people won’t need this feature, but for those who do, it should prove quite useful.

Before I moved the Dejal blog to WordPress, I had a test that was bundled with Simon called “Dejal posts” (you may still have this if you’re a long-time customer). This was a great example of using multiple filters to narrow down the output of a Web Page service. While the URL it monitored is no longer valid, it remains a useful example for you to learn more about creating your own filters.

The general idea of this test was to look at a “Recent Posts” page of the Dejal site, which listed all recent blog, forum, FAQ etc posts and their comments, and output some tidy text describing the most recent one, along with a changed state when a new post or comment is added.

Firstly, here’s the Service page; nothing remarkable here (the cookies are automatically recorded, and unimportant for this test):

The most interesting page is the Filters one:

When you check the test and look in the Activity log, you can see the output from each of those filters (from bottom to top):

Another way to view the output is via the Preview pane, which includes not only the service response and headers, but also the full output of each filter, to help you diagnose each step.

Here’s the output of the service; the full HTML of the web page:

Let’s break down each of the filters, via the Preview filter output.

The first filter, a Block one, takes the service response as its Input, and has Start text of <tbody> and End text of <td class="replies">. This finds the first occurrence of each of those bits of HTML in the service response, which corresponds with the most recent post information:

This filter outputs that:

The second filter is another Block one. It takes the output of the first filter as its input, and narrows it down further to just the title of the post. Notice that it also uses options disclosed on the right-hand-side of the filter configuration: it looks for the second occurrence of the Start text, searching from the beginning of the input:

The output of this filter is the post title:

The third filter is yet another Block (it is one of the most useful filters), but the input is different: this time it uses the output of the first filter, instead of the previous one (as is the default). It also has an option to look for the third occurrence:

It extracts the author information:

Filter number four is different. It uses an Ignore Links filter to extract out just the author name from the previous filter output. The previous filter doesn’t do this as when you were not logged in on the Dejal site, only the name is included (in which case this filter has no effect):

The output is just the non-HTML part of the input:

Next we’re back to a Block filter again, but this time looking at the original service response text to extract the number of replies to the post:

This should always output a number:

We then use a Singular or Plural filter, to take the number found in the previous filter and output “reply” if it is one, or “replies” for any other number:

As seen in the preview:

The last filter puts it all together: an Override Custom filter uses variables to combine the output of several filters in a nice readable way. In this case all the variables are variations of the filter output, but other variables are available too. Something that isn’t immediately obvious is that you can insert numbers to reference specific filters (otherwise it refers to the previous one):

Which results in:

So now that we’ve got some nice output text, what do we do with it? Of course, you can just see it in the Tests list, if you have the last change and failure displayed:

But you’ll probably want to get a notification:

I hope this case study is helpful. Most tests don’t need a series of filters like this, and there are other ways to achieve similar effects (like writing all the logic in a script), but it can be very useful when you want it. You can use similar techniques in your own tests.

If you install Simon on an Apple Silicon (M1, M2, etc) based Mac, you may notice Web Page tests timing out.

That is because the Web Page service uses an embedded helper tool to load the HTML in a separate process, to improve performance and reduce the risk of crashing Simon. But currently this helper is Intel-only. Some other helpers, e.g. to send emails or upload reports to a remote server, are also Intel-only.

This is fine, but it means that you need to install Rosetta, Apple’s emulation layer to enable running Intel apps on Apple Silicon.

The main Simon app is universal, so launching it won’t prompt to install Rosetta, but you can override that by checking the “Open using Rosetta” option in the Finder’s Get Info window:

Just remember to uncheck that option after you’ve opened Simon, so subsequent launches use the universal code.

A customer sent a query, asking how to use Simon to monitor the subscriber counts on YouTube channels.

This is easy for Simon to do, by having Web Page tests for each YouTube channel, each with a filter to extract the subscriber count, and whatever notifier you wish.

The first step is to add a Web Page test for a YouTube channel, and look at the HTML output in the Preview pane, to find how the subscriber count appears.

For example, for my Sinclair Trails channel, the HTML includes:

    "subscriberCountText":{"accessibility":{"accessibilityData":{"label":"30 subscribers"}},"simpleText":"30 subscribers”},

Yes, I currently only have 30 subscribers… rather sad. Please subscribe to help me reach a more respectable number!

A sensible default choice for a filter is the Block one, though in this case a better choice would be the Find Regular Expression filter. But if you want to have several tests with the same notifier configuration, an even better choice is to create a new custom notifier, so you don’t have to configure the notifier for each test.

A regular expression to extract the subscriber count from that HTML could be:

    subscriberCountText.+?simpleText\":\"(.+?)\”\}

This will look for text starting with “subscriberCountText”, some more text, then “simpleText”:"” , then capture the desired text up until “”\}” .

In my case, that will result in:

    30 subscribers

To make a new filter for this, you can go to the Filters page in Simon, and add a new filter named “YouTube subscribers” (or whatever you prefer).

Then choose Find for the Filter Kind, and Regular Expression from the find options menu:

Then enter the expression as the find text, and choose Capture 1 as the output:

Click Done, then go back to your YouTube test, and choose this new filter on the Filters page:

This will output just the subscriber count:

You can see this output in the Activity log:

Or you can add a new Email notifier to email the filter output using the {FilterOutputText} variable:

And of course use that notifier in your test, along with whatever other notifiers you wish:

Then you can add more tests for other YouTube channels you want to monitor, specifying your YouTube subscribers filter for each. For example, CGP Grey has a few more subscribers than me:

I hope this helps!