Bram Pitoyo, Portland Creative/Tech Event Review

Portland Net Tuesday June: An Event Review

Portland Net Tuesday June

(A note/recap from the organizer is available in PDF.)

When: Tuesday, June 24, 2008, 6:00 PM – 8:00 PM
Fourth Tuesday of every month

Where: AboutUs office, which I reached in an hour and fifteen minutes by biking really, really fast through the Springwater Corridor from Gresham.

What it’s about: Portland Net Tuesday is a venue where folks from nonprofit organizations can learn about ways to integrate technology into their activities. A note that focuses on the stories behind rather than the subtle technicalities of the two sites, Connectipedia and Squarepeg, is presented below.

*** BEGIN EVENT NOTATION ***

Connectipedia

Connectipedia is Wiki + database that’s focused towards nonprofits.

Objective: to serve as a go to place for both Foundation members and Nonprofit organizer to get information, connect with each other, and ultimately get funded, or fund the right organization.

How we’re different:

  • In Wikipedia, a page about dog looks literally like a collective book report on dog.
  • In Connectipedia, thanks to its database functionality, if somebody wrote “The best dog park is in Laurelhurst,” that same bit of information will show up in the dog page, Laurelhurst page and Portland page.

But Connectipedia isn’t built to be a wiki where user can find all the information, but one where he/she can find where all the information lives. Rather than having write-ups or contents, Connectipedia has links to write-ups and contents. If it’s available on other sites, Connectipedia will link to it.

If Wikipedia is a full-length book, Connectipedia is the reading list.

The easiest way to use Connectipedia: sign up, enter your organization name, and start filling it out.

DataPlace.org pulls in all kinds of public demographic data for various neighborhoods, counties and cities in Oregon. Connectipedia embeds statistics from DataPlace, so nonprofits can easily browse all these data, wiki-style, and compare them side by side.

Squarepeg

Story
Squarepeg started out when a group of student activists had difficulties maintaining contacts and creating momentum around their causes, while going to school at the same time.

The founders noticed a gap: when they build websites, nobody goes to it. But when they go to MySpace/Facebook, there’s too much information for anybody to pay any attention.

They also noticed that, on social media channels, they get a pretty solid response to any cause—until they sent out an email and invite the audience to meet. Then suddenly, half of them dropped out.

They finally learnt that people use social media to talk about their lives, the movies they watch, etc.—not about social causes.

What they found, however, was that if they meet with people offline before they organize things online, this greatly changes the dynamics and dialogue around the community. More people commit. Less people drop out. Etc.

In other words: in order to create real change, you need to have face to face, real life conversation. Internet is great as a databank of informational resource. But inspiring and organizing social activism events are an entirely different subject. It doesn’t work.

So they aimed to create a space where people can connect with other user, events and actual actions. Hyperlocal. In other words: they built a social network centered around social activism.

In this process, one of the first thing they realized was that they need a large number of user to make the network valuable. You know, the critical mass. So we tried to work with some nonprofit organizations in Portland who are willing to invest both members and times. They would literally help these organizations plan annual meetings and then say, “wouldn’t it be nice if we can use an internet tool to do this?”

That changed about two weeks ago.

TechSoup has a conference called NetSquared. For the last 3 years, this conference aims to bridge the gap between the developer and social activist communities by having the former vote on projects to be worked on during the next year. Social activist groups, then, will benefit from the developer’s expertise and resource.

Squarepeg was one among the twenty-one organizations that were selected; and they immediately got overwhelming amount of feedbacks from the people at NetSquared.

Almost all of them suggested one thing:
Don’t create your own social network.

That’s where we are today. And that’s why we don’t have a demo to show you tonight. We are scrapping the development of the social networking part of Squarepeg.

But they decided to do something better.

Squarepeg is now collecting organizations, users and actions around Oregon, from local blogs and event places, aggregating all these information in one big source, filtering them through a recommender engine, then disseminating the result through Facebook, OpenSocial and widgets.

In other words:

You put in your data, and the system spits out what thing you’ll be most interested in.

This way, nonprofit organizations don’t have to have a MySpace and Facebook account to reach MySpace and Facebook users. They can simply submit their listing to Squarepeg, and the system will push the information on all of those sites, through widgets and applications.

Put simply, it reduces barrier of entry for nonprofits who aren’t necessarily social media savvy to organize events and gain members from social media venues.

