bootstrap.footnotes.js - UX Lab 008
I love the Instapaper-style footnotes/endnotes that came about with the last major update. Here they are in web form, as a jQuery/Bootstrap plugin. Unfortunately there’s a dependency upon Bootstrap CSS/JS, but such is life. It’s retina ready too - as everything else should be these days.
Here it is in action:

Documentation and options are available on the demo page.
It also has its own GitHub repository.
3D Accordion Effect - UX Lab 006
I posted the following experiment as a way of demonstrating just how far the line has blurred between web based animation and OS based animation. I saw Dribbble shots (one and two) by Indian designer Pranav Pramod and was inspired to replicate the effect in CSS3.

Unfortunately nothing is ever as easy as it seems. If it was, someone else would have already posted a similar effect. The problem is that when animating something with a 3D transform with a forced perspective, there is no way to measure or mirror the actual height represented in the browser using CSS. If you animate the parent element from 0px in height to 30px, it’s a straightforward linear animation. The 3D transform, on the other hand, changes on a non-linear scale because of the perspective.
There are two solutions, neither of which are desirable.
The first involves JavaScript, which frankly I had tried to avoid. In this example, the animation is triggered by the addition of a CSS class via JavaScript - but could just as easily be bound to an :active:target CSS event. The only way to get the actual browser rendered height of the element is to get it via JavaScript with the obj.clientHeight getter. While discussion pointed to wrapping the object in a parent element and not needing JavaScript at all, this does not work in all browsers.
Instead the JavaScript method involves binding a function with requestAnimationFrame which sets the parent objects height to mirror the calculated height of the transformed object. Accurate, but if we wanted to perform calculations many times per second, why did we bother animating with CSS at all?
The other method, considerably less accurate and very fiddly, is to match the easing or timing of the two animations. It may be possible to create a custom timing function using cubic-bezier which matches the rate of easing of a 30px tall object, rotating from -90deg to 0deg, with a perspective of 400 units. But why would you? That’s shit house.
Maybe in this instance a flat out Canvas animation would have been much more sensible. You’re still performing a function every ‘x’ milliseconds, but at least the canvas itself may be hardware accelerated. Until CSS animation matures, we will most likely have to abuse the JavaScript add-ons such as the one described earlier. Or even better yet, sever the ties with HTML and CSS and - get this right - use graphical languages for what they’re intended.
Ninja Edit: Also, you can’t yet animate background gradients so the whole 3D effect on the depth of the flaps is kind of impossible for now.
Sad-face Edit: The second I posted this, someone posted pretty much the exact same thing to Hacker News in a much more polished way. Check out Paperfold CSS.
Idle jGrowl Re-routing - UX Lab 004
Paul Irish wrote a pretty chill script back in 2009 for detecting when a user becomes inactive. It’s quite ingenious in its simplicity, as the best things usually are. What wasn’t explained fully is the ways in which this can be used to deliver a better user experience. It’s fantastic for preventing timed or asynchronous actions when users aren’t going to benefit from the action.
This quick little experiment is aimed at demonstrating the concept in the simplest form.
A jGrowl notification triggered every ‘x’ seconds, or by a server event, isn’t of much use when the user isn’t around. They disappear after a few seconds. So instead, if the user is deemed inactive, you should make them “stick” or push them to a modal, similar to the loathed Growl notification rollup pictured below.

Obviously the linked example isn’t quite as eloquent, but it’s not like the Growl rollup was that well received to begin with. See what other cool shit you can come up with.
I’ve just pushed some major changes to my front end development guidelines to the public site. I spent a lot of time on this update, and it shows. I’ve added new content and improved old. I’ve ditched my own slap-dash styling in favour of the Twitter Bootstrap with some of my own personal tweaks. Be sure to check it out.
I’ve added some sections on:
- The importance of understanding the box model (CSS)
- Knowing when to float, and when to position (CSS)
- Generating unique IDs without timestamps (JS)
- Preserving middle mouse click functionality (UX)
I also:
- Made the website work without JavaScript enabled
- Cleaned up the overall design and interaction (Bootstrapped!)
- Re-wrote some content here and there
- Added pretty graphics to explanations
- Added some resources to the list
Basically, we’ve gone from this:

