Voxilating

New ways to connect to friends - using URLs and Siri!

2011-11-08T11:39:00.000-08:00

You can now provide friends with direct-connection URLs in HeyTell! When they open the web page from their phone, they can connect to you automatically, as long as your privacy is set to Low or you've connected before!

In addition, if you're using Siri, you can set up a contact to open HeyTell and select a friend to talk to!

To build a direct-connect URL for HeyTell:

1. On iOS, Open the Profile page, tap Change, then select the contact you've set as yourself. On Android, tap Menu > Profile. Ensure that the string you want friends to use to contact you is set inside your email or phone number fields.

IMPORTANT! If you don't want to share your email address or phone number with the world, we recommend adding a contact here that you do not mind sharing publicly - for example, a long, unique string in the phone number field, a throwaway email address, or a Twitter handle to protect your privacy. Check out the Voxilate Privacy Policy for more information.

2. After changing your "This is Me!" contact, set your privacy to Low.

3. Build your URL! If you provided an email entry, your URL will look like:

http://heytell.com/user/?email=username@userdomain.com

where support@heytell.com is the data you added in your email field.

If you provided a phone number entry, your URL will look like:

http://heytell.com/user/?tel=13015555555

(don't forget your country code!)

Launching HeyTell from Siri

If you're using Siri, you can create a new contact, for example, we created a contact called "HeyTell Support" with a home page set to heytell://contact/email:myusername@mydomain.com. You can also annotate a current contact - just add a home page entry with heytell://contact/email:username@userdomain.com or heytell://contact/tel:13015555555 where their email address or phone number (including country code) is included in the URL.

Then, we asked Siri to "Contact HeyTell Support."

When she finds the contact, tap "home page" and HeyTell will open--if the user you selected matches, their name will appear in the To: field and you can HeyTell them right away! If more than one user matches the contact information, you'll be presented with a list to select from!

A few caveats: When adding a new contact, sometimes it takes Siri a bit of time to recognize it, but eventually, she'll figure it out!

As always, if you run into any issues or have questions, drop us a line at support@heytell.com, android@heytell.com, pop onto the Facebook page at https://facebook.com/heytell, drop us a tweet on Twitter at https://twitter.com/heytell, or join us at Google + at http://heytell.com/+!

A few notes on HeyTell 2.3 for iOS!

2011-07-30T08:18:00.000-07:00

We've got a few fun changes for HeyTell 2.3, so we thought we'd write a little bit more about 'em!

Alert Tones: We added a new extra that plays alert tones. You can set a global tone for all incoming messages, and can also set unique tones for friends and groups. You can also configure it to play the alert tone when a message comes in while the app is open. While there are a bunch of ring tones to choose from, we encourage you to check out the Dog Whistle ringtone - 50% of our team can hear it, and 50% can't - can you?

A new Voice Changer option: Alien voice allows you to speed up or slow down your voice - sound like a chipmunk, munchkin, or slow yourself down. If you've already got the Voice Changer extra, the option will automatically appear for you after upgrade.

Export messages to Twitter: We've had a lot of requests for this - you can now, in addition to posting to Facebook and email, you can post messages you sent to Twitter, SMS, or export a link. Note that messages you export this way are publicly viewable for anyone who has access to the link. To export this way, tap the blue arrow next to the conversation, select the message you want to export, then tap the Actions button and select the type of Online Sharing you want to perform.

New translations: We've added Portuguese, Norwegian, and Italian translations - many, many thanks go out to John André Netland for contributing the Norwegian translation and to Gabriele Ravanetti for assistance on the Italian version!

Bug fixes: You may find a few other bugs resolved - note that we continue to recommend using released and supported operating systems only, but if you do run into issues, definitely drop us an email - and a big thanks to everyone who's contacted us so far, we do appreciate the issue reports!

April Fool Public Relay Weekend!

2011-04-03T20:57:00.000-07:00

Thanks for trying out the public relay - what a great time! We had over 150 people join the relay over the weekend - some participating, some just listening in. Topics of discussion included mobile technology, accessibility, snake breeding, and oh-so-many things. Messages sometimes flew so furiously that our phones couldn't keep up!

We got a lot of good feedback, and we're going to go back and figure out how to make group chat even better. We've learned a lot and discovered a lot of issues -- and we think we have good ideas on how to improve them while keeping the spontaneous nature of public chat alive. It's too much fun not to!

But if you need your HeyTell group chat fix, there's hope on the horizon. In the next month or so we're going to allow users (iOS & Android!) who have the Groups extra to create Shared Groups, which allow group members to "Reply All." Stay tuned!

Make a Tap-To-Talk Link for HeyTell on iPhone

2011-03-05T08:02:00.000-08:00

Did you know that you can create a link that lets others connect to you on HeyTell? You'll need an iOS device and a Facebook account and can put this link in web pages, emails, Twitter...wherever you want others to chat with you - iOS and Android users can connect to you by tapping this link on their mobile devices.

Here are the steps:

Go to the Profile tab on HeyTell and connect to your Facebook account.
Find your Facebook ID. This is the tricky part, and you'll have to log into the Facebook web page to do this. Go to your profile and mouse-over your profile picture, then look at the status bar for a URL with a number at the end. The format should be something like "id=123456789". We are interested in just the digits; this is your Facebook UID. (More detailed instructions here)
Your tap-to-talk link will have the format:

http://heytell.com/user/?fb=#####

Replace ##### with your numeric Facebook UID. (EDIT: You can also view the link by going to the HeyTell Application on Facebook)

You can paste this link wherever you want, and as long as you have your Privacy Level set to Low, others can chat with you just by tapping the link on their mobile device!

This is an experimental feature, so please let us know how it works out! We'll be adding more (and easier, and for Android!) ways to connect in the future!

More HeyTell Server Upgrades

2011-02-19T17:42:00.001-08:00

We've been working hard upgrading our servers to handle all of our new users -- and the majority of the work is complete. We think the new system is a lot snappier and more reliable, and we're going to post the following graphs to keep ourselves honest:

This is the uptime for the main HeyTell service, and as you can see there were a few outages over the last few weeks as we worked through a few issues with the upgrade. The high number of outages reported (162) are due to some transient network problems that were reported as multiple outages, and our daily two-minute maintenance period (which is no longer needed).

You can come back here any time and view the graph, which is updated daily.

Please report any problems you encounter to support@heytell.com!

Happy 1st Birthday, HeyTell!

2011-02-11T10:15:00.000-08:00

HeyTell just hit its first birthday, and what an incredible first year it's been! On February 10, 2010, fresh off the adrenalin of the Saints' Super Bowl victory in New Orleans, HeyTell was publicly launched with very little fanfare. 33 intrepid users downloaded HeyTell its first day in the App Store.

One year later, with HeyTell exceeding 3.5 million downloads, HeyTell users are proving that there's a place in their hearts (and their work days, and their nights out) for quick, personal push-to-talk style voice messaging.

And for this, we thank you, each and every amazing HeyTell user — you are truly what has propelled HeyTell's growth and acceptance as a vital communication tool for daily use. Your passionate sharing of the app with friends, family, and co-workers makes inroads each and every day in pushing forward the idea of quick voice messaging as a highly effective and personal mode of communication...not to mention minimizing the number of sore fingers and misunderstood text messages out there!

We're also really happy to report that it's possible to bootstrap a product and have millions of people use it in just a year. It's surely not easy; we absolutely owe a debt of gratitude to our family, friends, and advisors, ubiquitous Internet and mobile broadband, cloud-based hosting like Amazon Web Services, and distribution channels like the App Store and Android Market. We believe this entire endeavor would have been nearly impossible to pull off just a few years ago.

So what have we been up to lately? We recently released a brand new backend architecture that should scale to handle our anticipated growth through and beyond the next year and are hard at work on improved clients for iOS and Android. We're also looking towards additional platform support and expanded localization support as part of our efforts to grow internationally. In addition, we hope to have some fun announcements for you in the coming weeks!

And, because no 1st birthday should pass without a 'baby book' of sorts, we give you HeyTell's 12 month usage statistics:

HeyTell reached over 10,000 people by the end of February 2010. HeyTell hit the 1 million user mark in October, 2 million by early December, and 3 million in mid-January. Our biggest download day of 2010 was December 25.

December 25 was also a big day for the iPod 4G - we saw 5 times the number of new iPod registrations on December 25 than any other day of the month!

Registrations don't mean much, though, if people don't keep coming back. Around 450,000 people check in with HeyTell each day now. Each week, 1 million check in. Every month, we see around 2 million users sending, receiving, or checking their HeyTells.

So why do HeyTell users keep coming back? We believe it's because their friends and family keep coming back. Over 1.7 million messages are sent a day in 2011, and, over HeyTell's year of service, over 215 million messages have been sent:

If it were possible to play all audio transmitted via HeyTell end-to-end, it would take 44 years to play it all back!

So who's using what? Our figures show that roughly 25% of our users run Android operating systems, and 75% run iOS.

The Android audience is very diverse, there are 1114 different combinations of Android device and OS, compared to 35 iOS variations. The most popular Android phone among HeyTell users appears to be the HTC Evo; however, the most popular since December 2010 is the Samsung Galaxy S.

So, that's the HeyTell year in review—thanks to everyone who participated in HeyTell's Year One—we couldn't have done it without you! We hope you stick around and we look forward to another fantastic year ahead!

iOS and Android: The Odd Development Couple

2010-11-29T08:31:00.001-08:00

We recently ported our app HeyTell from iPhone to Android, and found that we gained a little perspective in the process. Because it uses a large number of system features (native widgets, location, database, audio, network services), porting the app really required a deep understanding of each platform.

A great way to get an understanding of the strengths and weaknesses of any software platform is to port software from one platform to another. For example, in the early days of my programming life, I'd write a simple "Missile Command" game to get a feel for a specific platform.

Here are some of the various perspectives of the iOS and Android platforms, and how we view them differently after the port:

User Interface - iOS has the benefit of being based on a mature UI framework (Cocoa) and Android has had to play catch-up with features (like animated views). iOS has the edge here with some features -- table/list views in particular are much more full-featured, if a bit difficult at times. Interface Builder also is much more slick than anything available on Android (I just edit the XML files directly on Android), so I'd say iOS wins this one.

Application Framework - Android and iPhone have very different ways of looking at the world. Android tries to model an app as a loosely-coupled set of Services, Activities, and Content Providers, while iOS sandboxes each app like a traditional OS. I understand the rationale behind Android's design, but I think it confuses more than it delivers.

Performance - We've never had serious problems with performance, although iOS seems to have a snappier UI in general and do a better job with compositing and animation. Both platforms allow native code (Android via the NDK) for CPU-intensive code.

Language - Objective C does seem to have a steep learning curve and a lot of new concepts compared with Java - especially regarding memory management. However, if you look under the surface, Android has many of the same issues (look up "android memory leaks weak references"). But if you're experienced in Java, you'll have a lot fewer hurdles with things like threading on Android.

Third-Party Libraries - There are roughly equal numbers of iOS and Android libraries on GitHub, for instance. On iOS, you have easy access to any C/C++ library (without going through JNI), while on Android, you have easy access to the thousands of native Java libs. I'd say this one is a tie.

Development Tools - Eclipse is a great environment and is perfectly optimized for Java programming. XCode isn't bad either, and the experience is a bit more polished. I do really appreciate the command-line tools like adb you get on Android, however. My partner is a big fan of the Dalvik Debug Monitor Server (DDMS).

Documentation - Apple has great documentation, and you can find pretty much anything you want to know there or in its example code. The Android docs are not quite as comprehensive, IMHO. We do use Google Code Search to search the Android code base ourselves, which is very helpful at times. But you're going to spend a lot of time on Stack Overflow, no matter what you pick. :)

Market - One feature of the Android Market is that you can push an update at any time without review. This is really comforting from a developer's standpoint (maybe not so much from a user's, but we're happy about it). Android also lets users comment on their stack traces, which is really neat. Okay, sometimes the comments are not so nice, but often they add steps to reproduce - this is really helpful, especially when it seems like we see a new piece of handset hardware appear in our matrix every day and testing across all devices/OSes/firmware revisions/carriers/whizzbang modded ROMs on Android is unfortunately really tricky for a small, bootstrapped team.

Monetization - Because HeyTell is free, we don't have any perspective on pay vs. non-pay apps on either platform, but Apple's In App Purchase capability has served us well. In App purchases are really important for us, because not all users want or need all features, and we don't want to charge users for features they don't want or need. Our fingers are crossed that Google adds an IAP capability soon. In addition, on the advertising side, there really isn't anything on Android quite as turn-key as Apple's iAd. All points go to iOS here, at least for now.

Ban the Internet Blacklist

2010-11-13T08:05:00.000-08:00

We at Voxilate oppose internet censorship and internet blacklisting. We do not think S.3804 (Combating Online Infringement and Counterfeits Act) represents the independent software development community.

For more information on the bill, click here or here. For a list of supporters click here.

To contact your Senator or sign a petition against the bill visit Demand Progress.

The following is the text of the letter we sent to Senator Ben Cardin of Maryland:

Dear Senator,

I have communicated with you in the past about technology initiatives in Congress. I'd like to call your attention to another bill, S.3804, or the "internet blacklist" bill.

As an entrepreneur whose business depends solely on the Internet, this bill greatly concerns me. It is an unreasonably heavy-handed approach to a problem which already has many solutions such as the DMCA which are backed in legal theory.

The bill will not be effective at stopping copyright violation or unauthorized distribution of any kind. Those who wish to share content will easily find a workaround -- they always have. We in the software industry begrudgingly accept a certain amount of piracy as a way of life, and I do not believe this bill represents our interests.

S.3804 would only serve to create an environment of uncertainty which would disrupt commerce and encourage other countries to avoid or bypass US infrastructure. Larger businesses would continue to operate in legally grey areas and lobby to avoid the blacklist, while emerging small businesses would be destroyed.

It is unsettling that just months after the President signed the Daniel Pearl Freedom of the Press Act, we are proposing a bill which would censor American internet sites and blacklist American companies. More policing is not the stimulus our country needs right now.

Please vote no on S.3804.

Viral Marketing for Nerds and Data Junkies

2010-11-09T09:25:00.000-08:00

Thanks for everyone who attended my Viral Marketing at 360iDev in Austin! Big thanks to John and Nicole for having us as speakers.

For everyone who asked, slides are below :)

