Ping.fm / Twitter Integrator

Here’s a screenshot of what that looks like for reference:

My thanks to the founders, wherever you are. That was a great weekend.

Update 2: This code is released to the public domain. You can use, modify, remix as you see fit.

Behold, fixed positioning on iPhone! http://doctyper.com/stuff/iphone/fixed/

Here’s a video for those without iPhones. This is running in the iPhone Simulator bundled with the SDK. Note that the animation is much choppier on an actual iPhone.

With the release of iPhone OS 2.0 came some great improvements over previous Mobile Safari versions. CSS animations are in (though buggy), as well as native touch events like touchstart, touchend, gesturechange, etc.

I played around with these new goodies while hunting for improvements to build into Pickleview. The most fascinating change to me was that you can now prevent the default behavior of elements with a simple preventDefault() call. It allows a user to drag an element around the screen without having to worry about the viewport wobbling about.

I grew curious as to what I could specifically call this on, and started testing out several elements. Turns out you can preventDefault on everything in the DOM, including the body element. This seemed incredibly useless for no other reason than the terrible usability it would bring if you couldn’t scroll the viewport. Then the proverbial light bulb went off: fixed positioning!

First, let’s recap why fixed positioning does not work off-the-bat. Mobile Safari uses a viewport to show you websites. Imagine a book in front of you. Take a piece of paper, cut a 320×416 square in it, and lay it over the book. To read the book, move the paper around and position the hole over the words you want to see. This is exactly what Mobile Safari’s viewport is doing. When you flick and scroll, you’re moving the viewport around while the website behind it stays static.

This renders fixed positioning null and void on iPhone. An element that has its position fixed is affixed to the body, not the viewport. So it is actually working as intended, though most people would prefer it attached to the viewport.

There are workarounds in the wild, but these are inelegant. You can reposition an element onscroll, but a scroll event in Mobile Safari is only fired after scrolling has stopped. This results in an evident “glitch” since you have to a) flick to your desired position, throwing the element off-screen, and b) wait for the element to reappear in the viewport after scrolling has stopped.

By disabling the default scroll behavior on the body element, you essentially glue the viewport down to its initial starting point, where it’s unable to go anywhere. This limits the viewport to exactly 320×416 pixels of space to show you. In this state, you have a perfectly useless experience.

This is where it gets interesting. In order to re-enable scrolling, I needed to only make the content area scrollable (think iframe, with header and footer above and below it). The touch and gesture events gives access to X/Y values, as well as timers and offset values. So by logging these and incrementing the top offset of the content area, we can create a scrollable block that does not affect the header or footer elements. A little spit and polish later: voila!

It’s pretty evident from my proof-of-concept that CSS animations need a lot of work. They’re promised to be “hardware-accelerated”, but there’s little proof of this. Most animations glitch, some to the point of non-use. The scrolling isn’t particularly smooth and even something as simple as animating a ‘top’ CSS property takes its toll. Still it’s usable, though I hope later Mobile Safari builds will address these issues.

If you’re interested, I’ve bundled together the source files for my proof-of-concept. Grab ‘em here.

After a furious weekend of code, I’ve pushed out Pickleview 1.5. What’s new? I fixed bugs, updated settings, added features and threw on a fresh coat of paint.

The improved Pickleview takes advantage of some minor iPhone goodies, and preps itself for the upcoming 2.0 software. It runs smoother and loads quicker. Good news for those EDGEing along at ballparks.

You can also do this now: http://pickleview.com/?dodgers

Check it out and enjoy!

It’s been a while, but you know the drill: Long hours + Longer todo lists = No time to post.

To kick off 2008, myself and fellow blogger/nerd/geek Micah Cambre sat ourselves down and podcasted for the very first time. It was simultaneously thilling and horrifying. You can find our labor of love at Footalk.net. Please enjoy.

Footalk!

Hot on the heels of the Fumbleview beta release comes Fumble U. It suffers from the same quirky bugs as its big brother, but it’s very stable.

I had decided to wait until Fumbleview reached 1.0 before releasing another app, but fortunately for me it only took a fraction of what I thought it would to tie into the college football database. It was still a minor feat, since there are a metric ass-ton of division 1-A teams. Ultimately I had to devise a method to fit all top 25 teams in the limited space I have.

Focus will switch to Fumbleview until I tie up its loose ends. Afterwards it should be a simple process to catch Fumble U up.

I’ll keep this short, as this comes down to very simple points.

I don’t block anyone from visiting Pickleview or Fumbleview. You can view it in any browser, mobile or desktop. I don’t sniff for iPhone, and lock out others. I don’t do any special CSS magic to block it from view. Rather, you get a much enhanced experience if you view the apps on iPhone.

My web apps will display and function perfectly in any browser that supports these standardized methods:

• XMLHttpRequest();
• addEventListener();

That’s it. Too much to ask for? Apparently.
(Note: Blackberries run IE.)

Introducing Fumbleview. I’ve been hard at work on it for a few weeks now, but like its predecessor I am releasing it as beta in order to get community feedback, reviews, and bug submissions. And yes, there are bugs. While the Pickleview framework is rock-solid, the majority of the bugs stem around merging the data source with the Pickleview API.

Like Pickleview there will be lots of updates along the way to release 1.0. I’m determined to hit the 1.0 milestone on opening weekend, bug free and feature-filled. In the meantime, check out Fumbleview and feel free to submit lots and lots of feedback.

NFL games abound later today and through the weekend.

Are you ready for some football?