Nothing Insightful

  • Archive
  • RSS

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

    • #ios
    • #iphone
    • #ipad
    • #notifications
    • #overlay
    • #javascript
    • #css
    • #framework
    • #plugin
    • #library
    • #css3
    • #html
    • #mobile
    • #open source
  • 4 months ago
  • 8
  • Comments
  • Permalink
  • Share

UX Lab 013: ThreeJS Battery

It’s been a bit quiet in the lab of late, and for that I apologise. To make up for it I thought I would have a dabble with something small in ThreeJS. I’ve played with it before, but never put out anything production-ready.

3D artwork has become pretty common place these days. But generally you’ll see it flattened, and in turn, unable to be interacted with. ThreeJS opens the web up to a whole new world of possibilities when it comes to gaming and immersive experiences. But what about the little things?

Here’s a little experiment from the lab, demonstrating just how easy it is to bring a bit of excitement to the web. As uptake of WebGL grows, so does the opportunity to liven up the web. I’m not impressed when you can build an entire iPhone with CSS using a single HTML element. I’m actually impressed when you design something awesome, you build it without compromise, and it’s not a completely flat, static experience.

So with that in mind, here’s a shitty battery I built :)

You can go about building things in different ways with ThreeJS. The ability to export existing 3D objects from popular programs like 3DSMax, Maya or Blender is the sole reason this technology is remotely useful in the real world. Strangely enough, I chose to create the battery with primatives, by hand, and not import any objects. No 3DSMax. No Photoshop (aside from a reflection map, oops). Just ThreeJS.

That meant it took a couple of hours one night to create the geometry and camera tracking, and a couple of hours the next night to create all the materials. That’s not long. I really don’t see why more people can’t build stuff like this.

So check it out, the source code is on Github.

    • #threejs
    • #ios
    • #battery
    • #3D
    • #webgl
    • #javascript
    • #animation
  • 6 months ago
  • 2
  • Comments
  • Permalink
  • Share

Delta jQuery UI Theme

Hey guys, just a quick heads up that I released the “Delta” jQuery UI theme a while ago over on the blog of my employer, Kiandra IT. It’s a completely free theme, and the best looking one yet. There are some known issues reported on the GitHub repo, so I’ve got to find some time to push up the fixes. All in all it’s pretty stable and cross browser compliant. It works on both light and dark backgrounds, something you don’t always see. It’s also retina display friendly and makes use of my OS-dependent modal script.

The details:

  • Detailed blog post
  • View Demo
  • GitHub Repository

Enjoy.

    • #jquery
    • #jquery ui
    • #theme
    • #kiandra
    • #github
    • #open source
    • #OSS
    • #javascript
    • #design
  • 6 months ago
  • 3
  • Comments
  • Permalink
  • Share
'\x3ciframe src=\x22http://player.vimeo.com/video/49375288\x22 width=\x22500\x22 height=\x22281\x22 frameborder=\x220\x22\x3e\x3c/iframe\x3e'

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.

    • #ios
    • #iphone
    • #ipad
    • #scroll
    • #javascript
    • #ux
    • #iscroll
  • 8 months ago > simurai
  • 217
  • Comments
  • Permalink
  • Share

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.

 

    • #UX
    • #lab
    • #javascript
    • #css
    • #html
    • #iOS
    • #Mac
    • #Windows
    • #usability
    • #notifications
  • 9 months ago
  • 5
  • Comments
  • Permalink
  • Share

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.

 

    • #javascript
    • #presentation
    • #impress.js
    • #best practice
    • #jquery
  • 10 months ago
  • 9
  • Comments
  • Permalink
  • Share

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.

 


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.


 

    • #jquery
    • #javascript
    • #css3
    • #css
    • #html
    • #ios
    • #jquery ui
    • #jquery mobile
    • #github
    • #design
  • 10 months ago
  • 2
  • Comments
  • Permalink
  • Share

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?

    • #ios6
    • #ios
    • #ios 6
    • #mobile safari
    • #safari
    • #iphone
    • #desktop
    • #debugging
    • #debug
    • #chrome
    • #javascript
    • #css
    • #html
    • #firebug
  • 11 months ago
  • 215
  • Comments
  • Permalink
  • Share
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.
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.

    • #mobile
    • #safari
    • #iOS
    • #iPhone
    • #iPad
    • #JavaScript
    • #iOS6
  • 11 months ago
  • 2
  • Comments
  • Permalink
  • Share

bootstrap.footnotes.js - UX Lab 008

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

Here it is in action:

Documentation and options are available on the demo page.

It also has its own GitHub repository.

 

    • #bootstrap
    • #twitter
    • #javascript
    • #jquery
    • #css
    • #js
    • #plugin
    • #ux
    • #ux lab
  • 1 year ago
  • 3
  • Comments
  • Permalink
  • Share

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.

 

    • #ios
    • #iphone
    • #ipad
    • #css3
    • #javascript
    • #library
    • #jquery
    • #css
    • #3d
    • #github
  • 1 year ago
  • 5
  • Comments
  • Permalink
  • Share

3D Accordion Effect - UX Lab 006

I posted the following experiment as a way of demonstrating just how far the line has blurred between web based animation and OS based animation. I saw Dribbble shots (one and two) by Indian designer Pranav Pramod and was inspired to replicate the effect in CSS3.