Viral marketing by the numbers

View more presentations from Voxilate.

Steve & Jen Speaking at 360|iDev Austin in November

2010-08-26T07:24:00.000-07:00

We attended 360|iDev San Jose in Spring of 2010 and had a great time — learned a lot, met a lot of really cool people, and got a chance to connect with fellow travelers on the indie iPhone developer scene. Great fun and a tremendous learning experience!

We enjoyed it so much, that when we heard "November in Austin," we knew we'd be there for sure. It seemed like a good idea to give back and share some of the things we've learned from the release of HeyTell Voice Messenger, so we both submitted talks — and both were accepted!

Steve will be presenting Viral Marketing by the Numbers where he'll bring a developer's perspective to marketing the freemium iPhone app HeyTell Voice Messenger and how it gained 100,000 users using a purely viral marketing model without paid ads or employing conventional PR.

He'll talk about the features and performance of viral vectors by the numbers, predicted vs. actual growth, and will draw some parallels between viral propagation of an app and nuclear reactions. The audience will hopefully take away additional ideas and strategies for successfully incorporating viral elements into their applications.

Jen's going to dig into The Reluctant SysAdmin: Managing the Server-side of a Client/Server iPhone App, where she'll talk about all the fun and not-so-fun things about managing the server-side of a client-server app with an emphasis on security, reliability, and survival (and sleep!) when you're small & indie.

