Nicer Rails confirm dialogs (and not just for delete methods)
I’m working on a Rails app, and I wanted to use a nicer confirmation dialog box than the Rails default, which is super useful, but just uses the browser default $.alert() box:
Specifically, I wanted to use a heavily-customized version of Twitter Bootstrap’s modals
I found this tutorial on LessEverything, “Customizing Confirmation Dialogs in Rails” that seemed to be just what I needed, but I ran into a couple of road blocks implementing the code…
First Road Block: Where do I put this stuff?
I’m a Rails newbie, so I’m sure this is a non-issue for more seasoned Rails developers, but after reading through this post I had pretty much no idea where to put this code. After a few Google queries and Stack Overflow threads, I uncovered the answer: controller-specific Coffee scripts.
I’m referring, of course, to the CoffeeScript (or JavaScript, if you don’t have the coffee-rails gem in your Gemfile) file that Rails automatically creates when you generate a Controller–files which I have, until this point, been pretty much just ignoring.
If you drop the code from the LessEverything blog post into a controller’s CoffeeScript file, its corresponding View files will automatically get much nicer delete confirm dialogs:
Nice! (And, as a personal added bonus, I got a nice introduction to CoffeeScript, which I had never used before and which is pretty awesome)
What about confirm dialogs for non-delete actions?
This worked pretty much out of the box for :delete methods, but I also wanted nicer confirm dialogs for other actions too:
And while the nicer, overridden modal box would still appear for these links, when I clicked the confirmation button nothing happened—the modal was simply dismissed and I found myself just staring at the page.
After some digging and debugging, I found that the issue came to this portion of the LessEverything snippets:
Basically, for the :delete methods, both of these commands—remove the “data-attribute” from the link, then click the link—were running.
For non-delete methods, like my reset link above, only the first command was running. The “data-attribute” was being removed, but then the link wasn’t being clicked.
The way I got around this was to mark my non-delete methods (again, in this example reset links) with an identifying class, “reset-link”:
And then I customized the $.rails.confirmed method to treat links with a “reset-link” class differently:
And voila! Now both my :delete links and my non-delete links would work as expected, with more polished HTML confirmation modals.
Avoiding User Experience Drag With Invisible Design Solutions
On a project I’m working on, there’s a specific form that, for business logic reasons, depends on one of the fields’ values beginning with a forward-slash:
In order to enforce this requirement, the form used to come equipped with validation rules that would kick the user back with an error if they tried to submit the form without a leading slash.
This experience was quite jarring…especially considering the fact that, at first, there was no warning or instruction or otherwise any way for the user to know that they were expected to start that field with a leading slash.
As the UX designer on this gig, this is, of course, my problem to solve. And the low-hanging fruit that I’m sure we all see at this point would be to add some helper or explanation text…
But as far as design solutions go, this didn’t feel great. Surely, this could be done better.
User Experience Drag
We should always be sensitive to the fact that our users have only a finite amount of time, energy, and effort they’re willing to spend with our products and apps. Anytime we require them to learn something new, pick up a new skill (or surprise them with an unpredictable validation clause…), or even just think about something differently than they normally do, we spend some of those finite resources and exhaust the user, just a little bit.
One way to think of this that I find useful is we create drag for the user.
The more drag we create–either by forcing the user to learn new things or by stranding them in frustrating, incomprehensible UI’s and user experiences–the more resistance we build between our product and the user. The more drag we create, the less the user will want to use our product, and the less useful and valuable it will become.
You don’t want to create drag. Ever, if you can help it.
Therefore, anytime you start to design instructions, or craft helper text, or in any way train the user to do anything at all that may deviate from their natural, intuitive behavior, you should stop yourself and think:
“Do I really need to teach the user something new in order for this to work?”
“Is this a worthwhile way to spend my user’s finite cognitive resources?”
“Am I creating drag for my user when I could be solving this problem in some other way? Some other way that, ideally, doesn’t even require the user to be aware of the solution?”
Many of the Best UX Solutions are Invisible
So, simply adding helper text to my form and forcing the user to learn that they need to start with a leading slash wasn’t cutting it. And even solutions like loading the form with a slash in the field, or using an input mask, still didn’t feel right–even those forced the user to be aware of the field’s requirements. And even being aware of the requirement forces them to spend some of their cognitive resources.
The ideal solution in this case was not to teach the user how to use the form…but to teach the form how to respond to the user.
So instead of changing a single thing on the front end–instead of moving a single pixel, or loading a single JS library, or dropping in a single letter of help text–I re-wrote the validation rules of the form so that it paid attention to whether or not the user started the value with a slash.
If the user didn’t start with a leading slash, instead of kicking the user back with an error, the form appended the slash to the beginning of the value itself.
And if the user did naturally think to add a leading slash, the form simply accepted the value and moved the user along on their journey.
This was a perfect solution in this case because knowing that this field needs to begin with a slash character is not a business-critical feature or component of the over-arching product. The only thing learning this requirement helps a user do is fill out this one form. So it’s much better to simply build out the form so that it’s smart enough to adapt to the user’s behavior, and save up the user’s cognitive resources so they can be spent on the other parts of the product that really require training.
Any time you set out to train or teach the user how to do something in your app, stop and scrutinize that thinking. Does the user really need to know this? Will learning this slow them down? Could I handle all of the possible scenarios that could happen here with the technology?
What you’ll find is that many of the best UX solutions are indeed invisible, and that the more of those kinds of solutions you implement, the more usable your applications and products will become. And, of course, the more your users will love using them.
SASS Mixin to Help You Build CSS-Triangles
I find myself constantly using Chris Coyier’s technique to build triangle shapes using only CSS, so I thought it’d be a good idea to add a SASS mixin to my Starter Kit to handle the heavy lifting.
I’m sure this a problem that’s already been solved elsewhere, but oh well. This mixin is easy to use and makes beautiful triangles. Here’s the mixin:
The mixin accepts three arguments:
- $color, which defines the color of the arrow. Defaults to #000
- $size, the size of the arrow. Defaults to 5px
- $direction, the direction the arrow points. Defaults to up.
Using it is easy. To point a hideously blue, 20px arrow to the right, in your SASS sheets you simply write…
If you decide you want to point it the arrow upwards instead…
And that’s it!
If nothing else, this will save me the time I take to pull up CSS-tricks every time I want to use one of the arrows. Hope you find it useful.
Some blatant gushing about why it's awesome to work at a "charitable organization" that will do anything for its customers
Just stumbled on to this short Slate article from a few months back:
…Amazon, as best I can tell, is a charitable organization being run by elements of the investment community for the benefit of consumers…Amazon sells things to people at prices that seem impossible because it actually is impossible to make money that way. And the competitive pressure of needing to square off against Amazon cuts profit margins at other companies, thus benefiting people who don’t even buy anything from Amazon.
I’m more than happy to confirm as an inside resource: Amazon, as a company, is entirely run on the principle of doing everything we can for the customer. Even at the expense of our own profits, if that’s what it takes.
We’ll literally do everything in our power to reduce prices, or offer literally every damn product we can get our hands on, or create some new product or service that we think our customers want or would benefit from.
Our business model and success is founded on genuinely obsessing over our customers.
It’s a pretty awesome environment for a designer, to be honest.
Compromise and the Design Process, Part 1
Designers tend to have an, ahem, slightly antagonistic attitude toward the very idea of compromise.
Indeed, some see compromise in the design process as an indication of failure—a red flag that signals the designer has failed to properly defend the work, and is now standing by helpless as the precious, pixel-perfect, ideal design-work is watered-down, Frankenstein’ed, design-by-committee’d.
This kind of thinking is at best ridiculous and immature—and at worst unhealthy and destructive, both on a personal and professional level.
Before talking a bit about why compromise is a perfectly natural and healthy part of any design process—and one that you should not feel ashamed about—let’s talk a bit about what a compromise actually is.
Compromise and the process of purchasing an iPhone.
Let’s look at an extremely common, frequently-occuring compromise—one that takes place countless times per day. One that many of us have engaged in several times. The act of buying an iPhone.
On a high-level, there are two parties involved in this compromise: the customer and Apple. There are two key items traded: money and an iPhone.
From the perspective of the customer, what’s the worst part of that transaction? The part that, if at all possible, they would be happy to avoid? Of course, giving Apple their money.
And from the perspective of Apple, what’s the worst part? The part that Apple would be happy to avoid, if at all possible? Yep, giving the customer the iPhone.
If there was no compromise involved, one of two things would happen, depending on who held the power in the relationship: either the customer would get an iPhone for free, or Apple would just take the customer’s money and give them nothing in return.
Of course, we have laws in place to prevent either of those scenarios from taking place. Both parties, then, are bound by law to compromise in this transaction.
Compromises are a part of life.
Compromises, and the act of compromising, are so deeply embedded into every possible crevice of your life that you could never possibly hope to escape them. From commerce to deciding what to have for dinner (What do I want to eat? What does my significant other want to eat? How much money do I have to spend on eating tonight?), you are almost always engaged in a perpetual cycle of compromise, negotiation, and resolution.
So why, then, is there such a pervasive stigma of shame surrounding the concept of compromise when it comes to design work? I’ll ramble about that a bit more in the next post.
Detect mobile device orientation change with jQuery
It’s super easy:
In Rails 3, redirect a logged in user from the home page to another page
Just drop a snippet like this into your controller:
Here’s some more info on redirect_to.
The more I get to know Rails, the more I love it.
Sweet SASS function to convert PX to EM
Ever since reading Trent Walton’s post “Flexible Foundations,” I’ve felt a bit uncomfortable about (and a little ashamed of) all the px-based CSS I write.
I want to write ems—really, I do—but it’s hard to think purely in em’s when design tools like Fireworks primarily on pixel-based grids. There are cool sites out there that you with the tricky math, but it’s kind of difficult to get a good flow going when you’re constantly tabbing between your SASS/CSS sheet, the site or app you’re working on, and some other tool.
Enter this awesome Gist by Ian Young featuring a super-useful SASS function:
This function does the conversion for you, so instead of using a separate tool and throwing off the whole flow of your coding, you just write font-size: em(18px) or padding: 0 em(10px) write into your SASS sheets.
I like .SASS syntax more than .SCSS, so I forked Ian’s snippet and tweaked it:
Dreamworks lays off hundreds of employees; CEO Katzenberg blames Rise of the Guardians
Dreamworlds Animation recently announced plans to layoff over 350 employees from its animation division, with a large chunk of that number coming from production employees.
Dreamworks CEO Jeffrey Katzenberg:
“‘Guardians’ was the first movie of ours, after 17 in a row, that didn’t work. When that happens, it really makes you rethink everything.”
Re-read that quote, and this time pay attention to the way the company’s CEO indirectly punts the blame for over 300 people losing their jobs and places it squarely on the shoulders of his own employees—specifically the staff behind Rise of the Guardians.
Think about how that would make you feel if you were any of the hundreds of people who poured blood, sweat, and tears into the production of that movie. I doubt it would leave you feeling particularly motivated or inspired.
If Katzenberg’s quote doesn’t strike you as particularly distasteful, turn back the clock 70 years and consider the fact that many of Walt Disney’s early animated films—films that Walt himself cared for and treasured very deeply—were box-office bombs.
Pinocchio, the studio’s second release, brought it only half of what it cost to make. Bambi released in the red , and Fantasia almost ruined the company—it had to be re-released multiple times in order to recoup costs.
And yet, Disney—who paid some of his animators more than he paid himself—never blamed the studio’s financial problems on his own employees.
With this kind of “leadership,” Dreamworks Animation will always be playing catch-up to Disney and Pixar—even with the occasional gem like How to Train Your Dragon and Kung Fu Panda 2.
"If a tree falls in the forest and no one's around to hear it, does it make a sound?"
I used to be pretty mystified by this saying, perhaps because I was thinking about it too literally. Of course anything falling makes a sound. The presence of a person doesn’t alter the laws of the physical world.. What a dumb thing to say.
Over the last year, however, I’ve begun to realize the true meaning—and importance—of this saying. Once could modify it into a much less catchy but more obvious version:
If a tree falls in the forest and no one’s around to document it, will anyone ever know that it happened?
If there was no Wordpress.org to tell people about Wordpress and teach them how to use it, would it be powering 60 Million+ web sites ?
If David Heinemeier Hansson had kept his nifty little development framework to himself instead of releasing it to the public and writing documentation for it, would it have ever had such a significant impact on the way that developers build web applications?
Turn that notion around to your own work. If you do incredible, valuable work for a client but never write release a case study about it, how will anyone know? If you’re an in-house designer and your design generates (or saves) millions of dollars for the company, but you neglect to document and disseminate this information, how will anyone ever know the true significance of your contribution?
Write. That’s the answer, that one word: write. You have to. We all do.
