Still alive

I know it's been a few days since my last post. I've been busy with some other minor projects (and I got a puppy, which, if left alone for more than a nanosecond, finds something expensive to maul).

I've been working on the new mockup and have completed a design for the front page.

I've also been working on Google Reader, which I hope to have up soon.

Stay tuned.

MySpace is working (for now)

I had a minor brain wave while researching another API today. The documentation stated that all requests must include a user agent header, which got me thinking about the MySpace problem.

Because it uses oAuth (and must send an oAuth header) it uses a different cURL function than most other feeds. That cURL function was not applying a user agent field. I corrected it and....no change. So I began debugging and outputting values throughout the authorization process and it all-of-a-sudden began to work.

So, could have been some sort of delay or caching problem keeping the old cURL function file for a few minutes after I uploaded the change. Or it could be that changing the user agent field has temporarily fixed a firewall blocking problem. Maybe it will work for a day then just stop, as it did when I first uploaded it.

But for now, it's working.

Please, try it out and let me know if you encounter any problems.

Mockup

Here is the mockup I promised. As I described in my last post, the feed icon appears on the left of the event.

The relative date time tag (which says 'About x minutes ago') now appears inline. I tried it underneath the event description but it was confusing. Having it off to the side means you really only 'see' it if you're looking for it. It also means we can imlement single-line events (such as the Gmail event in the mockup), which I like.

I debated for a while whether to include profile thumbnails (shown here for Twitter and Facebook events) at all, or to simply leave them out. I did mockups of both, but I think the thumbnails help 'suggest' to the user who the post came from, much better than text can. For example, if I were interested in posts from Fake Stephen Conroy (shown in my mockup), it's far easier to locate them given his bright red profile image. That said, it also makes the feed as a whole a little more crowded, so it was a trade off.

You may also notice the comments line under the Facebook post. I'm hoping to add support for comments when I implement this new design. They're not shown here, but clicking on the '6 comments' text in blue will expand down the comments. Each comment will have the profile picture of the author (if applicable). The last line in the comments section will be a text box for you to add a comment.

One other thing: I'm going to limit the width of the description field. See Senator Conroy's Twitter post? Under the current design, that stretches across the width of the feed and is difficult to read (that's why newspapers use columns). In the new mockup, it's constrained to about half the total event width.

If anyone has any feedback or suggestions, I'd love to hear it.

BTW, still no news on MySpace. I've posted to their forums, but I guess their API developers don't read it. I may end up just submitting an e-mail to a non-developer address and hoping they'll forward it to the appropriate department.

Redesign?

The problem with web development is that you stare at the same screen for hours each day. Consequently, you begin to second-guess your design.

The current look-and-feel of Timelimes is actually about the fifth iteration. Much of the incremental change has centered upon the styling of events in feed. At the moment, each event has a thumbnail to the left (which in the case of Facebook, Twitter and MySpace is the profile pic of the event actor, for Flickr it's the Flickr logo, for eBay it is the item gallery thumbnail and for Digg it is the item image if it has one, else just the Digg logo).

I use Timelimes quite a bit and I'm beginning to find it a bit difficult to mentally organise the information I'm seeing. Information digestion is exactly the problem Timelimes aims to solve, so it isn't good to have an interface which is not conducive to 'glance comprehension' (what I call the ability to quickly glance at a screen, or item on a screen, and intuitively understand what it's about).

I think the thumbnail image is the problem. It's confusing because, glancing at an event in the Timelime, you can't intuitively tell which service it comes from. Sure, there's the small icon under the title and description, but your eye isn't drawn to it. The entire event just appears as one big block of text. You have to actually read it to comprehend it, which violates the goal of glance comprehension.

If you use Timelimes enough, you begin to developer a sense of which service each event belongs to, but it shouldn't be something you need to train yourself into -- it should be intutive.

So, I'm thinking of trialing a new style for events, using the service logo on the left instead of the user's profile image etc. If anyone has any ideas, suggestions or feedback (once it's implemented), I'd love to hear them.

MySpace problems

The MySpace feed has been down for a few days now. At first I thought it was just the MySpace API server. Then I thought it was a performance problem with our server. Turns out our requests are being blocked by MySpace. Not sure why this occurring - we've somehow tripped their firewall. Too many requests maybe?

I've posted to the MySpace Developer forums (they don't have a direct support e-mail) but haven't heard anything back yet.

I'll post back here as soon as it's operational again.

I have one word for eBay: oAuth

The eBay feed is up. Currently, it supports notifications for BidReceived (seller), FeedbackReceived (buyers and sellers), ItemLost (buyer), ItemMarkedPaid (buyer), ItemMarkedShipped (buyer), ItemSold (sellers), ItemWon (buyers), ItemUnsold (seller), OutBid (buyers) and WatchedItemEndingSoon (buyer).

I may add support for dispute notifications later if people want it.

This has been by far the most convoluted, unnecessarily complex API I have worked with. Sooner or later these large sites will realise that 8 trillion pages of incoherent spaghetti documentation is not valuable to developers. Just give us a few, short, cohesive pages covering the major use cases and a wiki.

They should also give serious consideration to oAuth. Currently their procedure is as follows:

• Client obtains a session ID
• Client redirects to the eBay consent page
• Client retrieves the token using the session ID
• Client sets notification preferences using the token
• Client obtains a client alerts API token
• Client signs into the client alerts API and retrieves session values
• Client calls the API notification method using the session values

This is just absurd. Why not just use oAuth? It'ss simple, secure and widely supported.

eBay is another of those services that I don't use much, so please report any bugs. So far I've just been bidding small amounts on cheap items I don't want. I almost became the proud owner of a USB keyring shaped like a Nike sneaker.

MySpace

The MySpace feed is finished and seems to be working (after a lot of unnecessary work -- note to MySpace: providing the markup of event information in your activity stream feeds is not helpful).

I'm really more of a Facebook person so I'm not intimately familiar with the inner workings of MySpace. For those of you who use it on a daily basis, please try this feed out and let me know if you find any bugs.

I've almost finished the eBay feed too, hopefully it will be up by tomorrow.