drawing_hands2.jpg
(There will be 2 kickoff meetings on Thursday, April 19th. One at 9am & one at 6pm PST on Architecture Island. The experiment will run from April 19th – May 19th. The following document is posted at the following Wiki: Wikitecture 2.0: Program and Protocol… here’s the pdf)

 

Like any new burgeoning idea or philosophy, a number of words start springing up to capture its essence with greater accuracy. The growing excitement around Web 2.0 is no different. The following have been sighted in trying to describe this new phenomenon: Mass Collaboration, Social Networking, Wikis, Folksonomies, Open Source, Prosumers, Networked Intelligence, Crowd Sourcing, Crowd Wisdom, Smart Mobs, Peer Production, Lightweight Collaboration, Emergent Intelligence, Social Production, Self-Organized Masses, Collective Genius, Loose Networks of Peers, and Collaborative Infrastructures. But to use Wikipedia’s definition, which is fast approaching the voice of authority, Web 2.0 refers to a ‘perceived second generation of Web-based services that emphasize online collaboration and sharing among users.” My personal favorite portrayal is ‘a shared canvas where every splash of paint contributed by one user provides a richer tapestry for the next user to modify or build on.’

 

The ideas behind the online collaborative spirit of Web 2.0 have been successfully harnessed in a wide array of disciplines, such as: Wikipedia, Linux, MySpace, InnoCentive, Flickr, Second Life, You Tube, and the Human Genome Project to name a few. With books such as ‘Wikinomics: How Mass Collaboration Changes Everything’ fast approaching the New York Times best seller list, it seems as though peer production could provide alternative ways of working for a growing number of other disciplines as well. The question is: Can a field as subjective as architecture, or design in general, benefit from this collective intelligence paradigm?

 

To help answer this question, ‘Real Life Architects in Second Life’ (RLASL) will be conducting a ‘Wikitecture’ experiment on Architecture Island in Second Life over the next month to determine just how feasible a collaborative approach in design might be in the architectural profession. Not only will we aspire to create a noteworthy building design in the process, we want to use this experiment to explore and flesh out the specific measures, protocol, and tools necessary to make collaborative, asynchronous design in architecture a reality. I guess it goes without saying that since this is an experiment around open collaboration, we need contributors—we need you. You do not have to have any experience in Architecture or building to participate. We actually believe the more diverse the pool of contributors, the better. Whether you contribute to the design of the building or offer suggestions on how to improve the process of open-design, we welcome and need, any contributions you may have; no matter how big or small. Help us work out if there’s an Architecture of Architectural Design Collaboration?

 

Since RLASL revolves around using Second Life as a professional and educational tool, we would like the contributors to pretend as though they are designing a real life building and try to address, as this building design evolves, not just design’s ‘delight’, but also its ‘commodity’ and ‘firmness’ as well. Make Vitruvius proud as they say.

 

When designers are given cart blanche to design anything their imagination can muster, the possibilities are so numerous, finding a direction can sometimes prove difficult. In this vain, we wanted to provide a program for this Wikibuild that would give designers an initial direction, but vague enough, in turn, not to restrict any sense of innovation or creativity.

The Program Catalyst:

 

 

The project, located somewhere outside San Francisco, will be conceived of as an artist retreat to host any number of educational and social activities for the ‘RL Architects in SL’ group. Of the few stipulated functions, the building should accommodate an internal courtyard. Since the courtyard will mostly likely be the main gathering area, a large viewing screen, ideally incorporated into the architecture, should be located along one edge of the courtyard. In addition, to play off the burgeoning sustainability movement, a green roof will be located on top of the surrounding building(s). The program, however, in the encircling building can evolve into whatever the community of designers deems appropriate, but an entrance, classrooms, workshops, a library, a kitchen, or offices might be potential candidates and of course, per code, restrooms might be a good idea as well.

