simurai

Great concept. Be sure to watch the video as the text just doesn’t do it justice!

simurai:

Flick Scrolling

You might wanna watch the video above, but in short: When scrolling content on a touch-screen, instead of letting momentum stop the scrolling, you can decide exactly where it should stop. It stops at the point where you flicked it.

It would be great for things like books, blogs, timelines or anywhere where you don’t fly over, but continuously wanna “move forward”. Kinda like paging but within and long scroll. Some apps have a page up/down feature, but I don’t really use it because it moves always the whole height and might cut off a picture or so. With this “flick scrolling” you can decide to where it should move to. The last paragraph or beginning of a picture.

Flick Scroll illustration

Why not just use pages or cards? Yes, that works sometimes, but not always, especially not when you have no control over the content. iA wrote a good post about it: Scroll or Card? With flick-scrolling you get the joy of “card flipping” without the cards.

Here the two demos from the video so you can try it out (only tested on iOS).

Book demo

Timeline demo

Warning: I’m not really a programmer so the demo is just a hack to demonstrate how it could work. Would need some improvements. And of course, performance would be better if it would be implemented natively.

One thing I’m not sure about.. there is the possibility that you intend to do a flick scroll but end up doing a normal scroll or vice versa. You can judge for yourself in the demos. Maybe the detection could be further optimized or here some other possibilities (Let me know if you can think of more).

  • Use a two-finger scroll. But then you can’t use just your thumb which makes it not that useful.
  • Split up the screen into two areas, for example left for normal scroll and right for flick-scroll.

Credits: Demos use the iScroll4 library and in the timeline demo, the “scrollToElement” feature is used, which is a pretty cool one.

The Milwaukee PD Website

image

I first time I saw the Milwaukee PD website was on Awwwards. While the design treatment and technical execution was undoubtedly rich, I couldn’t quite put into words what was just so wrong about it all. It goes without saying that the American approach to policing is different to the rest of the world, but I still felt the agency was stressing the importance of the wrong information. Join the force, play with guns and big, black, military grade machinery. Less of a focus on making a difference, working with the community - just guns, trucks and bad guys.

This comment from jpxxx on Hacker News summarises it beautifully.

It’s militaristic, it’s alienating, it’s fetishistic, it’s hostile, it insidiously portrays class and ethnic conflict as an everyday battle worth fighting, and it panders to the worst in Americans who already endorse the myriad excesses and injustices of an ever-growing quasi-private law and order machine that has ruined the lives of millions.

But awesome job on the scrollbars, yo.

Check the site out.

Introducing techevents.co

image

I’m pleased to announce the launch of a micro-site aimed at aggregating the multitude of tech events centered in and around Melbourne, Australia. It’s far from ready but with the sheer number of events in the next few days/weeks I thought it was important I get it out the door.

It’s buzz word compliant!

It’s responsive. It’s got some subtle parallax. It passes JS Hint.

It’s boilerplated, bootstrapped, heroku-hosted, JSON driven, jQuery drawn wizardry.

image

But, the err, source code has seen better days. Hopefully I can clean that up in the next few days.

It’s been a pleasure working with @sesh on this. I basically provide him with a static JSON file, he uses that as a DTO for his back end stuff and, once we flick a magic switch, all the data becomes live. He flat out gets what you’re on about so most of the work can be organised in a 140 character twitter DM.

In terms of future functionality, we plan on cleaning up the UI a bit, adding more events and the ability to change state/location, with the potential for other countries too.

So yeah, check out techevents.co.

UX Lab 10, 11 & 12

Here’s a bulk upload of three UX Lab experiments. I’ve been pretty busy, but these are ideas I’ve had for a long time and have been kicking around on my hard drive to some extent. I thought I’d better get them out and about.

UX Lab 010 - Blurred Modal Backgrounds

