iosOverlay.js — iOS Overlay/Notification Plugin

Here’s a plugin that allows you to place iOS-style notifications over your web app. It’s useful for showing short succinct messages, or notifying the user of what action is being performed. It’s great for the same reason that the native iOS overlays are too; it’s intrusive enough to grab your attention, but doesn’t steal focus entirely. 

This plugin works equally well on desktop, mobile and tablet.

image

Given the trend towards micro js libraries and removing dependencies, this plugin can stand alone or work nicely with other frameworks.

Features and details:

  • Uses CSS3 transitions for smooth animation
  • Plays nicely with spin.js for sweet spinners
  • Notifications can show for a duration or be manually closed
  • Notifications can be updated on the fly (icon/text)
  • Framework agnostic (but you can degrade to jQuery animation if CSS animation is not supported)
  • IE7+ support (minus rounded corners) and all the usual suspects
  • Fully documented
  • MIT/GPL/Who gives a shit just don’t be a nozzle about it license

To do:
If there’s a bit of interest in this project then there’s more I’d like to do.

  • Add fancy CSS 3D transitions (drop, 3D drop etc)
  • Use fader.js for cleaner animation syntax (one less optional dependency) 
  • Add a fallback IE rounded corners PNG
  • Option to dismiss with ‘Esc’ keypress
  • Add some retina icons

image image

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.
Pop-upView Separately

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.

jQuery Mobile 1.0.1 - iOS Theme Compatible

I haven’t touched the iOS inspired jQuery Mobile theme in quite a while, but a few of you have been messaging, mailing at tweeting at me asking if I’ll support the jQuery Mobile 1.0 build. And….. it’s done. Here’s the list of changes:

  • Updated to jQuery Mobile 1.0.1 build
  • Fixed graphical issues stemming from this: #23, #24 and #25
  • Page buttons now take on gradient-less style (previously only <a> tags)
  • Merged a pull request related to a button icon bug fix

As always, the demo is up to date and available.

 

iOS Inspired jQuery Mobile Theme jQuery Mobile doesn&#8217;t deviate far from the pattern established by its sibling libraries: provide something that normalises functionality and/or design across browsers and operating systems.  The work by the Filament Group has been vital for standardising the look and feel of jQuery Mobile, especially when dealing with incredibly dated or under-featured mobile browsers. Borrowing upon conventions established by both the iOS and Android operating systems, they created something that is palatable across a range of devices. There will be odd instances when you need an application to look as close to native as possible. I completely agree with the Filament Group&#8217;s arguments against this, but currently designers are forced to roll their own solution. What I have created is the beta framework for an iOS-inspired theme that attempts to bring jQuery inline with the native iOS UI elements. I actually began this project when the first alpha was released, but with taking on a new job and other responsibilities, I found myself lagging behind the release schedule. I&#8217;m not sure of the response this will get, so hopefully I can gauge how much time I should spend on this in future. But without further ado: here is the iOS-inspired theme for jQuery Mobile. It works great in Chrome, Safari, iPhone and iPad mobile Safaris.    Some Caveats To achieve the look of the iOS style back button with CSS3, the HTML is customised and therefore must be copied and pasted manually. The back button template can be found in the GitHub readme file. The CSS3 back button isn&#8217;t perfect, there are some jaggedness and shadow issues. Plenty of elements still remain unstyled, or are missing hit state styling. Cross browser compliance is a low priority. This is an add-on theming layer. It was impossible to fork the actual jQuery Mobile theme and attempt to keep up with their changes, so this just sits as a skinning layer on top. Some Issues This Exposes in jQuery Mobile Dialogs need some serious work. I could have spent a lot of time and made my dialogs look exactly like the iOS ones, but this would have involved some pretty hectic CSS and JavaScript. As is I had to do a bit of a work around to get them to dock to the bottom and not the top. Most notably broken, the inability for these dialogs to behave like modals - showing the background as obscured. Back button syntax. They&#8217;re are definitely some cleaner ways to create the iOS style back buttons. I was keen to avoid images, but an image mask might have done really well in this situation. Regardless of that, you will probably find yourself plugging in custom HTML when working with jQuery mobile, and not just the buttons. It&#8217;s bloody hard to keep up with the release cycle. This is not a bad thing ;) I am, as always, open to merging pull requests and suggestions to help improve this project. I must also stress that it is important that truly innovative changes best be held off until jQuery Mobile makes it out of beta. ■
Pop-upView Separately

iOS Inspired jQuery Mobile Theme

jQuery Mobile doesn’t deviate far from the pattern established by its sibling libraries: provide something that normalises functionality and/or design across browsers and operating systems. 

The work by the Filament Group has been vital for standardising the look and feel of jQuery Mobile, especially when dealing with incredibly dated or under-featured mobile browsers. Borrowing upon conventions established by both the iOS and Android operating systems, they created something that is palatable across a range of devices.

There will be odd instances when you need an application to look as close to native as possible. I completely agree with the Filament Group’s arguments against this, but currently designers are forced to roll their own solution. What I have created is the beta framework for an iOS-inspired theme that attempts to bring jQuery inline with the native iOS UI elements. I actually began this project when the first alpha was released, but with taking on a new job and other responsibilities, I found myself lagging behind the release schedule. I’m not sure of the response this will get, so hopefully I can gauge how much time I should spend on this in future.


But without further ado: here is the iOS-inspired theme for jQuery Mobile. It works great in Chrome, Safari, iPhone and iPad mobile Safaris.

  

Some Caveats

  • To achieve the look of the iOS style back button with CSS3, the HTML is customised and therefore must be copied and pasted manually. The back button template can be found in the GitHub readme file.
  • The CSS3 back button isn’t perfect, there are some jaggedness and shadow issues.
  • Plenty of elements still remain unstyled, or are missing hit state styling.
  • Cross browser compliance is a low priority.
  • This is an add-on theming layer. It was impossible to fork the actual jQuery Mobile theme and attempt to keep up with their changes, so this just sits as a skinning layer on top.

Some Issues This Exposes in jQuery Mobile

  • Dialogs need some serious work. I could have spent a lot of time and made my dialogs look exactly like the iOS ones, but this would have involved some pretty hectic CSS and JavaScript. As is I had to do a bit of a work around to get them to dock to the bottom and not the top. Most notably broken, the inability for these dialogs to behave like modals - showing the background as obscured.
  • Back button syntax. They’re are definitely some cleaner ways to create the iOS style back buttons. I was keen to avoid images, but an image mask might have done really well in this situation. Regardless of that, you will probably find yourself plugging in custom HTML when working with jQuery mobile, and not just the buttons.
  • It’s bloody hard to keep up with the release cycle. This is not a bad thing ;)

I am, as always, open to merging pull requests and suggestions to help improve this project. I must also stress that it is important that truly innovative changes best be held off until jQuery Mobile makes it out of beta. ■

Introducing Crikkket

The Crikkket web app for streaming the Ashes’ scores is up and about. We’re constantly pushing changes to it, so if something breaks send us a tweet!  

Simply point your iOS or Android device to http://www.crikkket.com and add it to your home screen for the best experience.  

Designed and coded by me (@taitems) with back-end wizardry and data scraping by Brenton (@sesh).  


(This is a live screenshot dumped into an iPhone PSD)