Archives
Posted in PlaceShout | 3 comments 
Andre
We’ve just launched PlaceShout (http://placeshout.com) – a “cheatsheet”-style summary of places around town, created by you and arbitrated by the community. Now you can see what’s important about a place without wading though stories about someone’s neighbor’s dog.
If you have ever been anywhere, you’ll enjoy making shoutouts. You’re limited to 100 characters, so save the long-winded narratives for someplace else.
You are probably thinking that PlaceShout’s signup process is a long, arduous process. Let me be the first to assure you that it is not. If you have one of those new-fangled OpenIDs, you can sign right in. Because we’re web 2.0 like that.
The easy doesn’t stop there. To make a shoutout, just type it in along with and the name of the place:
Confirm the place:
Like magic, the shoutout appears:
People are shouting out places in small towns and big cities…
- According to Megan, Welsh’s Pizza of Pender, NE (pop. 1,145) is the “Best place in the tri-county for pizza!”
- Jim Benson is living the big city life in Seattle, WA (pop. 3,263,497), and spreading the news that Cafe Besalu’s “Ginger biscuits will make you happy”.
Where are most of the shouters? Right now Ann Arbor, Michigan is in first place. You can see all the cities and add your city here.
Like maps? We have a map. And it has nifty directional arrows:
Try it out now: http://placeshout.com
no comments
Derek
Cormac McCarthy, author of No Country for Old Men, is a man that isn’t afraid to break away from the accepted structure of English language:
- He doesn’t use quotation marks
- He doesn’t tell you who is talking
- Say goodbye to apostrophes
- Occasional long sentences joined together by “and”
In a previous novel, when a Spanish-speaking character spoke, he didn’t translate to English.
His style makes the story of a drug deal gone bad in a remote desert location come alive. An author going through the motions might write long passages describing the scenery, the characters motives, their backgrounds, etc – but that doesn’t capture the confusion that would really occur in this situation.
It struck home to me when thinking about building software – sometimes we go through the motions when solving a problem. We don’t focus on the problem itself. It’s asking ourselves “How can I build this RESTfully?” before really thinking about the end-user’s interaction. Perfect technical execution of an inferior solution is worse than breaking a pattern to better solve a problem.
no comments
Derek
This American Life recently profiled Harold Washington, the first black mayor of Chicago. The episode featured one of the most stiring sound bites in my recent memory – a portion of a debate that served as Washington’s coming-out party. It was easy to imagine myself listening to the minute-long segment on the radio and knowing instantly that whether I liked it our not, this longshot is going to win.
I love these moments – when I hear/see/do something new, and know instantly that I won’t return to the old way. They are the reason I build web applications. Getting an email from someone that used one of our applications and experienced this is amazingly gratifying. It’s easy to forget that this happens regularly for many of us in the web industry, but other professions experience this much less frequently.
Why do you build web applications?
1 comment | no trackbacks
Andre
Have you noticed how much easier it is to remember directions in your own city? Think about the last time your printer ran out of ink and you had to jot directions to a restaurant on a post-it. Compare that to writing out directions from a hotel to a restaurant in an unfamiliar city.
It's a lot easier on familiar turf. Why? Near home, the directions are anchored by points of familiarity in your mind. You already know how to get to someplace nearby, so you can use that as a ready point of reference. Closer to home, you get to use all kinds of reference points: your work, familiar street names, the park you go to, etc. Because that's the way your brain works. In your brain, everything is a relative reference.
This is equally true if you are communicating directions to someone, rather than just writing them down for yourself. The better you know the person, the easier it is: "go like you're headed to work, but turn left just before that Thai restaurant you like." Not only are the directions concise, they are simple enough that you probably don't need to write them down. Communicating is a lot easier when there are shared experiences, reference points, and a sense of "knowing what the other person knows."
There are lessons in here somewhere for those of us who create software. After all, we spend a lot of time with our computer trying to find things, either on the computer (photos, spreadsheets) or with the computer (a book on Amazon, that page you Delicious'd -- or did you mark it in Google Reader?). I often think of this when I'm using Delicious. I know I bookmarked something, but wading through the tag cloud to find it again takes too long. I usually end up finding it with a few Google searches. When the first search fails, there's usually something in those first results which triggers my memory on the keywords that will retrieve it.
Can software infer what is familiar terrain for us, and provide navigation relative to that? Can Google or Delicious know what my mental "anchors" are, and help me find stuff from there?
An OS-level example: I have a dozen or so Ruby on Rails projects in /Users/andre/projects/rails/, and I spend a lot of time in the immediate subdirectories. If there were a heat map of the places I spend time in, this directory would be hot. Would that be useful as a navigational device? Possibly. If a place got hot enough, the OS could ask me to label it in a way that's meaningful to me. I might use that as a jumping-off point as long as spend a lot of time on Rails projects.
Obviously there are pitfalls when trying to get a computer to guess what you're trying to do, or what's important to you (R.I.P Clippy). Still, there are bound to be payoffs for trying to get the computer to present navigation the way you think, rather than how it computes. A good start is to think about how our brains tend to remember things clustered relative to familiar points of reference.
Posted in Community, Ruby on Rails, Speaking | no comments
CBQ
Just a quick note that I’ll be speaking on Lessons from the Trenches – Learning from the Rails Bootcamp at the regional Ruby on Rails Conference dubbed acts_as_conference (a play on the Rails way of introducing behavior through code) in Orlando, Florida, on Feb 8-9.
If you’re interested in how to effectively teach your friends, colleagues, bosses, and maybe even your mom about Ruby on Rails, registration is now open to the public. Looks to be a great conference line-up, with keynoters Obie Fernandez and Dan Benjamin, and plenty of great talks.
Posted in Keeping it Simple, Ruby on Rails | no comments
James
As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I'm a big follower of that philosophy.
However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I've run across recently.
First, let's talk about filtering spam. I'm sure this raise some eyebrows, but I believe spam filtering is a human's job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it's a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That's right, I'm doing it all by hand and I much prefer it to any other system I've tried.
My complaint here isn't against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.
My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don't really account for my need to make corrections at all. I'm glad we make things so easy on the computer, but that means we're inconveniencing me. That can't be right. If I must be involved anyway, I want my role to be as simple as possible.
When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that's fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.
Let's talk about another example. In one of the applications Highgroove is currently working on the "Create" step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn't be a great experience. It's just one of those edge cases where it's really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.
How did we address this? With a good old fashioned phone call.
The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It's low hassle for all parties involved and gives the application that extra personal touch.
What will we do if the application grows so huge that this process becomes a bottleneck? Well, that's a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.
Don't let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can't handle too well don't underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.
no comments
Derek
When getting a shuttle to the airport, I came across this great idea immortalized in clipart.
Posted in Ruby on Rails, Business | no comments
Derek
Andre and I recently finished the initial launch of Placeshout’s Facebook application. There are several “getting started” tutorials available on building Facebook applications with Ruby on Rails, but there were quite a few issues we ran into that are beyond a “How To” blog entry.
If you are building your first Facebook application, expect very slow going at the start. I’d take your time estimate and double it. Here’s why:
- It takes some time to grasp Facebook in a multi-developer environment. You need to create separate Facebook applications with different names using different tunneling ports. You’ll also need to create several test accounts. Inevitably, I installed one application when I meant to install another. Getting our version control system setup for our development boxes and production system took some time.
- Understanding how Facebook handles sessions. We ran into several issues – knowing when to require an app install vs. a login, handling an app install redirect inside an iFrame application, etc.
- We ended up using a combination of Rails’ #respond_to and unique Facebook-only actions to handle requests. Many of our pages were quite different in Facebook, and trying to fit format-handling in the existing actions only made things more confusing.
- Testing was a pain. Because we integrated with Placeshout.com, we needed to integrate user accounts. Planning and testing integration steps took quite a bit of time. Facebook and rFacebook have some testing conventions, but that’s like saying that because the speedometer in my Ford Escape goes up to 120 MPH, it can go 120 MPH.
- The rFacebook gem and plugin were our weapons of choice. I don’t have any complaints. We modified several pieces of code to fit our application – including creating a user and installing the application, but that’s not out-of-the-ordinary. The rFacebook team has done a solid job in a short amount of time.
In the end, it felt a lot like traveling to a non-English speaking country – at the start it’s difficult to get basic things accomplished. Once you get in a groove though, you enjoy the scenery and forget that at one time, you didn’t throw up when drinking tap water.
Posted in Business | 3 comments
CBQ
You may have noticed a change of scenery on the Highgroove Studios site, and (for those of you not in feedreaders) this blog.
We’ve taken a good look back at where Highgroove has been, and a bigger look at where we’re going.
Here’s a highlight reel from the new web presence:
- We’ve got Andre Lewis (also known as Rails guru, technology expert, published author, geo-location extraordinaire, Alcatraz-swimmer, nice guy). Andre has joined the Highgroove team as a Partner.
- We’ve got products. Placeshout and Scout (limited client-only) are up and kicking!
- We’ve got vision. We’re still focusing on our sweet spot – solving complex problems with simple solutions. Making web applications easier to use. Making technology easier to understand. Embracing constraints. Leveraging Ruby and the Ruby on Rails framework.
- We’ve got great clients. Fortune 500s, government agencies, educational institutions, DemoGOD winners, Salesforce-award-winners, and very happy companies of all sizes and shapes.
Check out our new site, and let us know what you think at hello@highgroove.com.
