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.
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
iOS Theme Update
I pushed an update to the iOS jQuery UI Theme to add support for the latest release - jQuery Mobile 1.2.0. Not much should change, but there is a notable syntax change to “in page” buttons.
The changes are:
- Added support for jQuery Mobile 1.2.0
- Support for, and styling of new
popupelements - An example iOS style
popupas per the image below (would be best if you set it up with a timer to hide after a couple of seconds?) - Major refactoring of “in page” button styling. No more messy
.ui-btn:not(this):not(that), instead it inherits from.ui-btn-plain. - Closed various issues and pull requests
- While basic popups are supported, no nested popup menu support is available
- As above, button syntax has changed. This causes an issue with
<button>elements. I’ve raised a bug here.
Wishlist: An integrated iPhone experience
I’ve always liked the way that the iPhone fades out and pauses your music whenever a phone call interrupts. It took a bit of getting used to, but now I can’t imagine it working any other way. So I think it’s understandable that it feels a bit disconnected that my phone, ringing in my pocket, can’t pause iTunes running on my Mac Book - or even music and video on the iPad and Apple TV. Looking into the options turns up a $20 shareware solution that allegedly no longer works, and it’s not the answer. As a relatively new Mac user, I get the impression that Apple rewards those who commit fully to the ecosystem. And so I feel, something like this needs to go native.
But that got me thinking: why stop at pausing media?
The concept of finding a phone number online, pulling your phone out of your pocket and physically dialing the number; well it all feels a little last decade, doesn’t it? Admittedly, you can purchase Skype-out credits and have a dicky little widget that overrides numbers in web pages, but it’s just another program to install and more logins to maintain. Some of you may scoff at the experience I’ve described. Perhaps it’s already possible on an Android phone and a Windows box? But things like this are not about who is first to market, it’s about the value they add.
It’s been said that a lot of Apple innovations seem inevitable when you think about them. You can already use iMessage and FaceTime on nearly every iOS device. Phone calls via a FaceTime-esque protocol seems to be a standout omission. So whether calls are routed through a mobile phone via bluetooth or handled via VOIP, it doesn’t really matter. It’s certainly possible today, it just hasn’t been executed well.
Although pocket change for both companies, a pivot on Apple’s part would rival the value that Microsoft paid $8.56 billion for when purchasing Skype.
Dribbble is rife with shots portraying desktop widgets for answering calls. Spurred on by an informal rebound contest, there were 22 follow ups to Daryl Ginn’s shot. Funnily enough the shot was a conceptual take on (the terrible, existing) Skype for Mac, but the execution is good. I’d love something like this.
Great concept. Be sure to watch the video as the text just doesn’t do it justice!
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.
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).
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.
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.
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.
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.
HTML iOS Notifications - UX Lab 007
I thought I’d build a facsimile iOS notification plugin for shits and giggles. It’s pretty much the exact opposite of a good UX, but it’s more of a proof of concept than anything else.
- It’s 100% wide on standard and retina iPhones and 60% on desktop and iPad resolutions.
- It has built in retina icon handling.
- Doesn’t break middle mouse clicks when using a URL.
- Passes JSHint.
- It works with Chrome, Safari, Firefox and I believe Opera, but I haven’t tested.
Documentation and options are available on the demo page.
It also has its own GitHub repository.
Imagine every time a phone call came from an unsaved, non-private number it did a quick API call to the numerous crowd-sourced websites such as WhoCallsMe or Caller Complaints.
Someone build this, if it doesn’t already exist on Cydia that is!
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.
Luke Beard wrote an insightful post on the front end development of Zerply. One of the little things that stuck out to me was the method of using native iPad and iPhone controls disguised as normal HTML elements. He uses a native <select> element at zero opacity to trigger the native controls on touch. It’s incredibly straightforward when you think about it, but then again the best ideas always are!
Making OS X Look Like iOS - Quick & Easy
Before we get started I’ll answer the obvious question: why would you do such a heinous thing? Well, I like consistency - and so do others. Apple’s recent direction with the Lion UI has been to make things more like the iPad, so why should the overall skinning be any different. It’s also great for people who have never used a Mac before, or have trouble adapting from a Windows OS.
Changing Dock Icons
I thought I’d get the most obvious one out of the way quickly. Installing CandyBar (USD $29) is a great way to replace dock icons that contribute to an inconsistant experience. It helps to rectify debacles like the Twitter for Mac icon and present a unified dock. The next step is to install the Flurry icon set from Iconfactory. My experience with CandyBar so far has been a bit mixed. It simplifies the process of manually replacing the icons, but the fact that certain icons (like the Calendar) cannot be overridden, and the requirement to restart several times for icons to ‘take’ - kind of make the price of CandyBar seem a bit high.
Changing Growl Skins
Even if you’re a Windows convert like me, one of the first things you probably did was install Growl. The vast majority of applications can push notifications to Growl. It’s surprising that Apple hasn’t adopted Growl into it’s OS like a lot of their other innovations.
Theming it’s notifications to look like iOS is a bit cheesy, but extends the experience from the iPhone and iPad. You’ve got plenty of choice in terms of style.
My favourite:
More of a “Notification Centre” one:
More like what you’ll see in iOS5:
And That’s It
… only two steps. There are plenty more steps over on this page, good and bad. Simple things like changing the top bar to be black make sense, others such as hiding the hard drive to mimic the iOS file system are just a touch excessive. ■
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. ■
A Sidenote on iOS Notifications
A lot of speculation is brewing over the impending overhaul of notifications in iOS 5. The entire focus appears to be on the software end, but that is only part of the equation. If you keep an iPhone docked silently on your work desk, you too have probably felt the need for a better visual cue of notifications. Currently, you rely on strangely spaced reminder intervals, or compulsively checking your screen when you return to your desk. Neither method addresses email notifications.
A new lock screen would go part of the way to addressing the issue: Return from a meeting/coffee/toilet break and press a button to trigger the lock screen. It also fixes the problem of silent email alerts. The other blindingly obvious solution is to provide a new area of visual feedback, not linked to the main screen and its limitations. The power drain and risk of component failure are fairly straight forward reasons such a feature should never be built into the main screen (excessive size aside).
A second screen is certainly not a new concept. “Clamshell” phones have been running external displays for a long time, but they’ve always been far from seamless. Cheap and nasty plastic is broken up by an equally lo-fi LCD screen. My old Motorola KRZR was probably one of the better attempts, burying both the surrounds and the display beneath coloured glass. It did an okay job in softening the difference in materials. Others were less than ideal:
There were some more serious attempts that still looked pretty lo-fi, namely the LG Lollipop/dLite. I never saw this one in person, but the effect seems to be replicated outside of the press shots. Other clamshells like the Sony Ericsson z750 weren’t too shabby either.
The challenge should be clearly defined, it “simply” becomes a matter of implementation. Can Apple source a low power colour display capable of blowing back to near invisibility? Will this component fail all the time like the iPad 2 screen? Is the only other solution an etched screen backlit by coloured LEDs? Should the user be able to configure what icons are represented (Twitter, Facebook, IMs etc)?
The options, you can only have two:
- Configurable information/icons
- “Always on” display
- Colour display
If it were an LCD screen, it could lend itself to a range of possibilities including the time, the weather and all kinds of jailbreak goodness. Retail and enterprise implementations could be quite inventive too.
One thing is certain: the icons should completely disappear when not in use.
Not “as long as you’re facing it front-on they should be mostly invisible”.
Not “as long as they’re not in full sunlight they should be mostly invisible”.
Regardless of implementation, this is something I’d be really keen on seeing in the iPhone 5, 6. I’m also pretty certain that somewhere in 1 Infinite Loop, CA, this concept exists and sits in a room full of other Jobs-spurned prototypes. And it’s a damn shame really. ■