She'll hit on some of the fantastic things about maintaining a server component (metrics, Push Notifications, App Store receipt handling, did we mention metrics?) as well as the not-quite-as-fantastic (24x7 system monitoring, data security, and attacker-thwarting, rolling upgrades for services that can't go down, the occasional sleepless night) and will then focus on processes, products and technologies that make this all easier for a small team to implement, including continuous integration strategies, use & abuse of Amazon Web Services (EC2), and open source solutions for security & monitoring.

As you can see, we're really excited about 360|iDev in Austin - if you're coming, can't wait to see you. If you're considering, hurry up and book it! If you're not, reconsider and book it anyway!

Gauging User Sentiment with Word Clouds

2010-08-24T09:12:00.000-07:00

We just released the HeyTell Android Beta and, in the calm before the storm, wanted to take a little break and do something a little frivolous. Perfect time for word cloud creation! Why not take a look at frequency of the words users use to describe HeyTell for iPhone 2.0.3 when reviewing the app on the App Store?

So I popped over to iTunes connect, expanded user comments and saved as HTML. A little command line fu, like such:

grep "review-text" DownloadedComments.html |awk -F '\">|\<\/P' '{print $2}'

Copy and paste the output to http://wordle.net, et voila, user sentiment made pretty:

Requirements Tracking For Total Slobs

