On "Page Weight Matters"
tl;dr - page weight never stops mattering
It’s always a relief when you see your own personal opinions reinforced by industry heavy-weights. The linked article discusses the impact of page weight on the viewing experience of YouTube. There’s a prevalent developer ethos that HTTP requests are the devil, so combining and minifying (and ideally g-zipping) is the best way forward. I’ve worked on relatively straightforward projects in the past where the JavaScript alone weighed in around 1MB+. But that’s apparently okay, because once it’s loaded, every subsequent visit is a cache-hit, so it’s near instantaneous. The user cops the initial wait on the chin, and apparently it’s all smooth sailing from there. Except, that’s a bullshit attitude.
I don’t believe for a second that just because some home internet connections are faster than ever, that modularity, optimisation and bit crunching are no longer relevant.
This is based purely on the observations that:
- Our websites are increasingly being consumed outside the home network (phone, tablet, “dongle”), and LTE is young and 3G still crawls.
- As the number of users connected to the Internet is increases, so does your potential audience. Your resources can be served much more frequently than ever before, costing you money and bandwidth. Do you think Facebook can afford to serve 1MB JS files to its 1 billion users?
- We live, learn and work in a global community now, as the linked article demonstrates, and what is an acceptable page size locally may not be acceptable globally.
But where to from here? I’m not a network engineer, but I can certainly recommend research around code and CSS modularity, resource prefetching and other asynchronous techniques. Making your user wait while every single resource you could possibly ever want to use downloads is just not acceptable. The end user doesn’t care how fast your computer or connection is.
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
Styling File Inputs in iOS6 with jQuery Mobile
File this post under: “stuff that’s in obscure forum posts but not really documented well”. As per a previous post, iOS6 brought about access to the camera in Mobile Safari. While access is not real time (getUserMedia would be amazing), we are able to prompt the user to take a new photo or access the camera roll. Presumably for security reasons, styling file inputs in desktop browsers has always been hell on earth. Mobile is much the same.
What you can do as a work around is rely on native browser functionality where clicking a <label> triggers the clicking of it’s associated <input>. I’ve relied on the native jQuery Mobile button styling for speed, but you can achieve pretty much anything. Hiding the input can be achieved in various different ways, but as far as I know it cannot be display: none; for security reasons. Setting visibility: hidden; or opacity: 0; will all achieve the same effect, and setting position: absolute; will take it out of the page’s flow.
You can see it in action in the JSFiddle below.
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.
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?
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.
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.
Vertically Centering DIVs
The ability to vertically center a DIV in HTML is one of the holy grails of web development, along with sticky footers and just generally making shit work in IE. I had to vertically centre something recently, and I was sick of using the dirty hacks involving absolute positioning, negative margins and extra HTML elements.
The solution below works in all modern browsers, and is supported in IE8 and above.
<div id=”centered”>
I’m centered vertically and horizontally
</div>
#centered {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
margin: auto;
width: 200px;
height: 200px;
}
It is listed as Method 4 on this page, but frankly should be Method 1.
The reason I love this solution so much is that we have all been using margin: 0 auto; to horizontally center things for yonks. This answers the age old question of, well, why doesn’t it work vertically either? Another big plus is no extra HTML elements. Generally you’re forced to create one to horizontally center an item. Another to offset it 50% from the top and, depending on your cross browser confidence, another to negatively offset this with a margin. ■
Front End Development Guidelines - Update
Well that was a wild ride indeed! Since release, the front-end development guidelines I posted have gone bananas. Tens of thousands of page views, plenty of GitHub forks and followers, and even a kind word or two. Many thanks to Paul Irish and other figureheads for tweeting about the resource I put together. It really helped spread the word about what I was trying to do, and in turn pulled in some great comments and suggestions logged through the GitHub issues interface.
As we stand, there are currently 8 open issues and I’ve managed to close 20 others.
Some of the most recent changes I’ve made include:
- Rewriting the section on commenting your JavaScript. My team leader at my previous employer put this one together when he was proofing my work, and slipped it in. A lot of people have flagged it as a massive WTF and it has seen been replaced.
- I’ve merged in a range of spelling and grammatical changes. What can I say? Me dun speak english good-like.
- Added the new “micro clearfix” to the section on clearing floats.
- Added a section on commenting CSS blocks (handy!).
- Further discussed whether remapping “this” to “self” is a good idea.
- Added section IDs for deep linking (but no way to easily do so, as yet).
- Removed the Gotham web font, which I embarrassingly left in, ignoring my own advice.
Thanks for reading and contributing, be sure to send through any further suggestions using the issues interface or via my email address listed on the right.
My role with my last employer involved creating websites, applications and widgets with front end technologies like HTML, CSS and JavaScript. Other parts of my job included code reviewing commits and running training exercises to spread the knowledge around. When I handed in my three weeks notice, they were quick to ask me to write up guidelines on the best way to write maintainable, clean and accessible code. What follows is a GitHub hosted document, allowing for revisions, forking and issue logging - a concept I “borrowed” from the great resource JavaScript Garden.
Considering my knowledge is all gleamed from many years of reading Hacker News and following Twitter links, it definitely has holes. I am completely self taught in that regard. So although I can’t vouch for the accuracy of all the information, hopefully you can log any corrections or raise any questions via the issues interface.
Linking JavaScript Objects to HTML Elements
Alternative Title: The jQuery $.data() Function is Awesome
The Workflow creation tool I’ve been working on and blogging about (design & code pattern) would have been impossible without forcing myself to learn object oriented (OO) JavaScript. It was a pretty steep learning curve for a designer, and I soon came across the common pitfalls of writing OO code. The factory pattern structure I linked to above took care of most of the problems like: pushing pseudo-class objects to an array, easy find methods without the use of hash tables, and deleting objects non-destructively.
One thing that took me a while to wrap my head around: How do you form a relationship between the “back end” object instances and the HTML/DOM objects you output from these?
Say you have the classic Person object example:
var collection = [];
var Person = function(params) {
this.name = null;
this.age = null;
$.extend(this, params);
collection.push(this);
}
When I came across the problem of being able to link back to the object itself, the first (and laziest) solution that jumped to mind was searching using an instance’s unique ID. Creating the objects initially gives you the chance to ensure the HTML and back end instance shared the same ID. At a later point when you need to find the instance, you can loop through your objects with class manager shorthand findBy() function:
Manager.prototype.findBy = function(p, v) {
for(var i = 0, len = this.objs.length; i < len; i++) {
if(this.objs[i][p] === v) {
return this.objs[i];
}
}
};MyManager.findBy(“id”, 999);
This made a lot of sense initially:
- HTML attributes can only be strings.
- Make the HTML element and the back end object share an ID
- Loop through and match the object when required
An Example
In this example, we have to get the ID from the HTML element, convert it to an integer and then finally: loop through all the instances until it finds a match.
// get the ID value
var theID = parseInt($(this).attr(“objectID”), 10);
// silly loop to find the object
$(collection).each(function(i, item) {
if (item.id === theID) {
item.birthday();
}
});
But why bother looping? Maybe a hash table would be better suited to your scenario, but for me I wanted something more dynamic.
The Better Way
The jQuery $.data() method is awesome. On face value it’s like the native $.attr() method but doesn’t restrict you to a string value. What this incredibly long-winded post boils down to is the realisation that you can bind your HTML elements directly to their back end objects via the use of the data attribute. No (visible) loops.
// set the data attribute originally
$(obj).data(“personObject”, self);// call birthday on the object directly
var theObject = $(this).data(“personObject”);
theObject.birthday();
You don’t even have to declare a reference to the object, you could just as easily chain up your calls. A word of warning though: this can get a bit confusing if you’re using a chaining library like jQuery, especially if your object prototype functions share names like “remove()”. ■
$(document).ready() before CSS ready
I ran into a bit of an issue today that was causing some real headaches. Essentially, the $(document).ready() event is fired before the CSS has finished loading and rendered out. This was breaking a dodgy resizing script in IE6 through to IE8, where a height was resized before the padding was applied from the stylesheet. The result was a cropped window of content, visually ‘off’ by the padding amount.
You’ll find plenty of articles online telling you to call the stylesheet before any JavaScript and blah blah blah… but if you’re already doing that, you’ll have to Google a lot deeper to find the solution.
Using the $(window).load() event ensures the CSS and images etc have loaded before the function is fired. Oh how I wish I knew this 24 hours ago!
Read more about the difference between document ready and window load.