Since there are quite a number of students that visit the island, we thought it might be educational if the design of the building itself acted as an exposé of a few basic architectural principles; namely those principles outlined in Francis Ching’s book Architecture: Form, Space, & Order. We ask, as you develop the design to try to incorporate some on the architectural principles outlined in the following table. Do not feel, however, that you have to incorporate every single concept exhaustively; the design would most likely run the risk of becoming a little too chaotic. For those principles that cannot be accommodated within the architecture, we ask that the community designs small simple garden follies within and around the rooftop garden to demonstrate these missing principles.If you do not have access to Ching’s Book, the following PowerPoint lectures, although not exhaustive, cover a majority of the principles outlined above:

Primary Elements Form and Shape Transformation of Form

point elements

linear elements

planar elements

volumetric elements

visual properties

relational properties

primary shapes and forms

-circle

-triangle

-square

-sphere

-cylinder

-cone

-pyramid

-cube

dimensional transformation

subtractive form

additive forms

centralized form

linear form

radial form

clustered form

grid form

Manipulation of Form Horizontal Elements Defining Space Vertical Elements Defining Space

formal collisions of geometry

-circle and square

-rotated grid

articulation of form

-edges and corners

-surfaces

base plane

elevated base plane

depressed base plane

overhead plane

vertical linear elements

single vertical plane

L-shaped planes

parallel planes

U-shaped planes

four planes: closure

Openings in Space-Defining Elements Qualities of Architectural Space

Spatial Relationships

opening within planes

openings at corners

openings between planes

proportion

scale

definition

degree of enclosure

light

view

space within a space

interlocking spaces

adjacent spaces

spaces linked by a common space

Spatial Organizations

Circulation

Ordering Principles

centralized organizations

linear organizations

radial organizations

clustered organizations

grid organizations

circulation elements

building approach

building entrances

configuration of path

path/space relationships

form of the circulation space

axis

symmetry

hierarchy

datum

rhythm

repetition

transformation

If you do not have access to Ching’s Book, the following PowerPoint lectures, although not exhaustive, cover a majority of the principles outlined above:
http://archone.tamu.edu/~ENDS205/LECTURE1.ppt

http://archone.tamu.edu/~ENDS205/LECTURE2.ppt

http://archone.tamu.edu/~ENDS205/LECTURE3.ppt

http://archone.tamu.edu/~ENDS205/LECTURE4.ppt

http://archone.tamu.edu/~ENDS205/LECTURE5.ppt

http://archone.tamu.edu/~ENDS205/LECTURE6.ppt

http://archone.tamu.edu/~ENDS205/LECTURE7.ppt

http://instruct.westvalley.edu/clancy/design32b/lect01.ppt

http://instruct.westvalley.edu/clancy/design32b/lect02.ppt

http://instruct.westvalley.edu/clancy/design32b/lect03.ppt

Mod-Rights:
The 1st experiment, Wikitecture 1.0 was not really a true Wiki in the sense that contributors could not modify or delete the contributions of others. What resulted, although interesting in its own right, was an amalgamation of ‘stuff’ with not no overall coherency or unity.
Image of Wikitecture 1.0

Image of Wikitecture 1.0

This next experiment however, we want to ask all the contributors to turn on their Prim’s[1] permissions so their fellow contributors can modify and evolve the design over time. Obviously the quick answer, to allow your fellow contributors modification rights, would be to grant them permission by checking the ‘can modify my objects’ box in your friends list. Although this would be ideal for collaborating on this Wikibuild, we run the risk of a rogue ‘griefer’ deleting a fellow member’s creation somewhere else in SL’s world. So until SL allows citizens mod-rights to certain people in certain places, we have to take a few additional precautionary steps.

In order for all the members within RLASL to modify their fellow member’s contributions, all the prims within the Wikibuild must have the following permissions turned on in the‘General’ tab of their ‘Build’ window.

The following image illustrates:
permissions-dialog-box.jpg

‘Group:’ should be set to ‘RL Architects in Second Life’

(A newly created object will take on your ‘Active’ group name. —i.e., if you make ‘RL Architects in Second Life’ your active group it will be the default group with every new prim created.)

Check on ‘Share with group’

(Do not however click on the ‘Deed…’ button and deed the object to the group. If there are scripts associated with group owned objects there’s a chance they may not work properly, considering most scripts rely upon the object to be owned by a singer owner.)

Turn on ‘Modify’ and ‘Copy’ under ‘Next owner can:’

