arkitrave :: log

A few brief notes from a few of the panels on Day One:

Beyond Folksonomies: Knitting Tag Clouds for Grandma

Overall, an interesting panel. Admittedly a huge topic, there weren’t many answers provided; rather, it was the kind of experience that provokes more questions and uncertainty. The certain fact is that the rest of the world does not use or see tagging the way that web-people do. The presenters contrasted top-down taxonomy with bottom-up folksonomy, though positing that the two were not polar opposites but rather complementary and mutually necessary. Tagging allows people to invent their own classifications. Right now, it’s still in its infancy. Problems include usability (a lot of classifications are just bad), not enough critical mass, inadequate interfaces, too much information without the foundations being solid, and both differences in the way different people classify information and the way the same person classifies things over time.

People don’t want to do lots of work; the average person isn’t going to tag things just for the good of the community. It needs to be made really easy, and the ROI of tagging things needs to be obvious to people.

Implicit tagging has potential (a tool which, for example, looks at what you click on in a Google search associated with the keywords you used to search…this is automatic, but still human-generated).

Tagging needs to be integrated with things people actually use, instead of another site that people have to visit. It needs to move from the power-user realm to the everyman realm.

We need to look at problems and solve them, not invent technologies and then try to find a user for them.

Ajax: What You Need to Know (pdf)

Introduction (Schiemann): XMLHttpRequest is really a misnomer - it doesn’t have to be XML, it can be any text or HTML content. Microsoft just liked the name years ago when they invented it. Questions to ask: What is our intention? What does “back” mean? Page? State? You don’t want to go back to outdated data. Cross-domain security could be an issue. Progress indicators aren’t supported. Code can execute more quickly than the content it requires to execute without errors. Request limits (2 maximum open at a time per HTTP spec). Debugging is difficult with Ajax.

Getting Started: 1) Determine your requirements - what do you want to do? 2) Find a good toolkit - don’t reinvent the wheel. Use Dojo, MochiKit, Prototype, etc. This frees you to make new mistakes, not repeat old ones. 3) Learn more about JavaScript and HTTP.

Common Objections (Smith): 1) Accessibility and usability (you must make sure you give content to all users!). Plan degradability from the beginning, not as an afterthought. 2) User expectation (what about back button? bookmarking? map permalinks? 3) Cross-browser support - no excuse for ditching any (new) browser or Mac support. 4) Suits and marketing droids show up and try to “help” and sell stuff based on Ajax without learning anything about it. Geeks from the server side of things, who don’t believe JavaScript is a “real” language, show up and try to “help” the poor scripters since they are the “real” programmers. 5) Navigation issues, slow response times (LiveSearch appears to be slow, Spotlight on Mac OS X Tiger appears to be slow). 6) SEO friendliness (do we hide content from search engines by using Ajax?). She encourages us to check out what Yahoo! has been up to; this is good stuff.

In working with backend developers, remember two things: First, it’s JUST HTTP! It’s not really that different than what we are used to. Second, the client can manage it’s own UI - the backend doesn’t need to know that a button has been clicked; it just needs to know that it needs to deliver a piece of content to the client. Actually, in some ways Ajax decouples the model and view more than a traditional web page paradigm.

In designing workflow, know your people and what they want. Is it boxes and arrows? Storyboards? It’s tougher than a page paradigm, because you have to show how the thing works. Perhaps building it is the best way (cross-reference Coudal/Freid’s opening remarks).

Keynote: Jim Coudal and Jason Freid

Coudal

A couple years ago, panels were about tools. Now, they’re about taking the tools and building businesses with them.

When people think of “in-house”, they think of bad email campaigns, Comic Sans, sales videos, cube farms and lots of toys scattered all over the office…maybe signs that say “Creatives on the loose!”

People historically thought that good design happened independently of the client. Now, designers and coders are realizing that they can handle the business side of things, thanks to good technology. Curiosity and quick learning are the hallmarks of the new small businesses.

Good craft (markup, color theory, etc) they learned on behalf of clients when we worked “in-house.” Now, they are trying to control the creative product outside of the work-for-hire model. It’s better to BE the client than work for the client. Apply craft to their own business. Of course, it’s not that easy…

Issues come up - international shipping, tax law, redundant servers…client used to do these things for us. We need to be quick learners. Questions they always ask before accepting any project:

1. Will we have a product we are proud of?
2. Will we make money?
3. Will we learn something valuable through doing the project?

They’ll do a less-than-perfect product for lots of money. They won’t do mediocre work for mediocre pay. They will never take a project they won’t learn something from.

We need to learn how to learn quickly. The meek don’t inherit the earth, the curious inherit the earth.

Freid

So, how do we do this? We need entrepreneurship, not just tools. Starting is intimidating…what to do first? Don’t quit the day job. The old plan of VC, an office, a business plan, is expensive and puts investors before customers.

Make it a side job. Basecamp started as a side project of 10 hours a week. Benefits to this method:

• Obscurity - you will fail more than you succeed, so fail in obscurity.
• Less - this a huge competitive advantage. The age of “more” is very cold war/defensive
  • Less time - can’t waste time if you don’t have much
  • Less money - don’t need a lot of stuff - keep it simple
  • Less software - build simple stuff that people can use

Don’t try to be clever, like MS Word trying to predict what you want. Basically, more constraints are good rather than a hindrance, because they force you to do more with less and you won’t be indebted to any venture capitalists.

Q&A talked about how bad spec documents are - basically, they make final decisions based on information you won’t have until you build the thing. Just start creating rather than trying to build detailed spec documents. They reject any job with an RFP of more than two pages. Spec documents are political illusions of agreement - there are so many levels to how they can be interpreted that there is no guarantee anyone is actually really on the same page.

Also, don’t bullet point job skill requirements when hiring - the important thing is that someone is curious, not that they have x years with Photoshop or a college degree. Several of 37Signals employees don’t have college degrees. These easily quantifiable things are not indicators of how effective an employee will be. As long as they can do the work and are curious, they will be good employees.

Finally, charge for what you make! You will make money, then, and people are willing to pay for something that gives them value. Produce a good product, and people will pay for it.

Online in Offline Spaces

Basically this panel was run by people who build social apps that bring people together in real space - rather than the virtual utopia predicted in the late 90’s, people want to communicate with each other personally, and technology should serve that end. Dodgeball, Socialight, Meetup, and Squidoo were the apps represented by members of the panel.

Steeson talked about buildings that have interfaces. Peter Cook’s paper architecture, the plug-in city. The Pompadou Centre in Paris with the services externalized. Realities Unlimited in Berlin. The Pong game on the building facade, controlled by cell phones.

With my background in architecture, this was interesting, and I appreciated the emphasis on the real physical interaction that is coming to the fore in digital gathering. A dystopian element was presented as well - will we eventually be willing to pay to keep people from finding out where we are and what we are doing, or pay to not know background information on a place or building so that we can enjoy discovering it ourselves?

Later…

After the panels, I met back up with Erik and David, and went to the barcamp meeting at Thistle. I got my picture taken and even a free t-shirt! I bought a tasty Patron margarita, and Zach Inglis bought me a glass of wine. Zach’s a great guy (and not just because he bought me a drink); I enjoyed talking with him and found myself slipping into a really bad Scottish accent occasionally. I also spent some time talking with Patrick Haney, who works at Harvard but grew up in Hamburg and went to RIT. Carl Tashian, who I met briefly at the bar, is an interesting guy who works as a developer at Zipcar and, like me, has a thing for well-designed stuff like the Dyson.

We were invited to another party, but I am too old to stay up all night and get up at 7:30. More tomorrow night.