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.

http://www.netmagazine.com/interviews/alex-duloz-pastry-box-project

Introduction

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?”

Thinking in Platforms

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.

A Workflow Ethic: Avoiding the Pitfalls of Platforming

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.

Your Expectations, and What Your Projects Have to Say about Them

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.

Getting started: The Probable Loneliness of the Beginnings

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.

Now there are people out there who want to help you: find them; talk to them.

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.

The Power of not Saying “No”.

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.

Be Ready to Give a Piece of Yourself to Your Projects, and Never Get It Back: How Not to Feel Bad About It.

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.

tag for a page title (or for a website’s title) and some considerations about HTML5’s content sectioning, the concept of outline has never really been debated (at least not as much as I’d have wished since there’s only one place where it really took place).

This state of affairs leaves me with a few questions, and cogitations, that I would like to present in this article, both to document my thoughts on the subject of outlines and, maybe, to go against a few preconceived ideas when it comes to what exactly tags should wrap.

A myth already in hashes: only one


tag per document

For some time, there was a belief amongst web developers that there should be only one


tag per document, and that it should hold the title of the page, or even the name of the website. Luckily, many people were smart enough to read the specs and understand the true meaning of the following lines:

There are six levels of headings in HTML with H1 as the most important and H6 as the least.

And they preached the good word.

I especially like what Jeremy has to say about it:

You can have multiple H1s in a document. This is not something new to HTML5. You have always been able to have multiple H1s in a document—shock, horror. I’ve met working professionals on the web who have thought for years that it was in the specification that you could only have one H1 in a document.

A point I’d like to make, though, is that it wouldn’t be completely wrong to use a


tag instead of, say,

to mark up the title of a project. It would only really make sense, though, if the potentiality of having more than one project name displayed on the same page exists, which is highly unlikely (but it is fortunately a widely accepted practice not to have more than one web site co-existing on a single web page).

The real reason why the


is a poor choice for holding the name of an application, or the title of a web page, is that the


tag will never have any siblings, unless you purposefully decide to break the tacit rule which states that at a given endpoint (understand “url”), you find one specific website, not two or more, and one specific page, not two or more.

Those considerations clear up an early misunderstanding about


–


tags and allow us to make a statement about using them correctly: the potentiality for a given tag to have siblings holding information of equal importance should exist. In an outline, indeed, much information of the same importance should be able to coexist, if not practically, at least theoretically. If you wrap some text around a tag and you cannot find a possibility for content that would bear the same , then you should question whether you’re using the right tag or not.

An outline shall outline… what, exactly?

This being clarified, we can move to a deeper subject: what exactly should the nature of the text wrapped around tags be? The specs state that “a heading element briefly describes the topic of the section it introduces”. Translation: a heading element is contextual, and not structural. The words “contextual” and “structural” are of prime of importance here, and are sufficiently subject to interpretation to let us reflect on them a little. The general belief, it seems, is that


–


tags should mark only bits of text directly related to the specific content of a given document. Those bits of text, therefore, should be different with each document, and highly topical. It doesn’t seem that the word “context” should be understood in any way other than in its “specificity” meaning/sense. Here’s a coding example which exemplifies a content-oriented outline:

Plant Earth
Countries
...
Oceans
...
The Moon
Countries
...
Oceans
...

What is not topical, what has no contextual specificity, still according to our disembodied general belief (with broad shoulders), are bits of texts that refer to the structure of a given document. Here’s a coding example which exemplifies a structure-oriented outline:

Banner
Navigation
Main Content
Articles
...
Author
...
Complementary
Resources
...
Related Posts
...
Contentinfo
Copright
Humans

This second approach is probably considered wrong by many developers. But in my opinion it’s actually not. Please allow me to try to convince the most sceptical among you. The origin of my belief lies in a close analysis of the word “context”, which we must, in a pleasant mise en abyme, put into its own context: that of an HTML document.

What is the “context” of a document?

The word “context” is not to be taken lightly, as it is key to the correct use of tags. The specs leave us hanging, though, when it comes to clarifying exactly how the word “topic” (“context”) should be understood:

A heading element briefly describes the topic of the section it introduces.

Anyone familiar with reading W3C’s specifications is no stranger to hermeneutics, the art of extracting the hidden meaning of a text, the craft of deploying one’s own subjectivity based on textual evidence.

So let’s be like Hermes for a minute and try to be interpreters of the message coming from above.

The word “topic”, as provided by the specs, could easily be applied to the second outline approach, the structure-oriented one. Why? Because titles such as “banner”, “complementary” and “content info” are semantically highly charged in the context of a web page; they are almost literally pouring with meaning. People know what to expect in sections named “main content” and “banner”, and such expectations have everything to do with content, and context.

Are the words “banner”, “main” or “complementary” part of the content itself? I would be hard-pressed to say so. Yet the particularly close relationship that structure and content have in HTML documents allows me to say that a structural outline doesn’t betray the contextual approach encouraged by the specs.

And, in all subjectivity, I consider it more meaningful than the content one. Here is why. Consider our content-oriented outline in the two following contexts:

Plant Earth
Countries
...
Oceans
...
The Moon
Countries
...
Oceans
...

Plant Earth
Countries
...
Oceans
...
The Moon
Countries
...
Oceans
...

The difference is so obvious that I barely dare state it: depending on where this content is laid out on the page, its importance, its meaning, its sense (semantics again), radically change. The idiosyncrasies of a web page play a pivotal role in my thinking, and such idiosyncrasies (what the user expects, how screen readers work, etc.), when put together with the purpose of an outline, simply make it quite clear that structure has a role to pay in HTML-related outlines, and cannot just be kept aside, as if it didn’t connote the content it wraps.

An HTML document is not a book, nor is it a magazine (where, by the way, structural outlines have become very popular in recent years). You have to put your hands down into everyday-life markup to understand what makes an outline a good outline, and you cannot just transpose theories that work for other mediums. Build projects, check their outlines, see which outlines lead you in the most direct way to the specific content your users may be looking for. Then tell me that structure has nothing to do with it.

Once the general structure of a document has been outlined, its content can be tackled. Outlines can only gain in clarity with a “from structure to content” approach.

And HTML5?

HTML5’s sectioning elements seem to give weight to my arguments. With HTML5, specific elements are used to create content portions in which tags can deploy themselves more loosely:

HTML5’s sectioning elements free tags from the sequence consistency (h + 1,2,3,4,5,6) otherwise expected from them. Indeed, the importance of tags is reset within each new sectioning element (for the current sectioning element) thanks to their ability to contribute to the outline of the document (hence the “sectioning”).

Interestingly, sectioning elements are quite explicitly referring to areas of a web page. Even though