The Experiment

A number of test participants will be presented with a series of screenshots from various Twitter accounts. Upon seeing each screenshot, the test participant will make a single yes/no choice about whether they believe the account is a genuine representation of its owner. The participant will also be given the (optional) opportunity to explain why they think that account is genuine or fake. This information will help confirm if the factors I mentioned in my most recent blog post are relevant. Each participant will receive the same list of screenshots, though the order in which the screenshots are presented will be randomised. This is to help prevent order bias.

The reason I refer to the “genuine representation” of an account as opposed to the person who operates the account is to allow for users who delegate management of their account to another person. This is normally the case for high-ranking politicians such as Barack Obama and David Cameron, the latter of whom has previously given reasons for his lack of enthusiasm towards Twitter.

I previously mentioned the factors I believe influence a Twitter user’s decision on whether a given account is genuine. Based on these beliefs, each screenshot shown to a participant will contain the Twitter account’s:

• Avatar
• Username
• Biography/description
• “Verified” icon (if appropriate)
• Location
• Personal website information
• Three sample tweets by the account

So, a participant may be shown this image as an example:

I also intend to collect some profile information from each participant (e.g. age group, gender, level of computer experience, if they are a Twitter user) to help determine if different groups of people look for different pieces of information when authenticating a Twitter account.

Implementation

As this experiment will essentially be a series of questions answered by humans, any existing survey or questionnaire software should prove sufficient for collecting the raw data. Some survey creation services also provide automatic analysis of the data, saving time when I’m making my own analysis and conclusions.

The two main services I am looking at are SurveyMonkey and Web Survey Creator. Both websites offer free accounts for creating surveys, each with a maximum of 100 respondents per survey. However, while SurveyMonkey only allows a maximum of 10 questions per survey for a free account, Web Survey Creator allows for an unlimited amount of questions. However, neither allow for questions to be given in a random order, which is something I would require.

The “roll your own” alternative is LimeSurvey, an open-source survey tool. This software offers many of the same features as an online service, but since it will be deployed to my own web hosting there will be no limits for the number of respondents or questions per survey. The documentation does not mention anything about assigning questions in a random order, so I will need to investigate this software further before making a decision on whether to use it for this experiment.

Background

For my assignment I have decided to further explore the issue of trust and what factors are most influential in helping to decide whether to believe a given Twitter account. In my project proposal, I outlined a number of possible factors a person may look at when making this decision:

• The account’s username?
• Use of a face vs. a logo in the profile picture?
• Not having a profile picture (default “egg” picture)?
• If a user’s interests or expertise is listed in their “about me” section?
• If the account has been verified by twitter (blue tick)?
• The number of other users following the account?

The issue of trust within social media is itself a very broad, with certain aspects this field having already been examined. A paper titled “Twitter under crisis: can we trust what we RT?“ by Mendoza, Poblete & Castillo studies the behaviour of Twitter uses in a emergency disaster situation and the effects that false information and rumours can have on the situation. While not directly relating to the topic I wish to cover, it does offer an insight into how much more easily people would believe rumours in a desperate situation, as well as detailing how rumours can be detected by aggregating tweets.

Another article “Interpersonal Trust: A Comparison of Attitudinal and Situational Factors” (Scott, 1980), looks more into the issues of trust between people, and the circumstances which affects this trust. I feel this would be a good help with my research, however the article is currently restricted.

The language and structure of Tweets can also be an influence in making this decision; According to Ellis, Capra & Cowcroft (“In the mood for being influential on Twitter”, 2011) “popular and influential users linguistically structure their tweets in specific ways.” Therefore any experiment to gauge the believability of given Twitter users must also contain a number of sample tweets from those users.

The Hypothesis

It is my belief that a Twitter user would be able to determine whether another account is genuine, an imitation or spam by looking at their profile picture, description (biography) and a small sample of tweets from the account. I intend to test this hypothesis by presenting a number of people with a sample number of Twitter accounts containing the above information, and asking if they believe those Twitter accounts are genuine or imitations.

Despite being less than a month into 2012, one of the year’s biggest agendas already seems to be coming to the forefront as Governments increasingly try to legislate activity on the Internet. In the past couple of weeks alone we’ve seen the rise and fall of SOPA and PIPA as well as the ratification of ACTA, which lead to the resignation of one MEP from the European Parlament.

One of the websites which seems to fly in the face of legislation the most (outside of piracy websites) is Twitter, the micro-blogging service. On a number of occasions last year Twitter users found themselves skirting the law, most notably in the case of Ryan Giggs. In that particular case Giggs had taken out a super injunction to prevent the media from commenting on an extra-marital affair, however this did not stop over 75,000 Twitter users and a Scottish Sunday newspaper from naming him, making a complete farce of UK privacy laws in the process.