What’s unique about Squarepeg, however, is that they are planning to partner with media venues and for-profit companies, not just nonprofit organizations—but only ones that aim to cause social change. That, to put it simply, is how they’re going to make money.

We literally stopped the car and decided on a direction two weeks ago. When our direction was to create a social network, the development time was so long. In light of that, we decided that, this time around, development has to be really quick.

What our timeline today looks like:

  1. Recommender system will be online within a week.
  2. In 3 weeks, the system should be pulling data in real time from Social Actions (and all the other places) and framework for events listing should be done and tied in with the aforementioned recommender system. At this point, Squarepeg should be ready for private beta.
  3. One month to test it out.
  4. Official launch within 2 months.

*** END EVENT NOTATION ***

Technicality: ☝ ☝ ½
Translation: Some of the bits that go into the underlying technology and practices of Connectipedia were technical, but they’re easy enough to understand—provided that you have a laptop at hand.

Interestingness: ☝ ☝ ☝ ☝
Translation: It isn’t just about social activism and technology. It’s about stories—ones where the social web can make even the most low-key causes possible by putting them in the spotlights of active participants. If you’re in a nonprofit, Portland Net Tuesday is a must go.

UPDATE: But don’t take my word for it. Bob Uva can attest to this fact since he had been attending the event since February.

What I Learned From The Event In Six Words:
Social media cause meaningful social changes.

Advertisements
Standard
Bram Pitoyo, ip3, Portland Creative/Tech Event Review

Ignite Portland 3: An Event Review

Ignite Portland 3

When: Wednesday, June 18, 2008, 7:00 – 9:45 pm, although the ticket holders line formed as early as 4:30 and the conversations extended through the afterparty until close to past midnight.

Where: Bagdad Theater

What It’s About: 14 interesting Portlanders presenting unique ideas, stories and experiences over the course of 20 PowerPoint slides, each 15-second in length.

But to tell you the truth, I’m having a hard time deciding between what got me more excited about Ignite Portland: the wonderful presentation lineup, or the fact that I get to meet and connect with so many Twitter friends in real life? I can’t tell you how many times I used the introductory line “hey, you’re [Twitter username]!” or have a kind soul tap my shoulder and say, “you’re Bram, right?”

For example, I learned from Varun Thota that Akshay Dodeja was going to be interviewed by Robert Scoble the next day about their startup, Mugasha, that Cami Kaos just printed a new sticker for her and Mike’s Strange Love podcast, that Bill Lynch from Jive Software had a voracious apetite for good typography, and that the said software company had one of the highest DJ concentration among its staff in the country.

Allison and I even got a chance to hitch a ride with the elusive Gary Walter and learn more about the wonderful things that he did (as well as the reason why he stayed up all night.)

That, dear reader, is the power of social media, and nowhere is this fact more true than in events like Ignite Portland.

Technicality:
Translation: Ignite 3’s most technical presentation was about Boiling Water In 5 Easy Steps.

Interestingness: ☝ ☝ ☝ ☝ ☝
Translation:About the only thing that should be keeping you from attending this event is Bagdad Theater’s limited seating capacity.

What I Learned From The Event In Six Words:
Portland Is Awesome. Proof: Ignite 3.

Standard
Bram Pitoyo, Portland Creative/Tech Event Review

Bill Buxton on Design Thinking, Action and Ecosystem: An Event Review

Bill Buxton on “Design Thinking: Action and Ecosystem”

When: June 11, 2008, 7:00 – 9:00 pm

Where: World Trade Center Auditorium

What It’s About: How to optimize your physical and cultural ecosystems to optimize and maximize the uses of your specific design skills and practice.

*** BEGIN EVENT NOTATION ***

The Design Eco-System, by Bill Buxton

We’re surrounded with technologies. However, there are several issues with these ecosystems:

  • One where we undertake design (agency, studio, shop.)
  • One where we live and interact with technology.

There’s an area called Design Thinking that’s a very hot topic today. The challenge, though, is not simply figuring out how designer’s think, but also what they know. What is the knowledge that lies behind the thinking?

I literally bought every book in the bibliography of my book.

The reality is really painful:

When people thinks about ‘thinking,’ there’s a thought that thinking only goes in the head. And the whole theory about design thinking is based on this premise. But what I know from cognitive science is that thinking doesn’t only happen in the head, but also in the ecosystem surrounding the head.

