i’ve been a fan of austin kleon’s work for a few years now, and i was eager to get my hands on his latest book, “steal like an artist”. billed as a “manifesto for creativity in the digital age”, it’s chock full of great quotes, illustrations, and advice on how to follow your interests and embrace your influences. and though the title says “artist”, the material inside is applicable to any medium. it’s perfect for creatively-frustrated creative types (which i know many of you are), and i loved it so much that i want to give you a copy!
what you’ll get
your very own copy of austin kleon’s “steal like an artist”, shipped anywhere in the world, at no cost to you.
the rules
you have until may 1st to enter.
every reblog is considered one entry (likes don’t count, nor do replies).
i’ll use random.org to choose three winners.
keep your inbox open so i can notify you if you win. if a winner doesn’t respond within 48 hours, a new one will be chosen.good luck!
p.s. if giveaways aren’t your thing, you can always pick up a copy on amazon.
p.p.s. this giveaway is not affiliated with or endorsed by tumblr or my employer, new york media.
Loading...
Progress?
So anyway, I haven’t done much on my webapp lately, but now I’ve decided to pull my finger out. I originally started playing around with Google AppEngine for the back-end, but I realized a couple of things.
First, I’m not going to get very far, nor learn very much, just by copying and tweaking Google’s example code.
Second, using AppEngine ties you in to Google. You can’t easily move elsewhere. So I figured I’d be better off not going that route.
So I’ve decided to take a step back and refresh my programming “skills”. On the recommendation of my friend Idan, I’m working my way through Learn Python the Hard Way. Which I’m rather enjoying. It’s not really a Python book. It’s more like an introductory programming book that happens to use Python.
We’ll see where it leads…
Loading...
Bookmarklet, Part II
That bookmarklet is shaping up quite nicely. Shame it doesn’t actually do anything yet :)
Loading...
Bookmarklets
Woot! I made my first bookmarklet that actually works! It’s small and doesn’t do much, but it does something.
Loading...
Making
I want to make something. I have an idea and I want to bring it to fruition. To design it, then build it. All on my own. Right now, I can’t do it. Not all of it. There are too many things I don’t know yet. But I know enough to get started. I can design it. I can code the front end. I trust that I’ll be able to figure out the Javascript.
I don’t have a clue about the back end. Not yet. How to set up a database, handle requests, query the database, write to it. But I’ll learn.
So what is this thing I want to build? It’s something that I want, for me. It’s like Instapaper or Read It Later, but for people who lack self-discipline. Those apps are great, but they have one limitation—they have no limits. I toss stuff into Instapaper willy-nilly, knowing deep down that I will never have time to read all of it (and maybe not any of it).
It has become a bottomless pit, sitting there, being intimidating. I now have Instapaper guilt. Guilt about all those important articles that I should have read but haven’t. It’s become like a second inbox.
My app will be different. If Instapaper and Read It Later are giant backpacks that always have space for more stuff, my app will be a carry-on bag. You can put a reasonable number of essentials in there, but when it’s full, it’s full. If you want to put something else in, you’ll have to take something else out. That way, you’ll have to be very judicious about what you put in there in the first place.
Maybe it sounds like a daft idea to you. Fine. No problem. But it doesn’t sound daft to me. And maybe there are other people out there who will find it useful.
Time will tell.
Loading...
martinpolley.com
I finally got round to registering martinpolley.com. For now, it just redirects here. Maybe I’ll do something interesting with it at some point. Let’s just say that I’m not holding my breath…
Loading...
The Power of Personalization (or not…)
My wife recently got a new phone. She said she didn’t really need an iPhone, so she went for an LG Cookie Plus. It’s a nice looking phone, with a decent-sized touch screen and quite a slim casing.
I played around with a bit and found it incredibly frustrating. The touch screen isn’t as responsive as the iPhone’s. Swiping is as likely to move something as it is to do what you actually want it to do. In lists, it is way too easy to select something when you want to scroll. Etc.
My wife said she wanted to send it back and go back to using her old Sony-Ericsson candybar phone.
But then a funny thing. She changed the wallpaper. She changed the background color from black to white. She changed the icon set from the default iPhone-like one to one that looked hand-drawn.
And suddenly the phone wasn’t so bad after all.
What happened here? A couple of things. First, she had made the phone her own. And maybe because of this, she was more willing to give it a chance.
Second (and I think, more importantly) the phone did not seem to take itself so seriously any more. Instead of being a vastly inferior iPhone wannabe, it was something else. It had stopped trying to be something it very obviously was not.
It was suddenly more honest. It’s just a shame that it wasnt like that from the start.
Loading...
Do Tools Matter?
Michael Angeles has an interesting post over at konigi.com about how our tools are not important.
“Don’t let anyone tell you that the tools you choose are wrong or inappropriate. Find the right design and keep winning.”
This got retweeted a lot. I read it and found myself agreeing. I even retweeted it myself. But since then I have been thinking about this a fair bit. And now I’m not so sure.
I think he’s missing something by only talking about one side of the tool question. The side that deals with working through a design. As he writes, “There are no good or bad tools for finding the right design.” But there is another side to this. And that is concerned with what we do with the things we create using our tools.
And there I think there are not insignificant differences in fit between the actual deliverable and the thing we want it to do for us. As Bill Buxton has said on many occasions “Everything is best for something and worst for something else.” And we use the deliverables that we create for several different things: To show to our designer colleagues for the purposes of collaboration and critique. To show to stakeholders, for the purpose of getting buy-in. To share with our developer colleagues so that they will know what to build at the required level of detail.
A wireframe is good for working with design colleagues. A video walkthrough may be the best thing to show to stakeholders. And a high-fidelity HTML prototype may be better for communicating to developers than an annotated wireframe.
Maybe I’m stating the obvious here. What do you think?
Loading...
Loading...