But how can we ascertain that a source on Twitter is genuine? How do we know that the information it provides is genuine, or that the user him/herself is trustworthy? While the Twitter account that outed Ryan Giggs and other famous faces, one of the tweets relating to an affair between Jeremy Clarkson and Jemima Khan was later strenuously denied. The twitter account in question was a throwaway, likely to help avoid any legal repercussions, however the overall accuracy of the information helped it to gain nearly 100,000 followers.

But could any one person simply create an account, post a couple of tweets about a topic subject and gain 100,000 followers? What qualities do people look for when trying to determine if an account and/or the information posted by it is genuine or not? And how does the ability to create a throwaway twitter account cause problems for pre-Internet laws? I will be examining this question over the coming weeks and will post my research and findings on this blog.

So what next? How do I drum up some more publicity for RSS Alarm now the initial media coverage has faded away? A very difficult question for a team of developers, let alone a one-man operation. The clue to this answer is that this is version 1.1.0 of RSS Alarm, not v1.0.5. This is a major change.

After some time pondering this question, I’ve decided to release a free “lite” version of RSS Alarm. This version will be supported by banner advertisements, however I’ve been very careful to place these adverts non-intrusively. They will not get in the way of your normal usage, but will still appear prominently at either the top or bottom of the screen. The positioning of these adverts may change in future versions, but I promise not to place them in positions that seem underhand or interfere with your usage of RSS Alarm. If you’re not a fan of adverts, upgrading to the full version for 99p will also get rid of them.

For those who have purchased the full version of this application already, I’d firstly like to thank you for buying RSS Alarm, you’ve really made me smile over this past month. As a reward, not only will you copy remain ad-free for life, you’ll also get any big new features at least one version earlier than the free release. And what better time than now to give you your first reward?

Shake To Snooze is a brand new feature for those who own the paid version. Have you set your alarm a bit too early? Too tired to open your eyes? Just reach over for your phone and give it a shake, and the alarm will be postponed for 10 minutes.

So, to summarise:

• I’m releasing a free, ad-supported version of RSS Alarm
• Major new features will be exclusive to the paid version for at least one release.
• Bug fixes will be released for both versions simultaneously.
• Shake to Snooze is new and exclusive to the paid version for release v1.1.0.

• The ability to specify the amount of time between RSS Feed updates. (Main screen > MENU button > Settings)
• Alarm will be dismissed when moving away from the alarm screen (e.g. pressing the back or home key)
• All indexed podcasts will now be displayed on the Feeds screen, below the list of RSS Feeds.
• Did I mention RSS Alarm is now on Google+ and Twitter?

The update will automatically download to your phone shortly (provided you’ve allowed automatic updating), and if you don’t have RSS Alarm yet, you can buy it here.

- Fixed bug that prevented users from importing their feeds from Google Reader
- Fix bug that prevented the Text-to-Speech engine from reading out RSS feeds.

As you can see, those were problems that warranted an immediate fix, so here you go. Updates will be arriving to your phones within the hour.

I’ve downloaded the app and it looks great  and is easy to set up and use, I love the night clock mode.

 RSS Alarm also had an honourable mention in Thursday’s Guardian App Blog:

Clock widgets are ten-a-penny on Android, but RSS Alarm has a neat twist: it wakes you up by reading your RSS feeds, including podcasts. It works with Google Reader, Google Listen and other podcatcher services, and uses Android’s text-to-speech engine.

This has been absolutely brilliant, and I’m very pleased to see that the initial reactions are very positive. A huge thank you to everyone who has bought the app so far, and if you’ve enjoyed using RSS Alarm then please pass your recommendations to your friends and family.

If you don’t have RSS Alarm yet and want to grab it from the market, then you can grab it here!

Today’s been a very good day. Following several months of work and a number of UI redesigns, I’ve finally signed off RSS Alarm and uploaded it to the Android Marketplace. Given how hard I’ve worked on this project in my spare time and how much time I’ve put into it, it’s both relieving and very satisfying to finally see it up on the marketplace (and already attaining a five star rating!). So here’s a brief rundown and a few thoughts:

What is RSS Alarm?

In short, it’s an alarm clock with the ability to read RSS feeds aloud. In reality it does a few more things on top of that. It can also use any podcasts present on the phone, including podcasts downloaded by Google Reader. It can even use the standard alarm tones if you just fancy using it as a replacement to the built-in alarm clock.

How does it work?