To this:
Dynamic Credit Card Type Selection - UX Lab 003
If you find yourself buying a lot of things online, or perhaps building a lot of eCommerce websites - you will have experienced a range of credit card forms. The good. The bad. The ugly. Some fields are required to pass security checks. Some seemingly exist only to frustrate you. But what seems constant is the lack of innovation over the years in what is a staple in eCommerce design.
One example that does it really well is the purchase page for Coda, by Panic Software. Not only does it auto-select the card type of the credit card, but it also updates the select button with a background image indicating progress. The only downside I can really find to the Coda page is that when the card image changes, it’s not sprited so you see a flash of white as the images load.
Using a list of prefixes published to Wikipedia, it’s possible to identify nearly every card type in the world. This opens a host of possibilities to designers, like this:
“CC Rebound” by Ryan Rumsey
Not shown in this demo is the ability to isolate the first two or three characters, to further narrow the type of card. How would you differentiate between Diner’s Club (36) and American Express (37), both starting with ‘3’? Using substr(). The rest is up to you.
Introducing the UX Lab
The lab is a place for me to share my thoughts and experiments with the web development community. While the name indicates a user interaction and user experience focus - I’ll also be sharing CSS3, JS and HTML5 tidbits. My aim is to make the web a better, more consistent place. And what better way to achieve that than by leading by example.
The experiments will be hosted as one main repo on GitHub. That way you can easily view the code, download any resources, as well as forking or branching it for your own purposes.
Some of the cool things to come:
- Credit Card Type - Passive Selection
- jQuery UI Slider Toggle Switches
- Mac vs. Windows Close Buttons
- Flash-free Google Analytics
- and more…
iOS eBay: The Good, The Bad, The Ugly
Mike Rundle, author of Design Then Code, is a firm believer in an iOS application being a pixel perfect representation of a company’s branding and unquestionable design. He can be a real stickler, calling out poor design or UX conventions on Twitter and just generally being a loveable prick about it all. But every so often he does stop and remind us that there are real people behind these decisions - and that things are often beyond their control.
The people responsible for the eBay iOS applications care enough about their product to trawl Twitter looking for whingers like myself. And they’re not just looking to mitigate complaints, they’re keen to hear feedback and where people think they have room for improvement. They were sure to pre-empt criticism by stressing that the original application was rushed out in only 5 weeks.

Okay, you caught me out. I was more keen on using the “Good/Bad/Ugly” metaphor than actually thinking up reasons why both the iPhone and iPad eBay apps are “Good”. They both do some pretty cool things (barcode scanning, being more picture/gallery oriented than the website), but that’s not really what this post is about. This post is more about where the apps fall flat on their face.


Branding and Consistency
The only thing marketing experts love more than cocaine is “synergy”. But what the iPad app delivers is an icon and UI different to that of the iPhone app, and eBay’s branding in general. I’m not entirely sure what page in the styleguide the blacks and deep greys come from, and for some reason it really irks me. I think eBay’s marketing department may have overlooked the inconsistant approach for the sheer joy of being able to say they have an iPad app. It was, as mentioned, rushed out in only 5 weeks.
Considering the difference at the simplest level, picking up an iOS device and trying to flick through screens full of apps to quickly locate the eBay app can be difficult. It’s hard to remember that, for example: “oh, I’m on an iPad now, I should be looking for a grey icon, not the yellow one, silly!”
In fact the icon differences just draw attention to the fact that the two apps are presented separately in the app store, and not part of a universal application. Dropbox, Twitterific, Instapaper. These popular apps, free or paid, all have universal installs. I can’t imagine the eBay code-base being very different. Merging the two would even avoid inconsistant language and interaction between the two, like refining how far an item can be from your location:
eBay Mobile - “Local Search”

eBay for iPad - “Max Distance”

Design Treatment
Frankly, I haven’t seen diagonal scanlines used in web or app design since the early-00’s when I was abusing them too. I really can’t understand why eBay pushed an update that replaced the original simple graphics with dated scanlines. Subtle Patterns is a brilliant website for discovering and previewing modern designs of tiling patterns. All of which are free. They’re rich and tactile. They’ll date just as quickly, but scanlines already have a head-start.
Odds and Ends
There are also a few less critical odds and ends that need cleaning up. Prioritisation in lists could do with some work. As a category, “Won” probably is third-most important in the following view. But when the proceeding categories are empty, is it still relevant to show them at the top of the page?