Modal dialogs are used in preference to regular popups because they generally disable interaction with the page behind and guide focus to the new window. This is achieved by visually obscuring the content behind the modal, but not so much that the two seem disconnected.

As long as people have been doing this, the have been attempting to blur out the background to greater magnify the effect. It hasn’t been possible without the use of non-dynamic PNGs, Flash or some other form of hack. Now that Webkit-based browsers are supporting the CSS filter property (not to be confused with the IE legacy one), the sought after feature is now possible.

The linked demo guides focus in two modes. One blurs out all background elements, the other desaturates them.  Unfortunately there is no support for animation of these properties, so until that is implemented the effect is a bit blunt.

image image

UX Lab 011 - Flipboard-style Notifications

I see notifications similar to these throughout iOS and OS X applications everywhere. I like the way they demand a bit more attention than your normal jGrowl, but still aren’t too impactful.

Maybe I’ll fork these properly into their own GitHub repo. Maybe I won’t.

image image

UX Lab 012 - OS Dependent Modal & Close Buttons

This is something I thought of a long time back, and has been live in Kiandra IT development template for a while now. It’s frustrating that on the web, OK/Cancel button order and close button placement are all decided by the designer/developer. I remember a while back when a notable ex-Apple designer more or less told Dan Cederholm the close/delete icons should be on the left for everyone. Sure, there are probably more Macs and iOS devices on Dribbble than Windows - but it’s still pretty inconsiderate to force that upon the entire audience.

A UX guy once explained to me that the OK/Cancel placement on a Mac had a lot to do with the linear direction of the workflow. The OK being on the right, as it advances you another step to the right in a wizard. I remember the Windows placement being that you read the desired action first, and that’s the most important. After a bit of research, it appears Jakob Neilsen summarised it quite nicely..

But the little Mexican girl in me says:

image

It’s not even remotely difficult to implement technically, and shows you’re willing to compromise. Exhaustive studies may one day show one method to be “better” than the other, but until then, don’t be a dick about it.

image image

Beautiful Retina iPad Wallpapers

image

I’m not one for customising my iPhone or iPad to the nth degree, which is why I thought I would share this amazing retina iPad wallpaper collection with you all. A lot of wallpapers are suited only to lock screens, and contrast badly with the app icons of the home screen. But not these beauties! I really struggle to pick just one to use at a time, and I’m sure you will too.

Check them out over at Simon C Page’s blog.

image

Many thanks to @james_paintwork for the find.

JavaScript Trends (Presentation Resource)

As long as I continue to participate in the in-house Kiandra IT Friday presentations, I’ll endeavor to open source and post my material online where it makes sense.

image

Friday just gone, I gave a quick talk on the advances made to JavaScript in the last 12-24 months, and what changes are on the horizon. It tied in nicely with the release of a high-level roadmap from jQuery regarding versions 1.8, 1.9, 1.9.x and 2.0.

Topics included:

  • jQuery Majors - 1.8 release notes, 1.9 vs. 2.0 and the oldIE debacle
  • ECMAScript 6
  • Patterns & Best Practices - MVVM/MVC, AMD, Compilation & Linting

I decided not to cover any of the hardware and browser based innovations as they’re more about exposing new device properties, inputs and outputs. I wanted to focus on how we’re writing our code, not WHAT we’re writing. I also forgot to add unit testing to the slides, but we covered it loosely.

image image

This announcement from Brightcove should trigger excitement in any front end dev. Running web content on the Apple TV is something I’ve personally dreamed of for a while now. Unfortunately comments indicate that the free version is essentially just a teaser, and most of the cool functionality remains behind a $99/month paid service. Ninety nine bones. Every month.

No thanks. I’ll wait until Apple offers it natively.

Repository Updates (iOS Theme + jQuery.Gantt + Aristo)

Hey guys, not much has happening on the design/development front while I’ve been away on leave. Today I’ve landed some fairly big pull requests and bug fixes to what are probably my three biggest repos.

