Research provides the inspiration, guidance, and validation we need to design great products. From the personal (like interviewing users) to the analytical (like metrics) there’s a continuum of research skills that are essential for design teams. The most effective companies integrate this discipline into their culture and make research a habit.

Creative people are ones who are willing and able to metaphorically buy low and sell high in the realm of ideas. Buying low means pursuing ideas that are unknown or out of favor, but that have growth potential. Often, when these ideas are first presented, they encounter resistance. The creative individual persists in the face of this resistance, and eventually sells high, moving on to the next new, or unpopular, idea. In other words, such an individual acquires the creativity habit.

Think lightly of yourself and deeply of the world.

This little bit of wisdom was written in Dokkōdō (The Path of Aloneness), a book of 21 maxims on how to live life, written by the 17th century japanese samurai Miyamoto Musashi a week before he died. 

I also like “do not depend on a partial feelings” and “do not hold on to possessions you no longer need”.

(via stoweboyd)

(Source: heartbloodspirit, via keenancummings)

naveen:

a personal API
i’ve long been a follower of the quantified self – even back before we started calling it that and started building all this software behind it. when i was in graduate school, i remember thinking i wasn’t reading enough. so i made an effort to cut through many must-read books (75). in two years of school, i tracked (microsoft excel, as you do) each page read (21,278) and the number of days (622) and kept a running log of pages-per-day (34.21). i got my goal of 10,000 pages a year and, bonus!, i got through a few classics that still continue to be my favorite stories.
more recently, as i’ve gotten older, i started getting more interested in tracking my health and fitness. when we are young and in our twenties, we can get away with pretty much anything. but like everyone else, the older i get, the more i realize i only have one body – and that i should try to keep it tuned to get the most performance out of it. i started at first by writing my workouts down, and then trying out all types of digital trackers. one favorite tool that came out of this period was the withings scale: it allowed me to periodically keep track of trends in my weight and body composition and allowed me to think about big trends in my life that affected performance.
so far, i’ve used various tools and hacks over the years to collect this data. but i’ve long wanted it all in one place – or, at least, something to give me the illusion of ‘one place’. a dataset that is a single repository and view of my body as opposed to various silos of data scattered across different services and devices. of course, this requires that we all play along in some way and make our systems open and provide APIs for getting at this data. not only are we still in the early stages of building such self awareness software, but so too are we still some ways from designing the right data sets and figuring out ways to expose them to our users. i believe the openness of the latter is just as important as the first point and i think we still have some ways to go in that regard. (for example, on many of the services i’ve tried recently, i’ve had to cobble together and reverse engineer things to pull my own raw data out in some normalized form).
as a part of all these experiences, i’ve always been curious about the idea of a personal API – a ‘quantified naveen’ – that would expose all of the information i knew about myself in a clean, open document. i think i’ve wanted to do this because:
1) i wished to play with the idea of a ‘virtual me’ that’s entirely inside the machine;
2) the idea of a ‘published’, always-public me has intriguied me (we share our tweets and checkins and photos and music habits to a wide audience, so why not other types of behavior and habits as well?);
3) and i’ve been curious what one might be able to do with such a resource: will any of it be useful for research? might one create apps on top of me? or perhaps draw insights that i haven’t yet been able to see myself?
as a way to start this off, i’ve put up an API of such personal data. i’m calling it api.naveen. it currently exposes sleep, weight, steps, fuel/activity and checkins. i aim to keep adding to this list with a few more interesting ones as i think of them.
have a look: http://api.naveen.com/
drop me a note and let me know what else you’d like to see and what you end up doing with this. i welcome the start of a good discussion.
special thanks to: eric, for coining the term ‘personal API’; sameer, for help with the data layer.
  • Camera: Fujifilm X-Pro1
  • Aperture: f/1.4
  • Exposure: 1/20th
  • Focal Length: 37mm

naveen:

a personal API

i’ve long been a follower of the quantified self – even back before we started calling it that and started building all this software behind it. when i was in graduate school, i remember thinking i wasn’t reading enough. so i made an effort to cut through many must-read books (75). in two years of school, i tracked (microsoft excel, as you do) each page read (21,278) and the number of days (622) and kept a running log of pages-per-day (34.21). i got my goal of 10,000 pages a year and, bonus!, i got through a few classics that still continue to be my favorite stories.

