RSS
 

The Thing About Twitter

13 Mar

The thing that bothers me most about Twitter’s API announcement is that very few of the most useful features of Twitter were actually their ideas.

  • Hashtags.
  • Retweets.
  • Location.
  • Search.
  • Lists.
  • Conversation view.
  • Inline images and links.
  • Short URLs.
  • The entire mobile user experience.

All of these appeared in user behavior or other clients or other apps first, and Twitter picked them up into their clients, or bought the client outright.

I’m for picking up features from clients. I think it’s fantastic: a feature can be effectively tested among a small group via a niche client and if it’s compelling and popular, well, you may want to steal it for the whole userbase—or not, of course.

The comparison that sprang to mind was the Firefox add-ons ecosystem. Something can start as an add-on (say, Tab Candy or Personas) and if it’s popular and a compelling feature, sometimes it gets picked up into the product (Panorama, Personas). Other times (Firebug, Adblock Plus) it is incredibly compelling but not for everyone, and it doesn’t. (Or, in the case of Firebug, some of the ideas, if not the implementation, were picked up.)

The point of all that, to borrow a phrase from Jeff Chausse, is that thinking you will “inevitably make better apps [is] epic hubris.”

If 90% of user access to Twitter is through official clients, like they claim, then they are overstating the threat of “fragmentation” of the user experience, and doing so in a way which discourages anyone else from trying to do better, or simply different. (Unless, of course, they aren’t putting any technical teeth behind it, but in that case why say anything at all?)

Considering how much of the current Twitter experience was invented outside the company, it seems like this is indeed epic hubris.

NB: As all content on this blog, this post is my personal opinion and should in no way be construed as representing my employer.

 
4 Comments

Posted in Articles

 

A brief SumoDev update

12 Mar

A little while ago, I said that I thought we got a B in Q1, but we could move up to an A with a little more work. (This is my favorite grading system: everyone starts at 0 and works up.)

Well, we landed two things:

I said these two things would bring us up to an A, so, way to go team!

We entered this quarter with 5 goals around Continuous Deployment. We’ve hit three. The other two were stretch goals, and it looks like we’ll miss them. It’s been a particularly busy quarter for IT, and there’s just a bunch of work left to get the JS tests into CI. We’ll carry those forward into Q2 along with our goals of releasing every week and dropping the ‘next’ branch.

I’m really proud of my team and the work we’ve done this quarter. We’ve not only done great work improving the user experience across the site—especially for mobile users—we’ve also made significant progress toward simplifying and streamlining our releases, which will be crucial to CD.

 
Comments Off

Posted in Articles

 

Weekly Update for 11/3/11

11 Mar

Been a busy week!

Now to start a busy weekend!

 
Comments Off

Posted in Articles

 

Weekly Update 04/03/2011

04 Mar

OK, in line with my 2011 goals and because I’m sick of not remembering what I did last week, I’m restarting the weekly update posts. I hope you like hearing about the minutia of my job! (Just kidding. I write these for me.) I’m going to try a “sometime Friday” schedule instead of weekends or at night.

Also, this one will cover the last four-and-a-half-ish weeks, since it’s been a while.

 
Comments Off

Posted in Articles

 

O Hai Django AdminPlus

04 Mar

Last night, as happens sometimes, I was wishing it was possible to add some of our custom admin views to the Django admin’s index page. It’s kind of a pain to have to type the URL every time, especially when talking to other people: “It’s in the admin, but no, you can’t… just go to this URL.”

So I was reading the Django admin docs and, frankly, they aren’t great. They tell you about the benefits of subclassing AdminSite, or running multiple AdminSites, but they never really mention how to do it.

So, with a little trial and error, I wrote my AdminSite subclass and figured out how to use it. It simplified a bunch of code in our custom admin app, so I thought I would share it.

Here’s Django AdminPlus (and on PyPI).

AdminPlus adds a method, admin.site.register_view, that connects an arbitrary view function to your admin, and puts a link to it on the admin index page. If you put calls to register_view in someapp/admin.py, they’re picked up during the normal admin.autodiscover() process.

  1. # myapp/admin.py
  2. from django.contrib import admin
  3. from django.shortcuts import render_to_response
  4.  
  5. def my_admin_view(request):
  6.     return render_to_response(‘myapp/admin/view.html’)
  7. admin.site.register_view(‘mypath’, my_admin_view)
  8.  
  9. # With an optional ‘name’ parameter:
  10. def my_other_admin_view(request):
  11.     return render_to_response(‘myapp/admin/other.html’)
  12. admin.site.register_view(‘otherpath’, my_other_admin_view, ‘Fancy Stuff!’)

Assuming your admin URLs start with admin/, this will make my_admin_view available at admin/mypath and my_other_admin_view available at admin/otherpath, but it also puts them in a new section on the admin index, so you don’t even need to worry about the URL.

If no name is given we try to guess from the name of the view function.

That’s about it! Read the README and the other docs and enjoy!

 
2 Comments

Posted in Articles

 
« Older Entries
Newer Entries »