2010-07-26T19:23:00.000-07:00

I'm now working on an iPhone/mobile startup with just a handful of people, and we typically get things done via shouts, IMs, and emails. This works for us, but I used to work at a company which did things *much* more formally. We will refer to this way of doing things as (drumroll) The Process.

The Process goes as follows: Product Managers generate Functional Requirements which go to the Engineers which turn these into Design Requirements which go to the Developers which develop The Product which goes to QA who uses the Design Requirements to create a Test Plan which then gets sent to Integration Teams which use the Documentation generated from the Design Requirements to make the Installation Guide which then results in the Customer getting ... well, something.

This is a little heavyweight for the standard indie dev shop, but there's a good practice hidden here, which is the generation of Requirements. Why would you want to make actual Requirements when DESIGN.TXT in your home directory will do just fine? There are several reasons:

They encourage you to record design decisions, and act as high-level code documentation.
They give you a way to generate test plans - each requirement should be a testable feature of the product.
When doing a port to another platform, they let you know when you're done (when all the requirements are checked off)
They let the test team know when they're done (when all the requirements are checked off)

These all boil down to "scoping" your product. Any external party can look at the requirements of your application and get the gist of what's going on without looking at code, and if you do it right, they can test/document/port/translate/regress/whatever and know that they haven't missed anything.

