Menu

Yearly Archives: 2013

As Kickstarter gets more popular, I’m seeing more lousy Kickstarters. Most of them get ruined because they break the fundamental rules implied by any Kickstarter project:

1. If you don’t meet the backing goal, this project will not happen.
2. If you do meet the backing goal, this project will happen.

In case they’re not obvious enough, an example:

The Furry Pink Car Example

Let’s say I built an absurdist art car, and I want to add furry pink seats in time for the next Burning Man. I have a good reason to want the new seats: riding in the car without them is uncomfortable enough that people complain loudly. However, I don’t have the funds to add them myself.

I have some rewards in mind: an exclusive video of the seats being installed, a ride in the car itself, and for top backers, your name painted on the passenger door.

I know there are plenty of people who would back my project, so I’m ready to go. How could I screw it up?

Remember: If the goal isn’t met, the project won’t happen.

Easy. I could state my project in broader terms than I’m actually funding. “Absurdist Art Car at Burning Man 2013!” My project video could talk all about the car, with a quick mention of how pink fluffy seats would be nice.

When potential backers read that title and watch that video, they’re left with a big question: “You already have this car. Why do you need more money?” From the project page (which is all they have to go on!) it sounds like the project will happen whether they back it or not.

I had this feeling about a recent space company that went the crowdfunding route. The rewards were the usual space-company merchandise, and the project boiled down to “Help us do what we’re already doing!” My contribution wasn’t going to make a difference, so I didn’t bother.

How could I fix it? Change my title to “Pink Fuzzy Seats: The Only Way To Travel” and describe the benefits (and unreasonable expense!) of the all-important seats. If the money doesn’t come through, the art car will be as uncomfortable as it was last year, so no rides for anyone!

Great! How could I screw that up, then?

Remember: If the goal is met, this project will happen.

Messing this up is more subtle, but a lot more common. There’s an assumption underlying my whole project, something I might completely miss by (correctly) stating the goal narrowly. Take a look: can you spot it?

That’s right: I need a working, drivable art car. The rewards require it, the seats are useless without it. If something happens to that car so that I can’t take it to Burning Man, then I’m on the hook to fix it.

WITHOUT asking for more money. That’s the really tough part. Going back to those fluffy-seat backers with a second Kickstarter (or IndieGoGo, or anything like it) seems natural, but it’s dead wrong. By asking for new funds to make an old project possible, I’m casting doubt on my ability to complete that project at all. Why would my backers throw good money after bad?

I often see this problem with films and other art projects, the kind that have lots of steps. (Writing, shooting, editing, post-production, distribution, aigh!) It’s natural to make the film the project, with backer rewards to match, but if you’re just funding the first steps you should only provide rewards from those steps. (A rough cut of the film, for example.) Don’t offer the whole film if you’re only funding part of it.

In my case, I’m resolving to keep the car running and get it to Burning Man, no matter what. It’s something I would have had to do anyway, but now my backers are relying on me to get the furry pink seats on the road.

Note that I’m not going to list “car breaking down” as one of the “risks” or “uncertainties” on the project page, either. If Burning Man is canceled, that’s an uncertainty. If faux pink fur melts in the Black Rock sun, that’s a risk. However, I’m pledging to do everything I can to get the car there, and it’s reasonable to expect me to deliver on that promise.

Sometimes I need to work out a rough calculation to check whether my idea of something science-fictiony has any basis in reality. It doesn’t need to be super-rigorous*, but close enough to tell if my conception is way off the mark.

In this case, I’ve been thinking about how it might feel to walk around a city on Mars. It’s likely to be mostly underground to help shield against radiation, but there should be as much daylight as possible to save energy. On Earth, that kind of daylighting comes from skylights, windows, and (my personal favorite) light tubes.

But what about on Mars? Mars is farther from the Sun than Earth is, so it gets less light on the surface, but how much less? Is walking down a Martian street destined to feel like a gloomy overcast day?

First I had to get a grip on how to measure daylight. An obvious comparison is solar radiation, measured in Watts per square meter. Depending on time of year, Mars gets between 1/3 and 1/2 as much solar radiation as Earth, because it’s about 50% farther from the Sun. That’s handy for figuring solar power output, but the human eye isn’t so linear.

Another way is illuminance, measured in lux. Though the exact conversion factor between solar radiation and lux is a bit tricky due to the eye’s reaction to different wavelengths, I gather that the relationship is linear. Thus, using some standard Earth values and scaling them:

on Earth

on Mars (min)

on Mars (max)

direct sunlight

110,000 lux

38,000 lux

55,000 lux

indirect daylight

20,000 lux

6,800? lux

10,000? lux

clear sunrise/sunset

400 lux

130 lux

200 lux

(I’m assuming that indirect daylight is scattered as well in Mars’s pink sky as it is in Earth’s blue. Something to check later.)

Filling in a few other Earthly values for comparison:

bright overcast

25,000 lux

dark overcast

10,000 lux

studio lighting

1000 lux

office lighting

500 lux

cloudy sunrise/sunset

40 lux

So it looks like daylight on Mars wouldn’t look too different from daylight on Earth. It’s orders of magnitude more light than during “golden hour” on Earth, which is plenty to get around by. It would probably feel like a partly-cloudy day, since there would be more light than even the brightest overcast day, with sharply-defined shadows.

For daylighting, this probably means that Martian interiors would need twice as many Solatubes to get the same level of illumination, but we’re still talking about a fraction of the available daylight. In other words, using Earth-style lighting techniques should keep a Martian city street from feeling gloomy.

*Note the use of Wikipedia sources. Kids, don’t use Wikipedia as a source if you want anyone to take you seriously.

It may surprise you to discover I still work with Facebook on a daily basis. I did leave Facebook as a user over three years ago, but wrangling the Graph API is still a core part of my job. (For the web developers among you: It’s like your relationship with Internet Explorer.)

Last week I was updating Measured Voice to match changes in the Facebook permissions dialog, and I noticed that the documentation said one of my permissions was now out of date:

“Facebook used to have a permission called publish_stream, publish_actions replaces it.”

In a fit of eagerness, I broke the first rule of API usage* and switched out publish_stream for publish_actions. However, it soon became obvious that the two weren’t equal. The auth tokens produced before and after my update were markedly different:

with publish_stream

Requested

Granted

manage_pages

→

manage_pages

read_insights

→

read_insights

user_about_me

→

user_about_me

user_status

→

user_status

publish_stream

→

publish_stream

→

publish_actions

→

video_upload

→

create_note

→

photo_upload

→

share_item

→

status_update

with publish_actions

Requested

Granted

manage_pages

→

manage_pages

read_insights

→

read_insights

user_about_me

→

user_about_me

user_status

→

user_status

publish_actions

→

publish_actions

Requesting publish_stream gave me publish_actions anyway, which makes sense if the two are being treated as equals, but it also gave me a whole passel of other permissions I hadn’t asked for. As it turns out, at least one of those permissions is still necessary to do what I need: post status updates and photos to a Facebook Page.

But which one? I checked the documentation again, and… well, none of them are documented at all. Not listed anywhere, not mentioned as deprecated, not anything. Huh. Some of them do sound like permissions I’d need (photo_upload and status_update, for example), but without documentation it’s just a guess.

It sounds like the documentation is ahead of the actual API development, and reflects some design goal instead. Or maybe this is (yet another) API bug. Either way, I’m going back to requesting publish_stream until they get their facts straight. It still works. (For now.)