You heard the pixels!
(via muzze)
Real Racing 3 is looking pretty boss. Lets hope they can make it much more addictive than older versions which, besides looking beautiful, could get a bit repetitive at times.
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.
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.
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:
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.
Beautiful Retina iPad Wallpapers
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.
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.
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.
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$.ajaxSetupexternally.
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.
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)
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.
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.
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.
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 <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.
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’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.
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):
Firefox:
Opera:
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.
* 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:
- Download and extract OSX static build
- Add phantomjs directory to PATH variable
- 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.
Repository Updates
iOS Theme for jQuery Mobile
Good news! I’ve just pushed some major changes for my iOS jQuery Mobile theme. It now works with jQuery Mobile 1.1.0, which was a bit of a struggle. It also forced me to do some major code cleanup, delivering cross browser gradients and various enhancements I had been putting off.
A full list of changes and resolved bugs follows:
- Supports jQuery Mobile 1.1.0 (this was a nightmare)
- Code cleanup more strictly obeys my coding conventions
- All gradients and effects are now cross browser compatible (Issue #2)
- Updated slider toggle to iOS 5 style (Issue #7)
- Got dialogs looking as close to native as possible considering jQuery Mobile doesn’t support overlayed dialogs (they’re standalone pages) (Issue #3)
The changes have introduced a few minor visual quirks relating to the .ui-focus box shadows etc, but hopefully these will be rectified in the near future.
jQuery Gantt
I made some minor code changes, but the most important thing here was the addition of documentation. The original creator didn’t provide any, so hopefully this makes a bit more sense. I’m sure I’ve missed something here and there (holidays?), but I’ll fix that up as we go.
The changes:
- Added documentation and better demo with bootstrap popovers
- Works with latest jQuery 1.7.2
- Merged pull request for “undefined error”, thanks Nathan Colgate.
- Code and folder cleanup
Front End Development Guidelines
The page now passes HTML5 validation. Apparently some people care about this.
Made my first bagels. Boiled ‘em and everything.
They taste amazing.
Shit yeah!
I picked up a new Cycloc from eBay for a slightly better deal than the $110 AUD they seem to go for. A little bit more difficult to put up than expected, mostly owing to some misdirection from a Bunnings employee and a too short drill bit.