Turn on ‘Resell/Give away’

(In order to allow others to copy the Wikibuild (or past achieves) into their inventory and rerez them somewhere else to work in private, ‘Resell/Give away’ needs to be turned on.)

Unfortunately, and I may have missed a way of doing this, you cannot set these permissions as the default mode and have all new prims take them on initially. —i.e., newly created objects will default back with no permissions. To get around not setting these every time, you can either copy the permissioned object and change it while still preserving the permission settings or when done building for the day, select all your objects and change the permissions at one time. Whatever is easier for you.

Unfortunately, although contributors will be able to copy the objects of their fellow designers, they cannot use the object’s associated texture on a newly created prim—since they do not have the texture in their inventory. If you find yourself in this situation, do one of the following: either copy the prim with the desired texture and change it’s ‘building block type’ into the prim shape you want or just ask the person who made the prim originally and see if they can send you the texture.

Prim Conservation:
To insure that all the stuff in SL uploads and downloads evenly for all users, SL puts a limit on the number of Prims you can have on your property. As a result, all builders in SL are faced with the challenge and art of trying to convey the most, with the least amount of Prims. Employing a wise use of textures can sometimes substitute for the need to physically model the object in SL. For instance, a transparent texture with mullion patterns could be used instead of actually modeling the mullions in world or instead of using 4 prims to outline a typical window, use one box prim with the middle hollowed out. Other areas that might benefit from a judicious use of textures might include: fences, siding, and roofing patterns. As a general rule: Anything that’s small and repeats often is a prime opportunity for a wise use of textures.

In the 3,456 sq. meter area allotted for this Wikibuild, SL allows for a maximum of 790 prims. Yes, this is a very tight number, especially if you’re used to the seemingly infinite number allotted in any other modeling programs. Although I’m sure as bandwidth increases in the future this number will only go up, but for know please be conservative with your prim use.

For those who want to create transparent textures this tutorial is very helpful:
http://www.sluniverse.com/kb/article.aspx?id=10199

An image of the building site:
rlasl-plot.jpg

Dimensions of the land plat.

rlasl-plot2.jpg

Building with an Off-line Modeller:
Many have asked the question whether it’s possible to import third party models such as Maya, Blender, and Sketchup into Second Life. The answer is yes, but the elaborate conversion process you have to go through, with the few beta programs out there, is sometimes more work than its worth. The following is a list of the current conversion programs under development, but unless you have a warm affinity for the programming code you’ll have to cut and paste from one program to another, you might be better off learning to model in SL proficiently.

From Maya:

From Blender:

From Sketchup:

From Max:

If you do, however, use an offline modeler, make sure you approach the building process as though you are building in Second Life, —i.e., avoid curvaceous nurbs and surfaces; stick with primitives.

A Tool to Rank and Build Consensus around the Design:
So by what means do we, as a community of designers, determine how the community feels about the contributions of its members and as a result what design direction would make the most contextual sense? Ultimately in later phases of the Wikibuild experiment we would like to write a LSL script of some sort that would allow contributors to quickly rank and comment on what aspects of the project are working or not, but in the meantime let’s develop a rudimentary ranking system with the technology that’s currently available—a mashup of sorts. RLASL has set up a Flickr account called ‘Studio Wikitecture’, where contributors can upload snapshots of certain locations of the Wikibuild and be able to comment on what aspects of the project, in their eyes, either work positively or negatively. In addition to posting comments under the images, contributors can ‘post a topic thread’ to argue more specific points as well. Along with acting as a forum for comments, individual designers can elaborate on the logic behind their designs as well—in an effort ultimately to bring their fellow designers around to their way of thinking. And finally, to help the community quickly access what aspects of the design are either working or not, RLASL will periodically divvy up the individual posts into the following Flickr sets:

(=)Debated Topics(=)

(-)Negative Comments Overall(-)

(+)Positive Comments Overall(+)

If you do not want to give any textual feedback or even in addition to, a good way for us to tally quickly what design direction the group favors, would be to use the ‘Add to Faves’ button on the upper right of any Flickr image (see the following image). Along with positive comments, favoring images would help RLASL determine with more confidence which images should be moved to the (+)Positive Comments Overall(+) Flickr set.