Edwin Hitchins wrote in his book that, tools, maps, organizational structure of the ship (crew, equipment, etc.) and a whole host of other factors that’s beside the ship’s steering wheel, all plays a part in shaping its navigational system. Discount these factors, and the navigational system falters.

In the same sense, the tools, objects and notations that surrounds a knowledge (be they physical, conceptual or notational), are all inseparable ecosystems that surrounds a knowledge system.

In the same sense, design must continually consider and take its ecosystem into account, or be doomed to failure.

For us in the design industry: if we’re good at whatever we do, it takes a full-time job to get it. You pay the price to get where you are, not just in money, but in time, relationship, family, etc.

Today, everybody thinks and say they’re designer. Designer makes stuff, right? Wrong. Just as we’re not lawyers because we know a little bit of law, and we’re not doctors because we know a little bit about our body, we’re not designers just because we know a little bit about color, typography, layout, etc.

Well, there is a huge gap hidden behind the facade of people who are great at doing a specific thing. This gap is the idea that people who are good at what they do don’t have to sacrifice anything to get where they are. Believe it or not, even we as designers still get this idea when we think of other people.

In other words, it’s not in the result, but in the process that goes to get to the result.

That’s why I’m interested in investigating processes and thoughts that we can teach, learn and reproduce. I’m interested in one hit wonders. It’s the repeat offenders that I care about.

But first, why do we bother engaging in this conversation?

  • We are collectively failing miserably.
  • The issue at stake is getting more and more serious.

Somehow, we have to change everything at systemic level, or otherwise, we’re just going to get worse and worse.

The reason I got concerned about this is the revolution of ubiquitous computing. Today, microchip is embedded in everything we use. Again, the more they’re there, the worse we’re going to get.

Why? When technology started off, it serves to solve a technological problem. Somewhere along the lines, however, it became mainstream. For example: the architecture of a Von Neumann engine are essentially unchanged from way back when it was the size of a refrigerator. Yes, it got smaller, faster, cheaper. But the structure doesn’t change.

But the things that changed are these:

  • Who uses them?
  • And how they use them?

What happens is:

  1. These technologies affected our lives.
  2. Our lives are changed.
  3. But the technology itself remains the same
  4. This screws up our lives.

For example:
Imagine an office without any organization tool. Now introduce a paperclip in that office. You will change its culture.

In the same sense, everytime we put out a technology and place it on a society, we also change it. We are, inadvertently, redesigning the culture.

Now we have to take responsibility for those things.

So, somebody in the company decides to make this widget, design it, then sell it. This widget changes society. But where’s the thought behind it? Where’s the ‘design’?

Even when design is present in a product lifecycle, it’s not integrated closely.

Let’s clear things up a bit. Planning is not the same as design. Planning is not design in the same sense that conceptual art isn’t blueprint.

Yet my experience says that most people confuse the first sketch with the blueprint that’s made to construction.

OMA – Seattle Public Library

  • Call for proposals for architectural submission: November 1998
  • Awarded to winner: May 1999
  • Construction: March 2002
  • Building opens: July 2004

A scale model of the building [picture shown on slide] was built on Dec 1999. It shows up way before the construction.

But here’s the kicker. Interestingly enough, the design of that building still went on when it was constructed. But isn’t the design supposed to be “done” when construction starts? No. The primary, “high order bits” of the design may be set beforehand. But as the building shapes and takes form, you can see opportunity that you can add at a lower design level. Even when the building opens, you can still make refinements. This is why you always have leave to leave things open at a lower design level, and continually fill them out as the construction goes on.

There’s an interesting thing about ratio here [the timeline shows that the design phase went on for a longer period of time than the actual construction]: Design usually represents 17% of the total cost (25% if you’re Frank Gehry.) But they actually hire an architect to make the specification, which will inform the brief, which will inform the designer. But it doesn’t stop there, because a construction project doesn’t just involve architects and interior designer. Everyone from structural engineer, finance, and all other disciplines are interwoven, and must be present at every phase of the project in order for it to succeed.

You see, there’s an incredible amount of work going here.

Architecture mirrors software and hardware development in that, in a sense, they have the same level of complexity and same level of relationship between disciplines that work with each other. In software development, for instance, your software architect is also your structural engineer.

