I’ve started to post raw notes from events I attend. For more information, see the Notes Policy.
## 080917 Web2.0 Expo Notes
In this episode:
– Dan Saffer – Tap is the New Click
– DHH – Go REST with Rails
– Joshua Schachter – Lessons Learned in Scaling and Building Social Systems
– Keynote – Fred Wilson – The History of Tech in NYC
– Keynote: Deb Shultz – The Death of the Grand Gesture
– Keynote – Jason Fried – I Started 37 Signals and You Didn’t
– Maria Thomas – Etsy CEO on Growth
– Gary Vaynercheck – Ad Lib
## John Resig – Processing & JS
– proposed and first implemented in WebKit by apple
– bunch of primitives (line, rect, etc)
– NOT vector
– fill & stroke
window.onload = function();
var elem = document.createElement("canvas");
elem.width = 500;
elem.height = 500;
document.body.appendChild( elem );
var context = elem.getContext("2d");
context.fillStyle = "rgba(0, 0, 0, 1)";
context.fillRect(0, 0, elem.width, elem);
– Canvas can consume other images, other canvases
– in FF3.1 canvas will be able to consume video
– in an extension: web pages
– data visualization probromming language
– built on Java
– lots of libraries
– strictly typed
– has classes, inheritance
– very flat API (functions are globally accessible)
– two basic methods: setup() (called initially) and draw() (called repeatedly)
– no event handlers
– Initialization: setup() is called
– Draw loop: draw() gets called as fast as possible (unless a framerate is set)
– drawing area is similar to canvas: translate, scale, rotate, pushmatrix, popmatrix
– how to run processing on the web?
– natively with applets (but they suck)
– two stages: convert to js, recreate methods
– can we sync a dwg on canvas to music?
## Dan Saffer – Tap is the New Click
– public bathrooms are the interaction design labs for the world (dyson airblade)
– gestural remote control (bang & olafsoR) for messy hands
– most of this stuyy needs to be displayed in video to get it
– T-moblie gestural windows
– M$ Surface (table)
– Sphere surface w multitouch. awesome for panoramas
– David Liddle: “we’re using bodies evolved for hunting, gathering and gratutionsu violnecfor information age tasts like word processing and spreadsheet tweaking”
– we’re in the middle of an interactio design revolution
### History of Gestural interface
– HP 150 – tap on the screen to go to location
– Simon touchscreen phone 1994 IBM & Bell South
– POS restaurants for 20 yrs
– kiosks: jet blue
– two types of interactive gesture
– touchscreen (TUI)
– single touch
– the secret sauce: sensors
– other part of the interface: the human hand
– finger width: 16-20mm
– tip: 8-10mm
– pad: 10-14mm
– fingernails (blessing & curse): sometimes they work, sometimes not
– fake fingernails: evil
– finger oil
– (left) hnadedness
– accessibility issues
– wrist support
– inaccurate (compared to cursor)
– attached to a hand (ie, screen coverage)
– Don’t design the target in a way that the hand obscures it when user reaches!
– Touch Target Size
– Fitts Law: distance to target / size of target = time to get to target
– “iceberg tips”: touch area is bigger than the label
– adaptive targets: algorithmically guess the target based on info. Eg when you type “t-h-” on an iPhone, the “e” target on the QWERTY keyboard will be bigger than “w” or “r”
– Traditional UI element to watch out for:
– cursor: don’t need it. You know where yr finger is
– mouseover and hover
– selected default btn (can’t just hit “return” fo “Ok / Cancel”)
– undo (can’t un-clap a clapper)
### Documenting Gestures
– Dance Notation is a good place to begin. REALLY unwieldy
– Annotated wireframes are ok
– ARchitectural wireframes: size, height, relative to human form. Where are the sensors located
– “keyframes” – key moments in the activity
– gestural dwgs
– swim lanes: storyboard on top, user action row, machine state row, business logic row, etc
– timing is often a factor
– low fidelity:
– paper prototype,
– environments: paper, second-life
– off the shelf: chumby, Nokia 8500, M$ table
– DIY: arduino
– Turning Gestures inot code
– variables: what are you measuring?
– data: get the data from the sensor
– computation: determine diffs in data
### Communicating Interactive Gestures
– how to make people aware there’s an interaction available?
– Ambient Fear in public: people don’t like to look stupid in a public space, scared of breaking expensive equipment, etc
– Attraction Affordance: M$ Table has a great “riverbed” intro to bring people in
– written instruction (“Touch to Start”)
– small illustrations
1. available sensors & input
2. task that needs to be performed
3. physiology of the human body
### Ergonomics of human gesture
– avoid reptition
– keep muscles relaxed
### Rule of Thumb
– the more complicated the gesture, the fewer people that can do it
– match the complexity of the gesture to the complexity of the task.
– simple things should be done simply
– the best designs are those that “dissolve into behavior” (Naoto Fukasawa)
– the best designs match the behavior of the system to things people already do
## DHH – Go REST with Rails
Why am I interested in this stuff? REST has been around for a while, but its a very practical thing. Less interested in programming for its own sake than the outcome. Same w REST. After they built Basecamp, they decided it should have an API. At the time, APIs were something you bolted on to the side.
Most web developers haven’t read the HTTP spec. You don’t really need the spec to write a web app. GATHER? POST? Who cares?
That’s both the strength and the weakness of the HTTP protocol.
Most web devs have ignored the past for so long that they’re running into problems that have already been solved; we just need to dig down into the layers. Trying to learn what swart people wrote down 15 yrs ago.
HTTP is an ogre.
REST (“Representational State Transfer”) is like blue cheese: an acquired taste that’s disgusting when you first try. Once you get hooked, its really tasty.
WS-Star: an empire of specs detailing how to relate different services to each other. Associated with SOAP.
REST has infiltrated Rails
REST: a single resource that you can do multiple things to.
– GET: see
– POST: crud
– PUT: update or replace
– DELETE: destroy the resource
the latter two aren’t mapped in HTML, which is why they’re relatively unused
we’re simulating the full HTTP spec in HTML with this little hack (hidden form element using POST to implement PUT or DELETE)
REST enforces constraints. Treat everything as a single resource, use only those 4 verbs (GET, POST, PUT, DELETE)
Some benefits of REST: XML version is pre-built. This is the “multiple representations” part. Instead of building another controller (eg XML, API, whatever), REST re-interprets it. Why should I write it twice?
– RoR thinks about this in terms of “respond_to”
– everything has a single URL, and with differnte verbs you can do different things to it (read, write, etc)
– REST isn’t all abstracted away because it DOESN’T NEED TO BE!
– SOAP is so complex that when it breaks, yr fuxx0zed
### Convention over Configuration
– REST is **another** set of conventions, like RoR, but at a higher level: controllers, interface
– boost of productivity: not having to make decisions
– REST help with *spotting natural borders*
## Joshua Schachter – Lessons Learned in Scaling and Building Social Systems
types of scaling:
#### Tech Scaling
– partitioning: get yr users into groups
– don’t use one huge database. it sucks
– caching: don’t go to the database if you can at all help it
– replicas: fastest performance comes from having the data on disk *in the order you need it*. use multiple replicas if you need
– auto-increment will hurt you later: it guarantees that yr dada will be in the wrong order later
– put a proxy in front. when grandpa on a 2400 baud modem hits you, he’s gonna eat up the whole server slot. use a load-balancer or something. by the time you need it, you’ll wish you knew it already
– sloppiness: synchronicity is a bitch. decouple interactive performance from other pieces of the system
#### Social Scaling
– tend to need very different features at different scales
– SMALL: with few people, push everyone together into the same room to encourage meeting
– MEDIUM: features grow to be about mitigating traffic. 1,000,000 users is too big to be a community.
– scale is good for 3 things:
1. utility – hiring the product for a job. why do the users come?
2. network effect – value of the system becomes *the other people in the system*.
3. revenue –
do it in this order! If you start extracting value (in the form of cash) too early, it short circuits.
– product should be self-marketing. have the app exhibit as much functionality as necessary before logging in. registration-flow should be as light as possible. when you **must** have them register, remember the user’s state and return them.
– initial marketing vs actual marketing: not necessarily the same. The quick get may not be as powerful as the ultimate use. Eg, pausing TV (tivo) isn’t as big a benefit as network effects.
– layers of the onion: provide ways for people to continually get involved in the system: n00b, user, super-user, priesthood. Give people the means to market themselves using yr product.
– half the traffic came from RSS
– figure out the vectors for infection. For DEL, it was the FF extension. Great match; FF bookmarking sucked. Its ok to use another system as a carrier, but be wary of backing yrself into a corner
– book Josh likes: Animals in Translation by Temple ______
– use sensible defaults; people were checking “private” even when it was opt-in. changed it to “do not share” and finally people stopped checking it
– don’t go too far; do you need to tell the IDs of all the followers? or just the number of followers?
– software doesn’t map well to social norms; that’s why kids are ok with dropping accounts to lose crappy friends
– Spam & Abuse
– link exchange: people will build social systems **around** bothering you
– don’t ban users, legthen or destroy feedback loops. spammers & griefers will come back if you kick them, but they’ll never know if you lock them in a box
– pretty URLs: prime advertising space
– API: add some functionality to [whatever] without building a whole new system. people can fill the gaps that please them
#### Scaling Yourself
– when you build stuff, yr gonna do it wrong
– don’t spend a huge amt of time polishing.
– iterate quickly
– be lazy, reduce
– simpler is typically stronger
– have hygiene around yr ideas. write EVERYTHNIG down. Its a goood resource for instipation (or patents)
– Listen to yr users
– they love it when you respond. they never expect to hear from you
– every week, tally up all the reqs you get and figuer out what to build to engineer those problems
– Motivations: think very clearly about what yr doing
– user testing: yr understaning is biased, you need access to the way people look at things with fresh eyes
– measure and record everything
– always look for ways to shorten yr feedback loop. what did you learn?
– 60x performance increase: reshuffle records so that instead of storing no disk in the order written (primary key), store by URL, UID or UID, URL
– 25% of all passwords are “123456”, username, or domain name
– throttling is important. dictionary attacks are there. failed passwords are a BIG indicator.
## Keynote – Fred Wilson – The History of Tech in NYC
Seed stage deals:
1995: 160 20
2008: 360 116
1991: ZDNet (Ziff davis): put magazines online
1993: still using proprietary svcs, pre-web. Prodigy come out
1994: Pseudo, Razorfish. The name “silicon alley” starts being heard. Fred wants to kill that name. Big media (Time Warner, News Corp) takes its first shot at the web.
1995: 55 Broad St is converted by the city to a high tech incubator. Interactive agencies come along. BYT beta-tests their first web property with the Pope’s visit as their beta. Publications come along (Silicon Alley Reporter), online ad networks emergn (eg doubleclick)
1996: More activity. iVillae, theKnot.com, Flatiron partners
1997: early successes and failures. The roll-up starts: Razorfish bought a bunch of agencies. Doubleclikt isthee first NYC internet IPO.
1998: More success & failure. Kozmo.com. The last year of sanity before the 1st internet wave.
1999: all the offline companies start coming online. All hell breaks loose. Dozens of IPOs, acquisitions. 200 startups were funded. 1000s of parties. Josh Harris & Pseudo.com. “We Live in Public” is a doc about it.
2000: March: the Crash. High burn rates kill companies. Fucked Company. Google comes to NY.
2001: layoffs, landlords, bankrupticease.
2002: rock bottom. Doubleclick’s “Welocme to Silicon Alley” billboard is taken down. Calacanis is in LA, Harris is in the catskills.
2003: renewal. Denton launches Gizmodo. Fred launches AVC. the term “web 2.0” is coined. Schacter starts Delicios.
2004: Heiferman starts the NY Tech meetup. 10 people then, 7000 now. Union Square ventures rasise $125m
2005: NYTinmes buys about.com: NY’s biggest . Etsy launches. Y! buys delicious.
2006: google comes to NY in a big way. takes over the port authority building. 750 engineers in ny. Web video takes off. Wine Library, Wallstrip.
2007: 75 early stage tech deals by VC. Tumblr, Path101, I’minlikewithyou
NYC is different than Silicon Alley: more creative, more artistic, more connected to media and advertising.
## Keynote: Deb Shultz – The Death of the Grand Gesture
beethoven’s 5th: musicians understand the grand genture
-the presonal: human connections aren’t binary, but social web apps usually are: “friend or not”? “link of don’t link?
– can’t have a continuum without a grand gesture, and vice versa. Otherwise its all white noise.
– “Technology changes, humans don’t.”
## Keynote – Jason Fried – I Started 37 Signals and You Didn’t
– Software is a great place to be. You don’t have to worry about raw materials or physics; just type.
– Cost of change is way lower than other industries. Yr not plumbing.
– Software can be built anywhere.
– Doesn’t have the same feedback affordances as other things. Its easy to figure out if a water bottle is well-designed. Its not so easy to tell if software is well designed on not.
– What would yr software be like if it was a physical device? Would it be spikey? Comfy? Etc etc
– software can quickly devolve if you say “yes” to all yr customers.
– be the gatekeeper. be the editor. be the curator. a curator’s job is to say “no”.
– think about yr product as a museum, & yr features as things to hang on the wall
– software trends towards bloat because there’s no visible form
– once you hit bloat, its hard to go back
– “make a collection, not a warehouse”
– attach costs to things. shuts down a LOT of trouble
## Maria Thomas – Etsy CEO on Growth
– grandparents were all small business entrepreneurs
– Greek word “filotimo”: operating with purpose, dignity, and a sense of personal responsibility. No english translation. No kidding.
– only 1/10th of a % of US companies achieve more than $250m/yr revenues
– how people in a company treat each other and their customers is determinative of whether companies break into that 1/10th
– listen to end users
– practice filotimo; keep it human
– get the products out the door.
## Gary Vaynercheck – Ad Lib
– patience & passion.
– “There is no reason in 2008 to do shit you hate. You can lose just as much money being happy as hell.”
– listen to yr users? absolutely. But giving a shit about yr users? Even better.
– “Look in the mirron, pickt what you want to do. I pormise you can monetize that shit.”
– hustle. this isn’t about parties.
– getting a buttload of users and flipping it s not a business model. get a business model.
– “legacy is better than currency”. I want my grandkids being proud of me.
– the game is changing. i turned down 40 TV deals. there’s no reason for me to share my content. old media is no longer in control, and not everyone gets that.
– build yr own brand equity. believe. work hard, know what yr doing.
– “people are the people that will help you”
– use all the tools. connect to people any ande evryway you can
– we’re gonig through a gold rush of branding. yiou don’t need the machine anymore.
– “what do I want to do”
– “I’m In Like with You” should be a killer