Completely client-side user creation and sign in with Ember.js and Rails
PhantomJS opened up to me in a major way once I discovered I was able to drive it with Mocha. I still, however, find creating HTML pages for tests very cumbersome, and far from DRY. And I want to write my tests in CoffeeScript, dammit!
About a year ago I joined up with Aviary, the company that proved creative software doesn't need to be tied to the desktop with its Flash-based image/audio/effect editors. At this time, the war on Flash was in full swing and the job post I applied to was under the auspice* that I would be converting those awesome Flash apps into HTML5. Dream job material am I right?
Nicole Sullivan (aka @stubbornella) brought Object-oriented CSS (OOCSS) to NYC last Thursday in an updated presentation on how our best practices in CSS are killing us. She was refreshingly candid and it was great to have insight into her work process with big clients.
As with most things, using RequireJS wrong can be worse than not using it at all.
Toward the end of a recent post at The UI Observatory, there's a nice discussion about Undo/Redo in Pixelmator (an image editing app). Pixelmator actually messages you the type of action you've just undone or redone, front-and-center. This feature would be handy any time you find yourself creating or editing, as long as it's sufficiently out of the way when it needs to be. This could be especially useful on the web, where HTML editors generally hijack context from the browser and it's easy for the context of Undo/Redo to change with a few mouse clicks.
Apple has finally fit a multitouch interface into the 6th generation iPod Nano. In order to cram that into the diminutive form factor, users give up a few features such as video recording, playback, and the orientation sensor. Dropping the sensor seems logical now; the device is so small that orientation loses its meaning, and with a 1:1 aspect ratio there's no potential for a better fit for the on-screen content. I love the new approach of actually rotating the screen with your fingers, in the event you actually need to (assuming that would be due to the way it's clipped to you).
Clear primary actions can and should be applied across an application anytime there is a choice to be made. Although we can't control our users' actions, we can certainly guide them visually, and as Smashing Magazine points out, "[relieve] the user from having to think about which option to choose in order to complete their task."
I was recently building a "mega menu" (a really big drop-down menu panel) for primary navigation, so I decided to re-read the Jakob Nielsen Alertbox regarding them. Apparently the mega menu is the only form of drop-down menu to perform well under user testing.
A common drawback of progressive enhancement is that the UI will often "flash" or "flicker" when first loading. This is because conventional wisdom of separation of concerns calls for waiting until the DOM is ready to set up the UI for a richer interaction (tabs, accordion, drilldown, the list goes on). While this makes sense academically, we're not always putting the user experience first.
Orangoo Labs' GoogieSpell widget is a really clever way of spellchecking input fields or textareas on a Web form, completely inline (think Microsoft Word) and without that nasty popup window you usually see that loops through all of your typos serially. As a bonus, by default it makes a call to Google's spellchecking web service so you don't have to install or maintain your own dictionary (although you can easily extend it to do so). Also, did I mention it's FREE?
In-page links (or, links that jump to specific areas of the current page) are definitely useful for lengthy or text-heavy sites, and often essential when these pages are consumed by screenreaders or "legacy" mobile devices. But they can also be disorienting for many reasons — did I just move up the page? Down it? With the instantaneous transition the browser provides by default, a user is left to guess.