You must know:

  • What makes you distinct.
    Let’s all admit that, as a community, we are pathetic at articulating what we do! But if designers don’t know what’s important to them, who will?
  • Your value lies in your distinctiveness.
    The last person I would hire to work with me is another copy of me. Why? Because if I’m good at what I do, I must be bad at what I don’t do, so I need someone to cover my ass—so to speak.
    Designer takes warning: In the technology sector, a designer who assimilate into the workplace and try to be more and more like an engineer give up their distinctiveness. It’s like selling yourself short. Never lose what makes you unique in the first place.

The most cliched example about design and business in the last 5 years is Apple. But I’m going to tell you 3 things that you haven’t heard in any article about Apple’s design success:

  1. Jonathan Ive, as we all know, designed iMac, iPod and iPhone. But did you know that Jonathan joined Apple at 1993, when share prices were still way up there, and Steve wasn’t there?
  2. Did you know that In the first 24 hours (!) of returning to Apple, Steve brought a principal analyst in, who told him two words: Industrial Design?
  3. Did you know that virtually all of the designers who did the product designs for iPod and iMac worked for Apple before Steve came back?

There’s a gap here. If the same talents worked at Apple before Steve came back, why didn’t they came out with iPod in 1995? The design team already knew what they do, but nothing was changed in the mid ’90s.

Why? It turned out that they don’t have a Chief Innovation/Design Officer. Who takes care of design? No one.

Today, the success of iPod is such that if you had the silhouette of Bill Gates recognizably holding an Xbox 360 in that orange background [iPod print ad shown on screen] I would bet you that the ad would sell iPods! Other companies tried to copy their ads. Apple loved it.

Who made the iPods successful? Obviously, not only the design team or the iTunes developer, but also the guys at legal, who made record companies sell songs for 99¢ at an online environment that nobody at that time understood!

The point is, I don’t care who you are as a designer/engineer/financial guy/lawyer. You could all be the best in the world, but if you’re not playing from the same songbook, you’re toast.

By the way, while you congratulate Steve and Jonathan, may I recommend looking at the sales of the G4 cube? It’s a genius product. No fan, no noise, belongs in the MoMA, etc. But it sales faltered. Ditto with the iMac’s “hockey puck” mouse.

My point is this: if Steve and Jonathan had not failed and failed regularly in the past, they would not have succeeded in building the one killer product. Nothing ever comes for free. You have to learn from your mistakes.

People at IDEO have figured something out. If you’re a designer, in order for your design to matter:

  • You need to be high profile.
  • You need to build a company that hire and has T-shaped person as staff (Note: this concept is similar to what I wrote about Mashups and Alchemists.)

[Picture of a slick-looking gallery shot of Trek bicycles]
Trek doesn’t sell bicycles.

[Picture of someone riding Trek while crossing knee-length water]
Trek sells the ability to scare yourself shitless.

Trek buyers may give their money for a bike. But, really, they pay for the experience they will get by using the bike.

The lesson is this: you design experience, not product. So start realizing that things we design isn’t material, but experience. Yes, it will be a physical manifestation of something, but to the user, that “something” will always be a mean to an end. The physical product is what you give your money for. The experience is what you buy.

This principle changes the way we approach design.

[Picture of an HTC Dash phone]
In a traditional design mindset, you are asked to:

  • Draw this phone.
  • Draw my phone’s interface.

Easy enough.

But in this new principle, you are asked to draw the experience of using this phone.

I don’t know anyone who can design anything without some sort of a drawing or sketching involved. So if you agree with the premise that I elaborated above: that design should be generating experience, not product—there must also be a sketching for experience.

For example:
In the mid to late 90’s, Palm kicked Microsoft Pocket PC’s butt and got the market monopoly, while at exactly the same time Microsoft lost got a lawsuit about monopoly (how ironic is that?)

Jeff Hawkins designed Palm, and he was able to get funding. If you recall, the Newton was getting savaged in the press around that time. Ditto with Mimeo, Eo, Go, Pen for Windows, Dolphin, and the PDA that Sony had. There were millions of pen-based devised.

Yet Palm was the only one who nailed it. How did Jeff do it?

He didn’t start with the user interface, or materials—or even drawings.

Instead, he got a piece of wood, cut it to fit into a man’s pocket, then went about his everyday business for 2 weeks, where he would walk to meeting and pull out a pen and this wooden pad, then started taking notes.

