An already well-documented issue is that the cmd key triggers different key codes depending on the browser. In Firefox, the key code for cmd is 224, in Opera it’s 17, and Webkit browsers (Chrome and Safari) make a distinction between the left cmd key, for which the key code is 91, and the right cmd key, for which the key code is 93.
This inconsistency is not that bad, especially if you consider that all modern browsers agree that
event.metaKey refers to the cmd key.
Which leads us to Issue 2.
.metaKeynot available in the
When the cmd key is released, which is when the
keyup event is fired, the
metaKey property of the
event object cannot be used: metaKey becomes purely and simply invisible. If you want to work with the cmd key in the scope of a
keyup event (which is useful if you need to count the number of keys simultaneously pressed), you will have to first figure out which key code the cmd key triggered when the
keydown event was fired (those key codes are listed in “Issue 1″), and check that very key code when the
keyup event fires.
You’ll have to admit it makes things quite complicated.
But it gets worse.
keyupevent put on hold for other keys
As soon as the cmd key is pressed, it takes all the attention of the
keyup event, which will purely and simply forget other keys exist. It is therefore impossible to count reliably how many keys are pressed at the same time as soon as the cmd key enters the equation, which is a big problem when you’re looking to capture complex key stroke combinations (many modifiers + many “regular” keys).
Those issues make it clear, in my humble opinion, that the command key shouldn’t be treated as just another modifier key, at least not yet. The
event.metaKey || event.ctrlKey pattern that is often used in keyboard-centric applications can therefore lead to unpleasant surprises, unless you’re just capturing combinations made of a series of modifiers accompanied by one “regular” key (which most keyboard shortcuts are made of).
For kDown, I took the decision to completely ignore the command key for the
whenDown methods as their very purpose is to monitor complex combinations (in a way, those methods consider that the command key is to a Mac what the Window key is to a PC). However, I decided to take the cmd key into account for the
whenShortcut methods, where only modifiers accompanied by one regular key are valid input to listen to (no need to count how many keys are simultaneously pressed).
Hopefully, future implementations will be more consistent with regard to the command key, as it indeed seems to be a logical UX choice to make it the equal of the
ctrlkey for Mac users.
Well, I feel kind of embarrassed, that’s for sure, because I sent many emails to the Pastry Box guests, took up their time, and it was all for nothing. I guess I don’t have to be, but I am. I’m disappointed, too: in all honesty, I thought the book would be funded in less than 48 hours. Really, I thought that’s how things would turn out. I believed that reaching my goal would be easy not due to delusions of grandeur, but because at $35 a book I would have needed approximately 500 backers to get the project rolling, which is truly nothing compared to the traffic the website generates on a daily basis. About that, yes, I’m disappointed. But about the project not becoming a book, about the fact that the campaign failed to reach its goal, no, I don’t feel bad. Oddly.
Here’s why, I guess.
Failure is a great starting point. When you have already seen many different projects fail in your life, you come to understand that failure is a source of creativity. I’m not trying to present things in any way differently to how they truly are, and nor am I attempting to hide my disappointment behind some forced, faked optimism: failure is the impossibility of seeing your intentions become reality, and it’s a very unpleasant outcome, especially since it usually means a lot of wasted time and energy. But when you look at it carefully, failure is also a very strong opportunity to find new and different ways to give those frustrated intentions a voice.
I realized the fundraising would not produce the desired result on the fourth day of the campaign. Many people had tweeted about the project, the Pastry Box project was receiving its usual fat load of traffic, and yet the number of people visiting Backified was very low. Extremely low. And I’m not talking about people landing on the campaign and bouncing back. And I’m not talking about people registering and then getting cold feet upon seeing that their credit card would be charged immediately (in Indiegogo fashion). I’m talking about simple, bare page loads: Backified has received very few visits. Unsurprisingly, the Pastry Box stats showed that only a handful of people clicked on the link to the campaign (which wasn’t what you would call a discreet link).
So, what does this mean?
Simply that our users are not interested in having a book containing the texts published on the website. Please let me pompously quote what I said on that matter in a .net interview dedicated to the Pastry Box project:
If more than one of your users requests a feature then you should try to add that feature. If readers of The Pastry Box request a book, I want that feature to have a chance to be included in the project (…) The funding campaign is a question to our audience: is the website enough or would they like us to seal its content in a paper version? I think it’s better to ask such questions through a full-fledged funding campaign rather than through a poll. At least you know where you stand. If it’s a ‘yes’, then the feature will be included (we’ll publish the book); if it’s a ‘no’, then we’ll stick to the digital version, which is quite awesome as it is. It’s worth a try, anyway.
Well, my question got a kind reply: “Let’s stick to the digital version.” If I count the number of emails I received in 2012 about the Pastry Box becoming a book and the number of people who backed the project, there is almost a match. So, the readers who wanted the website to become a book did not represent a “silent mass”. People are simply fine with the website as it is. The fact that the fundraising fell short of our goal in that regard isn’t really even a failure. Indeed, the website has received rave reviews and the traffic is growing exponentially. So, the Pastry Box is what you would call a “successful” venture, and the fact that the campaign failed to achieve its goal isn’t due to the project itself. Clearly, our users are not in need of a paper version of the Pastry Box project. Period.
Which leaves me with my motivations for turning the website into a book. Please let me quote myself a second time here:
Behind the idea of making The Pastry Box into a book lies a disturbing question: is the Internet ready to preserve content through time, through the ages? Unfortunately, the answer, at the moment, is ‘no’. (…) On a very personal level, I built The Pastry Box to be a legacy for the future, a door to a specific area of our day and age with a view to understanding it, dreaming about it, and reconstituting what it really is through details and anecdotes which, when put together, draw a precise, vivid landscape of an era, as opposed to the vague, always inaccurate myth coming times will retain. We can’t risk letting that content disappear into the abyss of digital production.
Here’s the big failure, the part of the whole thing that is so unpleasant, the part that hurts: I find myself with a publication which has a strong concept and great content, but whose form is a complete anti-pattern: how can you at once try to document a facet of your day and age to pass to future generations and accept that the result of this process a) lies in a single remote location (some server), b) is tied to a database that, by its nature, breaks content into smaller, often inconsistent pieces, and c) whose availability depends on one single person not forgetting to pay the hosting bills?
This is so wrong.
And… that’s exactly where creativity sets in.
If content preservation is not going to be achieved through a book, it will be achieved through other means. Because, I mean, when you have already seen many different projects fail in your life, and you’re still creating new stuff, you come to understand that there is a thing inside of you that doesn’t take failure as an acceptable conclusion.
So, on the fourth day of the campaign, I started asking myself the following question: “Which means is going to seal the Pastry Box content more safely than just a bunch of web pages whose content is obscurely spread across a remotely hosted database?”
There is no perfect answer to that question—even a book wasn’t a perfect answer—but I’ve already come up with a few ideas that have kept me very busy for the past few weeks. And I’m wondering why I didn’t start with those ideas in the first place.
And, when you have already seen many different projects fail in your life, you come to understand that it’s a damned good sign.
So, all in all, failure proves once again not to be a bad thing (although it is an utterly unpleasant experience). I wish the book had got funded, but it’s more interesting that it hasn’t. It forces me to open other doors, to find workarounds. To be more creative and get out of my comfort zone.
For keen ears, thuds are the sound of progress.]]>
It feels great. Rewarding. Really.
Don’t you ever forget that.
How does an idea take shape? Which ideas do we nip in the bud because we deem them as “unfeasible”? We’ll consider those “unfeasible” ideas and why they are exactly what you’re looking for. I’ll explain why “unachievable” projects carry with them an infinite stock of creativity when you start trying to answer the following question: “Which projects should I create to find myself in a position where that unfeasible project becomes feasible?”
We’ll reflect on how a given project can lead to another project, which can lead to yet another project, which will eventually lead you to achieve something you thought could never be achieved, which opens even more doors. I will explain why thinking in terms of platforms is incredibly efficient and enlightening, and why this approach will get you much further than you originally expected and planned.
Building on Frank Chimero’s Proposed Creative Workflow, we’ll see why you should only green-light ideas that are satisfying both as a means and as an end. The risk with thinking in platforms is that you’ll create projects you don’t really believe in or don’t really like just as a means of starting another project you really want to do. We’ll reflect on why you will expose yourself to failure and burnout if you follow some cold, elaborate scheme instead of your gut, and what you will be missing if you don’t follow adequate creative ethics.
In this part, we’ll talk about expectations: yours, your contributors’, your coworkers’, and, finally, your users’. We’ll expand on why you don’t actually need to establish any expectations, and how your projects will in fact take care of everything for you as long as you remain smart enough to understand their potential and the personal fulfillment they have to provide.
In this part. we’ll reflect on collaborations and the almost unavoidable, and rewarding, loneliness of the beginnings. When you start building your stack/wall of projects while trying to answer the seminal question: “How can I find myself in the position of turning an “unfeasible” project into a “feasible” one?” it’s likely no one will trust you with their money or their time. Deal with it. Yourself. And get better at your craft.
How many times have you found yourself thinking that it would be great to contribute to a project you love? How many times have you actually tried to? Well, now that your first project has launched, you will need help, and there are many folks around the globe who’d love to work with you but for one reason or another won’t try to get in touch with you. We’ll learn how to find them and how to start collaborating with them.
We’ll think about “control” and “open-mindedness”. We’ll try to understand why saying “yes” to the ideas people involved in your projects come up with (even the ones you totally don’t beliebe in!) will lead you into new, unexpected territories which you will probably not be able to discover if you try to control everything.
Your projects, like the devil, will take a toll on you. You will find yourself sitting with friends and family, maybe at important junctures in your life or theirs, and you will suddenly notice that part of your mind is stuck somewhere else (composing the next email, pre-writing the next article, drawing up a complex to-do list and whatnot). We’ll talk about not feeling guilty about this, which often happens, and we’ll reflect on the methods and discipline which can prevent you from not giving enough of yourself to the world outside.]]>
$.fn.myjQueryPlugin = ...
What most jQuery plugins do is just use jQuery to do whatever they have to do, and for those plugins, extending
jQuery is not very helpful or meaningful.
Unless I specifically need to inject my plugins’ methods into jQuery, why should I tie my public API so tightly to jQuery? Consider the following ways to fire some blahblahblah plugin:
$("#some-div").blahblahblah(); blahblahblah.init( "#some-div" );
In terms of public API, the first line ties the blahblahblah plugin very tightly to jQuery, while the second line is “library agnostic”: it uses jQuery, but it doesn’t show.
When a plugin is released, it’s impossible to say what its lifespan is going to be, how successful it’s going to be, and how widespread across the internet it’s going to end up. Imagine you’re the owner of an incredibly successful piece of code. The way you coded your plugin, its public API (or to put it more simply, the lines of code that people type to use your plugin) is filtered through the prism of jQuery. And one day you want, for whatever reason, to untie yourself from any dependencies.
You’re going to have a hard time selling that idea to your users. Imagine telling them they now have to go through all the pieces of their own code to make it comply with your plugin’s new, “unleashed” API. Your fan base is quite literally going to melt down.
Whenever possible, it’s better to think in terms of composition|agreggation rather than extension. The looser the ties between pieces of software, the bigger the flexibility and the freedom of movement for the developer.
Off the top of my head, here are a few reasons why I don’t want my code to be too tightly tied to a library:
A vague acquaintance releases her own framework, and for strategic reasons I have to support her, because she has a friend that has a friend that my best friend kinda likes, and she might set up a date for him, and, you know, if I can help…
A new framework is released, with a new philosophy that fits my ethics better and an amazing offer to fix my bike for me for a whole year if I endorse it.
John Resig bumps into me just before I walk on stage to speak at a conference, and my glass of water spills all over my pants, and John doesn’t apologize. The crowd, obviously, giggles a lot when the curtain rises and I’m alone on stage.
Think about this before you start coding.]]>