REuse, REcycle, ReTWEET! A WAWNN post

I've been writing this post off and on as I work on the Cooperative Retweeting functions. The concept was simple. The implementation... Not so much. 

What else is new, right?

The short, sweet version of the idea

Users divide the world into three Groups, their Clan, their Tribe, and everyone else.

Users set how many supporting retweets they want to put out for their Clan and Tribe.

Retweets solve three issues. First, they give much-needed variety to a tweet schedule. Second, they allow for a mutual support system between users. Third, they make an account much more interesting for potential followers.

Everybody loves a retweeter. (tweet)

For the App-With-No-Name, it also opens the door for pure Content Curators to function effortlessly.

Clans

A Clan is a list of Twitter screen names that the user wants to support. They are not limited to the accounts you control, although they could be. 

The system assembles all the tweets it scheduled from all your Clansmen (sorry, “Clansperson” sounds weird). It randomly selects whatever number of tweets you pre-set and rebuilds them as RTs. Then it schedules them evenly throughout the day.

Clansmen don't have to be members, yet. Of course, the system will only have access to their tweets if/when they join. Until they do, the system will ignore them. If/when they join their tweets will be available for retweeting. You only need to add Twitter handles to your Clan.

Here’s my Clan:

aaron_skogen aurorasacoach beBeeblogs beBee_EN ChefsUnDiet CherylSnapp DBGrinberg DrGarySharpe FedeAlvarezSm GloOchoa GuyLeChevalier InsightsOccur InvisiTech JaredWiese JavierBeBee Jenaiamorane Jimbobmur juanblanco76 KarthRajan Mamen_locutora Mialis79 milosdjukic011 MSweetwood OutThinkingPD PaulCroubalian PepeUrries PIWillia QuimojoTweets riccikeeper RuffRidersPets sarahelkins WayneYoshida

About half of them are not member/testers. Jared, Jena, and Mamen joined recently. Their tweets just started appearing in my tests.

You may note that I'm in my clan. Twitter allows that. So does the Web-App-With-No-Name. I don't particularly like the idea. It's there just for testing. I'll remove it later.

Note that Clan Retweets have access to everything from the original tweet. They are old-school style RTs. Essentially, they are a new tweet based on a previous tweet.

Tribes are Different

Tribes are more like Topic families. Right now, I have 8 named Tribes. I only defined the Content, Writing, and Editing tribe.

• · Content Writing and Editing,
• · Environmental Issues,
• · Arts and Recreation,
• · Lifestyle,
• · Travel and Hospitality,
• · Business and Finance,
• · Fitness and Wellness,
• · Technology.

I’m open to creating a few more Tribes if people want. I don’t mind changing them around, or combining them either. 

Don’t be shy with your suggestions. The Web-App-With-No-Name is crowd-built. Your input is welcomed and appreciated. (tweet)

Let’s keep the number below 10. You’ll see why in a minute. You’ll also see why I say that only one tribe is defined.

For the Live Test, only the Content Writing and Editing Tribe will be active.

We need quite a bit of processing power to create a Tribe’s tweet list.

First, I choose a few big name influential accounts in keeping with the Tribe topic. Then ...

• We grab all their tweets over a given time. That’s a lot of tweets.
• We grab all tweets from everyone who retweeted or mentioned them. That’s a helluva lot more tweets.
• We count the number of retweets and mentions for each distinct tweet from the major accounts.
• We rank each tweet by the number of retweets it earned (popularity).
• We delete duplicate tweets
  

• We schedule system retweets in order of popularity, in the number you specify.

Phew!

QUESTION: I’m toying with the idea of only using the X# most popular tweets and randomizing which ones get retweeted. Please leave your thoughts in the comments section. Doing that brings up the possibility of duplication but allows for more varied retweets by members.

Users can change Tribes whenever they like, as often as they like. Well, users can change as often as they like anyway. We calculate possible retweets daily. Changing Tribes more frequently won’t accomplish anything.

Two Flies in the Ointment

Nothing ever goes smoothly, right? Even when you think it does, it doesn’t. That’s one of Life’s paradoxes.

The First Fly in the Ointment

A retweet is a different API call than a tweet. It’s simpler to use the tweet call, but that makes butt-ugly retweets. They become text-only. 