jQuery.Gantt

This is the big one. I made some pretty major changes before I went away but wanted a few more people to test it before I did the writeup.

I received a fairly major (and necessary) rewrite from Leo Pfeifenberger who sped up this project like you wouldn’t believe. It wasn’t a simple matter of landing the pull request, as the performance changes did come at the cost of coding standards and consistency. Some parts had been buggered by what looked like Visual Studio auto formatting, but they could have been hand-coded that way too.

For future reference, here are my own personal front end dev guidelines that have been received well by the community. They’ve changed in some regards based on feedback from individuals and organisations and represent how you should aim to format your code.

  • Major performance increases.
    A before and after IE9 test shows performance going from 20 seconds to 400ms.
    That’s 2% of the previous run time.
  • All new click events - fired when clicking an item or when clicking the empty space. Use this to edit events or create new events at certain points.
  • State persistance - requires cookie.js to work.
  • Scroll to today on load
  • Extensive documentation
  • Defined a license (MIT)
  • Removing $.ajaxSetup, which was corrupting other scripts in the page.
    According to this stackoverflow answer it was only there to ensure it worked in ASP.NET situations. If you’re using it there, consider setting $.ajaxSetup externally.

Unfortunately that means there are some new issues:

  • Code standards - I spent a considerable amount of time running the code through JSHint and fixing issues. I got most, but that included setting a few ignores.
  • Eval - yep, as above, you’ll notice that there’s an eval in the code. Yuck.
  • Holiday and “Today” highlighting are not occurring on the cell, only the header.

Two steps forward one step back. No biggie.

image image

iOS jQuery Mobile Theme

I realised there was a big difference between what I was seeing in Chrome, the iOS simulator and my iPhone running iOS 5.1. Turns out the iOS simulator was only running 4.3.1, so I’ve now got the 5.1 simulator and that’s helped me resolve some visual quirks.

  • Fixed: header bars had black top border
  • Fixed: Vertical centring of header buttons was off (related to above, layout woes)
  • Fixed: Black buttons had blue text shadow
  • Fixed: Footer icons had crept to the right with last update (jQuery Mobile styles took precedence)
  • Pull Request: <label> styles coming from poorly scoped selector
  • Pull Request: Demo page typo
  • Set demo page transitions to “slide” by default
  • Set all demo page toolbars to be position=”fixed” by default
  • Decided on licensing (MIT)

image image

Aristo jQuery UI Theme
  • Fixed: Cross browser CSS3 animations appear to have been re-instated.
  • Pull Request: Added a non-prefixed value that I missed.
  • Pull Request: Widget nesting issue fixed.


image
 image

What iOS 6 Mobile Safari Offers Front End Devs

Update: Now that iOS 6 is out and the NDA is no more, Max Firtman has posted an excellent summary of new iPhone 5 and iOS 6 mobile Safari enhancements and regressions. It goes into further detail and mentions features that couldn’t be publicly announced while still under NDA (not that I was, I’m not a registered dev).

Corrections: Although I recommend checking out the above link, I received two corrections via email from Apple. One regarding smart banner documentation and one clarifying css filter support.

Here’s what we know about Mobile Safari in iOS 6 so far, and what it brings to the table for front end developers. I expect there’s more to come in future betas and as people experiment with the current beta more.

Web Inspector via Remote Debugging

The pre-existing developer tools for iOS are limited to say the least. A console.log is flattened to a single level, without actually presenting the contents. iOS 6 introduces the Safari Web Inspector to both the iPhone and the iPad via the Safari ‘Remote Debugging’ interface.

It implements a similar interface to how the Chrome for Android remote debugging works. Safari remote debugging acts in a similar fashion, such that when you select an item in the Safari desktop inspector, it is highlighted on the iOS device.

Prior to this, the only alternative was embedding Firebug Lite, which while powerful, is not designed for touch screen devices. 

As far as I can tell, the old, flawed Developer Console has been removed.

