funkatron.com

Spaz has been around a long time: since early 2007, which I think makes it 77 in Internet Years. It’s been a while since I started playing with the Twitter API in RealBasic, and later under AIR after I saw the Pownce desktop client and wanted to make my app look cool like it.

A lot has happened since then. A lot of cool stuff with Spaz, and lot of cool stuff for me, and a lot of sometimes cool and sometimes not so cool stuff with Twitter. Now we have a desktop client, still on AIR, and a native mobile client for webOS. Spaz isn’t SUPAR POPULAR, and it’s not proved to be anything but a giant time and money sinkhole, but it’s been a very fun ride.

Through all of this, Spaz has stuck with open technologies: JavaScript, HTML and CSS. We’ve done so because we’re dedicated to true openness and transparency. The Spaz Statement of Purpose spells out the project’s reason for being. And in the light of Twitter’s moves to make the microblogging client scene more of a closed monoculture¹, the significance of Spaz as a counter to closed technologies is greater than ever.

After some recent events – a big career move for me, some horseshit policy changes by Apple, and some disappointing moves by Twitter – I decided we needed to assess where Spaz is headed. So, like any good open source project guy, I went to IRC: I called a meeting on Freenode in #spaz. Turnout was encouraging, and we made some important decisions.

Here’s what’s going to happen:

Most urgent: implementation of OAuth/xAuth by June 1

In June, Twitter is shutting off HTTP Basic Auth support. For client apps to function, they must start using OAuth or xAuth. Spaz Desktop has been approved to use xAuth, an OAuth variant where the user enters their username and password, and the server exchanges these for an OAuth access token. This means we can support a more typical user experience, but don’t have to store credentials anywhere — we just store the access token.

Earlier this week I added support in the SpazCore Twitter library to authenticate with an OAuth access token instead of Basic Auth. This should allow apps using SpazCore to use either Basic Auth (for systems that still support it, like StatusNet) or OAuth/xAuth. Much more needs to be done, though, to get Spaz Desktop and Mobile ready.

Short term: get Spaz Desktop 0.10 out the door in June

The Spaz 0.9 branch, which is the development branch for 0.10, has been stuck in dev for far too long. The codebase has been refactored considerably, and a number of cool features either have been implemented or are planned, but it needs to actually get ready and usable. We need a push, and assistance from a number of motivated folks who are willing to put the time in. Our 0.10 milestone entry on spaz.lighthouseapp.com outlines the various tasks that need to be completed.

Longer term:

1. Move Spaz Desktop from AIR to Titanium Desktop by October 2010

I’ve been a big fan of Appcelerator’s Titanium for a long time, and their Desktop product offers a compelling alternative to AIR for these reasons:

• Titanium is a true open platform: open source with a liberal license
• JavaScript is fully a first-class citizen in terms of language support²
• Titanium allows leveraging Ruby, Python or PHP
• Better Linux support
• Web Worker support
• Full interaction with external processes
• Native installers for each supported platform that includes the runtime

The big knock I see against Titanium is poor documentation, and that’s something I really hope Appcelerator works to rectify.

All in all, though, Titanium is a better fit for us, technology and philosophy-wise. Porting to Titanium is probably about 20 hours of work as it stands now.

2. Start development of web-based mobile/tablet client

I really like powerful mobile devices, and I really like multitouch tablet devices like the iPad. What I don’t like are the restrictions being placed on developers by companies that refuse to be transparent about their policies. I think the way around that is to make a great mobile/multitouch web app.

A web app will also make Spaz available to all devices with mobile webkit browsers. It would run on Android, Palm webOS, and likely BlackBerry and Nokia devices (I’m not super familiar with those, but I believe they have webkit browsers now or will soon).

While Spaz will be a hosted web application, it will still be FOSS, and anyone would be able to get the source and set up their own install. In this sense, it would be an interesting complement to StatusNet.

If folks are motivated to create native clients for their preferred devices, that’s definitely a possibility — either with a wrapper system like PhoneGap, or a native UI system like Titanium Mobile. It just would not be, at least initially, a primary goal.

What about webOS? Not sure right now. It requires dedicated folks who will keep up with it. Nick Carter has helped a lot, but we need more help, and/or we need to leverage the stuff we do in the web-based mobile client. That may necessitate moving away from Mojo as a framework, though. Palm’s dev relations team has indicated that they are interested in making web apps first class on their system, though, and I suspect they’ll have some interesting stuff to make that possible.