Of course, no one is really going to go through much extra effort generating documentation when they could be making apps and making money. That's foolish. That's why I'm going to show you my bone-simple Requirements Generation Technique. Watch closely!

1. A requirement is defined in a source file (.c, .cpp, .m, .java etc) with a code comment. Here is an example:

// Requirement: When a Butterball is hit with a bullet, split it into two Niblets.

2. Generating a design document is done as follows:

% find . -name '*.[cm]' -print0 | xargs -0 grep Requirement: > design.txt

3. Doing a "Gap Analysis" (comparing two design docs) is done as follows:

% sdiff design1.txt design2.txt

With a little effort, you can pipe requirements to CSV files and upload to Google Docs so other team members can review, make test plans, etc.

Congratulations! You've just replaced thousands of dollars of expensive requirements-tracking tools and at least three middle managers! You've also taken a step to better documenting your code and your product so others can more easily play in your sandbox. You don't need an overweight version of The Process like our example bureaucratic organization, but it helps to have a little organization in whatever you do.

Top 10 Bolt-On Cocoa Touch Libraries

2010-04-05T20:44:00.001-07:00

In the last few months of iPhone dev on apps such as HeyTell, we've learned a lot about how to save time and add features by taking advantage of third-party libraries. In no particular order, here are some of the easiest to integrate (thus "bolt-on"):

1. Reachability - Every iPhone developer should know about this. It's the Apple-approved way to check to see if network connectivity is available from your app. It helps to wrap this with your own code for generating helpful Alerts when the network bounces up and down.

2. SFHFKeychainUtils - The Keychain API may look scary, but it's useful too. How else will you store encrypted, backed-up key-value pairs that persist across uninstalls of your app? This wrapper API has just a handful of easy-to-understand methods.

3. Plug in an analytics API like the Medialets SDKs to capture information about your app at runtime. In just a few minutes you can be capturing app installs and start/stop events, a little more time gives you custom app events and lets you integrate ads into your app.

4. java-apns - Ashwin Phatak's Java library for push notification. Requires a bit of integration work (and a server component) but much better than rolling your own. (ok, so it's not a Cocoa Touch library per se - but it's essential if you're doing APNS in Java)

5. Combine your native code with HTML by using PhoneGap and iUI to make look-alike user interfaces in HTML, JavaScript, and CSS.

6. If you're a game developer you must have heard of OpenFeint, so there's no need to explain this popular social-media-enabling bolt-on library.

7. Appirater helps you get feedback on your app by requesting a review after a configurable amount of time or number of app runs. Just a few minutes to integrate.

8. The default HTTP client libraries sometimes don't cut it, especially when streaming or multi-threading. Try ASIHTTPRequest and get a wealth of features above and beyond what the standard NSURLRequest provides.

9. When building apps that parse XML from REST queries, you may want to try TouchXML which provides an easy-to-navigate DOM tree object from your XML documents. Don't like XML? Try Google's Protocol Buffers or Apache Thrift for more efficient and robust network protocol structures.

10. And when your project is ready to ship, give Hudson a try to automate your builds. The new Xcode 3.2 provides features that may help in archiving built products, but I think there's still value in doing a clean checkout and build from the repository (instructions for iPhone here)

We hope these give you some ideas on how to save precious mental CPU cycles on your next iPhone/iPod/iPad project!

Reduce your micro-startup burn rate...and see the world, too!

2010-01-07T08:34:00.000-08:00

At Voxilate, we've taken a novel approach to reducing capital expenditures while maximizing productivity and creativity: we're taking the show on the road and are putting our money where our mouths are--creating voice-activated applications for mobile devices while being mobile ourselves!

This is a bit easier to do as a micro-startup (also known as "Micro ISV"), given highly-available mobile broadband and ubiquitous wireless Internet connectivity, competitive hosting and "cloud" solutions, and the myriad online, hosted services at our beck and call these days.

Here's a quick rundown of tips we've found vital to our mobility so far (we will expand on these in later posts):

Mobile broadband: Don't leave home without it. We purchased a wireless broadband plan and wireless card that's plug-and-play with our mobile broadband-enabled CradlePoint MBR900 router. We also have a PepWave Surf personal wi-fi receiver that can harness available wi-fi and make it available to more than one team member or computer.