image

Many thanks to Andrew Harrison for fact checking and screenshots.

<input type=”file”>

Finally, it’s here. You can now upload photos and videos from the Photo Library using a regular input element. This was previously only possible via the use of Phonegap etc.

This is a real game changer for mobile apps.

No word yet on if it allows you to capture a new photo. It does.

Real time camera streaming has been confirmed as not supported.

Smart App Banners

The new Smart App Banners are a way of showing Safari users a message indicating that a native app for the website is available in the App Store. While not really a great thing for those of us hoping to move apps back towards the web, it’s still a good experience for the end user. It’s also possible to preserve the page/state/view and send this to the native app. Documentation is available on the Safari Developer Library.

image

Picture via Wired.

Web Audio API

How useful this is remains to be seen. Web audio tends to be fairly handicapped, regardless of browser, operating system or device. Microsoft’s HTML5 Cut The Rope game still used Flash to play the sound effects. I truly hope the iOS implementation changes that, but I’m also a realist.

CSS Filters

According to the Can I Use report, these are only supported in Chrome 18+ with a -webkit- prefix. CSS Filters are also supported in Safari 6, on Mac OS X Lion and Mountain Lion (10.7 and 10.8, respectively).

Full Screen View in Landscape Mode

Interesting by itself, but with desktop browsers beginning to land support for a full screen API - can this be triggered progammatically?

requestAnimationFrame

This has landed, albeit with a webkit prefix.

You should be using the Paul Irish polyfill anyway.

App Cache Upped from 5MB to 25MB

I believe it used to show you a dialog asking for more if you exceeded the 5MB limit.

JPEG Downsampling Ceiling Lifted

JPEG downsampling no longer occurs at 2MP, and instead kicks in around the 5MP on supported devices. The iPhone 3GS and 4th gen iPod touch remain at 2MP. That’s if your carrier isn’t downsampling for you (AT&T, Optus in Australia).

Faster JavaScript Performance

This happens every year, so it’s not really news. Nitro was previously brought to home screen apps giving them a massive performance boost. Nitro hasn’t yet been brought across to UIWebViews, one of the many reasons that the Facebook app is a steaming pile of shit. Maybe future iOS 6 betas will bring Nitro to UIWebViews? Maybe it’s already in iOS 6?

Mobile Safari Wishlist — What Devs Want
This years WWDC in June will hopefully bring about a new iPhone and iOS 6. But in reality, pundits are calling an October release far more likely. While Apple has been slowly closing the gap between mobile Safari and native application development, there is still a host of issues holding mobile Safari back. What a lot of it boils down to is granting software access to hardware components. Stabilising the home screen app experience. Ironing out inconsistencies.
So what do front end developers desperately want from the next version of Mobile Safari?
Home Screen App back to Safari
Fantastic! With a handfull of &lt;meta&gt; tags, you can turn your web page into standalone, chrome-less home screen app! But the second you click a non-ajax link (or external links) - you&#8217;ll be thrown straight back into Safari. While it&#8217;s not really a problem if you&#8217;re writing single page, MVC or AJAX centric applications from scratch; try serving an existing page-based layout to run as an app and you&#8217;re gonna have a bad time.
Workaround: A StackOverflow question along the same lines features a host of pre and post iOS5 solutions hacks.
getUserMedia/Camera/File Access
It&#8217;s currently impossible to take new (or load existing) photos without the use of some intermediary like PhoneGap or Titanium. More frustrating yet is the inability to upload anything in mobile Safari at all. I&#8217;m sure part of this stems from iOS not having an exposed file system, but it&#8217;s been notably missing for a long time now.
The new and immature getUserMedia functionality at least gives desktop websites the ability to access webcams. Because it&#8217;s only available in Opera nightly builds and the correctly flagged Chrome, Addy Osmani wrote a polyfill that no doubt uses Flash to patch support. That doesn&#8217;t do much for us on iOS.
Workaround: PhoneGap etc.
Device Orientation Lock
Speaking of PhoneGap founder Dave Johnson, I was lucky enough to catch his talk at the recent WDC12 conference in Melbourne. A spec is underway for a device orientation lock, resulting in layouts that are explicitly portrait or landscape only. This would help further bridge the gap between web and native by allowing apps to only work in one mode.
Workaround: Currently it can only be hacked together with CSS transforms triggered via media queries on device orientation changes. Undesirable.
WebGL
It&#8217;s possible to build some pretty amazing stuff in WebGL using wrappers such as Mr Doob&#8217;s mind-blowing three.js. His work on three.js has made it incredibly easy to get started building 3D scenes without having to write your own texture and lighting plugins.