The application works largely thanks to Android’s Text-To-Speech functionality. Text is fed in (parsed from the RSS feeds), which is then read out by the phone in what can only be described as a sexy female version of Stephen Hawking. Android’s built-in TTS engine certainly isn’t Siri, but it’s certainly decent enough.

The feeds themselves are managed directly by RSS Alarm and are automatically refreshed every 15 minutes. I plan to allow users to change this interval in a later version, but for now that should be enough without eating up too much data.

The alarms are pretty much what you’d expect of any alarm clock app. Alarms can be set for any minute of the day, for any day of the week. Alarms can be set as one-offs, or can repeat for certain days of the week.

Other features

There’s a few other neat things that RSS Alarm does, without going into too much tedious detail. Firstly is the importing of RSS feeds from your Google Reader account (which can be accessed from Feeds > Menu > Import).  Just enter your Google Reader username and password, and RSS Alarm will automatically start importing all of your feeds from Google Reader. Simple.

Then there’s the podcast import. RSS Alarm will automatically scan your storage space for any Podcasts, from both Google Listen and your phone’s /Podcast directory. And if you do use a podcast as your alarm tone and hit the snooze button, RSS Alarm will continue playing the podcast from that point ten minutes later.

Finally, there’s the night clock. A soothing way to glance at the time when you’re trying to sleep, this was one of the best-appreciated features of RSS Alarm amongst our Beta testers. Providing the perfect amount of lighting, this feature allows your phone to sit on your bedside table as a true alarm clock replacement.

Oh, and it’s also available in Traditional and Simplified Chinese thanks to the translation skills of my amazing Fiancé. <3

What’s next?

That entirely depends on how much time my University course eats up. Final year BSc Computer Science is very time consuming! I do have some ideas in mind, particularly customisation features, so if I do get to implement those ideas I’ll post them on this blog. Likewise, any future changes to RSS Alarm will be documented on this blog on release.

As mentioned before, it’s up on the Android Marketplace right now for only 99p/$1.59! Give it a try!

Thanks for reading, and enjoy the app!

Changelog

v1.0.1 - Minor bugfix. Solved issue where “Language not found” dialog would appear on feed screen, despite the user’s language being supported by the text-to-speech engine.

v1.0.0 - Initial release. 

Development

All in all, not really that much to do once I had done a bit of planning, making it the easiest part of the app development process. The app consisted of two activities – of which one was a menu with only three buttons – and a class to parse the rules of a game. By having a rule parser instead of hard-coding the rules into the generator activity, the app can be expanded in the future to pick numbers for more international lotteries e.g. the Irish lottery.

Within 2 hours a functional-but-unpolished demo of the app was created, and any functionality bugs were ironed out. I was particularly pleased about how this stage turned out, given the lack of time for planning and documenting the classes.

Interface Design

Screenshot of the main menu.

The toughest part of an app’s development, for me at least, is the design of the user interface. Human-Computer Interface (HCI) design is one of my weaker aspects, which is probably why the HCI module was my second-lowest score at Uni last year. However, because this was meant to be a simple app, I needed to keep the interface just as simple.

I’m really not a fan of Android’s default black-on-grey scheme, and looking at the vast majority of decent apps out there, neither are most developers. Luckily android’s interface is very customisable, but this in turn presents its own challenges. Namely picking a decent colour scheme at half 3 in the morning with tiredness starting to overcome the caffeine levels.

Nevertheless, it was time to open photoshop and visit the ever-lovely Colour Lovers to pick a colour scheme. Given the lottery games this app would cover, I opted for a blue and red scheme similar to that used by the UK National Lottery. I had experimented with a few other schemes prior to this, but they just didn’t seem to fit in with my vision for the app. The background would be an off-white fading to a very light sky blue, with white on red for titles and white on blue for buttons. The same scheme would apply to the generated numbers, with the main numbers appearing on blue balls, and the “special” numbers appearing on red balls to highlight their significance.

In the end, nothing fancy, but this was to be expected given the limited timespan.

Final thoughts

Screenshot of number selector.

Other than creating a few promotional graphics and testing on different screen resolutions, the app was done. I exported the package, organised all the media files and uploaded everything to the Android Marketplace. Within minutes the app was available for purchase and at 5.50am, with the first light of the new day appearing, my work was done.

To go from a concept to a finished product in one night gave me a good insight into the Android development process and gave me new ideas on how to translate the small-scale processes from this one night’s work up to a larger, more involved project like RSS Alarm. More importantly it’s proof that, given enough effort and the right idea, a potentially high-selling application can be made and put to market in a very quick time.

How you interpret that name is entirely up to you