more recently, as i’ve gotten older, i started getting more interested in tracking my health and fitness. when we are young and in our twenties, we can get away with pretty much anything. but like everyone else, the older i get, the more i realize i only have one body – and that i should try to keep it tuned to get the most performance out of it. i started at first by writing my workouts down, and then trying out all types of digital trackers. one favorite tool that came out of this period was the withings scale: it allowed me to periodically keep track of trends in my weight and body composition and allowed me to think about big trends in my life that affected performance.

so far, i’ve used various tools and hacks over the years to collect this data. but i’ve long wanted it all in one place – or, at least, something to give me the illusion of ‘one place’. a dataset that is a single repository and view of my body as opposed to various silos of data scattered across different services and devices. of course, this requires that we all play along in some way and make our systems open and provide APIs for getting at this data. not only are we still in the early stages of building such self awareness software, but so too are we still some ways from designing the right data sets and figuring out ways to expose them to our users. i believe the openness of the latter is just as important as the first point and i think we still have some ways to go in that regard. (for example, on many of the services i’ve tried recently, i’ve had to cobble together and reverse engineer things to pull my own raw data out in some normalized form).

as a part of all these experiences, i’ve always been curious about the idea of a personal API – a ‘quantified naveen’ – that would expose all of the information i knew about myself in a clean, open document. i think i’ve wanted to do this because:

1) i wished to play with the idea of a ‘virtual me’ that’s entirely inside the machine;

2) the idea of a ‘published’, always-public me has intriguied me (we share our tweets and checkins and photos and music habits to a wide audience, so why not other types of behavior and habits as well?);

3) and i’ve been curious what one might be able to do with such a resource: will any of it be useful for research? might one create apps on top of me? or perhaps draw insights that i haven’t yet been able to see myself?

as a way to start this off, i’ve put up an API of such personal data. i’m calling it api.naveen. it currently exposes sleep, weight, steps, fuel/activity and checkins. i aim to keep adding to this list with a few more interesting ones as i think of them.

have a look: http://api.naveen.com/

drop me a note and let me know what else you’d like to see and what you end up doing with this. i welcome the start of a good discussion.

special thanks to: eric, for coining the term ‘personal API’; sameer, for help with the data layer.

Right now, there are brilliant students from all over the world sitting in classrooms at our top universities. They’re earning degrees in the fields of the future, like engineering and computer science. But once they finish school, once they earn that diploma, there’s a good chance they’ll have to leave our country. Think about that.

Intel was started with the help of an immigrant who studied here and then stayed here. Instagram was started with the help of an immigrant who studied here and then stayed here. Right now in one of those classrooms, there’s a student wrestling with how to turn their big idea—their Intel or Instagram—into a big business. We’re giving them all the skills they need to figure that out, but then we’re going to turn around and tell them to start that business and create those jobs in China or India or Mexico or someplace else? That’s not how you grow new industries in America. That’s how you give new industries to our competitors. That’s why we need comprehensive immigration reform.

Rails in Realtime

layervault:

Update: We’ve written a complementary post that goes into more depth. Read this first and then check out Rails in Realtime, Part 2.

LayerVault is built using the popular web framework, Ruby on Rails. The framework, at times known for its divisiveness, has allowed LayerVault to grow from a single box to a swarm of machines over the past year. Recently, there has been a wave of great JavaScript-based frameworks that make creating a “realtime” app a cinch. Because LayerVault is a perfect facsimile of a team’s filesystem, having the web interface update immediately is incredibly important. Every ⌘R is two key presses too many. Finder doesn’t require you to refresh every time a file changes, why should a web app? We’re happy with Rails, so transitioning to Meteor, Ember.js or Backbone.js whole hog isn’t the right move for us.

The phrase “realtime” is thrown around about as much as “local” and “disruptive” these days, so the phrase is often ambiguous. For the purposes of this post, a “realtime” app is the following: page refreshes are not required to see the most up-to-date state of information and new information is communicated in tens of milliseconds instead of hundreds or thousands.

This blog post will cover some of the patterns that we use to allow LayerVault customers to never worry about pressing ⌘R. This is all done by using vanilla *.html.erb templates and never rendering any parts of the page using JavaScript. Once a database record is changed, that change appears in <500ms in a customer’s browser.

Read More