Unfortunately iOS does not officially support WebGL, although it can be enabled on jailbroken devices with this recently released app. It relies on the fact that WebGL is actually installed, but not enabled for Safari.

WebGL was added to iOS 4.2 for iAds but Apple has not yet turned it on for general browsing and the like. Enabling WebGL for single applications has been done in the past but this is the first tweak that I know of that applies across the whole OS, including Safari.


navigator.connection.type, navigator.battery etc.
It seems that all the cool stuff seems to exist on the navigator object. In iOS we were already sourcing geolocation and connectivity via the navigator object, but there&#8217;s heaps more coming in the form of specs and proposals.
Android web browsers lead the way in exposing a navigator property that reveals the type/quality of the connection the device is receiving. It&#8217;s therefore possible to determine if the device is EDGE, 3G, WiFi or I guess LTE connected. Safari on iOS is only capable of differentiating between online and offline modes, exposed by the navigator.onLine property. You can also bind events that listen for the ononline and onoffline events too.
In his talk on AppCache manifests, John Allsop touched on the user experience methodology of listening for the online/offline events and enabling/disabling submit buttons respectively. Why not take this one step further by serving tailored resources and displaying spinners relative to the network speed? iOS already does it at the system level, so why can&#8217;t your app? 
Sidenote: I only stumbled across this disparity because I was trying to implement the above for a UX Lab experiment.
Double sidenote: PhoneGap founder Dave Johnson mentioned that, funnily enough, a call to navigator.battery actually decreases battery life.
Proper Resume and Suspend 
Home screen apps always start from scratch when opened.
Even if they are reopened via multitasking.
Seriously.
Workaround: Preserve the state with localStorage? I guess?
Non-binary Device Zoom 
Setting the acceptable zoom levels in the viewport meta tag is quite final. When building a native-ish application, it&#8217;s generally advised to set the zoom and min/max values to 1.0. so users don&#8217;t accidentally scroll &#8220;native&#8221; elements. But doing so completely removes the user&#8217;s ability to resize images and resources displayed within the app. Think a mobile Safari Facebook where you can&#8217;t zoom any of your friends photos.
Workaround: Hilariously bad. -webkit-scale styles bound to events.
Did I miss something? Found a factual error? Let me know in the comments.

Mobile Safari Wishlist — What Devs Want

This years WWDC in June will hopefully bring about a new iPhone and iOS 6. But in reality, pundits are calling an October release far more likely. While Apple has been slowly closing the gap between mobile Safari and native application development, there is still a host of issues holding mobile Safari back. What a lot of it boils down to is granting software access to hardware components. Stabilising the home screen app experience. Ironing out inconsistencies.

So what do front end developers desperately want from the next version of Mobile Safari?

Home Screen App back to Safari

Fantastic! With a handfull of <meta> tags, you can turn your web page into standalone, chrome-less home screen app! But the second you click a non-ajax link (or external links) - you’ll be thrown straight back into Safari. While it’s not really a problem if you’re writing single page, MVC or AJAX centric applications from scratch; try serving an existing page-based layout to run as an app and you’re gonna have a bad time.