Everyone thought that he was a lunatic. But what he was really doing was going into the wild and asking himself, “How would it feel to have everything on my pocket, that’s always on, that I can take meeting notes on? Will it feel stupid or not?”

That’s experience sketching.

In this respect, other’s companies’ failures aren’t really failures. They’re expensive education that somebody else paid for, that you should learn from.

Design, by my definition, is choice.
There are two places where you can exercise your creativity in a design process under this definition.

  1. How do you get a set of different option from which to choose from? If you work with me, you do not come to an ideation meeting with less than 5 equally viable solutions to the problem. Come with 5 that you don’t know all the answer to, so you can ask questions and explore possibilities. Each of those solutions must be meaningfully distinct, and you have to be able to articulate why they’re meaningfully distinct. If you do your job correctly, you’re going to end up with another 5 equally viable solutions.
  2. Determine a criteria that will throw all of your solutions out out, so you’re forced to think outside your 5 options.

Enumeration/Elaboration → Reduction/Selection.
Design is the most negative job in the world. Hardly anything you come up with will manifest into product. Only one out of a million concept, in the end, will come up. You start with a lot of things, you finish with one.

But how do you optimize this process? You combine two methods of ideation:

  1. Refining. Let’s imagine that going from first idea to final product is like walking through a road that converges on the horizon. Now, imagine that designing is like walking through this path, in a circular/zig-zag manner, but in increasingly smaller circles.
  2. Exploring. Imagine a tree, where many tree branches grow and stem out of the bigger branch. To achieve growth, you need both branching and pruning.

Either method is sufficient. Both is essential to the process.

Since sketching is an activity that’s central to both methods, we’re going to discuss that.

Sketching
[Picture of the Taccola’s Notebook from 16th century]

In my research, the first time in history that sketching was used as a mean of thinking was present in Taccola’s Notebook [in the page shown on screen, he elaborated on different ways to construct a catapult.] Prior to the Renaissance, sketching was essential, but only as a way to remember, catalogue, or draw from memory, but it wasn’t a tool for ideation.

The anatomy of sketching
So what makes a sketch a sketch? I went to look to traditional sketching as practiced by architects and industrial designers. From those, a pattern emerged. I then analyze these at a meta level:

  • Quick, timely, inexpensive and disposable. A sketch has to look like it’s done in an instant and leaves room for the imagination. Instead of doing one beautifully, do a dozen.
    When I teach, I will even take marks off for good sketching works. You have to. A sketch has to look like you didn’t invest any time in it because you’re so full of idea.
    The idea is that, the more you sketch, the more the brilliant ones will show up among the crappy ones.
  • Plentiful.
  • Clear vocabulary. You know a sketch when you see one, because it’s characterized by things like lines that extend through endpoints, etc.
  • Resolution-dependent. A sketch should have no higher resolution than one that is required to communicate the intended purpose or concept. It shouldn’t contain more detail than it needs to.
    I’ll say it again: the resolution of the rendering should not suggest a degree of refinement of the concept that exceeds its actual state.
  • Suggest and explore, rather than confirm. If you want to get the most out of a sketch, you need to leave big enough holes for the imagination to fit in. Leave some room.
  • Ambiguous. A sketch should contain notions of loosenes and openness.

I should also note that there is no such thing as ‘low-fidelity’ or ‘high-fidelity’ renderings. There’s only the right or wrong rendering fidelity that’s appropriate for the price, phase of the project and client.

So what is the right representation model and material to use? That highly depends on the project; but your team must be fluent in many ways of representing, so that you can choose the most effective and appropriate one. You may prefer sketching to sculpting a model, and that’s okay, but your design team must have someone who is fluent in every visual representation method.

During the ideation phase, ideas are dime a dozen. The style of management should reflect this. So, at first, you have an “easy in, easy out” type of situation, and later, you have less options and ways out.

A way to think of a sketch versus a prototype is to think of them as occupying different sides of a smooth continuum, rather than as activities that are exclusive to each other.

Sketch

Prototype
Evocative

Didactic
Suggest

Describe
Explore

Refine
Question

Answer
Propose

Test
Provoke

Resolve
Tentative

Specific
Noncommittal

Depiction

How many of you:

  • Had your high school yearbook said “most likely to be the best artist in the class”?
    [few people raised their hands]
  • In a class of 30 people, how many of you did not know where you stood between “sucking at drawing” and “good at drawing”?
    [a lot of people raised their hands]

