There are two parts to the collection process – automatic and manual.
- rssmix.com – feed aggregator
- feedsifter.com – feed filter
- feedrinse.com – feed filter
- feedburner.google.com – feed parser
- Amit Agarwal’s excellent solution to: twitter .rss via google script
- twitrss.me – individual twitter users
widget.websta.me/rss/tag/– instagram tags widget.stagram.com/rss/n/– individual instagram users instagrss-mgng.rhcloud.com/– individual instagram users
The automatic collection process relies on numerous .rss feeds, selected and tailored to reflect the “taste” of each specific #SPG owner.
These .rss feeds are created and filtered using combinations of the following services:
The combination of any number of various filtered .rss feeds are delivered directly into the #SPG’s carrier stream by means of specific IFTTT recipes, one for each collection of customised feeds.
Aggregated feeds must be controlled by filters otherwise they are prone to being rather prolific, and thereby expose the degree of automation employed.
Posting “frequency” is a matter of debate – if a topic is trending and the #SPG can deliver large amounts of relevant information, then the frequency can be quite high, but if the #SPG is set up to deliver broad-based content on diverse topics, then posting frequency should rarely rise above more than once or twice an hour at most, otherwise it will appear as spam.
Manual collection is the process whereby the #SPG’s owner provides their own input into the #SPG system via email. A basic IFTTT recipe delivers this post into the #SPG’s carrier stream, where it is then processed by the #SPG.
All monitoring, apart from the #SPG’s carrier stream itself [which is monitored directly by the #SPG], is undertaken by IFTTT.
Individual recipes for each possible action on each platform are created, and the results of these actions are delivered by IFTTT into the carrier stream.
So, for example, whenever a user “likes” any particular pin within pinterest, an IFTTT recipe fires which sends information about the pin [url,title,contents etc] and the action [like] into the #SPG’s carrier stream.
The same principle applies to any action, on any platform – posting, liking, reposting etc – NB: a specific recipe must be created for each action.
The carrier stream for the #SPG contains a record of all recent responses from IFTTT monitoring recipes [generated either by .rss feeds or from user interaction with any of the supported social platforms] and delivers them to the #SPG system for processing.
- Stream source
The #SPG initially confirms that the latest post in the carrier stream has not already been through the system by checking for the presence of a specific identifying #hashtag. As all posts emanating from the #SPG contain this #hashtag, any post carrying it will be ignored and the next post in the stream is selected, continuing until a viable post is found.
The #SPG then extracts the following content [if present] from the post in the carrier stream:
It also makes note of the absence of any of the above.
Text to Image Conversion.
If there is no other content bar text [no URLs etc], then the #SPG turns this text into an image with a background randomly selected from a bank of bespoke images.
The #SPG then checks the origin/source of the content, and the content itself, looking for any material that may require special formatting rules, eg:
Tweets on Twitter
Pins on Pinterest
Specific publishers eg The BBC
To improve efficiency and create a greater appearance of scope to the #SPG’s output, whenever possible, all collected URLs are modified and reduced to their original sources, with stream referrers and extra code removed as needs be.
Whenever possible, all unnecessary extra characters eg ellipses, or superfluous text are removed from the content.
As default, an #SPG-specific #hashtag is added to the beginning of all posts, to give the #SPG an identity.
The flavour of an #SPG reflects its personality and, along with the choice of content of posts selected, this also includes any additional comments and #hashtags the #SPG adds to the original content prior to distribution.
“Who agrees with this?”
The #SPG can select these additions from arrays or databases, to reflect different personality types and the content of the original post.
The degree of additional flavour that can be added to content is ultimately dependent on the length of post [in most cases, this would be Twitter’s 140 character limit].
Depending on the outcome of all the above, and rules set up to reflect the #SPG’s individual posting style, the #SPG now makes decisions about the following:
Controlling post type:
Text, links, images etc
Including giving priority to certain media formats, depending on platform, content and source.
Controlling post distribution:
What post type to what platform?
What post content to what platform?
- post media directly to some platforms, and the link to the page containing the original media to others.
Content can be excluded/included at certain times or on certain days.
Never tweet about politics after 5pm, local time.
Only post music and video to facebook in the evenings and at weekends.
Once processed, posts are returned to IFTTT for distribution.
As with the monitoring process, all aspects of distribution are handled via IFTTT recipes. To avoid unnecessary complication, two separate IFTTT accounts are employed for each #SPG, one dedicated to monitoring [see above], the other to distribution.
Due to the significantly different ways the various social platforms process their content, the #SPG has a different set of rules for communicating with and delivering content to each platform. Each rule has its own IFTTT recipe. These are created for each method of posting on each social platform. The #SPG sends all revised content to these designated IFTTT recipes, which in turn deliver the content to their respective social platforms, in the appropriate format.
For example, Twitter has two distinct recipes; one for tweets with images, and one for without. The #SPG employs the recipe it has selected as being most appropriate for the content of the tweet so, if there appears to be an image in the original content, it would use the “tweet with image” recipe.
The choice of using IFTTT as a method of interacting with various social platforms is currently a simple one.
Ideally, the better option would be to harness the .APIs of all platforms associated with the system. But the majority of these platforms are constantly evolving, require various different types of authentication before permitting access, and then impose limitations on this access.
So, for the time being, rather than deal with the complexity of creating code to deal with these perpetually evolving systems, it was decided that, as IFTTT was already doing the job admirably, it would provide this solution instead, at least for the interim.