Posts Tagged ‘software design’

Simplicity in Mobile Software: Showing Instead of Telling

December 28th, 2009

Simplicity in Mobile Software Design

In Simplicity We Trust.

One of the most difficult parts about being a start up is focus. Initially you look at a bunch of different ways your product solves problems in the name of getting customers. After you get a handful of customers buying your product, you’d think that problem would go away, you’d have more confidence in what you are building. In fact, the opposite is true, because now you have even more people thinking of new interesting and amazing things that you should add to make your software better, faster and easier to use. The more features and functions you add, however, the harder your software is to use.

We’ve collectively made a decision here to stick to simple. With the mission of making mobile technologies simple and accessible to more companies and organizations, we’ve collectively come to realize that simplicity starts with us. For our Text a Librarian and 2-way text messaging software it starts with believing in the “Big Red Answer Button” (a mantra that came from hearing one of our customers explain why she loved using our software).

Big Red Answer Button

In most others, however, it has come down to one thing: Showing, not telling. This means using visuals, videos, use cases, etc to illustrate our usefulness and reducing the amount of words used. This direction feels good. It didn’t come easy, but with everyone on board, it is easier to explain what we do and people are getting it.

Here’s to simplicity in 2010!

For those of you interested in learning more, here’s a link to the Ten Laws of Simplicity. It has played a vital role (along with us collectively asking “is it easy to understand?” at every turning point) in use moving this way heading into the new year.

Why We Don’t Use Google Voice as an SMS Gateway: It’s Illegal

December 28th, 2009

Google products are great and we use a handful of them at our office. But the question of using a “Google Voice SMS Gateway” for text messaging reference software has come up recently with regards to Mosio’s Text a Librarian, so we wanted to quickly explain why we don’t do it.

The answer is simple: it’s illegal.

It’s Illegal, Part 1: Screen Scraping and Polling
Google Voice does not offer any sort of API (permitted) way of letting you piggy back your technology onto Google Voice, to receive text messages via your Google Voice number and then use them in other software. What that means is that anyone using Google Voice to piggy back on their text messaging function is doing so by automatically logging into the system, which is known as “screen scraping” or “polling.” Doing this is a direct violation of Google’s Terms of Service:
5.3 You agree not to access (or attempt to access) any of the Services by any means other than through the interface that is provided by Google, unless you have been specifically allowed to do so in a separate agreement with Google. You specifically agree not to access (or attempt to access) any of the Services through any automated means (including use of scripts or web crawlers) and shall ensure that you comply with the instructions set out in any robots.txt file present on the Services.”

It’s Illegal Part 2: Reselling Google’s Services
Google as a company is a wonderful contributor to the open source movement and offer APIs to many of their products. Google Voice, however, is not one of them. Currently there is no Google Voice API and depending on who you ask, the response is either hopeful or “there’s no way that will happen.” Regardless of which side you stand on, any organization or individual selling software that includes Google Voice hacks is again doing so in violation of Google’s terms of service:
“5.5 Unless you have been specifically permitted to do so in a separate agreement with Google, you agree that you will not reproduce, duplicate, copy, sell, trade or resell the Services for any purpose.

It’s Unreliable
When Google releases APIs to their software and services, they are providing reliable access under an agreed upon set of circumstances (some involve commercial vs non-commercial rights, etc) and make product change decisions with APIs in mind. Simply put, when they make changes, they do so either without affecting the API or by giving those with API access appropriate information so adjustments can be made, ensuring the services will still work well. With no API, there’s no warning, no information on why code changes. If you’re accessing Google without an API and things begin not working, there is no recourse in getting things up and running again.

We hope this clears up any questions people have regarding Google Voice and why we don’t use it as an SMS gateway. We think Google Voice is pretty cool, but it’s not a legal, reliable way to offer text messaging software to libraries, companies or organizations, so we opt instead for legal, approved ways of giving our customers access to text messaging. As far as Google being a company the supports openness, we applaud them for being so, but also recognize that Google is open when it’s convenient for them. While it may not be “go to jail” illegal, it’s simply not a risk worth taking.

If you have any questions for us, please feel free to contact us.

The Mosio Team