When we sat down to write Khan Academy’s company values in 2010, “shipping beats perfection” flew out of Sal’s mouth before our butts hit the chairs.
It’s almost 3 years later. I have one-on-ones with teammates new and old who wanna talk more about what “shipping beats perfection” means. When outsiders happen across our development principles, “shipping beats perfection” becomes a lightning rod for anything from compliments and respect to accusations and fury. Our internal chat bot, the culture cow, drops “shipping beats perfection” as occasional chat room reminders (between MOOs).
At some point along the way when the phrase passed between my ears for the NNth time, my brain started believing it was invented by Google or Facebook (nope, that’s “move fast, break things”) or some other big boy with so much success that small fish like us just naturally start repeating whatever they say.
But now that I sit down to explain it, I’m googling for "shipping beats perfection" -khan and not finding much. And while I love its simplicity, “shipping beats perfection” contains subtlety in need of explanation.
We’re willing to be embarrassed about the things we haven’t done yet. Did you know our mobile app only offers video viewing, not the rest of our interactive platform? Did you know we don’t yet completely cover loops in our programming tutorials and challenges? Did you know we don’t have fully immersive simulations for teaching students physics?
Well, that’s all true, and quite embarrassing…for now. Would we go back in time to delay our mobile app’s launch until we figured out how to support the entire Khan Academy platform in an app? Absolutely not. Would we go back and undo the launch of Khan Academy programming because it doesn’t yet contain all of the content it really needs to? Absolutely not.
Is this the right philosophy for all products? Absolutely not. But educational content is so badly needed right now, and students are so hungry, that it’d be vain of us to think satisfying our own hunger for perfection is worth more than students’ needs. We’ll get to the complete mobile app. We’ll get to better coverage of computer programming content. Maybe we’ll even get to a fully immersive physics simulation. One day.
"Shipping beats perfection" doesn’t mean we should ship something we’re embarrassed of. Far from it. Would we ever put out physics content that felt crappy or didn’t help students learn? Absolutely not. Would we ever push out a mobile app with a frustrating video viewing experience? Absolutely not.
That would be embarrassment over what we have built. We don’t ship that.
I’m not taking advice from anybody who says ‘shipping beats perfection’…makes no sense anyway you slice it…stability, cache issues, etc.
— Concerned Redditor
Concerned Redditor, you need not worry your pretty little karma-filled head. We work hard for performance and stability, and, well, I don’t even know why I’m defending us against this statement because “shipping beats perfection” doesn’t in any way mean “ship crappy code.”
We code review literally every change and demand clear, understandable code. We docstring almost everything. Unit tests are popping up everywhere. If a code reviewer is confused by anything, she can simply say, “I’m having trouble understanding this part,” and it’s on the coder’s head to fix their code or documentation so things are clearer for future readers.
Perfection? Far from it. We can only afford this level of quality and still ship like crazy because we’re willing to be embarrassed about plenty of other things we haven’t gotten to yet.
Try this on for size.
You’re assigned the task of adding a brand new data report for teachers who need to know more about what their students have learned. No doubt in your mind, the report is going to be huge for them. Plus, you just did a design sprint, so you think you know exactly what needs building and how long it should take.
You crack your knuckles and wryly smile as you’re about to fire up your editor and do what you do best.
What’s the right move here? Refactor everything and fix it, even though you’ll lose a couple weeks at first? Curse crappy code like a sailor and just hack the new report right on top?
Spoiler alert: we don’t have enough information to answer. How badly do teachers need this? When? Is the “cruft” a bunch of edge cases that really do matter and shouldn’t be thrown away willy-nilly? Is it really old code genuinely in need of replacement?
Every coder faces this demon. The good ones take a step back, ask the above questions, and choose appropriately for each situation. The bad ones dogmatically believe “any code I’m around must be perfect” or, equally as bad, “just ship it.”
You won’t always know the answer, so here’s something for your toolbelt: “leave it better.” Can you liberally add TODOs around the old code, explaining what you will do to fix the situation soon, write your new code such that it demonstrates the new pattern you proudly suggest, and at the same time solve the pressing problem for teachers?.
If so, you left it better. You didn’t delay teachers’ needs for two weeks due to a refactor. You didn’t write lots of new code that you’re embarrassed of. Sure, you may need one messy hack to link your new pattern to the old code. That’s ok, you did so for a reason — for learners — and you added a helpful TODO and a Trello card just to be sure you’ll get back to it. Sure, you’re embarrassed that you didn’t do the full refactor yet. That’s ok, it’s the type of embarrassment — we just haven’t done the work yet — that we’re ok with.
If you’re the type who can’t “just” leave it better but must make code perfect, then you’re satisfying your own needs instead of learners’. You’re violating “shipping beats perfection.”
We’ve seen videos of Spanish-speaking students in South America using Khan Academy to learn math. If a UX guru walked into one of these classrooms in Peru and sat down next to a student, here’s what they’d report back:
And then at this point the UX guru’s head would a-splode.
We’ve seen videos of this happening (minus head a-splosion). Many of us have felt deep embarrassment in the past over our lack of translated versions of Khan Academy. But shipping beats perfection. For a long time we weren’t ready to tackle translations. We had to swallow our embarrassment and move forward with the English platform.
So should we be satisfied? Absolutely not. In about a week, a fully internationalized Spanish version of Khan Academy will be out of alpha. Will it be perfect? Far from it. Will 100% of our content translated? Absolutely not. Is our internationalization code free of TODOs and the occasional messy hack? Absolutely not.
Will our internationalization work leave our students, our product, our code quality, and hopefully our world in a better place than before? Absolutely.
You only have to watch one Spanish-speaking student joyfully use an English-only math resource to realize that high code quality and perfect UIs don’t matter for their own sake. They matter when they make a difference for learners. So we leave things better every day, are willing to be embarrassed about what we haven’t done, take pride in what we have, and ship great educational content to everybody as fast as we can.
Shipping beats perfection.
You know those puzzles with the matchsticks? Where you have some shape made out of ‘em and then you remove one and somehow, magically, you’re supposed to reform the original shape with one less matchstick?
"Remove one matchstick and rearrange the rest to reform the original shape."
(It’s a joke, it won’t work, don’t get nerd sniped.)
That’s the image that fills my brain when I try to make sure the right people are working on the right teams.
As a dev team scales it crosses the specialization barrier and forms internal teams. And every once in a rare while, for one reason or another, those teams need to be shifted around without disturbing the bigger picture.
Maybe a bunch of interns just left and certain teams are short-handed. Maybe somebody needs a team switch for their own personal sanity. Maybe a project that’d only been in the backs of your minds for the last two years is suddenly injected with a fever pitch of support, and you need to get things moving quickly on this difficult, previously unstaffed challenge or be remembered as the chump who was unwilling to disturb your oh-so-perfect team breakdown to make room for something new and far more important.
Doesn’t really matter how — it happens. It’s happening at Khan Academy right…wait for it…NOW due to our talented interns so rudely leaving us to finish school or something.
As we consider our priorities, I’ve heard the following from no less than 6 different teams:
We’re pretty stretched at the moment. Given how critical we are for the mission, our team needs more people.
For the first one or two, I was pretty optimistic. We could make a small change, help their team, and maintain the big picture. I was always kinda good at those matchstick puzzles.
Around request four or five I realized that the puzzle’s impossible. Need moar matchsticks. There’s no way we can give all the support we want to all the teams.
One terrible response to this would be to start growing so quickly that we abandon our hiring principles. That won’t be happening. We could also decide to have fewer teams slash do less stuff — a principle I almost always argue for — but Khan Academy has done a very good job recently defining our core mission and focusing on what matters. We don’t want to do any less.
Hence my conundrum. I was pacing around inside our office, then outside our office, then outside other people’s offices. At some point my pacing was interrupted by a lucky 1-on-1 with Craig. I bored him with my matchstick saga and he started laughing. He shared:
Eric Schmidt always said that if one of your teams isn’t asking for more people, something’s wrong. Teams should be able to do ~90% of what they want — not enough people to do everything, but not so few that they’re working unhealthily.
Relief washed over me in an awesome wave. It’s hard to listen to a team asking for help and not immediately help. Hearing that those asks are expected in a culture as respected as Google’s made me feel much better about Khan Academy’s current team breakdown.
The other day I was talking to David, learning whatever I could about how he works his VPEngineering magic over at Stack Exchange. Technical interviews came up. He was interested in new types of interview questions, not just the standard difficult programming challenges. He put it something like this:
We kinda get the whole “devs who can solve really hard technical problems” thing for free. We just hire the top Stack Overflow users.
Tough luck, I know.
Stack’s entire company is built around surfacing experts who offer great answers to hard questions. It’s only natural their own dev team will have first pick from — and deep insight into — a pool of hard problem solvers they’ve been obsessively building since day one. I don’t know if I’d call that “free” (probably actually costs millions of dollars), but it’s enviable.
It’s team culture — extremely valuable culture — that just sorta falls out of their mission.
"No, wait wait. I’m being serious for a second. I really love you guys."
That had me thinking when our discussion shifted to encouraging a culture of employee growth.
At Khan, our entire company is obsessively focused on helping students grow. Compassion for students who don’t know how to divide decimals yet. Belief that a kid struggling near the bottom of the class can soon be at the top if given the right mentoring. Embodiment of a growth mindset, the idea that talent is not simply fixed but can be developed through hard work.
We try to build this growth mindset into our product — and hopefully our users — all day e’ry day. It’s only natural we’d bring the same attitude into our team’s inner workings.
I think we do a uniquely good job growing our own developers. I’ve noticed this growth in certain individuals since starting at KA (personally seen the impostor syndrome banished from a talented developer’s head at least three times). But it was really drilled into me during the 1-on-1 talks I just had with each of this summer’s interns. They raved about how much they’re learning, and not just technically. I attribute this to the growth-focused attitudes of their mentors.
This enviable culture — extremely valuable culture — has just sorta fallen out of our mission.
I feel proud that we’re becoming a place that turns good devs into great devs and great devs into free electrons. But I should probably just feel lucky, because this attitude has been sewn into Khan Academy from the get-go.
You should probably apply for a Khan Academy internship.
I heard from a number of people who got value out of last year’s “How We Hackathon" post (that number, for those curious, is ‘3’). Here goes round two.
Just like before, our hackathons’ defining characteristics are: act like a healthy hacker, "hacking" means creating (not just coding), and everyone demos. Those looking for more details and a strong sedative can read my email below for more.
diff last_year this_year
From video lessons of hand-
assemblingsoldering a working computer to multiplayer math games to drastic improvements to Khan Academy’s internationalization pipeline to proofs of concept that we had, weeks ago, decided were problems so difficult we couldn’t tackle ‘em for another 6 months…I can’t simply summarize what I just saw demo’d a few hours ago. I’ll be blogging about my project, so here’s where I ever so subtly encourage others to do the same.
The amount of value — value that’ll make its way to real students — created since 4pm Friday has humbled and energized me. Thank you to everyone involved.
Feel free to borrow liberally from our planning communiqué:
Subject: Oh, the Features You’ll Hack!
You’ve heard all the whispers,
The rumors are true.
Two weekends from now,
Healthy Hackathon Part Deux.
You’ll think up some hacks. Consider the code.
About some you will say, “App Engine can’t handle that load.”
With your head full of brains and your scripts full of TODOs,
you’ve come to build what you want, to ship what you choose.
[Cue epic music.]
♤✌☭☂♘ (The Second) Khan Academy Healthy Hackathon. 7/19 - 7/21. ♘☂☭✌♤
I wasn’t here last year. WTF is a hackathon?
A chance to get together with teammates and build absolutely anything you want that’s connected to KA. You don’t have to be a coder! This is open to the entire company. We’re all about making, not just coding — and it doesn’t matter how wild or crazy your idea is.
Time to start letting your brain wander.
But WTF are we hacking on?
Anything related to KA. Below is a grabbag of examples, but the best ideas will come from you. Some of the following actually shipped last year.
- Make the next level of Tic-tac-toe-ception. “We need to go deeper.”
- Create your own tutorial full of videos and interactive content for learning sign language.
- Build a brand new exercise tool that teaches students how to read music, then release it on www.khanacademy.org/labs.
- Write a blog post about what you do at KA.
- Master hive enough to figure out if users from a specific non-US country have unique usage patterns, then blog about it.
- Make your first perseus or interactive math exercise.
- Release a widget that lets anyone add Khan Academy profile flair to their sites/blogs. Then blog about it.
- Learn any programming language you want by creating a wrapper for our API in said language. Chicken chicken chicken counts.
- Add an API to our CS platform that lets users play sounds.
- Add a banner to the top of every KA page that reads, “A personal appeal from Salman Khan” (spoiler: this was done last year).
- Ship a new careers page to the live site and a new build script that we’ve always wanted and a new embedded calculator for exercise users.
- Design a sweet team t-shirt and get it printed for everyone before the first night ends.
…or whatever. Here’s last year’s board full of ideas, things that were demo’d, and stuff that was shipped.
Just WTF is so different about our hackathon?
It’s not just for coders. Draw a mural on our walls. Fill in a spreadsheet. Moderate our discussion boards. Write a KA song. As long as you’re creating something that you can show off to the rest of the group, you’re hacking and you’re in.
It’s healthy. We reject the whole red bull, 3am, alcohol-powered images of hackathons. We invest in employees for the long-term. We’ll eat well and get sleep.
K. WTF am I supposed to do before Friday?
- Add your ideas to the Trello board
- Commit to an idea if you’re sold.
- Start lobbying others to join your team. We humbly suggest using this as a chance to work with people you don’t work with every day.
- Do not start hacking yet. Emily. Cheater.
WTF happened last year?
Well, for one, a shocking amount of cool stuff was built. For two, we wished we had a bit more time. So this one’s extended. For three, we needed another roaming hacker* or two to help out teams in need. If you’re interested in helping, please let me know.
Who TF is invited?
KA employees, past KA interns (lookin’ at you, David), and the whole KA Lite team.
WTF. Tell me more.
- You have to create something connected to Khan Academy.
- You have to demo or show off what you’ve created at the end of the hackathon.
- You have to act like a healthy hacker (sleep, eat good food).
- 4:00pm Friday the 19th: Start. Our office. We’ll kick off by letting idea owners pitch others in an attempt to get help.
- 11:45pm Friday: Everyone kicked out, doors locked. Get a healthy night’s sleep or we’ll steal your computers.
- 9:30am Saturday: Doors reopen.
- 11:45pm Saturday: Kicked out, doors locked.
- 9:30am Sunday: Doors reopen.
- 4:00pm Sunday: Pencils down. Keyboards disconnected. Every team will demo — expect for the whole thing to end around 6.
Dinner Friday night, lunch and dinner Saturday, and lunch Sunday. All included. Plus snackies the whole time.
We highly encourage hackers to work in teams, but try to keep team size limited to 3 or 4.
Judging rules will be shared when the hackathon starts. Prizes include at least one [redacted] and one [redacted]. Maybe two or there [redacted]s.
Do I have to attend? This is my weekend. FOR THE LOVE OF THE GODS LEAVE ME ALONE.
No problem. We believe the weekend is your time, and you should use it without hesitation. This is a completely optional healthy hackathon that just happens to instantly make all attendees ridiculously cool and good-looking. The choice is yours.
Ben, WTF, do you really only send emails all day?
Yes. But not during the hackathon. Not. during. the. hackathon.
* Last year Alpert was our “roaming hacker.” He went from team to team helping anybody who needed helping. Without him things probably would’ve devolved into a lord of the flies type situation, and quick. We need more roaming hackers this year. Email me.
The phrase “the App Engine way” is muttered around our office and wielded in our code reviews. As in, “Yeah, I know it’s counterintuitive, but that’s the App Engine way.”
It boils down to two principles about structuring data:
These aren’t obvious. It won’t be obvious to folks from SQL land that App Engine’s performance is tied so tightly to these ideas. It won’t be obvious that, since
JOINs don’t exist, it’s really easy to write a bunch of code that
1) loads a Monkey entity, 2) looks at Monkey.zoo_id, then 3) queries for the monkey's Zoo…and that that’s bad.
So we use “the App Engine way” to remind ourselves of these fuzzy guidelines and spread ‘em to newcomers.
Denormalize your data — as in your Notification models should have all the data necessary to render themselves. They shouldn’t just point to the thing that triggered a notification. As in whenever you’re sitting around wishing you could just
JOIN Zoo ON Zoo.id = Monkey.zoo_id you should actually be storing all of
Zoo's properties on each and every
Monkey. Got billions of
Monkeys? Who cares, copy the
Zoo data a billion times. “Storage is cheap” and all that.
Do lots of work on write to make reads fast — as in your
Post models should have their
monkey_count stored as properties on the Post itself. As in they should be updated every time a new
monkey is brought into this wonderful world. As in any time you’re sitting around googling for App Engine’s version of
AVG(), realize you should just be updating these aggregates every time they’re modified. As in whenever you write to a
Zoo entity, kick off a task to update all denormalized copies on your
Monkeys. Who cares if writes are a bit slower? This makes reads blazing fast.
A simple rule of thumb for knowing when you’re done:
If you really care about performance, you should be able to create all of the data queries for an entire web request just from incoming GET/POST data and the currently logged-in user’s properties — no query-to-get-the-data-for-another-query allowed.
This is the price of entry for access to one big, enormous, whopper of a benefit: you get a datastore with consistent read/write performance no matter how big your data set becomes. Have a query that returns 10 items from a set of 10,000? Relax knowing that after your company blows up in 6 months, you’ll get the exact same speed when pulling 10 items from a set of 10,000,000,000.
Recently two Khan Academy devs dropped into our team chat and said they were gonna use React to write a new feature. They even hinted that we may want to adopt it product-wide.
"The library is only a week old. It’s a brand new way of thinking about things. We’re the first to use it outside of Facebook. Heck, even the React devs were surprised to hear we’re using this in production!!!"
Great. And so my stodgy old brain entered Phase 1.
Here’s a sneak peek for you, brave proposer of new tech, inside the heads of your teammates.
Your job is to create a wormhole that transports a developer’s brain from Phase 1 to Phase 8 and then shove everyone on your team through it. Here’s how.
You’ll be seen as the clear owner of this decision. Nobody will want to waste their time agonizing over objections because you’ve already done that for them and provided answers.
Exactly how it should be.
…and you write this:
There’s a new JS library out called React. It’s promising but a bit scary. I’m playing with it for my new feature to try to learn more, and I think it’s possible we’ll want to use it everywhere in the future. Before making a team-wide decision like that, I scheduled a tech talk on Friday for us to discuss. I’m writing up a blog post before then that’ll teach others about the library and why I chose it. Read it, then bring all your concerns on Friday. I’ll have a plan for transitioning old code if we want to move forward, and if we decide this isn’t right for us I’ll undo my experiment.
…well. That’s a wormhole capable of transporting even your stodgiest, oldest teammates’ brains straight to “Phase 8: I thought of this and I am so brilliant.”
All the math formatting in this very serious example makes it hard to preview the content as it is being edited.
Our renderer, post-React, is on the left. A typical math editor’s preview is on the right. Ben Alpert and Joel Burget can tell you more about how they’re using React to make this so buttery. It’s absolutely brilliant. I’m just glad I thought of it.
Thanks go to Ben Alpert for draft-reading and to Fleetwood for bandana-wearing.
Giving public talks is one of those few activities (see: flying) that causes an enormous surge of nervous adrenaline to course through my body.*
But at the same time I love sharing Khan Academy’s work. So I’ve been trying to get better. Thankfully, we now have this great “grillmasters” event in our office where anybody on the team can practice any speech and get constructive feedback from everyone, including one of the best public speakers around.
Here’re the highlights of Sal’s speaking advice for me so far:
Heh. Both are big challenges for me, but I put these tips to the test recently while giving a talk about how Khan Academy uses data — with a focus on mistakes we’ve made along the way — and ended up having a blast. If you watch the video you’ll see that I fail miserably at the smiling thing. But I’m getting a bit better at not speeding through my speech at a million words a minute for fear of wasting somebody’s precious time.
Still a long way to go. But I relish the fact that public speaking gives me a chance to be uncomfortable. Feels healthy.
The video of my dog was the talk’s biggest hit.
In case you’re preparing for a talk and in the same boat, I’m super grateful for these resources: What happens to our brains when we have stage fright, Slide Design for Developers, and Scott Hanselman’s Speaking Hacks.
Better yet, if you have tips, I’m all ears.
* Scott Hanselman is an inspiration in many ways. In this case I’m thanking him for his openness about being a type I diabetic — like me. The pre-speech adrenaline I refer to above causes my blood sugar to spike wildly. I only drank water the morning before my last speech, yet my blood sugar shot from ~100 mg/dl to 380+ in the minutes before I went on stage. This can have frustrating effects on your brain and body. Scott’s example as a terrific speaker and openness about being diabetic (he’s checked his blood sugar on stage before) helps and inspires me to be more open.
Our dev team's grown to twenty-three and when the summer intern zenith hits we'll be — this is weird to type — forty for a few frightening days.
My biggest personal challenge now, by far: How do you stay connected to a product amidst all this scary m͓͇̘̗a̴̹̠̜̝͖̘n̩͙̘͙̫ͅa̬͙̖̬͍̦͔g͓̼͈͇̙i̪̺̘̙̻͘n͕̠̰̦̗g̗? Do you launch the damn editor? Write a single line of code?
I’ve been trying to squeeze every last bit of advice out of role-models I respect. I’m seeking stories from folks who’ve successfully navigated these waters. From personally writing tons of code in v1 to scaling and managing teams who then receive profuse apologies for all those v1 hacks. If this is you, plz send tips.
Here’re the various mentor voices in my head so far.
You must stop coding. But you must not stop coding. Stay very connected to your product. Make mockups and decisions and docs. Scale your team. Intimately know your tech and your tools. Don’t get out-of-date. Be a coder, but don’t waste time in the code.
You absolutely without a doubt need to keep coding, but under no circumstances should you be coding.
Got it. ✔ Chhhheck!
As confusing as that seems, there is solid agreement for how a technical manager should spend, say, 85% of her time. Scaling, recruiting, empowering, refining some teams’ focus, blah blah blah BLAH we’ve all heard it. Everybody agrees.
It’s the other 15% of the day that’s up for debate. This is that short bit of time when you do something creative that magically keeps you tied to your product and on top of your tech stack and immunized against pointy-haired-boss disease. Some suggest mockups, some suggest small production bug fixes, some suggest adding unit tests, some suggest writing code that you never intend to check in.
There’s leeway here, so for anybody else who’s trying to figure it out, here’s how I’ve chosen to spend my intentionally non-managerial time.
Rands’ Technicality is the authoritative piece on this search for maker/manager balance. He opens with “Stop coding." By the end he commands, "Don’t stop developing.”
What’s clear is these waters are murky. Any good technical manager must go through the difficult transition from coding to spending almost their entire day empowering smarter teammates. But how you maintain that certain je ne sais quoi that separates you from the non-technical manager you never want to be is a pretty personal choice.
Me? I have to launch the damn editor. Just for 30 minutes. Not to code, but to code a single line.
Heard a bit of an interview with Dick Costolo while driving home. He was telling the story of why he started his “Managing at Twitter” course that he personally teaches to all new managers. It went something like so:
An engineer came up to me who had recently switched from one Twitter dev team to another.
He said, “My old manager used to hold 1:1 meetings with me. My new one doesn’t believe in them. Which is it? Should I be having 1:1 meetings with my manager at Twitter?”
Supposedly this kicked off a wave of realizations in Dick’s head about all the inconsistencies in Twitter’s management styles. He wanted to fix the problem, started his “Managing at Twitter” course, and you’d have to ask some manager at Twitter what happened next because how the hell would I know if it’s working.
Working on v1.1 of “Managing at Twitter” that I teach to managers at Twitter. - thought it would end up being a 2hr class & it’s 6 hours.
The story did strike a chord with me. As Khan Academy’s pool of new mentors grows while interns simultaneously flood in the door (13 confirmed so far this summer, join up), it feels healthy to head off any mentorship inconsistencies at the pass.
I want simple and uncharacteristically terse guidelines for Khan Academy mentors. Here goes.
Mentorship is nuanced, and the above is purposefully far from exhaustive. If we’re gonna have the same old shockingly high expectations for mentorship quality that we had when we were a much smaller team (we do!). we’ll need to keep building artifacts like the above for our growing team (we just did!).
The hover effects on Amazon’s big ‘ole “Shop by Department” mega dropdown are super fast. Look’it how quick each submenu fills in as your mouse moves down the list:
See the delay? You need that, because otherwise when you try to move your mouse from the main menu to the submenu, the submenu will disappear out from under you like some sort of sick, unwinnable game of whack-a-mole. Enjoy this example from bootstrap’s dropdown menus:
I love bootstrap, don’t get it twisted. Just a good example of submenu frustration.
It’s easy to move the cursor from Amazon’s main dropdown to its submenus. You won’t run into the bootstrap bug. They get away with this by detecting the direction of the cursor’s path.
If the cursor moves into the blue triangle the currently displayed submenu will stay open for just a bit longer.
At every position of the cursor you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their cursor into the currently displayed submenu. Amazon uses this for a nice effect. As long as the cursor stays within that blue triangle the current submenu will stay open. It doesn’t matter if the cursor hovers over “Appstore for Android” momentarily — the user is probably heading toward “Learn more about Cloud Drive.”
And if the cursor goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.
So if you’re as geeky as me and think something this trivial is cool, I made a jQuery plugin that fires events when detecting this sort of directional menu aiming: jQuery-menu-aim. We’re using it in the new Khan Academy “Learn” menu:
I think it feels snappy. I’m not ashamed to copy Amazon. I’m sure this problem was solved years and years ago, forgotten, rediscovered, solved again, forgotten, rediscovered, solved again.
If anyone else on the planet ends up finding a use for jQuery-menu-aim, I’d be grateful to know what you think.
Thanks go to Ben Alpert for helping me understand the linear algebra / cross-product magic Amazon uses to detect movement inside the “blue triangle.” I ended up going w/ a cruder slope-based approach, mostly b/c I’ve lost all intuitive understanding of linear algebra. Sad. Need to watch more KA videos.