Good-bye Amplify, Clipmarks; Hello, Clipboard!

Posted on February 25, 2012
Filed Under Splatforms | 12 Comments | Share this post via

In the ever-changing world of target web sites, the landscape continues to evolve. Two more of our favorite target sites, Amplify and Clipmarks, have joined the countless others that have gone before them and are now silent.

This time, however, a new target site, Clipboard, has risen up to take their place. Of course, this means that all of the Tasks that have been developed for the retired sites will no longer be of any value, and new Tasks will need to be developed for the replacement site, but that’s just more practice for the Task developers. That ought to help keep them off of the streets for a little while, anyway!

So long, … we’ll miss you!

Posted on November 10, 2011
Filed Under General | 21 Comments | Share this post via

Today we were saddened to hear that will be shutting down. Yes, congratulations are certainly due Tim Bull and Alex Dong,’s co-founders, but we still hate to see them go away like so many others before them. Our own little spot on’s site was one of our favorites, and we’ll keep the link on our blog’s sidebar to the bitter end, but eventually it will disappear forever, and join the distinguished list of retired sites to which we once posted via one or more *forms.

So here’s to you, Tim and Alex. The best to you in your new adventure with another of our favorite targets, our old friend Delicious. We look forward to seeing what you will be bringing to the rebirth of that old standard. But just so you know, we’ll already missing your creation, and you haven’t turned out the lights yet!

Build Your Own *form Task, part 3

Posted on September 9, 2011
Filed Under Splatforms | 24 Comments | Share this post via

In the last installment of this series we took an existing *form Task that posted a Link *form to HubPages and converted it to post an Article *form to HubPages. Today we’re going go one step further and combine elements of two working Tasks to produce a new Task that will post an Event *form to HubPages.

Event *forms are one of two *form Types that can be represented as microformats (the other is the Contact *form). Many Tasks that post Event *form data target calendar web sites that have specific fields for the various properties of an Event such as the description, location, start date/time and end date/time. You can also post an Event to a simple publishing destination, however, and just format the properties of the Event for display. In those circumstances, it is always nice to format the Event using the rules for an hcalendar microformat. One of many existing Tasks that already does that is the Task that posts an Event *form to Tumblr, which happens to be Task #28. Since someone has already gone to the trouble of working out all of those details, the quickest way to set up a new Task to post an Event to HubPages would be to start with the Task that posts a Link, just like we did before, and replace the Link data with the formatted Event data, which we can lift right out of the existing Tumblr Task.

So, let’s start out with another copy of our old friend, Task #520, “Post Link to a HubPages Hub”:

Once again, we are simply changing parameters to be posted in the final step — everything else remains the same. Events do not have a “title” property, but they do have an “event” property that can serve as a tile, so let’s change this parameter:


…to this:


The only other thing that we need to do is to change the content parameter, and for that, let’s take a quick look at our source Task, #28:

This Task, which is a one-step POSTing Task that leverages the Tumblr API, contains a POST parameter called body, which is what we want to snag for the basis of our own content parameter. Our existing content parameter does have some interesting stuff that we might want to hang on to, though, so let’s take a quick peek before we get to carried away.