My question is: how did you know?

You knew because everytime you draw something, you are reminded of how good or bad you were by other people. “Mine looks like chicken scratch,” for example. Other people don’t just look at it. They comment and compared it against other drawings.

Our relationship with our sketches is the same thing. A sketch should not be something that we only look at. It should be a catalyst for conversation. A two way street. A sketch has to speak back to you.

One more thing: you have to put your sketch in a sociopolitical context. Until you can do that, it’s just “a big, crappy, red, really expensive painting that my mom has, but nobody else in the world can understand the significance of.”

Let’s imagine you sketching in your studio. Then this person who dresses swanky comes in, and they shred it. “The marketing people don’t understand me. Only other designers can,” you said.

Well, then why they hell did you give them the sketches, knowing that they can’t read it? Never show a sketch unless the person can read it. If they can’t read, it’s your job to teach them to read.

Remember: there is just as much variation in our ability to read a sketch as it is about our ability to draw it.

If the person with 10 year of experience can get way more from seeing the same sketch that a design student sees, that means that reading sketches can be learned and perfected with experience.

[Editor’s note: the notion of reading a sketch is a concept that I find very intriguing, and not many people have delved into.]

Designers are collectors or crap. Crap that they might use and pin in the wall for a moodboard or inspiration. Crap that you can pick up anywhere. Well, all these craps are “Awareness Servers.” If you have a shop, you better have this in your wall, or you’re dead. These “Servers” can serve the agency as:

  • Persistent communal displays (that anyone can add.)
  • Shared reference points (so anyone can say “this product will have a button that look that the one laptop we have in the Crap Piles” and everyone else will get it.
  • Conversation Provocateur. Collect things that references to something that will generate question and illustrate.

For example: I have a picture of a guy who speaks in public with a pajama [Editor’s note: it’s a very long story; one that provides context to the quote, but that I also failed to note in full.]

This picture spurs conversation over and over again, and clients would ask “What is that guy doing in an inappropriate dress code?” Then I can say “Well, if I dress differently at home and work, why does my technology remain the same in both places? If I take the technology that I use at work back home, it would be the equivalent of dressing in a full-on suit when you go to bed, no?”

So why do I go to Pixar and see these moodboards and “Awareness Servers” everywhere, but go to an agency or marketing department, and only see their client portfolio?

Mark My Words: Annotation is important to ideation.
An agency or shop should encourage non-destructive commentary and idea exploration. This is why you have to have tissue paper besides your table, so when your friend presents a mockup, and you suddenly have sparks of idea (“what if we put this element right here?”), you can contribute and add to it.

This concept of annotation should apply to any materials: 3D, film, 2D, anything. You have to be able to comment and explore things non-destructively. Pixar even go as far to invest their money in building all these internal tools that can mark up and criticize animation like crazy without destroying it. That’s why their stuff looks so good.

But you know what’s sad? Most shops don’t have those tools, and their work isn’t even as complicated as an animation feature film.

The Critique:

  • It’s about the work, not the person. If we’re friend, and I don’t critique you even though your work sucks, I disrespect you, because I wasn’t being honest, and therefore allow you to get ripped by client, or people outside of the safe agency/design environment.
  • Importance of multiples. Never present one solution.

I think that the practice of critique at least as important as sketching.

But I couldn’t find a single book that talks about critique anymore. Why is this? Well, I also couldn’t find a single book that said “Designers need to breathe oxygen to stay alive.” That’s why nobody talks about Critique anymore. It’s so important, critical, and fundamental to the process of design, that we often forget it.

If you are a designer, and you can’t articulate everything about critique, then before you go and complain to anybody about why design is not taken seriously in your environment, you should help everyone understand cross-disciplinary critiques, and you will change your environment’s culture.

“It takes almost as much creativity to understand a good idea as to have it in the first place.”
– Alan Kay

This quote pisses me off, because he hadn’t told me this 23 years before he said it.
Not understanding this quote was the biggest mistake I have made in my career as a design director. I can write good article. That’s not enough. I should be able to get enough ideas 20% the of the time, and spend rest of the time cultivating creativity across all discipline inside the company, so that they can internalize this quote and I can get ideas anywhere.

If you get this right, the product will take care of itself.

Summary

  • Every concept from traditional design still applies to this new paradigm of Designing for Experiences. The tools may change. The behavior doesn’t.
  • What changes: the representation. The new thinking requires:
    • New tools
    • New practices, and
    • New teaching
  • Creativity: use it or lose it. Generate. Generate. Generate. Eventually a great concept will stick. Just keep adding. Never stop. That is the most important message.

Final thing
What we need to do is this: redesign the culture of organization and doing it effectively.

Things like drinking and driving and picking up after you smoke are really design exercises, because the originator of those concepts know how to engineer the change in society by “pushing the right button.” Kind of like Designing for Experience, isn’t it?

I will close with this: somebody once asked my professor friend, “what single characteristics is common across all of your best students?”

This was his answer:

“They all have the ability to deal with models at the conceptual/meta level, yet at the same time deal with materials. They sew, make pots, play with LEGO, etc. While they work at a high levels, they were equally as conversant with the pragmatic tools and never lost that touch.”

*** END EVENT NOTATION ***

Technicality:
Translation: The same principles that guide Designing for Experiences apply to everything from software development, architecture to marketing.

Interestingness: ☝ ☝ ☝ ☝ ☝
Translation: Design Thinking was flat-out the best talk I’ve had all year, and one that made me regret not knowing and hanging out with more Information Architects and User Experience Researcher/Designer in the past. Immediately after arriving at the venue, I got a vibe that connoted hard work, brilliant thinking and high intensity. It’s almost as if these people simultaneously put three times as much thought not only into what they do at work, but also what they talk about at social events.

What I Learned From The Event In Six Words:
I’ll tell you after I reread.

Standard
Bram Pitoyo, Interlude

On The Creative – Tech Divide

NOTE: This post was originally made to reply to my friend Aaron Hockley’s Advertisers, Marketers, and the Portland “Tech” Scene, but contains a thought that I’ve been wanting to write for some time. Aaron’s post provided a good ‘push’ for me to get it out. My thanks to him for writing it.

I have a confession to make.

As a brand strategist by day and (secretly) a geek by night, who is very lucky to have the chance to hang around both communities, I often envy the latter.

I love both communities to death, and wish that they could comingle and share ideas (in events like Lunch 2.0), but I see an inherent problem. Now if you excuse me as I stereotype both folks to illustrate my point. No harm is meant.

Geeks may be inner-focused, but are also community-minded and are not averse to sharing. Creatives may be social and outgoing, but are really protective of their “secret sauce.”

Proof: go to a BarCamp meetup, then to an AIGA networking event. I can attest that almost everything, down to the atmosphere of the room, was different.

This is very apparent in my effort in co-planning Cre8camp after attending and being inspired by the last BarCamp Portland. Right from the start, there was thoughts that “making oneself vulnerable” by sharing knowledge—a factor that’s elemental to BarCamp’s success—must be approached differently for a creative audience.

Because code is objective, but design is subjective—so to speak.

Thought experiment: critique a page of HTML, then a piece of ad.

HTML
Here’s what you did wrong. You use deprecated tags and non standard compliant practices. Done.

AD
Art Director: “Isn’t the type too dark?”
Account Executive: “But the client insist on using dark type.”
“Too light?”
“Again, it depends on the eyes who see it.”
“Too big? Small? Strong? Weak?”
“What about the headline?”
“The imagery?”
“The choice of color?”

Code can’t lie, or be justified beyond what’s already written. Design and ad solutions, on the other hand, must be defended and justified. Code is firm. Creative is debatable. So geeks don’t mind sharing, because, hell, more knowledge is better, right? while creatives may be inhibited to share their “secret sauces.”

Again, it’s because code is objective, and design is subjective.

My ad side says: I envy the geeks, because you are inherently open and collaborative. My geek side says: I admire the creatives, but you are inherently in a position to judge anyone by a matter of taste.

I’m overly generalizing—pardon—but you get the idea. My point is: these approaches aren’t inherently right or wrong. They’re just different. And different is good. Because different viewpoints always makes for better end product and cutting edge solutions.

But “different” also don’t mix, and that’s what frustrates me.

Because I believe that folks from both industries can do great things by learning from each other’s strengths, weaknesses and experiences. Right now—and, again, to generalize—we are too different. Too separate. Too averse to communicate. And events like Lunch 2.0 (or maybe another event that will draw both crowds) could be pioneers that dare to bridge the gap.

Mashups and Alchemists”, there’s your call to action.

Standard
Bram Pitoyo, Layer Tennis

Announcing The Link En Fuego Layer Tennis Series

But first, a little history.

Layer Tennis as a competitive sport was started by Coudal Partners as Photoshop Tennis, followed by Veer as Lightboxing, then revived again as Layer Tennis last fall.

This one is done over email, recapped over blog posts, and played among close group of friends as substitute of smack-talking and pushing each other around the bush.

In order of appearance (and if somebody still have the time to make a volley) the contestants are:

  1. Bram Pitoyo
  2. Jackson Sherwood – skipped
  3. Tori Hartke – are you still game?
  4. Allison McKeever

(If nobody among us have time, I may open it to the Twitterverse—perhaps starting with local designers. The ambitious idea, then, is to have enough designers that the list would go on ad infinitum. Everyone may not volley more than once, but she will get to see volleys from every designer. Rinse and repeat.)

Here we go. The first volley:
Layer Tennis Volley 1 - Bram

Download PSD.

We will see you soon.

Standard
Bram Pitoyo, Portland Creative/Tech Event Review

Beer and Blog – Make your blog load fast and save the environment: An Event Review

Beer and Blog – Make your blog load fast and save the environment

When: Friday, June 6, 2008, 4:00 PM – 6:00 PM

Where: Green Dragon Bistro & Brewpub

What It’s About: Jason Grigsby from CloudFour talks about optimizing website, then shows you how to do it. Unfortunately, I am not technical enough to fully comprehend the latter part of the presentation, but any web developer and geek worth her salt should know these. Anyway, on to the notes.

*** BEGIN PARTIALLY COMPLETE EVENT NOTATION ***

2003, John and I worked at another company. Our datacenter reached max capacity, and the power company wouldn’t give us more electricity. We end up spending a lot of times optimizing 60 customers site to make them run faster. This is the kind of stuff that a lot of web dev don’t pay a lot of attention to today, or even back in 2003.

Recently, I realized how important this is for the environment. In California, datacenters can’t get more electricity. How people deal with thes: companies that have big network are load balancing to another country.

What about the regular web developer? We can do things to make site use less CPU time and bandwidth. It’s like recycling a can: not big, but if everybody is doing it, then it will make a difference.

In a Google survey, only 5% of the page is HTML document. The other 95% is CSS, JS, images and other stuff. So, really, the vast majorities of what the user will feel to be different is the parts that loaded after HTML. Another research showed that the size of typical pages have tripled since 2003, and the objects contained within it have doubled.

Clearly, then, there is a lot that developers can do to optimize the way they currently do things—if not for performance’s sake (which can be a non-factor with high-speed internet connection), then for the environment’s.

Yahoo! has guidelines on improving web pages performance. Jason discussed 13 of them. Some notable ones:

  1. Install YSlow for Firebug, which will give you metrics and score to judge and improve your site against.
  2. Make fewer HTTP Requests. This is the one of the most important thing that you can do to optimize your site. Firefox 2 and below only make 2 HTML requests per website at a time.
  3. Sites that has a lot of CSS and JS files should combine them in a single file. Images, on the other hand, can be hosted on several domains to balance the load.
  4. Use content delivery network: things that will allow you to geographically put content closer to the user. For instance, Google launched the AJAX Libraries API last week.
  5. The simplest thing to do—but one that not enough people does—is Gzip your files.
  6. Every time a site is loaded, a browser will check its header for update. This is important, but only if it’s updated. But elements like header graphics, and things that don’t change for a while don’t need to be updated and ‘checked’ by browsers all the time. Therefore, setting your header to expire in the future is a big deal.
  7. This one is common practice: but put stylesheets on the top and script on the bottom.
  8. Minify Javascript, particularly if you’re doing mobile web development.

*** END EVENT NOTATION ***

Technicality: ☝ ☝ ☝ ½
Translation: The fact that I only had enough aptitude to take note of the first part of the presentation—and not the second—should tell you. However, don’t let this deter you from learning and attending more presentations by this local mobile web dev maven.

Interestingness: ☝ ☝ ☝ ½
Translation: All suggestion is simple and practical—indeed, much like recycling a can to help the environment. In fact, I’m doing it on my professional website as we speak.

What I Learned From The Event In Six Words:
Change the world. Optimize your HTML.

Standard