If you want to have auto-RTs that look like manual RTs, you must use the retweet API call.

A couple of my coders argued for using the tweet call. It needs less server space and scripts. It’s also the way everybody else does it.

We aren’t everybody else. Retweet calls it is. That means a little more work on the back end.

Tougher for us. Better for you.That's a no-brainer decision. (tweet) 

The Second Fly in the Ointment

At first, I wrote the scripts to set RTs daily. The server would ...

• Start with the first member
• Grab the Clan list.
• Grab every Clanmate’s tweets scheduled for that day,
• Grab every Tribal tweet for the previous day,
• Grab those Tribal Tweets mentions,
• Grab those Tribal Tweets retweets,
• Rank mentions and retweets
• Build the possible retweet lists,
• Select retweets,
• Schedule stuff.
• Move to the next member and start all over again.

All the user needed to do was set how many Clan tweets and how many Tribal tweets they wanted.

The script was set to run once a day. That way, retweets would always be for the most recent tweets.

It worked beautifully. It also worked too slowly. It’s no biggie for the few of us testing the App. What happens when we get to the 5000 or 10000 maximum accounts?

SIDE NOTE: Yes, I plan to limit total membership. The idea is to give a marked advantage to our members. I can’t justify giving that advantage to everyone. An advantage that everyone has is no advantage at all. (tweet) The eventual number is still an unknown. It will be a balancing act between the minimum required for profitability and the maximum desired for functionality. I’m really hoping to be able to stay below 5000 accounts. 

For 5000 accounts, the script will need about 18 minutes to do what it needs to do.

Not good. That would mean that nothing else would happen during those 18 minutes. I could add more servers, but I really want to stay below $5 a month.

Some ReThinking about ReTweeting

If a job is too big to do in one shot, break it up into smaller jobs. Then, spread the work out.

We can’t have a server run a long process at a set time. Let's have the user trigger the retweet scripts individually.

When a user logs in he/she refreshes the scheduled retweets.

First, we check if you already ran the scripts today. If not, we delete all scheduled retweets and repopulate them with the most recent available retweets.

Problem solved. Another problem added.

That’s par for the course.

Since the log in triggers the retweet schedule, the user must log in to schedule retweets before the schedule runs out. 

When you set how many Clan and Tribes retweets you want, you also need to set a time range for scheduling. Choose a time slightly longer than your average time between visits to the App.

If you log in once a week to schedule your latest post, choose 9 days. If, like me, you access every day or so, choose 3 days. Those are just suggestions. Choose whatever you like.

The system can also send you a reminder email that your retweet schedule will expire shortly. It will include a link. Click the link to refresh your retweets.

Important Notes for Twitter’s new rules

On September 19th, Twitter announced major changes to what counts in the 140-character limit. One of those changes was that @ mentions would no longer count. Frankly, I think they’re opening a humongous can of worms.

Scammers and spammers are probably delighted. How Twitter will police them, I have no clue. Until Twitter figures that out, their attempts will adversely affect many legitimate users.

I think that’s what happened to me recently.

Twitter muzzled my version of the App. They said it was due to, “a large volume of unsolicited @mentions.” My first thought was that someone complained that I promoted their post. That makes very little sense.

Everybody loves Retweets and Mentions of their own stuff. (tweet)

Now, I wonder if it isn’t just Twitter trying to figure out how to flag spam. If so, they overdid it.

The Web-App-With-No-Name doesn’t violate any rules. When I asked why they muzzled it, they reactivated it instantly.

For the next little while, limit the number of mentions in the tweets you schedule.

That applies to any scheduling method, not just the Web-App-With-No-Name. If your scheduling app allows for it, monitor tweet success. If you see many errors (HTTP code 401 or 403) in a row, contact the support team at wherever.

For the Web-App-With-No-Name, that would be me.

Cooperative Retweets are ready... Sort of

We wrote all the scripts and database modifications. The scripts are completely functional. The pretty pages to access them aren't.

We will have those pretty pages ready very soon. Then we’ll move into live testing. Remember, only the “Content Writing and Editing” tribe will be active during testing.

I think I’ll also include a simple text list of your retweets just to show you what it did for you. We’ll remove the list when the feature goes live for real.

I’ll get the pretty pages set up over the weekend. 

Live testing will start next week.