<p><em>Posted:</em> $rightNow.toString("EEE, MMMM d, yyyy 'at'
hh:mm aaa")<br/><em>From:</em> <a href="$url"
<p><em>Tags:</em> $tags</p>

That first line publishes the posting date, which is actually useful information and worth keeping around, so let’s drop everything else, but leave that part in place:

<p><em>Posted:</em> $rightNow.toString("EEE, MMMM d, yyyy 'at'
hh:mm aaa")</p>

Now all we need to do is add in the microformatted event code that we lifted from the Tumblr task, and we now have a new value for the content parameter:

<p><em>Posted:</em> $rightNow.toString("EEE, MMMM d, yyyy 'at'
hh:mm aaa")</p><div class="vevent"><p><strong>#if($url)<a
class="summary url" target="_blank" href="$url">$event</a>#else
<span class="summary">$event</span>#end</strong></p><p>
<em>When:</em> <abbr class="dtstart" title="$startDate">
$dtstart.toString("m/d/yy hh:mm a")</abbr><br/>#if($endDate)
#if($endDate!="")<em>Ends:</em>  <abbr class="dtend"
title="$endDate">$dtend.toString("m/d/yy hh:mm a")</abbr><br/>
#end #end #if($location)#if($location!="")<em>Where:</em>
<span class="location">$location</span>#end #end
class="description">$description</p>#end #end</div>

That’s it. Now we have a new Task to post an Event *form to HubPages, and do it in a way that makes the Event visible to any tool that recognizes microformats. And we really didn’t have to do much of the work at all! It was all from parts and pieces that we found laying around.

There are plenty of working Tasks out there to grab and start playing with. A little of this Task mixed with a little of that Task mixed with a dash of your own unique stylings and all of sudden there’s a brand new Task in the pile. Go ahead — give it a try. You might even find yourself having a little fun with all of the possibilities!

Build Your Own *form Task, part 2

Posted on September 2, 2011
Filed Under Splatforms | 31 Comments | Share this post via

Now that we’ve gotten all of that background, conceptual, and theoretical prerequisite stuff out of the way, let’s look at some real Tasks and see if we can’t actually make something out of something else. One of the simplest ways to alter an existing Task is to modify the source, or *form Type. Those of you who have been playing along at home will remember that there are five (5) basic Types of *forms: Text, Link, Article, Event, and Contact. Although each unique Type shares a limited set of common data elements with all or most of its cousins, the complete collection of data available for each Type is specific to the Type. Two types that are similar in nature are the Link and the Article; both have tags and titles, only the Link has the URL property, but a Link has comments and an Article has a body, both of which are roughly equivalent. So, it wouldn’t take that much to copy something that was built to post a Link and convert the copy to something built to post an Article.

It wasn’t all that long ago that we were playing around with HubPages, so let’s just grab that Task that we build to post a Link to a HubPage. This link only works if you are logged in to your account, but if you are, you can see the entire Task here:

Just FYI for those that have a little bit of hacker in them: you can actually use that link above to look at any *form Task — just change the number 520 there on the end to the Task number of the one that you want to look at. Again, you have to be logged on, but once you are, you can look up the full details on any Task in this way, or just put in a random number and see what you get back. But we digress …

Here’s a screen shot of the link above for those of you who have not yet set up your account:

Task Detail

Task Detail

If you look closely at the Task, you find that it has five (5) steps:

  1. Fetch the Logon page,
  2. Complete and submit the Logon page,
  3. Follow the post-login redirect back to the Logon page,
  4. Fetch the Hub edit page, and finally
  5. Post data to the edit tool.

If you look even closer, you can see that the *form data only comes into play in that very last step. Every other step in the Task is just preparation for that final step, which is the money shot in this entire orchestration. From that you can see that, as long as we know that the rest of the thing already works, there is no real pressing need to know or understand how any of that works. We have no interest in changing it in any way, so all we really have to do is to focus on the part that is going to be different in our version, and all of that happens in Step #5.

In fact, the only thing about Step #5 that has to change is a single property of the step: the parameters to be posted. Everything else can stay exactly as it is. Not only that, every single one of those parameters on the list can stay exactly as they are except for one: content. Let’s take a look at what we are posting to the “content” parameters right now:

<p><em>Posted:</em> $rightNow.toString(“EEEE, MMMM d, yyyy ‘at’ hh:mm aaa”)<br/>
<em>From:</em> <a href=”$url” target=”_blank”>$url</a></p>
<p><em>Tags:</em> $tags</p>

Now, a lot of that is HTML, and for those of you who do not know HTML, don’t worry — the HTML in this example is pretty simple, and we’re not going to mess with it all that much. And for those of you who haven’t even a clue what the hell it is that we are taking about, the HTML is all of those little “tags” enclosed in less than (“<“) and greater than (“>”) symbols. Web browsers and other rendering agents use those to determine how to display the text that is not a tag. To see how that works, compare the snippet below, with the actual rendered version below:

Posted: $rightNow.toString(“EEEE, MMMM d, yyyy ‘at’ hh:mm aaa”)

From: $url



Tags: $tags

This time, instead of escaping the tags so that they would be displayed instead of interpreted, we just fed your browser the raw HTML, and the browser did what browsers do with HTML: it let the HTML control how the rest of the text was displayed.

But, enough of that little side trip — back to the task at hand. Now that we see what this Task does to format the “content” parameter to display the data from a Link *form, let’s see what we have to do to modify it to display the data from an Article *form instead. For starters, an Article has no “URL”, so we can strip that part out right off the bat, leaving this:

<p><em>Posted:</em> $rightNow.toString(“EEEE, MMMM d, yyyy ‘at’ hh:mm aaa”)</p>
<p><em>Tags:</em> $tags</p>

An Article does have a posting date, and it also has tags, so those two lines can stay, but it doesn’t have comments, it has a body instead. One quick fix could be to simply replace the word comments with the word body and leave everything else well enough alone:

<p><em>Posted:</em> $rightNow.toString(“EEEE, MMMM d, yyyy ‘at’ hh:mm aaa”)</p>
<p><em>Tags:</em> $tags</p>

Although that would work, in actual use it might not end up looking so well. The Link task was surrounding the comments with paragraph tags, and was also replacing all of the line feeds within the comments with endind and beginning paragraph tags. This was done because comments are not usually marked up with HTML tags, so this adds the tags to make things display a little nicer. Articles, however, usually are marked up with HTML, so this step will add extra tags in addition to the ones that are already present in the article. A more appropriate approach for an Article *form would be to simply drop in the article body and assume that it is already marked up with the appropriate HTML:

<p><em>Posted:</em> $rightNow.toString(“EEEE, MMMM d, yyyy ‘at’ hh:mm aaa”)</p>
<p><em>Tags:</em> $tags</p>

And that’s it. We have copied Task #520, changed the Type from Link to Article, changed one value of one parameter of one step from the original Task and left everything else as it was. We should also rename it and change the description, but that’s all there is to it. Without knowing a whole lot about how all the rest of it worked, we just focused in on the part that we wanted to behave differently and stayed away from the rest. Now all we have to do is add this Task to our own preferences, post an Article *form and see how it works.

This one was a pretty simple example, but it was enough to demonstrate some general principals. Next time we’ll see if we can stretch a little bit and do something a little more challenging.

Build Your Own *form Task

Posted on August 27, 2011
Filed Under Splatforms | 26 Comments | Share this post via

There are two schools of thought on what a person needs to know before attempting to create or modify a *form Task. One theory maintains that a *form Task Developer needs to understand the HTTP protocol, the request/response cycle upon which all web traffic is based, the inner workings of the infrastructure, including the role of the *forms Local Agent, the Velocity scripting language, XML syntax, and the intimate details of the operation of the specific target site for which the Task is intended. The opposing opinion is that, while having a deep and thorough understanding of all of these subjects may certainly have its potential benefits, all that you really need to know in order create a Task of your own is a working sample Task that you can carefully tweak here and there to get the results that you are looking for.

The truth is probably somewhere in the middle of those two extremes, but the bottom line is that you definitely do not need to be an expert, a programmer, or a software engineer to make a copy of an existing Task and tinker with it to try to make it do something slightly different. It is helpful to understand at least a little bit of what you are doing and why you are doing it, though, so we are going to try to hit the high points without getting too mired in the intimate details.

Ultimately,*form Tasks are instructions for the *forms Local Agent. The *forms Local Agent resides on the user’s computer and plays the role of the user when interacting with the target web site. From the perspective of the target web site, they can see web traffic coming from the user’s PC authenticated using the user’s username and password as if the user were sitting there typing away at the keyboard. What actually happens during this process is that the *forms Local Agent will receive some directive from, it will carry out that directive by making an HTTP call of some kind to the target web site, and it will then take the target web site’s response to that call and send it back to for evaluation. Based on that evaluation, will then send another directive to the *forms Local Agent, and the process repeats. All of this is done without the need for the user to be there sitting at the keyboard, freeing them up to pursue other activities.

The directives sent to the *forms Local Agent come from the steps within a *form Task. The evaluation of the target web site’s response is performed on using the evaluation criteria defined for that step. A *form Task, then, is the collection of steps and subsequent evaluation criteria necessary to walk the *forms Local Agent through the process of performing a specific set of interactions with the target web site. It doesn’t really matter if you understand exactly how all of these things work together to make this happen, but you do need to know the general flow of information between the *forms Local Agent, the target web site, and, as well as the role that the steps and evaluation criteria within the Task play in orchestrating the entire process.

With that little bit of knowledge, you should be able to start looking at existing Tasks to see how they are built and begin to understand how they work. From there, it’s not too great of step into making your own copy of a Task and starting to play around with it to see what you can do differently.

Next time, we’ll grab some existing Tasks and see if we can make some simple modifications to make them do different things. In the meantime, if you have ever processed any Tasks of your own, you can sign on to your account and go to the processed tab and drill down into the results and actually see the results of each step processed, which will also give you a better idea of how all these things work together to get to that desired end result.

Too Much Fun with HubPages

Posted on August 14, 2011
Filed Under Splatforms | 23 Comments | Share this post via

A few days ago, we created a Hub on HubPages to validate a couple of Tasks that we developed to post *form data to a HubPages Hub. We didn’t spend a whole lot of time on our new Hub; other than a contact form and an RSS module to pick up the feed from this blog, the entire Hub was composed of links and text posted via Splatforms. Today, the Splatforms Team received an e-mail from the HubPages Team regarding this Hub that we built:

Dear splatforms,

Your Hub has been identified as a violation of our Terms of Use. If this is the first time you’ve gotten an email like this, don’t worry! You’ll have an opportunity to fix it.

Problem: Duplicate content, including:
* Text that appears in whole or large part on another site, even if you wrote the text or retain the copyright.
* Text that already appears in whole or large part on HubPages.
* Text copied from multiple sources.
* Substantial similarity to another work. This includes close paraphrasing, among other forms of misappropriation or copying of content (see for more information)

A link to your Hub:

Your Hub has been unpublished, giving you the opportunity to revise it. When you are ready to have HubPages review it again, please edit it and click the “Submit for Publication” button. We will then review your Hub and publish it if it appears to be unique.  (An exception is typically granted only when quoting is done to a minimum, or some commonly-used, public domain, or historical phrases have triggered the duplicate content detector.)  You will then get an email saying that the Hub has been cleared for publication and republished.

Here are examples of high-quality Hubs that you might want to take a look at:

Please do not submit your Hub for republication until all of the problems identified above have been addressed. Thank you!


The HubPages Team

Our efforts as they stand are definitely a violation, as would be anything that consisted solely of content generated from processing *forms. That’s the whole point of *forms, after all: to post the same content to multiple destinations using a single form entry. Even if you were to factor in the use of spintax, such content would still clearly fall into the category of “substantialy similar”. Although we could definitely devote some resources to creating a Hub of primarily original content to remove this violation, that’s not really near the top of our priority list at the moment, so we have elected to set that aside for now. We have removed the link to our Hub on the sidebar of this blog, but we will definitely leave open the possibility of returning to this project at some point the future and working to ensure that we meet all of the applicable Terms of Use.

Which is all just a long-winded preface to the entire point of this post, which is simply this: the use of *forms does not relieve you of your obligation to follow the rules on the individual sites to which you post your *form data. is a tool to help automate tasks that you would otherwise be doing manually yourself. As with any other tool, what you get out of it depends entirely on how you use. Virtually all target sites to which you can post *form data will have their own Terms of Use, Acceptable Use Policy, Terms of Service, or some other end-user agreement that defines what you can and cannot do on their site. The fact that you are using *forms in place of manual entry does not alter that requirement in any way, and may itself be a violation of those terms in certain circumstances. This is not an attempt to dissuade you in any way from using *forms; it is simply a reminder that, no matter what tool or method you use to post data on a site, you are ultimately responsible for what you post.

Fun with HubPages

Posted on August 11, 2011
Filed Under Splatforms | 24 Comments | Share this post via

We had such a good time playing with Squidoo the other day that we decided to go ahead and do the same thing with HubPages. HubPages and Squidoo are similar sites with similar goals, but they each have their own unique language when it comes to the elements involved in the process. On Squidoo you create a Lens; on HubPages you create a Hub. On Squidoo, you build your Lens using modules;  on HubPages you build your Hub using capsules. It’s pretty much the same process, but things have different labels on each site.

Like Squidoo, HubPages allows one user to create multiple Hubs (or Lens, in Squidoo-talk!), so as we did with Squidoo, we need to collect some additional information along with your username and password to identify which Hub you would like to you use. Unlike Squidoo, which requires the name of the Lens, HubPages Tasks need to know the number, or ID, of your Hub. Just like Squidoo, this information is collected by your *forms Local Agent using the Site Credentials context menu option:

Setting up your credentials for HubPages

Setting up your credentials for HubPages

So far, we have created support for Links and Text for both Squidoo and HubPages, but hopefully it won’t be too long before we have added Articles, Events, and maybe even a little Spintax into the mix.

Getting Started with Splatforms (cont)

Posted on July 29, 2011
Filed Under Splatforms | 19 Comments | Share this post via

Some time ago we put out a little piece that we called Getting Started with Splatforms to step folks through the various set-up items that one needs to accomplish in order to successfully access all of those wondrous benefits of having an account on Since that pretty much covered everything fairly well, rather than repeat any of that information here, we’re just going to tell you to go check it out (Yes, that’s the same link as first one, but hey — we’re pushing the idea. Seriously, go check it out!).

Once you have your new account established, you can also access the Getting Started page, which happens to cover the same subject. One thing that we neglected to mention in our earlier coverage of this issue, and the main reason for this post, is an important link that you find near the beginning of the Getting Started page, which will take you to the Set-up Status page. The Set-up Status page will verify your progress in setting up your account so that you can see exactly what items have been completed and what is yet to be done:

Set-up Status

The heart of the Set-up Status page

Once you have all four red X’s converted to green checkmarks, you will know that your account is completely set up and ready to rumble.

One other thing we should note is that, since version 1.1.3 of the *forms Local Agent, setting up your target web site credentials is even easier if you happen to use the same username and password on all of your target sites. Version 1.1.3 resolved Ticket #3:

“This is a new feature request: allow the user the option of setting up a default username, e-mail address, and password that would be the fall-back values for any target web site that did not have any values in the username/e-mail and password fields for that site. This way, if a user set up all of their accounts with the same username and password, they could skip the individual site set-up steps and just rely on the standard default values.”

Oh, and if you’re concerned about the security of your target web site credentials, you should really check this out as well: Splatforms and Security. We really have no interest in any of your usernames or passwords; you keep those on your own computer where they belong!

When Your *form Task Fails

Posted on July 28, 2011
Filed Under Splatforms | 19 Comments | Share this post via

As much as we’d love to tell you that every single Task for every single Target Web Site always succeeds for every single user, the reality is that this is an imperfect world, and there are a variety of reasons why things do not always turn out according to plan. What you can do when a Task fails depends a lot on the reason for the failure, and while there are many, they all fall into a few simple general categories:

Temporary Problems with the Target Web Site – These can include such things as a site being down for maintenance or a site being overwhelmed with activity and unable to handle more traffic. Problems with your account can also fall into this category, and can include such things as you account set-up not being completed or your account being temporarily disabled for such things as violating the site’s Acceptable Use Policy or putting in your password wrong too many times. The bottom line characteristic of things in this group is that they are all temporary, and presumably can all be resolved by someone.

Permanent Problems with the Target Web Site – These can include such things as a site closing down or transitioning to an entirely different purpose or having some kind of catastrophic failure of their hardware or software. What differentiates this from the former category is that nothing here is going to change and we’re going to have to consider the site retired and take it off of our active list. We have a few of those on there now which we need to remove, but we always wait just a bit, just to make sure that they are not coming back to life.

Problems with Your Account Credentials Set-up – Basically, if you have not correctly set up your username and password in your *forms Local Agent, your Tasks are not going to work. The good news here is, just like with the first group, this is something that can be fixed, and the even better news is that it is something that can be fixed by you.

Problems with the Task – Each *form Task is a little miniprogram or script that has been developed to take a specific *form’s data and post it to a specific target web site. These Tasks are developed by humans, who are prone to make human errors, and sometimes Tasks have flaws in their design or construction. The good news here is this is a yet another situation that can be resolved, but unless you are the Task Developer, it’s not going to be resolved by you. You are dependent on the developer to know about, understand, and correct any problems with the Task.

So, assuming that whatever the problem is can be, and has been, resolved, then what? Well, we’ve set things up so that, whenever you are ready to give a failed Task another shot, you can simply click on the Resubmit icon and have the Task queued up for another try. All of your recent Tasks can be reviewed via the Processed tab, and at the far right-hand edge of every failed Task under the Outcome column there are a couple of things that you can click on. Clicking on the word Error will reveal the detailed results of the various steps that make up the Task, and clicking on the green resubmit icon right next to it will resubmit the Task for another try.

So, if at first your Task does not succeed, fix the problem (if you can), and try again!

Fun with Squidoo

Posted on July 23, 2011
Filed Under Splatforms | 18 Comments | Share this post via

Well, we finally got around to publishing our Squidoo Lens. Squidoo is a nice tool, and very user-friendly. We could have finished what we had started there quite some time ago with very little effort, but there have just been a lot of other things going on. The main reason that we decided to go ahead and put something out there now was so that we could test out our new Squidoo Task that posts a Link *form to your Squidoo Lens.

Setting up Squidoo credentials on your *forms Local Agent is slightly different for Squidoo because the tool allows you to create multiple sites, or Lenses as they are called on Squidoo. In order for any Squidoo-based Task to function, we not only need you to enter your username (your e-mail address on Squidoo) and your password, but also the name of the Lens to which you want your *form data posted:

Setting up your Squidoo credentials on your *forms Local Agent

Setting up your Squidoo credentials on your *forms Local Agent

Our version of posting a Link to Squidoo adds a new Squidoo Text module to your Lens and then maps the data from the Link *form to the fields available on the Text module. Unfortunately, Squidoo adds new modules to the bottom of the Lens, and we wanted our new content to appear at the top, so we had to add a step in the Task to reorder the modules to make that happen. During that process we discovered a shortcoming in the way in which the current version of the *forms Local Agent handles multiple valued form fields, so we opened up a Ticket to have that fixed. That correction should be included in the next release. In the meantime, we approached the problem in a different way to work around that issue.

Now that we have the Link *form working for Squidoo, we plan to use that Task as guide to provide support to other *forms such as the Text and Article forms. Who knows — maybe we’ll even throw in a little spintax version. So many possibilities; so little time …

keep looking »