Network redundancy: Make sure you're bound to more than one network and/or cell provider. You want to always be able to call out, check email, and connect to remote systems with at least one of your team's phones or netbooks using wireless broadband cards or cell-phone tethering. We often switch between AT&T and Verizon services. Would be better to switch between three or four - but we're talking about belt-tightening, here!

Hardware: In addition to your mobile broadband card and portable routers, a good mix of laptops, external hard drives, and small form-factor systems like the Mac Mini will serve you well. You'll also want cigarette-lighter power adapters to power and charge your stuff - and, if there are more than one of you not driving while on the road, use the router in the car with the broadband card. Also remember to bring power strips, outlet expanders, Ethernet cables, thumb drives, extra chargers, connectors, and so on.

Internal Systems: You should have a source control system, build system, and bug system for development. What you choose to administer locally or remotely is up to you, but do make sure that everyone's got a copy of the source repository checked out and if you're self-hosting build & source control, ensure that you can swap build and source control systems from one laptop or mini-server to another in case of catastrophe. If you're going to be someplace for a day or two, make sure you check in your code. During this 'period of stability,' remember to also rsync (or some other replication method) to back up your critical systems to your hard drives as well as a secure off-site backup provider that you trust and uses encryption.

Hosting redundancy: Choose hosting providers you trust and who have good reputations - don't always go for the cheapest (although price doesn't always mean quality, either!). Look for hosting providers that provide data center geographic diversity. Augment with other providers - you want the ability to quickly bring your systems up in case of a hosting provider's catastrophic failure. Amazon's web services are excellent for this purpose--encrypt and backup your data to S3, build your backup systems with EC2 & EBS--and pay only when you need to bring them up or test (and you can bring them up in minutes, with simple shell scripts). Great for staging/development/pre-production servers, too.

System monitoring & Maintenance: You'll want to set up something to quickly alert you via email or SMS when remote systems go down - use a service like Pingdom and supplement with self-monitoring on your hosts. Sign up for system status and downtime alerts (if you're not added by default) for all of your providers. Follow their Twitter feeds and check your email. Do what you feel you need to do to keep peace of mind and security; script it, add it to crontab, and have it email you its results. For example, scan your web logs for unexpected traffic that doesn't 404. Monitor vulnerability alert RSS feeds for software you use (both locally and especially on your externally hosted systems). Use Snort and OSSEC. Use whatever tool(s) you love. I love elementary shell scripts. Lots of people love Nagios. Many adore splunk. Mix and match for great justice.

Delegation: Use services to do your bidding and spend your time doing what you do best. Take advantage of great services like Amazon's Mechanical Turk for quick, repetitive, or data entry type tasks and 99designs.com for graphic design expertise. Get a good accountant that can meet via phone or email. Use online fax and voice services to stay connected wherever you happen to be.

Mail: We use trusted family members and a mail receiving/scanning service, Earth Class Mail. You can view your mail online and have it scanned and/or snail mailed to you wherever you happen to be, singly or in batches. They even have an auto-deposit option for checks you receive. Also try to configure anything you can to send you bills and notices online--scanning costs can add up.

Digital and Physical Security: This is a biggie! When you're carrying your tech like a turtle on your back and depending on the wireless of others, an awareness of both physical and network security are vital. Don't connect to wireless networks you don't trust. Don't check your bank balance using hotel wireless, for example, and always check certificates (although that isn't any guarantee these days, unfortunately). Be careful what you download. Bring your own routers to ensure that you can connect to your local resources without going over the public Internet.

As far as the real world goes: Assume everything you have will be stolen and plan for the occasion. Make copies of all important documents and store with someone you trust. Categorize the importance of what you're lugging, then lock up the most valuable things and keep them on your person when you leave your vehicle for the night. Get into a routine, and make everyone crosscheck each other so you don't leave anything behind.

Short-term locations: Go beautiful, go off-season. Use sites like HomeAway.com. Check out executive long-term stay spots as well - if you plan ahead, you can often get a really nice condo in a great location for much less than you'd pay for a standard hotel room.

Make sure they've got broadband, and come prepared with all the things described above. Plan your stays around your work schedule - stay awhile if you're in deep development. You don't want to be on the road (well, with the tips above, you can be if you want to be!) when you've got a lot of coding or testing to do!

Trust, but verify: Verify your setup before you embark long-term. Use your network setup where you're currently at, then take it with you on the road. Try staying somewhere local for a week or more, near friends/family/business acquaintances so that you can easily offload equipment you find you don't really need.

These are just a few of the things we've done to reduce our micro-startup 'burn' while enjoying a spectacular view.

EN576M6GTHWF

Turking the Healthcare Bill

2009-11-20T19:31:00.000-08:00

As some of you have no doubt heard, the 2,000+ page healthcare bill is making its way through the U.S. Senate and is due for a preliminary vote on Saturday evening. There's a big challenge ahead for legislators trying to make sense of this complex and lengthy legislation.

We'd hate to pass up the opportunity to perform a public service, so we took a few minutes to use our technology to ask Internet denizens (via Amazon's Mechanical Turk) to collectively read the bill in a lot less time than the 36 hours it would take to read it on the Senate floor.