3. Target StatusNet as a top-tier service

StatusNet has always been a favorite service of mine. They match our principles, and I think Spaz as a FOSS client and StatusNet as a FOSS service complement each other well. StatusNet needs better clients, and I think Spaz is decently positioned to be a part of that. So, I think we should create a StatusNet API library to support any StatusNet-specific features available, and implement support for this in Spaz.

We should also consider other services, like Facebook and RSS feeds. The first step would be developing SpazCore libraries for these.

How to help

If you’re interested in helping with Spaz, here’s what you can do:

• Read our Statement of Purpose and Diversity Statement
• Read “How Can I Participate in the Spaz Project?”
• Talk to us about what you’re interested in doing
• Make a commitment to putting in a certain amount of time every week. Even a half-hour a week helping with user support is a big help.

You don’t have to be a programmer. We will work with you to learn new skills. All you have to be is interested in building something cool with us.

Normally I try to chew on an idea for a post for a few days; it lets me sort out my thoughts and form some kind of thesis. I’m totally not doing this here, though, so I should preface this with a note that I could be completely off-base. But I don’t think so.

Discussion about how we interact with computers heated up recently with the introduction of the iPad. Lots of nerdy types (myself included) were frustrated that Apple had introduced not a tablet “computer,” but a big iPod Touch. They’re both computers, of course, but the way we interact with them is different: the modern computer interface uses a multitasking windowing motif, and the iPod/iPad interface is fullscreen and single-task focused.

As a Nerdy Power User, I am well-versed in how to navigate a multitasking interface, and for the most part I understand how and why it works the way it does. I, in fact, enjoy learning about the intricacies of these kinds of systems. So when I use a single-task interface like that of the iPod Touch, I frequently bash my noggin against the barriers it imposes. Copying a URL from the web browser to my Twitter client takes orders of magnitude longer than it would on OS X or Windows, for example.

What I’ve learned from interacting with most computer users, though, is that they do not give a rat’s ass about how computers work. They want to accomplish certain tasks, and will do this in the way that is most sensible and direct for them. And the way they end up accomplishing these tasks within the multitasking window motif is typically not the way I would do it.

The recent fiasco on ReadWriteWeb, where a RWW article became the first Google result for “facebook login,” is a classic example of this. And, unfortunately, so is the reaction of most Learned Computer Fellows: one of mockery and derision, admonishing the confused users for being stupid, incompetent, or lazy.

I’ll admit that I took some glee when I first saw the numerous comments on the article; I love a humorous clusterfuck as much as the next guy. But seeing some of the reactions by the Very Smart Computer People, I began to realize that We Are Not Getting It. Consider:

• Isn’t this really a failure of Google? How did it become so easy to game search engine results that an article about Facebook and AOL became the first result for ‘facebook login,’ instead of the obvious thing people are actually looking for?

• How is it the fault of the users when we present them with multiple, barely-differentiated text fields within the same window. Is it really surprising that they don’t understand the differences between each? And is it surprising that they choose to use the one which works with more natural language, rather than entering syntactically-unnatural domain names?

• There is LOADS of anecdotal evidence that most users simply use search engines as a sort of natural language CLI. Shouldn’t we be designing interfaces that work in the way most natural for the majority of users?

These people have better things to do with their days than tweaking out the spacing in their browser toolbars. A computer for them is a utility. One that is increasingly complex, and one that is used because it’s the only option for accomplishing certain things – not because it’s a good option.

It’s kind of like the Photoshop Problem: when people want to crop a picture, we give them Photoshop. Photoshop is a behemoth application with nearly every image editing and touchup function imaginable, and it is terribly complex. Now Photoshop is an impressive tool, but only a very tiny percentage people need the power it offers. The vast majority just want to crop their ex-husband from the photo and let their friends look at it. But even iPhoto, the poster child for Apps So Easy Your Grandparents Can Use Them, continues to pile on features and complexity.

When folks need an elevator, we should give them an elevator, not an airplane. We’ve been giving them airplanes for 30 years, and then laughing at them for being too stupid to fly them right.

I think we’re the stupid ones.

Update

As I said at the start, I wrote this piece a bit off the cuff, so upon further review I think I could have made it a bit clearer. First, a couple great rebuttals I read:

