Key Issues to Consider When Developing Twitter Applications
This chapter is from the book
This chapter is from the book
This chapter is from the book
What You'll Learn in This Hour:
- Different types of Twitter users and how they impact code design
- Different types of Twitter applications and program architecture
- Things to consider if you are not building a web-based application
Types of Twitter Users
As one would expect with an API system as open as Twitter, and the explosion of interesting applications people have developed, we have also seen the development of different types of Twitter users. Understanding these types of users and knowing which of them we are trying to reach will inform how we may want to build our Twitter application framework. As with any large user base, there are a number of ways to set up categories. In this hour, we will break down and discuss the users in the following categories or types.
The News Reader
Twitter is a great source of breaking news, whether it's politics, business, sports, or following celebrities. Most users use searches to find what they are interested in, or they follow Twitter feeds that act like RSS readers. For example, BreakingNews is what you would guess it would be—a Twitter account publishing breaking news. Most news outlets have such accounts: CBSNews, ABC, BBC, and so on. The screenshot of NewsSnacker, an application created by the author (shown in Figure 3.1) is a good example of a Twitter application that focuses on the news.
)
Figure 3.1 Screenshot of NewsSnacker.
Although making search and Twitter account API reads from Twitter does not require authentication, you can still get dinged going over the API limit because Twitter will limit calls from an IP address. So, you still need to keep in mind how often you make calls. In the case of NewsSnacker, we use a white-listed account because the user could exceed the API calls-per-hour limit since each news service is a separate call. Suppose that the user has 10 sources and refreshes every 30 minutes. That is 200 calls in an hour, which is over the current limit of 150 for non logged in users. This does not include normal calls to check for new mentions or direct messages from the user's chosen Twitter client application. An alternative approach is to create a list of twitter news accounts and then call that list. However since newsSnacker removes duplicate posts, a large number of returns on the list call would be required. Both approaches have their merits however; one feature of newsSnacker is to allow a custom list of sources. This can be done by having the user log into the application and then select which of their lists they would like to call thus the second approach is being pursued in the next version of the application.
Chatters
Twitter does allow for people to have conversations; it's called a direct message. However, many people like to hold their conversations in public and a big attraction for these people is conversation threading. This is a very complicated proposition, so much so that new APIs are being created to deal with this situation. We will cover retweeting in later hours, but this could cause quite an impact on your code's structure because of older reply techniques that use the letters RT for conversations instead of recent API methods that support replies formally. So, supporting Twitter conversation is a decision you will want to make early in your product's design.
Power Users and PR Managers
Although you will have a drag-out fight between the two because one is personal messaging and the other is more professional, the impact on product design is not that much different. PR (public relations) managers, power users, and anyone who consumes or monitors a lot of Twitter information will put special requirements on you as a product developer. Like the limits to the number of API calls mentioned in the section discussing the user group news readers, the issues with the power users and PR managers group will be the same, with the added requirements of being able to sort and search the stream of messages that come in. They may also need to send messages on a schedule or from people using the same account. There is usually no simple way around this issue other than to start thinking of a well laid-out database up front. You may want to also explore having your server make the API calls and relay the information to your Twitter application in the form of automatic processes or bots. Furthermore, set up your architecture to deal with a wide variety of API calls. We will cover this later in the hour. PR managers will want more than just searching the Twitter stream; they will want to make sense of it and make sense of who is on that stream and their influence. The API has just expanded to handle retweets, but not all Twitter clients will be updated to work with this API. As such, you still need to pay attention to RT (the current convention for a retweet) and hashtags. Plan for this up front. Also, plan to keep some of the user information in your database; you will want to use it for user profile and relationship analysis. Although the number of power users, compared to typical Twitter users, is quite low, having a power user using (and advocating) your application is highly desirable, and although every power user you talk to will have a different list of features and functions, there are some things you must be able to support—for example, dynamic search. Just providing a call and return to the search API is not good enough anymore. The current and future power users of Twitter are going to demand just as much power and feedback as they get using Google search. For example, power users would want links with the tweets that are returned to be followed and analyzed in some manner. Perhaps you should show a thumbnail of the site, or display the title and the first 50 words of the link. Be sensitive to nonstandard protocols, such as searching stock quotes using the $ sign in front of the stock market ID. For example, $aapl for Apple. Power users are going to demand speed and customization and will fully expect that your application understand the nonstandard features (social conventions) of Twitter.
Microbloggers
Microbloggers will want to take the time to craft each tweet carefully. Pay attention to the ease of creating a message—that is, allowing them to save as drafts, sending to multiple Twitter accounts, spell checking (yes, spell checking), and although this is not easy, a quick look up of the other tweeters or access to a list of tweeters. Especially for PR users, you may want to have a look at simple web-based CRM products to give you ideas. A new API to Twitter is the capability to store lists of tweeters. This is useful to all power users as well as microbloggers.
High-Frequency Users (TwitterHolics)
The current rules of the API system allow only 350 calls per hour if you are logged in, 150 if not. This may seem like a lot, but based on what features you are providing to your users, this can go very quickly. It's not unlikely that you could have five API calls per user action if you need to make follow-up calls. If they are high-frequency users, they may find themselves approaching the 350-call limit pretty quickly. Although there are calls that do not require credentials, you could still run up against this limit because Twitter does count the number of calls from an IP. As such, be sure you monitor the number of calls the user has left and deal with it accordingly. The good news is that an API call exists for checking how many API calls the user has left which does not count against your API limit. However, calling it over and over again too often (every 5 seconds, for example) could trigger other traffic limit controls.
New Users
This is less an API architecture question than a GUI issue. Although GUI design is not addressed directly in this book, consider using clear terms and common metaphors (like an email system, for example) for the layout and functionality of your application. Do not assume that your users will understand various social conventions in Twitter, so explain it up front and design your functions' intent clearly using tool tips for icons for example. If you are making an application that reflects some aspects of the Twitter.com site, be sure to follow the conventions Twitter uses.
Bots
Bots (programs that perform automated tasks), including creating spam or setting up phishing attacks, will always be an issue. A sophisticated Twitter application will be aware of some of these bots and try to protect users. You may, however, need to create your own bots (for good, not evil). For example, you might take a RSS feed and republish it to Twitter after passing it through a business rules filter which is something the main Author of this book does. Because a bot is nothing more than "rules" you have for dealing with reading or creating Twitter messages or lists, you will find creating automated processes very easy with the Twitter API.