(more about yesterday later)
hmmm, 5 after and nothing is happening yet. little conversations both in front of me and behind me. (I think a big chunk of the brighton crew is sitting right behind me.)
“we’ve got a bit of a problem with the site” (at 5:30 pm) no page refresh, not a bug but a feature. “oh, yeah, ajax, I remember.” but…”it’s not in the functional specification” can’t get finance to sign off.
wireframe as a replacement for functional spec.
I wish it wasn’t so dark on them, because they’re actually standing, moving, etc.
“nothing is easier than believing we understand experiences we’ve never had” box quoting matt webb.
“trying stuff is cheaper than deciding whether to try” (a fundamental rule of the internet)
something more complex & nuanced than prior technique, traditional wireframing.
limiting the possibility space vs expanding it. (really?) maybe it’s a question of stuff vs action. what about the problem of too many choices?
see the patterns, create a framework for discussion.
switching from why to how. yay!
“ElfCartel” OMG that’s actually a cool name. 🙂 As an example….
“may be a little overdesigned for a wireframe, but it was just off the shelf.” I worry about something like that being too “designed” — when I did grey-scale work at Pierce, I always made it “deliberately ugly.” Times New Roman, grey background, default link colors.
I like the way their notes look, and the show/hide thing. I tend to use just a paragraph with “yellow” as the background color, not that faint yellow, but the one you get with “background: yellow.”
“Not calling the server” just the visual bit with jQuery to make it mimic the interaction.
shared library of patterns & widgets. (shared with myself? yay!)
so much mockery of Jeremy Keith, one assumes in a friendly way.
I’ve been chatting on meebo: interesting discussion of timing, how interaction & design are scheduled.
missed a switch to a real wireframe; site to track carbon footprint. (it reminds me of wesabe, in terms of the goal bit.) showing multiple interactions, and discovering that an inline form wasn’t the best way to do something. okay, this is where it gets useful.
(damn, just realized I left my water at the ikea lounge. sigh.)
“don’t want the tool to get in the way of the hard part, which is the thinking” which makes sense particularly if this (HTML/CSS/JS) is the tool you know best. (vs visio et al)
q: js should enhance, not be required. but it doesn’t look like that’s here. they design for js on, but they are still thinking about what happens if JS isn’t there. if time the wireframe includes that status, but usually “just have that conversation”
do clients get attached to the “off-the-shelf” look? “managing expectations” I still think that there’s too much “pretty” in what they’ve got. For most people, that looks like a finished (or mostly finished) design concept. I wonder if that really works; they say so, but….
how long have they been doing this? they are being cagey, IMHO. what year did they start using this particular technique? what did they do beforehand? why didn’t that work?
good to pick up: the use of JS to mimic behavior. I don’t have anything specific to use that for, but it’s a cool technique to know.