So, we just launched an update to the Structure Sensor homepage, and it features some neat HTML5 / CSS3 tech. I’m pretty happy with it. It required me to learn a few things, which I’ll hopefully have time to write about here soon.
Christopher Buecheler on Penny Arcade’s really sad job posting earlier this week:
You don’t want that job. There is no upside to taking it. You’ll be worked like a dog and paid like shit while you’re doing it, while Khoo, Krahulik, and Holkins continue cashing their trade show checks.
Robert Khoo is a brilliant businessman, and such businessmen excel by finding the sucker and exploiting him or her.
Don’t be that sucker.
Never be that sucker.
Short answer: No. Long answer: No, but nobody takes advice like this no matter how good it is.
This week I’ve officially accepted a position with Occipital, helping them bring their kickass computer vision research and products to the web. You may know them from their app, 360 Panorama, which is found on most iPad demo units in Apple stores. They also created Red Laser, which is now owned by eBay.
What Aaron Swartz called “All the good ideas I’ve heard in one place,” and it is chock full of them. Required reading for anyone who builds software, hires people who do, or manages them. Much of the advice can be applied to just about any profession, though.
While replying to a job posting, I started writing this little manifesto of sorts as a mission statement for myself. After kicking it around a little with my good friend Jesper of Waffle Software, I felt I should open it up to the world for criticism, additions, and discussion. The format and content owes much to Dieter Rams’ 10 Principles Of Good Design.
Good Code is simple. It should be easy to understand for anyone who has to work on it.
Good Code is instructive. Anyone with a similar level of expertise should be able to understand how to keep building on the code.
Good Code is clear. Functions and variables should be named simply and descriptively. They should exist in a logical place in the source.
Good Code is generic. Common functions and elements can be used in future projects, or improved and applied to older ones. Projects are simple and more easily maintainable.
Good Code is specific. It solves only the problems it needs to.
I’m genuinely interested in feedback on this. Reply on your blog, tumblr or tweet me.
A new tumblr created by Me, available from now: The Details Are Everything, sifting the user interfaces and experiences I come into contact with in daily life. It is A) An excuse to write more about semi-work-involved things and B) something I’ve been threatening to do for long enough that I needed to either start it, or shut up.
Say I’m building a website that deals with data from other websites (social and professional networks, etc), and I want users to be able to enter in their existing profile info into of the application. I can’t just ask for their current username (e.g.
http://facebook.com/<yourname>), because some of these websites do not have very friendly URLs (e.g.
http://www.spoke.com/info/<somecharacters>/<yourname>) and these may confuse the user. Our mock-up implementation looks like this:
In the example above, “Sign Up For” send the user to the specified site’s sign up page, and the form element is their ID. It changes based on the site in question, and I don’t think it quite works. What troubles me most (I’m not in love with it being overlaid on the text) is the language, but none of it is something I can’t live without. “Finish this URL” makes it sound like a game, or look like a CAPTCHA, neither of which is what we want. So, UI/UX/Usability gurus: How would you do it? Comments are open.
And a weird thing happened.
With no planning, we all started acting as if we were people in a real office. Almost immediately we began to adopt characters and send officious announcements. Soon we were referring to characters in the office who didn’t exist in real life.