Workaround: A StackOverflow question along the same lines features a host of pre and post iOS5 solutions hacks.

getUserMedia/Camera/File Access

It’s currently impossible to take new (or load existing) photos without the use of some intermediary like PhoneGap or Titanium. More frustrating yet is the inability to upload anything in mobile Safari at all. I’m sure part of this stems from iOS not having an exposed file system, but it’s been notably missing for a long time now.

The new and immature getUserMedia functionality at least gives desktop websites the ability to access webcams. Because it’s only available in Opera nightly builds and the correctly flagged Chrome, Addy Osmani wrote a polyfill that no doubt uses Flash to patch support. That doesn’t do much for us on iOS.

Workaround: PhoneGap etc.

Device Orientation Lock

Speaking of PhoneGap founder Dave Johnson, I was lucky enough to catch his talk at the recent WDC12 conference in Melbourne. A spec is underway for a device orientation lock, resulting in layouts that are explicitly portrait or landscape only. This would help further bridge the gap between web and native by allowing apps to only work in one mode.

Workaround: Currently it can only be hacked together with CSS transforms triggered via media queries on device orientation changes. Undesirable.

WebGL

It’s possible to build some pretty amazing stuff in WebGL using wrappers such as Mr Doob’s mind-blowing three.js. His work on three.js has made it incredibly easy to get started building 3D scenes without having to write your own texture and lighting plugins.

image

Unfortunately iOS does not officially support WebGL, although it can be enabled on jailbroken devices with this recently released app. It relies on the fact that WebGL is actually installed, but not enabled for Safari.

WebGL was added to iOS 4.2 for iAds but Apple has not yet turned it on for general browsing and the like. Enabling WebGL for single applications has been done in the past but this is the first tweak that I know of that applies across the whole OS, including Safari.

image

navigator.connection.type, navigator.battery etc.

It seems that all the cool stuff seems to exist on the navigator object. In iOS we were already sourcing geolocation and connectivity via the navigator object, but there’s heaps more coming in the form of specs and proposals.

Android web browsers lead the way in exposing a navigator property that reveals the type/quality of the connection the device is receiving. It’s therefore possible to determine if the device is EDGE, 3G, WiFi or I guess LTE connected. Safari on iOS is only capable of differentiating between online and offline modes, exposed by the navigator.onLine property. You can also bind events that listen for the ononline and onoffline events too.

In his talk on AppCache manifests, John Allsop touched on the user experience methodology of listening for the online/offline events and enabling/disabling submit buttons respectively. Why not take this one step further by serving tailored resources and displaying spinners relative to the network speed? iOS already does it at the system level, so why can’t your app? 

Sidenote: I only stumbled across this disparity because I was trying to implement the above for a UX Lab experiment.

Double sidenote: PhoneGap founder Dave Johnson mentioned that, funnily enough, a call to navigator.battery actually decreases battery life.

Proper Resume and Suspend 

Home screen apps always start from scratch when opened.

Even if they are reopened via multitasking.

Seriously.

Workaround: Preserve the state with localStorage? I guess?

Non-binary Device Zoom 

Setting the acceptable zoom levels in the viewport meta tag is quite final. When building a native-ish application, it’s generally advised to set the zoom and min/max values to 1.0. so users don’t accidentally scroll “native” elements. But doing so completely removes the user’s ability to resize images and resources displayed within the app. Think a mobile Safari Facebook where you can’t zoom any of your friends photos.

Workaround: Hilariously bad. -webkit-scale styles bound to events.

Did I miss something? Found a factual error? Let me know in the comments.

Web Directions Code 2012 Wrap-up Slideshow

I was lucky enough to win tickets to the Web Directions Code 2012 conference in Melbourne this year. I had an hour to put together a quick little wrap up for our usual Friday in-house presentations just to show everyone else here at Kiandra just what they missed out on.