In terms of showing when refinements have been applied to a search, the iPad app takes the better approach. Normally black buttons turn blue when criteria are applied. The iPhone app uses text instead, with a lazy check/square root symbol.
iPad App - Normally black buttons become blue
![]()
iPhone App - Text only indication
![]()
Also strange is the way in which setting a price range is not enough to trigger the refinement indicator in the iPad, while the search radius is.
There are also plenty of other little bugs and enhancements, but no app is perfect. The inability to enter a landscape keyboard mode in the message centre could probably be fixed and pushed out quickly. The caching of gallery images when flicking between items is probably just as straightforward. These are less UX issues and more programming bugs.

Breakable Workflow
It’s far too easy to get to a point in your search where you can no longer get back to your results, or preserve your refinements.
For me, one of the most interesting functions I can perform on eBay is to view a sellers other items. I’ve done this countless times on eBay and Gumtree (an Australian Craigslist), and it can result in beautiful things and some absolute bargains.
If you were to click “View Sellers Other Items” on the iPad app, you can kiss your search results goodbye. This is incredibly frustrating when you’ve spent time narrowing your search with refinements. I want a road bike. Only from the cycling category. Within 100km of where I live. Only the recent listings because I’ve seen the rest. You might find a cool bike, but the size isn’t right or it’s already well outside your price range. The seller mentions they restore bikes, and suggests you check out their other items. Maybe you’l have some luck there? Boom. Search results, refinements and position gone. No back button. Start again.
Oddly enough I just noticed this only happens on the iPad app, the iPhone app remembers exactly where you came from. Another reason to merge code bases.
Can’t Refine Location Unless Logged In
All iOS devices at this point should be able to geolocate themselves, regardless of 3G connection. Apple and Google are both conducting some wizardry where they can pinpoint your location based on Wi-Fi signal alone. But unless you have an eBay account and you’re signed in, the eBay application gives you no way to filter search results by location.
Even mobile Safari has been able to request your current location since 3.0 with a simple JavaScript call:
navigator.geolocation.getCurrentPosition
The user is offline, or Safari can’t determine the location of this particular Wi-Fi router? Store with window.localStorage and it will persist between sessions. Simple.
What appears to be a fairly straightforward issue to resolve can be immediately attributed to reviews in the app store:

Can’t Update Location When Travelling
Travelling overseas or even interstate will not search where you are now located. This can be directly attributed to the apps reliance on the user’s location listed in their account profile, and not the device’s geolocation. While definitely an edge case, it would also be resolved while addressing the above issue.
Overall
I think that my personal frustration stems from usability issues that could be handled better as a mobile web application. That’s not to say I would ever suggest that eBay goes down the path of only offering web apps. Native will ALWAYS trump web facsimile. But with that being said, if you know that performing a particular action will always break your workflow - you get used to opening that link in a new tab. There is no quick native fix for that. A desktop-sized web app can become a mobile-sized app with a few lines of responsive CSS. There is no quick native fix for that. Merging code bases will be fiddly and time consuming.
Bugs take time to identify. Bugs take time to fix. Submitting to the App Store for a review and update takes time (and isn’t guaranteed to pass). As we speak there are probably similar items as I’ve described, logged internally for eBay’s development teams. But as I’ve discussed, there is no end user work-around for some of these issues - while there would in a mobile app. eBay still offers both, but it highlights a flaw in the native vs. web app argument.
I hope that the product owners and dev teams can take some of what I’ve said on board. This isn’t unwarranted criticism. Staff at eBay have expressed a desire to learn more about what UX people like myself think they can improve on. Here’s to a better UX for everyone.
A behind the scenes look at Mill Touch. There are some amazing concepts going on with this device, aside from bringing the Minority Report concept to life. I particularly love the overlay where you can see the pre and post productions at the same time (around 2:55).
I never knew the team at Mill were behind so many incredible commercials. Nike. Old Spice. Skittles. Budweiser. Various super bowl ads. Here is their 2011 showreel and their more recognisable 2010 showreel.
Hi, I'm a UX Developer - You're a What?
I showed this to my computer-illiterate girlfriend a while back to help her understand what I do for a living. While broad articles like this are never going to describe every person, perfectly; it did ring true in a few regards.
A really good read. Recommended.