Unfortunately nothing is ever as easy as it seems. If it was, someone else would have already posted a similar effect. The problem is that when animating something with a 3D transform with a forced perspective, there is no way to measure or mirror the actual height represented in the browser using CSS. If you animate the parent element from 0px in height to 30px, it’s a straightforward linear animation. The 3D transform, on the other hand, changes on a non-linear scale because of the perspective.

There are two solutions, neither of which are desirable.

The first involves JavaScript, which frankly I had tried to avoid. In this example, the animation is triggered by the addition of a CSS class via JavaScript - but could just as easily be bound to an :active:target CSS event. The only way to get the actual browser rendered height of the element is to get it via JavaScript with the obj.clientHeight getter. While discussion pointed to wrapping the object in a parent element and not needing JavaScript at all, this does not work in all browsers.

Instead the JavaScript method involves binding a function with requestAnimationFrame which sets the parent objects height to mirror the calculated height of the transformed object. Accurate, but if we wanted to perform calculations many times per second, why did we bother animating with CSS at all?

The other method, considerably less accurate and very fiddly, is to match the easing or timing of the two animations. It may be possible to create a custom timing function using cubic-bezier which matches the rate of easing of a 30px tall object, rotating from -90deg to 0deg, with a perspective of 400 units. But why would you? That’s shit house.

Maybe in this instance a flat out Canvas animation would have been much more sensible. You’re still performing a function every ‘x’ milliseconds, but at least the canvas itself may be hardware accelerated. Until CSS animation matures, we will most likely have to abuse the JavaScript add-ons such as the one described earlier. Or even better yet, sever the ties with HTML and CSS and - get this right - use graphical languages for what they’re intended.

Ninja Edit: Also, you can’t yet animate background gradients so the whole 3D effect on the depth of the flaps is kind of impossible for now.

Sad-face Edit: The second I posted this, someone posted pretty much the exact same thing to Hacker News in a much more polished way. Check out Paperfold CSS.

 

    • #css
    • #css3
    • #html
    • #ux
    • #javascript
    • #experiment
    • #dribbble
    • #ui
    • #design
  • 1 year ago
  • 4
  • Comments
  • Permalink
  • Share

jQuery-UI.toggleSwitch() - UX Lab 005

The last thing web devs need is another toggle plugin. But this was developed for sites that already run jQuery UI and don’t want the extra bloat of yet another library. It draws upon the theme .ui-slider for the look and feel, and can be applied to <select>  elements with two child options.

Configuration options and examples are contained within the UX Lab page. I guess this warrants it’s own GitHub repository for change management and issue tracking. I’ll get around to that eventually.

 

    • #JavaScript
    • #jQuery
    • #jQuery UI
    • #toggle
    • #switch
  • 1 year ago
  • 12
  • Comments
  • Permalink
  • Share

Idle jGrowl Re-routing - UX Lab 004

Paul Irish wrote a pretty chill script back in 2009 for detecting when a user becomes inactive. It’s quite ingenious in its simplicity, as the best things usually are. What wasn’t explained fully is the ways in which this can be used to deliver a better user experience. It’s fantastic for preventing timed or asynchronous actions when users aren’t going to benefit from the action.

This quick little experiment is aimed at demonstrating the concept in the simplest form.

A jGrowl notification triggered every ‘x’ seconds, or by a server event, isn’t of much use when the user isn’t around. They disappear after a few seconds. So instead, if the user is deemed inactive, you should make them “stick” or push them to a modal, similar to the loathed Growl notification rollup pictured below.

Obviously the linked example isn’t quite as eloquent, but it’s not like the Growl rollup was that well received to begin with. See what other cool shit you can come up with.

 

    • #jGrowl
    • #jQuery
    • #JavaScript
    • #UX
    • #lab
  • 1 year ago
  • 2
  • Comments
  • Permalink
  • Share
My new personal site is live!
It&#8217;s just a little micro-site tying together a range of social media websites. There&#8217;s some fancy coding behind the scenes that predicts where I&#8217;m going to be at any given time, because we&#8217;re all a walking bell curve. It&#8217;s good to get it out the door, because designers are notorious for over-designing and iterating their personal sites.
Enjoy,taitbrown.com 
Pop-upView Separately

My new personal site is live!

It’s just a little micro-site tying together a range of social media websites. There’s some fancy coding behind the scenes that predicts where I’m going to be at any given time, because we’re all a walking bell curve. It’s good to get it out the door, because designers are notorious for over-designing and iterating their personal sites.

Enjoy,
taitbrown.com 

    • #design
    • #css
    • #css3
    • #location
    • #javascript
    • #vcard
    • #mini site
  • 1 year ago
  • 27
  • Comments
  • Permalink
  • Share
← Newer • Older →
Page 1 of 4

About

My name is Tait Brown, and I'm a Melbourne-based UI designer and a front end developer. I like to make stuff.

taitbrown.com

taitbrown@gmail.com

Me, Elsewhere

  • taitems on Dribbble
  • taitems on Forrst
  • @taitems on Twitter
  • taita_cakes on Last.fm
  • Linkedin Profile
  • taitems on github

Twitter

loading tweets…

  • RSS
  • Random
  • Archive
  • Mobile

Effector Theme by Carlo Franco.

Powered by Tumblr