We know that the eyes of the average citizen tend to glaze over looking at the bill, so we opted out of asking turkers for a deep analysis of each page -- they wouldn't have context of neighboring pages, for instance. We instead asked for a visceral response; we asked each turker to type in their most favorite and least favorite words (from their point of view, of course) that they could find in their particular page of legislation.

First we converted each page of the extremely-long PDF into individual bitmaps -- each one looking something like this (though larger):

Then we used our command-line client (discussed previously) to submit each page individually to Mechanical Turk.

The best (most preferred) words can be visualized in the following word cloud:

The worst (least preferred) words are here:

So what does this all mean? Well, if you read the images literally, citizens want quality affordable health benefits, information, and respect. They are fearful of abuse and fiscal limitations . They also loathe the bill's document structure ("subparagraphs" and "subsections") and legal mumbo-jumbo ("striking" and "amended").

The final costs were as follows:

Mechanical Turk fees: $20
Time until entire bill was read: 8 hours

The $20 fee results from each worker's payout of 1 cent for their analysis of a single page. Certainly you'd have to pay a well-heeled K-Street analysis firm a bit more for a similar result. ;)

Batching Mechanical Turk Jobs at the Command Line

2009-10-09T09:13:00.001-07:00

Here at Voxilate, we use Amazon Mechanical Turk for a lot of things - from crowdsourcing translations to gathering market research to deciding where to go for lunch! Some of the jobs are one-time deals that we don't want to spend a lot of time on.

Typically, you can submit, monitor, and approve Mechanical Turk jobs (HITs) using the API or the web interface. The web interface requires a lot of mouse-clicking and .csv file generation and it really doesn't allow for full control. The API is complex and doesn't lend itself to quick experimentation. There are also a set of command-line tools provided by Amazon, but these just wrap the API and can be a little clunky.

Wouldn't it be nice if you could just type a single line and watch Workers' responses come back in real-time like this:


% mturk -j 3 -t "What is your favorite color?"
blue
blue
red

Or this:


% mturk -t "Who is in this picture?" albert.jpg bea.jpg
Albert Einstein
Bea Arthur

We thought it would be pretty cool, so we created a quick script using Python and the boto library.

How does it work?

Given a command like:


./mturk.py -p .50 -j 10 -t "Is there text in this graphic?" -D "If you see text in this graphic, type \"text.\" If not, type \"no text.\"" -w 300 -A IsThereText01.jpg IsThereText02.jpg

We'd create two distinct HITs - one for each file (JPEGs, in this case). The -j parameter controls the number of assignments we submit for each HIT; in this case, we'd run 10 iterations of each HIT, for a total of 20 assignments. Each assignment would pay out 50 cents (specified by -p .50), and because we used -A for auto-approval, you'd be out $10 if workers accepted and completed all of your hits!

By default, the script uses the Mechanical Turk sandbox so that you ensure that your usage is correct before spending real money. The -w option ensures that the script waits the specified number of seconds for HIT results to print to standard out, then exits.

In our example, we used JPEG files, but the input files themselves can be:

Blank - You don't want to pass any data, you just want to ask a question with a single answer.
Image, Audio, Video - show the user a picture, video, or sound and have them return a response.
HTML - This allows you to have full control over the HIT. Whatever <form> tags you use in the HTML file now posts results to Mechanical Turk. They are hosted on Amazon S3 as an "external question" and appear in the IFRAME of the HIT. (More on this in a future blog post.)

We've found this really kind of useful - for instance, we've used this script as part of a Makefile to implement a complicated workflow. Let's run through an example.

First, let's check our status:


$ ./mturk.py
You are in test mode.
Funds remaining: [$10,000.00]
There are 0 jobs active.

Note that we see $10,000 because we're using the sandbox. If you had active jobs, you'd see the jobs listed by HIT ID and filename. Running mturk.py in live mode (./mturk.py -l) will show you how much money you really have:


$ ./mturk.py -l
You are in LIVE MODE.
Funds remaining: [$41.38]
There are 0 jobs active.

Next, let's submit a job. In this batch, we're using the sandbox (no -l!), and "paying" 4 cents for each assignment, with two iterations of two graphics for tagging. We should auto-approve submissions 360 seconds after completion and wait 400 seconds before exiting the script.

Here's what we run and see on the command line:


$  ./mturk.py -p .04 -j 2 -t "Tag this graphic" -D "Type keywords, separated by spaces, that you think best describe the image. Please enter at least 2 and no more than 5 keywords." -k "voxilate tagging" -d 120 -e 300 -a 360 -w 400 Namazu.jpg SydneyOperaHouse.jpg
You are in test mode.
Uploaded to http://com.voxilate.mturk.s3.amazonaws.com/home/jen/Turkpipe/Namazu.jpg
/home/jen/Turkpipe/Namazu.jpg: Created HIT 936MY1Y9KY4ZTJH4ZXTZ.
Uploaded to http://com.voxilate.mturk.s3.amazonaws.com/home/jen/Turkpipe/SydneyOperaHouse.jpg
/home/jen/Turkpipe/SydneyOperaHouse.jpg: Created HIT M1N2Y04MX34RW21CGY6Z.
/home/jen/Turkpipe/Namazu.jpg: 0/2 assignments completed.
/home/jen/Turkpipe/SydneyOperaHouse.jpg: 0/2 assignments completed.

And here's what we see in the Mechanical Turk Sandbox:

Next, we'll play worker and grab some of these HITs:

And the other:

We'll then see changes at the console, as it polls for completion:

/home/jen/Turkpipe/Namazu.jpg: 1/2 assignments completed.
/home/jen/Turkpipe/SydneyOperaHouse.jpg: 1/2 assignments completed.

Because we submitted two iterations, the Turk won't let me do *all* of the tasks myself, so we wait for other workers to jump in to complete them (on the Sandbox, bug a friend or use another account). When complete, the script exits, dumping the following to the console:


/home/jen/workspace/Turkpipe/Namazu.jpg: 2/2 assignments completed.
/home/jen/workspace/Turkpipe/SydneyOperaHouse.jpg: 2/2 assignments completed.
catfish japanese art
japanese catfish painting
sydney australia opera house
Sydney opera hall Australia water

And that's it - Turking at the command line successful! Add a -l to the command (and an -o output_file to save results to file) and you're ready to go live!

Mobile-Enabled Silent Auction

2009-09-03T21:02:00.000-07:00

We've been recently playing with Twilio, and looking for other niche IVR applications to build. The perfect opportunity arose as we were involved with helping out a local charity event.

During the event, there's a silent auction. Attendees bid by entering their name and the amount of their bid on a bid sheet next to the item, and at the end of the event the winners collect their bid sheets and pay for their item.

Cash and check are obvious -- but using a credit card requires the winner to transfer his information to a volunteer who manually enters it into a payment system. There are always more people looking to check out than volunteers to take their payment, so this process is ripe for automation.

Here's a quick walk-through of how it works:

All bid items are listed in a Google spreadsheet

Users at the silent auction enter their name, bid amount, and phone number on the auction sheets.

When the auction completes, on-site staff enter the winners into the Google Spreadsheet.

Bidders dial the Twilio-provided number and enter their phone number as a PIN (automatic if they send Caller ID). They are told whether they have won, and if so, what their total is (important for those who bid on multiple items!). They are then instructed to say their names, addresses, and other pertinent information and are of course thanked for participating.

This information is then transcribed and posted into the Google Spreadsheet (this is fun to watch in real-time!) The Twilio link to audio is also included in case the information needs to be double-checked.

On-site staff can then complete the checkout at their leisure.

We're using Google App Engine for serving the TwiML responses to Twilio, and the Google Data APIs for connecting to Google Spreadsheet.

There are a couple of issues right now, like that of credit card numbers traveling throughout the cloud -- even though all communciation is encrypted between Twilio <-> Google, some of us have a security background and we like to be extra careful ;) We're also looking @ payment integration to pre-authorize cards, for instance, and a SMS back to the winner to tell them their payment has been verified.

The ultimate addition would be to have the entire bidding process phone-enabled, and a demo of such a system is what we've demonstrated with our Twilio contest entry! You can call (877) 277-9839 to try it from your cell phone. Click here beforehand to see the auction items. (Don't worry, it's only a demo .. bid away!)

But this does show how a mashup that takes just a few hours to build might save a ton of headaches and help out a good cause!