• Reply to Funkatron’s Analysis of the RWW/Facebook Debacle of 2010
• No, We’re Not The Stupid Ones

I posted a comment on Phil Crissman’s blog, which I think explains a bit further what I’m thinking, and addresses the notion that some learning may still be required. To copy and paste myself:

I certainly don’t think that the computer can become (anytime soon) a magic box that determines our whims, nor do I think that people shouldn’t have to learn some things.

What I do think is that the current interface modern OSes on computers provide is simply overwhelming for most users, to the point that it’s very challenging to learn how to accomplish tasks without a very significant investment of time. Driving would be a good example of a task that does require investment of time, but is not so overwhelming that the vast majority of people fundamentally get it wrong: you don’t see people steering with their feet, or accelerating and braking with the radio. I’d argue that modern computer interfaces, in a rush to offer flexibility and capability, make it possible to steer with your hands, feet, teeth, and knees — and don’t make it particularly clear which one is best.

Update 2

Some more responses:

• Really? Are we the idiots?
• Some People Can’t Read URLs

Feel free to forward me others; I think I’ve given up trying to track them down for now.

Remember when you went to SXSWi last year, and you said “I love the parts where I meet cool people and eat free food and drink free booze and throw up, but I wish the presentations and panels weren’t so goddamn fluffy?” Me too. That’s why Alex Payne (aka “The Guy Who Has Actual Name Recognition”) and myself submitted the talk “Security for the Social Set.”

The idea is that we give some solid, useful information about the security problems social networking apps have to deal with, and how to deal with them. While we can’t get too focused on specific languages and frameworks, client-side defense with JavaScript will certainly be demonstrated, and I intend to show examples in PHP and probably a couple other platforms (coughRailscough). It will be hard to get into heavy detail within the alloted time, but it’s my hope that we can kickstart awareness and understanding of fundamental secure web app programming techniques.

Plus, I need a justification for dropping the coin for hotel and air fare on this boozefest, so please, vote for us.

• Security for the Social Set (SXSW 2009)

Oh, and a few other meaty talks you should consider include:

• Practical JavaScript Development
• More Secrets of JavaScript Libraries (this was packed last year)
• 200s, 304s, HTTP Compression, and You
• Hackproofing Ruby-on-Rails Web Applications
• Functional Programming Without A (Strictly) Functional Language
• Unit Testing Back to Front: Prove it Works!

I have these five promo codes from Dreamhost. They expire in three days. Apparently you get super-hot deals with them, like:

• Four times the normal disk and bandwidth
• $150 off a 5-year plan
• $200 off a 10-year plan

I would not sign up for 5 years with any shared host. However, I do think DH is pretty decent for small-ish sites that can work with shared hosting. I’m well aware that they’ve had a couple embarrassing public flubs in the past couple years, but I generally think they’re good folks who try to do right by their customers. Some will certainly disagree, of course. 8)

I still maintain my old account there for low-cpu, high-bandwidth/storage stuff. They do quite well with PHP hosting, and can handle Ruby and Python setups with a little effort. They’ll let you do crazy stuff like compile your own PHP if you are fine with using FastCGI, and have a nice GUI to setup SVN repos. Not many shared hosts will do the same at a similar price point.

Anyway, here are the codes. They’re first come, first serve. Yes, I make money if you sign up with one of them. I will not be hurt if you don’t use them.

• 998942362256
• 916860787004
• 591140700044
• 047271781406
• 160643597831

Dreamhost Signup Page

I’ve been working at Purdue for over 6 years now, and I have to say that I’ve enjoyed it immensely. While the experience can vary from department to department, in general it’s a fairly low-pressure environment with a lot of opportunities to learn and develop new skills for motivated folks. Purdue offers great benefits, and the Greater Lafayette area is a pretty cool, decently progressive environment considering the size – US News & World Report recently picked West Lafayette one of the “Best Places to Retire” in the US.

A job just opened up in the Math department for a “Web Programmer/Analyst”. This position calls for strong PHP, PostgreSQL and MySQL skills; Linux and Unix fu (you should be able to admin the web stack); good communication skills (you’ll be working with a number of different people with varying tech backgrounds); and plenty of independent motivation.

I’m not involved in the hiring process at all, but I’m friends with those who are, so if you have specific questions, I can route them to the right person. Please email me directly – do not post questions in the comments.

• Web Programmer/Analyst - West Lafayette - Mathematics