Hi All. Just a quick post – I forgot to mention that I’m in Northern Nowhere this week. So, like two weeks ago, if administration is slow, it’s because I can’t get to the internet. 😛
As promised, here’s the post about the development process of the BeerRiot Facebook app.
Aside: Wow, rereading that last post about the Walled Gardens, I can’t believe I posted it. Totally fluffy lameness. Forgive me – this post will not be as bad.
I could very easily make this another post like others out there right now. Many people are upset about how unfinished the Facebook API is. Documentation is lacking (and only available online), specifications are weak, and test environments could be more feature-rich.
But, except for that little digression above, I promise, this is not one of those posts.
Instead, I’d really like to remark about how great it is developing this app in Erlang and Erlyweb!
There are nearly a dozen different Facebook API implementations – every object-oriented web language you can name. Facebook’s own official one is PHP5. I could have used the PHP version – Yaws comes complete with the ability to run PHP scripts. But, since the rest of BeerRiot is already in Erlyweb…
I rewrote the Facebook client in Erlang. And truthfully, it really wasn’t that bad at all. Erlang comes with very simple HTTP-communciation and XML-munging code. Hell, there’s even a simple way to compute an md5 sum. Once I figured out how to actually put together a proper POST and walk a rather verbose XML tree, the rest was just mimicking as closely as possible the official PHP scripts.
All this is not to say the process wasn’t without difficulties. Yaws’ standard url_encode proceedure doesn’t like nested io_lists very much, so I’m doing some ugly string/binary flattening. And, Facebook’s errors are nearly meaningless … but this isn’t about Facebook complaints. 😉
There are yet more benefits. Rather than dealing with cron firing up processes periodically, I have fully-supervised Erlang gen_servers up to date constantly with what data needs to be pushed out to Facebook. I can log into the running server and examine the current active sessions, monitor profile data pushes, etc.
Extending my existing Erlyweb application to handle new Facebook requests from the canvas page was even pretty simple (once I finally – I think – understood the Facebook session rules). Another controller, another view – bam!
One of my few real pains was source control. I may need to finally bite the bullet and leave CVS. I’m hearing good things about SVN. But that’s another topic.
So, chalk up one more win for Erlang/Erlyweb. Fantastic existing libraries. Quick development environment. Crazy server flexibility. I’m staying as long as I can.
Yes, I promised new things well over a week ago. My excuse is that I picked up a cold during my trip to the Middle of Nowhere that took me out of commission for a solid week. 😛 But, now that that is over…
I’ll probably talk more about how the development went in another post. Right now, though, I’m thinking over the whole “Walled Garden” argument.
For many of the apps, both the data source and the data sink reside inside the Garden – Facebookers talk to other Facebookers. For another large chunk, the data source is outside, but the sink is still inside – Stock quotes, sports scores, etc.
For BeerRiot, I’ve managed to allow the data source as well as the data sink to be on either side of the wall. Beers and comments added by Facebookers can be seen by non-Facebookers, and the other way around. Really, I’m just using Facebook something like an OpenID provider.
Of course, for some apps this isn’t necessary, and for others it may be impossible. But, it feels like this is the right way to think going forward. Using this method, there would be nothing stopping me from bridging more walls to connect more gardens together, while still keeping the web at large in the loop.
Okay, I’m about to fall asleep, and I can’t tell if this blog post is just simple fluff or not, but I’m going to post it anyway. Post in the comments if you like/dislike the FB app, what you think of Walled Gardens, or how bad this post really is.
I just wanted to warn all those interested that admining will likely be slower than usual this weekend. I have to make a trip to the middle of nowhere. The only internet connection I’m likely to have will be in my hotel room. Even there, I’m rather worried that the connection will be so awful that I won’t be able to handle anything but the simplest tasks.
Actually, the worst part may be that the nearest brewery is hours away.
On the upside, though, the long travel time is likely to be spent hacking at new features. (Provided I don’t find myself stuck without documentation, of course.) So, hopefully, you all can look forward to new things next week.
I’m not a fan of “settings” pages. They give a terrible interaction experience.
To change settings on a settings page, I have to stop what I’m doing; open the settings page; find, change, and often save the setting; then find my way back to what I was doing. If my change wasn’t exactly what I wanted, I have to do it all over again.
More often than not, this breaks my concentration to the point where it may take me minutes to figure out what I had been doing, and get back to it. Productivity tends toward zero.
So, I’m trying something different with BeerRiot. I’m going to try to keep all settings relevant to the page they affect on the page they affect. No need to leave to find the setting elsewhere – just change it and update.
I forsee only a couple of occasions that I’d ever have to make an exception: the structures to change the setting would consume too much space, or the setting doesn’t relate to any other page. The latter is already exemplified by email and password settings.
I think these exceptions being on separate pages may make sense, though. If the structures take a lot of space, they may be complicated, so focusing on them alone may be helpful. If they’re not related to the page I’m on, then I’m probably not worried about getting back to that page after I change them.
Today I have the default map view setting on the map view page, maximum item list lengths on each item list page, and each member’s public information on their own public page. I think they fit pretty well, but of course I’d like to hear what you all think.
Also, does anyone know of any research on this topic? I’ve read a bit of general user-interface stuff, but I don’t recall anything that specifically spoke to “settings” pages.
Don’t Throw Out Maybe Yet!
Jeffrey Zeldman’s post “Maybe” is one option too many caught my eye this afternoon. I completely agree with him that “maybe” is a pain in the neck. From my vantage point, yes/no (or like/dislike) are the only user inputs that really matter.
Most of you will notice that BeerRiot has a third option – “shrug”. It wasn’t always this way. The first versions of BeerRiot had no middle ground – you liked a beer, or you disliked it. I was staunch in my position, callously telling people that they should make up their mind.
It wasn’t until over half of the first twenty people to which I showed BeerRiot asked, “Where’s ‘meh’?” that I started to change my thinking. I started to realize that being forced to make a black/white decision was making people uneasy. They really wanted the comfort of being able to postpone making their choice.
The decision was pretty easy at that point. I wanted people to stay around my site. Therefore, it seemed a good idea to make them comfortable. Shrug was born.
In the time since introducing shrug, I’ve found it to be more than just indecision. It’s a way to acknowledge the existence of a thing, without passing judgement. For beer voting, it lets me know that although I have no strong feelings about a beer, I have tried it (something I have trouble remembering with the wide variety available). I can see it working similarly for party invites: it lets the organizer know that even though I don’t know my schedule, I have, in fact, received the invitation.
Here’s another way to think about it. Suppose there is no “maybe” option. You must either accept or decline the invitation. So, what are people who don’t respond? Are they not “maybe”? Maybe you’re a pessimistic person: you consider non-responders “no”. Okay, then, if all non-responders are “no”, then why even have a “no” option? Why not just have “yes”? A unary system – respond “yes”, or you don’t exist.
For BeerRiot, at least, that would seriously cut my dataset. I think the same would be true for party invites. You couldn’t even tell what kind of buffer you might want to plan for – all you would know is the number of people who are definitely coming. Or in BeerRiot’s case, I couldn’t tell if a beer is controversial – I’d only know the number of people who like it.
So, I say don’t throw maybe out yet. It’s more than just indecision. It’s user comfort and metadata all rolled into one.
I’ll leave you with this, though: I don’t see the point in more than three choices. “Kind-of-like” and “Sort-of-dislike” are even less data than maybe to me. At least with “maybe” I can tell the voter is unsure. With “maybe-like”, I can’t tell if she’s unsure or genuinely less positive about this beer than others.
P.S. I love Bill W.’s comment about rating other people’s ratings. It’s exactly the kind of problem that BeerRiot tries to solve.
Night of the Lagers was awesome. There were quite a few beers there that really did break from the stereotype of Fizzy Yellow Water ™. In particular, I’d call attention to The Tap’s Pilsnaah – really a great example of what I think a pilsner-style beer should be.
There were also beers that didn’t appeal to me, of course, but the big news of the evening was Harpoon’s absence. The brewery sponsor, with their Official Beer of the fest, Pre-Prohibition Lager, didn’t even show up Friday night. The word is that the “Pre-Pro” turned out so bad that they refuse to serve it. Very sad, if not fitting that the recipe from the old days fell to the problems of the old days – you never knew what would come out of a barrel after months of storage.
Anyway, I’ve added the rest of the line up for Saturday’s sessions under the same tag. Please log in, rate, and comment if you’re going today. There are quite a number of beers on the list that I really wish I could be there to try myself!