I spoke with John Allsop and he’s pretty keen to get the videos of the presentations up soon. They’ve collected all the slides, audio and video of the presentations - and are hoping to put together a rich multimedia experience similar to Mozilla’s popcorn.js. I didn’t touch on any of the presentation material in my talk as I’m really looking forward to showing the videos instead.

I figured I might as well as put it online if others want to do the same. It’s a high level overview of Web Directions itself, and the topics covered at the conference. You can see it by following the link below, but it’s also available on GitHub for your own uses.

image

CSS3 Input Styling, A State of the Union - UX Lab 009

David Calhoun’s iPhone slider built with an <input type=”range”> is a fantastic example of what’s possible with a single native input element, combined with pseudo and shadow elements. But, like most things these days, it’s Webkit only.

A recurring comment on HN goes something along the lines of:

Webkit only? Webkit is the new IE6.

But this is quite frankly bullshit. Firefox and Opera still streak ahead in other areas*, but the fact is that Webkit-based browsers consistently implement features we front end devs need on a day-to-day basis. Perhaps that’s a result of Google employing people like Paul Irish as a developer advocate. Perhaps he is responsible for prioritising features that real front ends like us actually want to use? I can only speculate, but the benefits cannot be denied.

So what if you try and build an iOS-inspired toggle switch with a single, native checkbox? Dissecting it mentally, all the pieces seemed to be there. I can use :before and :after pseudo elements to construct the extra visual elements. Maybe I can use data attributes to set the on and off state text? In fact, I even expected Firefox to outshine all other browsers in this test as it would be the only one to animate pseudo elements.

But this is the reality.

Webkit (Chrome/Safari):

image

Firefox:

image

Opera:

image

Hacks I considered to try and get it working:

  • Animating the checkbox element as the toggle handle, along the non animatable pseudo element background.
    But this would occur the page to jump around, and is working around the unfortunate ability to animate pseudo elements. 
  • Hide the native checkbox and use only two pseudo elements for the effect.
    This meant no animation. Probably no text. And if animation of pseudo elements eventually drops, it wouldn’t be future proof as it would look a bit naff regardless.
  • Use the <label> for the on/off text.
    This feels very hacky, and definitely like a compromise. This kind of stuff should ideally be able to plug into any existing solution and work straight away. No modifying of <label>s, just replacement of <input>s. Also, I guess the only way to change the text of the <label> via CSS would maybe be via a :target selector and a content property, which probably wouldn’t work and would require yet more pseudo elements. Slopsville.
  • Using JavaScript at all.
    But that wasn’t the point of the exercise at all.

Anyhoo, the experiment is designed so that the second Firefox and others begin to implement the missing functionality, it should just work.

image image

* Firefox remains the only browser that can animate pseudo elements, and an Opera nightly is the only browser that currently implements the getUserMedia specification.

Installing PhantomJS on OSX for Designers

PhantomJS is a headless webkit-based browser with all kinds of nifty use cases. In it’s simplest form, it’s a javascript-driven web scraper. I’m writing this guide note for any novice users having problems installing it on OS X.

Ariya Hidayat wrote instructions on installing PhantomJS on OSX, but glosses over one of the most important steps that is assumed knowledge for competent devs. He has made it as simple as possible to download and extract the binary source as an executable, but as new Mac/Unix user I didn’t understand what was meant by references to changing the PATH.

In order to run phantomjs as a command (and therefore pass another file to it), the folder phantomjs is stored in needs to be indexed via PATHs. This means you’ll be able to: phantomjs helloworld.js. Prior to adding it the PATH reference, phantomjs would not be recognised as a command - or if run from inside the executable, it would result in parse error.

So, all you need to do is add the directory to the PATH variable and you’ll be good to go.

Again:

  1. Download and extract OSX static build
  2. Add phantomjs directory to PATH variable
  3. You’re good to go.

This took me way longer to grasp than necessary, so hopefully this helps you avoid making the mistakes I did.