Using the ‘Add to Faves’ button

favorite.jpg

Uploading the snapshots to the ‘Studio Wikitecture’ Flickr account:

Option #1: Sending Snapshot via email:
(because Flickr does not accept BMP files, you cannot send the snapshots via the ‘send a postcard’ function in SL. You have to download them to your hard drive and convert to a JPG before sending them off to Flickr.)

  1. Take a snapshot(s) of whatever portion of the Wikibuild you’d like to comment on and ‘save [the] snapshot to hard drive’
  2. Convert the snapshot file from a BMP to JPG format. This can be done with a number of programs; such as Adobe Photoshop or Microsoft Paint. Use XnView if you’d like to batch covert a number of BMP files all at one.
  3. Attach the JPG file(s) to an email with the following address: next00beyond@photos.flickr.com. (This is the email address Flickr has assigned to the ‘Studio Wikitecture’ account.)
  4. Use the ‘subject’ and ‘body’ of the email to write a little blurb explaining the rationality behind your design—as exhaustive or as brief as you want.
  5. send away.

 

Option #2: Sending Snapshot to Flickr via blogbud.com:
(This method might be a little more cumbersome on the front end, but once setup, it avoids converting from BMP to JPG format. In addition, since your posts will not only go to the Flickr account, but the main Bloghud feed as well, Wikitecture 2.0 might garner a little more interest from the outside community—potentially bringing in additional contributors. One drawback, however, is the images come in rather small (258×345) in Flickr.

  1. Go to http://bloghud.com/ and create a Pro Version account, which will cost you around US$ 3.70 (L$900). (Unfortunately you cannot send images to Flickr with their free account.)
  2. They will ultimately send you to the following slurl link to pick up a HUD (Heads-Up Display) called blogHUDPRO: http://slurl.com/secondlife/Nooribeom/181/186/23
  3. After you follow their not so friendly setup instructions and have a fully operable account, go to ‘manage my bloghud.com profile’ on their website and enter in the ‘Studio Wikitecture’ Flickr address: next00beyond@photos.flickr.com. (Unfortunately, Bloghud does not remember multiple Flickr addresses so if you already use Bloghud to send photos to another Flickr account, you’d probably be better off using the first alternative and sending snapshots via your email.)
  4. After all is said and done you can finally send snapshots via the ‘send a postcard’ function in SL to the Flickr account using Bloghud’s email address: pix@bloghud.com. Got that?… me neither.

As you can tell, this is not the most ideal method for tallying the thoughts and opinions of the group, but it’s a start. As hinted at before, please use this Wiki to offer any suggestions or ideas you may have to improve this process, such as other mashups or possibly even a ranking script.

Archiving:
As a contributor, we ask that at the end of your work day, that you save a copy of the entire Wikibuild (with your modifications, of course) to the Archive Kiosk that’s near the foot bridge to ‘Crescendo Design’s Eco-friendly Neighborhood’. In this way, if the community, via a demonstrable Flickr Forum consensus, decides to ‘roll-back’ the design or if individual contributors would like to elaborate on an old idea, they have onsite access to past iterations of the design.

Image of ‘Archive Kiosk’

archive-kiosk_001.jpg

If you’re not familiar with how to save prims inside other prims, the following steps should help. Here’s the short version: Take a copy of an existing ‘archive plate’ and rerez it anew onto the next rung of the ‘archive kiosk’. Replace the previous contributor’s archive with your newly updated Wikibuild design. Replace the texture image attached to the ‘archive plate’ with an updated image illustrating your work. If so inclined, please leave a little blurb explaining the rationality behind your modifications within the attached notecard called: -Notes on the Design <don’t rename>.

Here’s a longer version of how to archive at the kiosk:

1. SELECT all the prims and objects that make up the Wikibuild

2. Right click on any of the prims to display the pie menu… click on ‘More>’ and then click on ‘Take Copy’. A copy of all these prims and objects will be sent to your inventory under the ‘objects’ folder and simply named: ‘object’.

3. Right click on the ‘object’ to rename. Pick any naming convention that you like; including you name and date might help.

4. ‘Upload a snapshot(s)’ of either the entire Wikibuild or the areas that you modified. It will be sent to your ‘Photo Album’ folder in your inventory.

5. Go over to the ‘Archive Kiosk’ and right click on the most recently dated ‘Archive Plate’ to display the pie menu and click on ‘More>Take Copy’. A copy of the ‘Archive Plate’ will be sent to your inventory.

6. Drag the ‘Archive Plate’ from your inventory into the world and reposition on the next rung of the ‘Archive Kiosk’. (note: The script that gives the UTC date and time only works when the ‘Archive Plate’ is rezzed in this manner.)

7. Right click on this newly rezzed ‘Archive Plate’ and go to ‘Edit’

8. Go to the ‘Content’ tab in the ‘Build Window’ and delete the last contributor’s Wikibuild Archive, do not, however, delete the following script: ‘Date Archive Prim was made’

9. Drag the Wikibuild Archive that you made and renamed in steps 2&3 into the ‘Content’ tab.

10. Optional Step: Open the Notecard in the ‘Content’ tab called: -Notes on the Design <don’t rename>. Within it, please add on to the running dialog with a little blurb explaining the rationality behind your design. See following example. In addition, send this little blurb with some pertinent snapshots of the Wikibuild to the Flickr sight dedicated to this Wikitecture experiment—as mentioned in the previous section. Upload blurb and images via your email with this email address: next00beyond@photos.flickr.com

 

**(Because Flickr does not accept BMP files, you cannot send the snapshots via the ‘send a postcard’ function in SL. You have to download them to your hard drive and convert to a JPG before sending them off to Flickr—as mentioned in the previous section.)**

An example of the running dialog within the Archiving Notecard:

 

–Theory Shaw: (4/11/2007 – 2:52 AM)

example text:

but i really think…

i agree that was a weakness…

i like Indie’s…. so i…

 

–Indie Nyle: (4/11/2007 – 2:48 AM)

example text:

well i thought this…

i modified your…

i deleted… because

why theory… why?

 

–Theory Shaw: (4/11/2007 – 2:42 AM)

example text:

I was trying to…

I was playing off…

I did this because…

I think…

wouldn’t it be nice…

 

 

11. Go to the ‘Texture’ tab and replace the previous contributor’s snapshot with the one you made in Step 4.

12. Done.

Building in a location off-site:
If you prefer to take a copy of the Wikibuild somewhere else, such as a Sandbox, to work on it in private, please, before you update the ‘live’ build, make sure someone hasn’t modified the live build during your absence. If this be the case, please try your best to incorporate the other contributor’s modifications into your own. If by some remote chance, the two (or more) designs are too different to merge together nicely, please document your design via images and comments in the dedicated Flickr account and archive your design at the ‘Archive Kiosk’. In order to get the community to weigh a judgment as quickly as possible between the two (or more) designs, ‘Create [a] New Notice’ within the RLASL’s ‘group information’ window and explain that a conflict has arose and you’d like the community’s assessment as soon a possible. As you can see, from the amount of jockeying this might cause, it might be safer to stay onsite to make your design modifications.

Payouts:
What if this process of collaborative design does ultimately lead to a viable way to design architecture? How will you get paid, if the criteria for establishing the weight of one’s contribution is somewhat subjective? Although finding the criteria for logically dividing the work is almost impossible, especially in creative fields, we believe if you allow the community to vote on each other’s perceived contribution, however subjective their individual assessment might be, when averaged out, a fair and balanced assessment will most likely result. Although a small gesture, RLASL would like to put forth L$80,000 Linden Dollars (US$300) as a payout for design services rendered by the group; the distribution of which will be determined by group vote. The final vote will occur at the end of the month long design charrette. Since it would appear that the community will consult the ‘Studio Wikitecture’ Flickr Forum to help inform their votes toward the payout percentages, it would seem advantageous to document as much of your work within this forum as possible.

(I’m sure this is relatively simple as programming goes, but if anyone would like to offer up a website that would automate this task of taking votes and tallying the results, please let me know. If not, I will most likely just request the vote through email and I’ll tally the results manually. Ideally I would like to avoid any manual tally to prevent any perceived conflict of interest. )

Forking the Design:
What if, as the design evolves, factions form that cannot reach a consensus in the project’s continued design direction? In that case, not unlike open source software, the project can fork off into two separate divergent designs. Obviously we would like to avoid this since it would take a substantial amount of momentum out of the project, but on the other hand we do not want to squelch what could very well be a viable improvement of the design as well. Unfortunately, due to available land restrictions, Architecture Island can only host one ‘live’ built at a time. If the project does indeed fork, someone will have to offer land to host the additional project. The determination of what project goes where, will be left up to group vote. To give further incentive to stick out the evolution of one design, the payout can only be divvied up amongst the contributors of the one project that wins the community’s vote.

Adjusting the Scale of Your Contribution:
Although this will be hard to regulate, we ask that the magnitude and scale of modifications to the design become less and less as we approach the end of this charrette. —i.e., if we are three weeks into the design, reconceptualizing the schematic layout of the building might be counterproductive. The community will mostly likely self-regulate this from happening however.

Open Questions:
The following are open questions that this experiment will look to answer. And as mentioned initially, as this experiment evolves, if you have any other questions you’d like to post, or modifications to the program in general, that you think might help inform this and further Wikitecture experiments, please do so at the following Wiki pages.

Wiki for this Program and Protocol:

Wiki for Refining the Tools for Building Design Consensus:

Wiki for the Questions this Experiment Poses:

Open Questions:

Will the aggregate of a diverse pool of contributors, with their varying view points on design, produce a final project of any aesthetic worth or will it just be an amalgamation of stuff with no overall coherency?

Since computer code or encyclopedic entries can be modularized into bite-size pieces it’s easier for individuals to make small contributions, that when aggregated, are more than the sum of their parts. Since the act of designing cannot easily be divided up into bite-size tasks, will an open collaborative approach to architecture even work?

What if this process of collaborative design does ultimately lead to a viable way to design architecture? How will you get paid, if the criteria for establishing the weight of your contribution is somewhat subjective?

How could using the Flickr account to log the history of the communities viewpoints be improved upon? What other types of ‘mashups’ would better convey the community’s design intentions?

This project is strictly community driven—i.e., the community determines the design will evolve. When, however, you have a client driven project, where the client is calling out the design direction, will the community be less apted to participate? Or could they possibility be more willing to participate knowing they are not at the whim of a ever changing landscape of design criteria?

Will architects, who historically have been individualistic by nature, even want to participate in a process where their contributions could potentially be watered down?

Will this be quicker than the conventional way to develop a design?

Would RW clients be open to a community of designers designing their projects?

With so many cooks in the kitchen, so to speak, will the design evolve into a lowest common denominator of conservative mediocrity?

If this experiment results a project worthy design, can you continue utilizing a Wiki approach in later phases of an architectural project; such as DD (Design Development) and CD (Construction Document) phase?

 

One Last Note:
I sincerely hope that this approach to designing architecture creates a project more than the sum of its parts. If so, could small neighborhoods, or even municipalities use this approach to bring their residences further into the design process—creating an environment that, as the great urbanist Jane Jacobs coined, “is multidimensionally diverse— one that does not just cater to a single industry or a single demographic group but that is full of stimulation and creative interplay.”

And finally, if this experiment does prove itself on some level, we would like to extend an invitation to any real world clients who would like to offer up their next real world project as the centerpiece in the 3rd Wikitecture experiment? The design, of which, will be more client driven, verses the community driven approach this experiment illustrates. If so, please contact either Keystone Bouchard or Myself (Theory Shaw) via an IM in Second Life. We would be excited to have a real world setting to demonstrate the potentials of a Wikitecture approach in architecture.

We would like to thank the community in advance for their contributions and we hope, if at the very least, this experiment reveals in some small fashion the potential uses metaverses, such as Second Life, might have for not just architects, but any for anyone affiliated with the building industry.


[1] “Prim”= primitive. A primitive is a basic shape: cube, sphere, torus, and so on. Everything you can build in Second Life is made up of primitives.