You are currently browsing the category archive for the 'Uncategorized' category.
We really, really need your help on this one! We are confident that if the readers of this blog collectively vote as a unified voice to push 3D Model Interoperability as a priority item for Linden Lab, we will be heard. You all know that Importing and exporting models is currently the biggest bottleneck preventing architects and designers from using Second Life as a tool in professional practice, and Linden Lab’s public Jira system is the perfect way for us to make it clear that this is a must have feature.
So, please, please, please take a minute and log in to Jira and vote on the following issue: http://jira.secondlife.com/browse/SVC-2634
To vote, go to the left margin on that website and click on ‘Voting:’
You will have to Login first. That’s it.
Spread the word! Post this on your own blog, and link to this page! Let’s do whatever it takes to raise the priority level on this! If you have any other ideas about how we can move this forward, feel free to leave comments!
It is with great pleasure I bring you the news that Studio Wikitecture’s entry in the Open Architecture Network Challenge was awarded the ‘Founder’s Award’ as well as ‘3rd Place’ for our design of the Nyaya Tele-Medicine facility in Western Nepal. The announcement was made this morning.
Architecture for Humanity awarded its Founders Award to the third place Asia challenge finalist, Studio Wikitecture, for embracing a truly collaborative way of working using online crowdsourcing and Second Life as a way to create a highly participatory design approach. Source
I want to direct a big ‘congratulations’ to those individuals that contributed, on whatever level, to the ultimate success of this entry. Well done! In particular I would like to thank the following for their dedicated contributions.
Jon Brouchoud - (Keystone Bouchard in SL)
Roger Wellington-Oguri - (Omei Turnbull in SL)
Roberto Carretero - (Otrober Breda in SL)
Michael DiTullio - (Far Link in SL)
Simone Riccardi - (Turboy Runo in SL)
Ethos Erlanger in SL
Chip Poutine in SL
I would also like to thank the programming gurus at i3dnow for helping us develop the 3d-Wiki technology we used to help facilitate this whole process. With all the contributions made throughout the process, it would have been a virtual impossibility to build a consensus without it.
And finally a shout out to Kirsten Kiser from arcspace for generously donating a large part of her Second Life island to this project.
We’ve definitely come a long way since asking the question: Can the design and production of architecture learn anything from the open and decentralized methods of production demonstrated in projects such as Wikipedia and open-source software. We certainly learned a lot since the early days of Wikitecture 1.0 and 2.0. I have no doubt Wikitecture 4.0 will prove just as successful.
Thank You, Again.
Ryan Schultz
We couldn’t have said it better ourselves (though we’ve tried!) - the power and potential of mass collaboration and creativity is becoming increasingly evident, and this video outlining the ideas in Charles Leadbeater’s new book explains it incredibly well:
(Update: If importing 3D models in Second Life is important to you, please vote for this issue on Second Life’s Issue Tracker: http://jira.secondlife.com/browse/SVC-2634. You’ll need to login with your SL name and password first)
I’ve been using Second Life for a number of years now to run experiments, through our ‘Studio Wikitecture’ group, to see if a Metaverse, such as SL might one day act as the platform for collective intelligence in architecture and urban planning. I’m also an active member of the ‘RL Architects in SL’ group. As you can imagine, most of the members that compose these two groups are architects. What I have found, participating in these groups over the last year or so is that new members are always excited about using Second Life as either a collaborative tool or as a platform to exhibit their work. Unfortunately, however, their interest soon wanes when they find out there’s no easy way to import in models from third party programs. I realize there’s a number of grass-roots initiatives out there that have developed rough and crude ways to import from the following:
Although, I give my utmost respect to the programmers that have developed these projects, to say they are crude, is to pay them a compliment. What invariably happens is that after sharing these links with the many people that ask, they come back (if they come back at all) even more confused and frustrated having labored through the elaborate and evolved process of copying and pasting pieces of code back and forth between one program and the other. The process is about as easy as painting with rice grains.
Having had a number of conversations over the year with people about this, I can say with confidence, that SL’s lack of portability is the number one hurdle for our demographic and the main reason why many people never come back. Although speculation, I would imagine this is a major hurdle for other groups as well.
What I don’t really understand is why this issue is not pushed more by the SL community at large. I have noticed there were a number of issues posted on SL’s Issue Tracker that call for portability of a number of various file types, such as .OBJ, .3DM, .3DS, .DXF, & .DAE.
What I don’t really understand is why, firstly, the overall SL community is not voting on this en masse and secondly, why have some of these grass-roots initiatives outlined above, just withered on the vine? Some of these projects are over two years old, with no sign of life or continued evolution since they were first posted.
Having been in the middle of this conversation for awhile, it seems the standard responses usually involve two factors: technology and/or SL’s economy—Technology, from the aspect that it’s currently still too difficult to do and economically, from the aspect that the sudden influx of new models would dilute the value of existing in-world creations, resulting in a negative impact on SL’s economy. Although I’m sure there are more reasons, these seem to be at the forefront of the discussion.
What confuses me, from my perspective anyways, is that these reasons still don’t seem plausible to me and I’m found wondering if I’m missing a valuable part of the equation.
First, although I have a limited background in programming, it appears from the existence of these grass roots projects, that portability is indeed obtainable. Having dabbled a little with each project above, I realize the process is laborious—cutting and pasting code from one program to the other.
I also realize that most of these conversion programs drastically simplify the form when imported into SL, such as textures being stripped off, and meshes and certain objects such as cylinders and sphere’s being simplified down to plain ‘box’ prims in SL. Although these are indeed hurdles, the technology is currently there to do this on a very limited basis.
What I don’t understand, is why these projects haven’t evolved into a more user-friendly format after the years they have been in place. This is just a lack of user-interface design verses a lack of back-end programming. Even though they are crude and might only import texture striped SL boxes in some cases, i know that I, as well has a horde of others, would still jump at the chance to have access to a tool like this and in most cases would actually pay good money for such a thing.
On to the economic end of the argument. I guess I can see on the surface, why a number of residences might be fearful of a world where seamless importing and exporting becomes the norm. I would imagine their argument springs from the fear that they either think their creations would be diluted by all these new models or that their creations could easily be exported and in turn imported, further diluting their value. I think these are legitimate concerns, but are there not ways of regulating this? Could you not add an additional layer of modifications rights that would give the owner of the in-world object the choice on whether they allowed subsequent owners to export out their creations?
From the importing perspective, yes, I’m sure such functionality would initially effect the market. The problem is however, that in the long run, the longer SL holds out on this functionality, the more negatively it will impact the economy, that is, when they finally do implement it. I’m not an economist, but I would imagine this is the same phenomenon you see when age old tariffs are removed and the economy in which they were trying to protect in the first place, finds itself unprepared to compete in the more innovative and efficient economy that was growing up all around them the whole time.
The assumption here, of course, is that they will do this eventually. The reason being, I believe, is that they will be forced to from market pressures from other virtual worlds offering portability as standard service and perhaps. In the end, perhaps this is exactly the reason why SL hasn’t offered this service yet. There’s no real viable competitor yet.
Although part of the reason for writing this post is to rant a little, my main objective is to start a conversation around why you don’t think portability has become common place for the end-user by now. I just wanted to share my confusion with everyone and see if there are others that are either just as confused, or perhaps have a more nuanced answer to this problem.
And by all means, if this too is a thorn in your side, please place your vote on Second Life’s Issue Tracker. Pick your poison. .OBJ, .3DM, .3DS, .DXF, & .DAE. Voting is easy, just login in first.
And if you’re a developer, just know that I’ll be the first to put my order in and I’m sure I wouldn’t be alone. The market seems to be begging for it.
Thanks to all that have been so patient over the last couple weeks while we worked out some of the major kinks.
Can mass collaboration and collective intelligence improve the quality of architecture and urban planning?
We are happy to announce that, Studio Wikitecture will continue to try to tease out this question, via it’s 3rd Wikitecture experiment kicking off officially on Nov. 7th. To accommodate those in different time zones, there will be two different times: Wednesday, Nov. 7th @ 9:00am and 6:30pm PST/SLT.
(post Nov. 7th: Here’s a link to the transcript of that of kick-off meeting. It goes into a more extensive step by step on how to operate the in-world interface: http://studiowikitecture.wikidot.com/kickoffmeeting)
The project on which this experiment will center around will be the competition recently announced by the Open Architecture Network. Competition sites range from a medical facility in rural Nepal, a media lab and library in the slums of Nairobi, or a fair trade chocolate factory in Ecuadorian Amazon.
Since the OAN is an “open-source community dedicated to improving living conditions through innovative and sustainable design”, we thought it would be a perfect opportunity to submit an entry for this competition that is, in turn, designed and composed in the same collaborative and open-source fashion.
We would be happy for you to join the next experiment and help us design this collaborative competition entry. You don’t need any experience in architecture, engineering or construction to participate. We actually believe the more diverse the pool of contributors, the better. You will need, if you don’t already, a Second Life account. Registering is easy.
Once you have downloaded the Second Life application, registered an account and log in, press the ’search’ key on the bottom of your screen (it looks like this: ). Look for the group ‘Studio Wikitecture’ and click ‘join.’ Enrollment is open to all.
After you have joined, click the following link for a ‘teleport’ to the Wikitecture 3.0 Parcel (link), which was generously donated by arcspace.com. Once there, ‘touch’ the base of the ‘wiki-tree’ interface, which looks like the following:…
to get the password for the website.
For the login: use your full ‘Second Life’ name.
If you have an problems, don’t hesitate to IM either Keystone Bouchard or Theory Shaw in-world and we’ll come by and help you.
A Brief Overview of the evolving technology behind Wikitecture 1.0, 2.0, and 3.0
We are not only excited about the project, but the new website and in-world interface (not operational, until nov. 7th) that will allow everyone to better communicate and collaborate with each other over the duration of the project’s two month time frame. Along with the following description, this video, provides a nice overview of the technology behind Wikitecture 3.0 as well.
Over the last year, we have been using the virtual world of Second Life as a platform for conducting ‘Wikitecture’ experiments to work out the procedures and protocols necessary to harness a group’s collective intelligence in designing architecture. We have already conducted 2 experiments within Second Life to explore this idea of ‘open source architecture’. The videos of their final form can be found here: 1.0 & 2.0. The following gives a brief overview of the evolving functionality behind Wikitecture 1.0, 2.0, & 3.0.
1.0
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 - a result we expected.
2.0
In the 2nd experiment, we asked contributing members to enable full-permissions on every object they added. This new protocol enabled designers to add/modify/delete each other’s designs. In addition, we set up a Flickr Account that allowed contributors to upload descriptive snapshots of their designs and leave feedback as well. With Wikitecture 2.0, we also introduced an archiving system, where members, through community consensus, were able to roll-back the ‘live’ design to previously saved iterations. Although this system was still rudimentary, the resultant design was far more unified and coherent than Wikitecture 1.0.
3.0
For our 3rd experiment, however, we have continued to try and improve upon this underlying technology. In teaming up with i3D inc., experts in creating virtual applications that cross the 2D/3D divide, we have developed both an in-world interface (’wiki-tree’) and external website that continually communicate with each other. From the in-world perspective, contributors are able to archive their particular design into an abstract ‘leaf’ within a 3-dimensional ‘tree canopy’. As this canopy grows, the branching network of ‘leaves’ communicates to other designers, how related all the different designs are to each other.
image of the ‘leaf canopy’. Although not always the case, the general rule will typically apply: one ‘archive leaf’ = one design iteration = one contributor.
In addition, to fully communicate their vision and rationale behind their designs, this interface will allow contributors to take snapshots of their designs and, combined with descriptive commentary, upload them to the external website.
Since there will be multiple designs iterations within the ‘tree canopy’ and only a limited amount of land, the ‘wiki-tree’ interface, by touching the leaves, will allow members to ‘rez’ out the designs, one by one, onto the viewing parcel. Once rezzed out, viewers are then able to immerse themselves, 3-dimensional, in the design. In addition, to augment the experience of actually occupying the space, the three screens in the viewing kiosk near the ‘wiki-tree’ will allow users to cycle through the snapshots and comments associated with the active design on the viewing parcel as well. This viewing kiosk will become especially helpful for those who want to communicate their designs informally with a smaller group of individuals.
The ‘wiki-tree’ allows the community, in turn, to vote and comment on their fellow contributor’s designs.
Other than cycling and rezzing out the individual designs from the ‘archiving leaves’, The website component will allow users all the same functionality as the in-world interface. In other words, through the website, members can vote and add comments, as well as upload images they would like to associate with their saved designs.
What if this collaboratively designed entry actually wins this OAN competition? How will the reward money actually be divvied up amongst the contributors? If you worked on the last Wikitecture experiment, we will be using the same system whereby we ask all the contributors to assess what percentage they feel they have contributed to the design as well as what percentage they feel others have contributed. The general idea being, that when everyone’s assessment of each other is averaged out, however subjective it may be, a pretty fair judgment is made to how much (compensation, ownership, IP rights, etc) should be dolled out to each contributor. If, in the event, Studio Wikitecture’s entry wins the competition, we will distribute the winnings in this manner.
Although this system of assessment is not perfect, we feel it’s a start. This is one component of the experiment we feel will need to be massaged here and there as we go forward and would love your input to help improve it. Throughout the next two months of designing and assessing, if you have an idea on how to improve either this contribution assessment procedure, or any other functionality for that matter, please let us know. We have set up a forum for such discussion: Feedback & F.A.Q.
Although, this collaborative platform is light years beyond what was used for the 2nd experiment, please be aware that it’s still somewhere between alpha and the prepubescence beta stage of development—we will most likely encounter our fair share of bugs.
Although running at a base level right now, certain features will not be available until Nov. 7th.
image of the ‘trunk’ of the ‘wiki-tree’ interface.
After tallying the results, the consensus for the best time to meet is: Tuesday, September 25th @ 9:00am PST/SLT. Here is the slurl link to the ‘Studio Wikitecture’ parcel in Second Life.
Although kick-off is not until Oct. 15th, we wanted to hold an early meeting to get a gauge who would like to participate as well as share some improved features projected for the new website and inworld voting/commenting system. In addition, we would like to hear your thoughts on which of the three ‘Open Architecture Network’ challenges we should pursue.
We are excited that the project the 3rd Wikitecture experiment will center around will be the competition recently announced by the ‘Open Architecture Network’. The ‘AMD Open Architecture Challenge’ is an open, international design competition. Its aim is to develop solutions for building sustainable, multi-purpose, low-cost technology facilities for those who need them most.
They have three challenges on which to choose from—a project based in South American, Africa, or Asia. We would like for the next meeting to get your opinion on which of the three we should pursue as a collaborative entry. The following are links to the specific competition briefs.
the South America Challenge…
the Africa Challenge…
the Asia Challenge…
general information about the OAN Challenge…
Since the OAN is an “open-source community dedicated to improving living conditions through innovative and sustainable design”, we thought it would be a perfect opportunity to submit an entry for the competition that is, in turn, designed and composed in the same collaborative and open-source fashion OAN is known for.
See you there.
What is ‘Studio Wikitecture’ Group in Second Life………………………………………………….
Studio Wikitecture is a ‘Second Life’ group composed of a diverse spectrum of individuals interested in exploring the potential of applying an Open Source paradigm to the design and production of both real and virtual architecture and urban planning.
What we’ve been doing………………………………………………………………
We have over the last 10 months been conducting Wikitecture experiments within Second Life to tease out the exact procedures and protocols one would need within a Metaverse to harness and aggregate a group’s collective intelligence in creating an architecturally noteworthy design.
Please go to this Flickr site to see the evolving snap shots from our last experiment…
Here’s a link to the program and protocol for this experiment as well…
In addition, here are some excerpts from a Manifesto written by Dennis Kaspori that outlines some of the salient points around an open-source approach to architecture.
Would you like to participate in the AMD Open Architecture Challenge on a global team of qualified and talented architects, designers and engineers? Studio Wikitecture invites you to just that.
In keeping with the spirit of the Open Architecture Network’s goal of ‘improving the living standards through collaborative design,’ we will be employing the next generation Wikitecture process in order to more fully enable true 3D collaboration by community members from around the world. In much the same way Wikipedia enables multiple contributors to collaborate on content creation, the Wikitecture process gives community members an opportunity to share ideas, edit the contributions of others, and to vote on the success or failure of proposed modifications.
Through a series of ongoing experiments during the past several months, the Wikitecture process has been evolving based on community participation and feedback. With this input, Theory Shaw has developed the ‘Wikitecture Tree’ concept, and we’ve hired the clever folks at i3Dnow to build it for us, which will include both inworld and web-based functionality. We hope to roll out this new platform just in time to get started on a collaborative Wikitecture competition entry for the AMD Open Architecture challenge.
The Wikitecture process currently uses the free to use, free to access virtual reality platform of Second Life to enable multiple contributors to share ideas and collaborate on design concepts.
If you are interested in participating, you’ll need to do the following:
1.) Download and install the Second Life client at SecondLife.com
2.) Complete the orientation course to help familiarize yourself with navigation, etc.
3.) Click on the ‘Search’ button on the bottom of your screen. With the ‘All’ tab highlighted, search for either ‘Keystone Bouchard’ or ”Theory Shaw’ - the organizers of the Wikitecture project. Click on their name, and you’ll see an ‘Instant Message’ button in their profile. Send either of us a message, and we will get back to you shortly with more details on how you can join the community.
4.) By clicking on the ‘Map’ button and searching for Architecture Island, you will be able to teleport directly into the site location, and migth even run into other members of the in-world community who can help with any questions you may have.
Our official launch meeting will be September 25th @ 9 am PST/SLT on the Studio Wikitecture parcel in Second Life. Click here for the slurl location. - the event time will be determined by community consensus. Please send your vote to Keystone Bouchard in-world, or to jbrouchoud@gmail.com
We hope to see you there!
To join our project page on OAN, visit HERE.
To learn more about the architecture and design community in Second Life, visit The Arch blog
To see a video of Cameron Sinclair’s event in Second Life, featuring the Open Architecture Network’s Porchdog design, visit This YouTube site
To see the construction of the Porchdog in Second Life, visit: This YouTube site
“Only one thing is impossible for God: to find any sense in any copyright law on the planet. Whenever a copyright is to be made or altered, then the idiots assemble.” Samuel Clemens (Mark Twain), circa 1906
“Good artists copy; great artists steal.” —Pablo Picasso
The benefit of an open approach to architectural design is that you can play off and improve the design of others, which in turn, one would hope, benefits the lives of all—as should be an architect’s ethical tenant. The standard ‘all rights reserved’ approach to licensing, however, limits this ability to create derivative works for the benefit of all. The creative commons, however, offers an alternative approach to IP rights that facilitates this idea of remixing the work of others—as described in the following quote from their website:
This process of generically giving permission in advance – use my content so long as you attribute me, or engage in non commercial use, or make no derivative works or share your improvements with the broader community – allows users upon seeing content labeled with the CC symbol to know exactly, at that instant, what right they have to reproduce, communicate, cut, paste, and remix.
The following describes each of the six main licenses offered when you choose to publish your work with a Creative Commons license. They are listed starting with the most accommodating type you can choose and ending with the most restrictive.
Attribution (by). Lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation.
Attribution Share Alike (by-sa). Lets others remix, tweak, and build upon your work even for commercial reasons, as long as they credit you and license their new creations under the identical terms. This license is often compared to open source software licenses. All new works based on yours will carry the same license, so any derivatives will also allow commercial use.
Attribution No Derivatives (by-nd). Allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to you.
Attribution Non-Commercial (by-nc). Lets others remix, tweak, and build upon your work non-commercially, and although their new works must also acknowledge you and be non-commercial, they don’t have to license their derivative works on the same terms.
Attribution Non-Commercial Share Alike (by-nc-sa). Lets others remix, tweak, and build upon your work non-commercially, as long as they credit you and license their new creations under the identical terms. Others can download and redistribute your work just like the by-nc-nd license, but they can also translate, make remixes, and produce new stories based on your work. All new work based on yours will carry the same license, so any derivatives will also be non-commercial in nature.
Attribution Non-Commercial No Derivatives (by-nc-nd). The most restrictive of the six main licenses, allowing redistribution. This license is often called the “free advertising” license because it allows others to download your works and share them with others as long as they mention you and link back to you, but they can’t change them in any way or use them commercially.
From my understanding, the various licensing options boil down to the following two scenarios: Someone can make a derivative work, make money commercially, and not pay you a thing or the opposite, someone can make a derivative work and neither of you make money commercially. There is of course the scenario, where both parties are able to benefit by signing a commercial licensing agreement, but this is usually after the fact. With this arrangement, you run the risk, however, that the original licensor will not want to come to a fair and balanced assessment of each other’s contribution. With this potential risk loaming in the future, you would be less likely to even start a derivative work in the first place—there’s less initial incentive. If this is a public project, the public would, in turn, loose the opportunity of having a superior design (judged on many fronts, not just aesthetically), for less. Do we really need to reinvent the wheel with every project? So in pursuing this commercial licensing agreement are we not back to the same cumbersome legal wrangling we were trying to avoid in the first place by creating the CC? Can there be a CC license that finds a middle ground where people are open to use other’s work, but all parties benefit monetarily, without the intervention of a cumbersome legal process?
What if, however, there was a New Licensing option—somewhere between ‘Attribution Non-commercial’ and ‘Attribution No Derivatives’—that stated that you are free to pursue commercial gain without consent, but if you use the derivative work to make money, the payout percentages to all parties is assessed by the ‘community’ and not left up to the lawyers to determine? Under this license, I would have a little more confidence using someone else work initially, knowing that if my derivative work does indeed make money, that there’s a better likelihood that the community, on average, will make a fairer assessment of each other contribution, than if left up to the biases of lawyers and other interested stakeholders.
What is the community in this case? Perhaps, initially this community is composed of only those involved in the project—the originator and those that modify the design. If, however, through this 1st phase, a unanimous vote is not achieved, assessment would be opened up to another tier of paid editors and arbiters to make the final evaluation. Since this group of editors, would in turn get a small percentage of the project’s revenue, there’s more incentive for the original parties to come to an agreement. Perhaps in order to insure that this group of editors, on average, doles out a fair and balanced assessment, there could be a system in place where the editors in turn are ranked by those they are arbitrating for—i.e., you are able to rank the ranker so to speak. So, in the end, only the editors with the best rankings are allowed to participate in this process. Through this you are in essence placing more faith in the ‘Wisdom of Crowds’ to establish a quick and fair judgment, than you are in a traditional legal procedure.
I feel, if such a system of licensing were in place, people would be more apt at using someone else’s work from the very beginning, knowing that since the ‘community’ is establishing the percentage of authorship, they’d be more assured that everyone, in the end, would be granted a fair deal. I believe this method would not only allow good ideas to propagate themselves more prolifically in the world, through the continual process of refinement, they would also improve at a more exponential rate as well—a win-win scenario for all.
Imagine if you had a song, novel, or any piece of art for that matter that was already well liked by a majority of people. Now imagine if everyone was free to modify this piece of work to improve it in their eyes. What if people in turn were able to rank these derivative works of art? What are the odds that the most popular spin-off from this ranking process would be a work of art better than the original? If you believe, like I do, that we all benefit from a world where art is able to capture humanity’s true essence, than why, if this process does truly improve the end product, are we not embracing it as viable way to produce and refine art? Now imagine, instead of a song, novel, or piece or art being the centerpiece of this process, you have the design and evolution of an entire city as the central focus. Could we actually harness this collaborative filtering process to improve our built environment, perhaps even making it more sustainable?
Well, at a little more than half way through the month long experiment, the evolving building design is looking quite promising. I would like the thank all the contributors that have participated thus far.
I thought perhaps to make this Wikitecture Experiment less intimidating and to facilitate further contribution, it might be a good idea to boil down the extensive program and protocol to a few key points.
Key aspects of the wikitecture experiment:
Overall this experiment is set up to explore just how feasible a collaborative approach in design might be for the architectural profession. In this regard, we would like to invite anyone, with or without architecture experience, to contribute to the building’s design - please fell free to add, modify, or delete any aspect of the building you feel would improve the design—no matter how big or small.
Mod-rights:
Please, however, make sure your prims have the following permissions turned on so others may improve on your design as well:
• Set the ‘Group’ to ‘RL Architects in Second Life’
• Check on ‘Share with group’
• Check on ‘Modify’ and ‘Copy’ and ‘Resell/Give away’ under ‘Next owner can:’
Building Design Consensus:
Whether you’re a contributor or just someone that would like to comment on the design of the building, please take a snapshot(s) of the area you’d like explain or comment on and send it via email (jpg formatted), along with a little written blurb, to the following address: next00beyond@photos.flickr.com
Please go to the following Flickr website for a log of these ongoing comments: http://www.flickr.com/photos/studiowikitecture/
If, for instance, the community decides, through this forum, that a certain contribution has detracted from the overall design, the design can be rolled back to previously archived versions.
Archiving:
Although RLASL will periodically archive the project, for added assurance, please archive your contribution at the ‘Archiving Kiosk’ near the foot bridge. Archiving instructions are provided at the base of the Kiosk as well as at the following link.
To view a more in-depth write-up on this Wikitecture Experiment go to the following link: http://studiowikitecture.wordpress.com/2007/04/15/wikitecture-20-designing-the-architecture-of-architectural-design-collaboration/
Thank You.
Although Brandon Catteneo posted the following as a comment to the previous post, i felt, considering the level of thought and ideas within, I needed to post again for more visibility…
This is great! SL is spawning yet another revolutionary concept. I think this is an excellent idea, and I am very interested in seeing it take off. I’ve read the minutes on The Arch from your meetings. Obviously the scope of the task is large and will require a lot of grey matter to come up with standerds, but as far as using SL for the Wikitecture platform it is possible to accomplish this collaboration by engineering the workflow properly:
1) Each Project Needs a Project Manager:
Designer Dingson hit the nail on the head when he said “every team regardless of whether it is free colaboration or not - needs one thing for sure and that is a ‘leader’.”
Whomever owns the land is, by default, the PM. If it becomes too cumbersome you cut up the land into parcels and give each one a PM. If that is too much the PM designates an assistant PM for each separate structure (I will use the term ‘build’ from now on since that is what is used in SL).
The PM is responsible for the general management of the land and has the ability to delete or return any objects found thereon. He can change permissions on the land to prevent vandalism and act as POC for griefing incidents (to issue bans, etc.). Further, the PM acts as liaison and POC for the group, the Lindens, the creator/designers/builders (I’ll use the term ‘builder’ from now on since that is what is used in SL), and the community as a whole. It sounds complex but it really is not. See below:
2) Self-Determination is the Engine of Organization:
All builders want their creations recognized. Therefore, just as on Wikipedia, they need to adhere to some simple rules. If you do not properly format your text on Wikipedia it will be edited by someone else who will put it in the proper format. So too with Wikitecture. The builder must adhere to a few common criteria:
(a) Save Your Work: The builder will obviously save his own work into his inventory, and if he wants to prevent it from being deleted by the next person to come along he must also submit it to the PM (or his delegates). If the build needs to be ‘rolled back’ as they do on Wikipedia the PM can do that at anytime (and so can the community if the PM chooses).
(b) Use Comments: Just like on Wikipedia if you change something it is wise to add in some comments and (preferably) put some notes on the Talk Page about what you changed and why you changed it. In this case the builder simply jots down the changes in a ‘Builder’s Notecard’ and submits that to the PM along with the build.
(c) Use a Common Versioning Standard (CVS): Before submitting your build rename it to a new version. I would suggest the format x_ YYYY_MM_DD_b where x is the name of the build and b is the name of the builder. Thus the Catteneo Hotel would be called Catteneo Hotel_2007_03_02_Brandon Catteneo. If this is changed on March 14th of 2007 by Designer Dingson it would become Catteneo Hotel_2007_03_14_ Designer Dingson. (obviously this is just a proposal, and maybe this particular standard is adopted and maybe we decide on something else, but you get the picture)
(d) Prototype the Build: The concept of “shards” is great (if I understand it correctly). On Wikipedia you preview your work before you commit the edits, and so too should this be done on a Wikitechture build. Do your work in a sandbox or some other unobtrusive area, then replace the ‘live’ build with the one you have constructed. If it has changed since you were there last add your elements to the design. Ideally this will not be necessary (ideally), since builders can collaborate with the other builders working on that particular project.
3) Each Build is Accompanied by an Infoprim:
The Infoprim can have any appearance (maybe a spinning question mark “?” symbol outside of the build, or maybe an object within the build like a kiosk in the lobby in the example of the Catteneo Hotel), but the objective is to have an object that delivers a Builder’s Notecard with the revision history of the build, similar to what you have on Wikipedia. The PM is responsible for keeping this updated with the text in Notecards given to him by subsequent builders (simply cut n’ paste, save new, put in Infoprim). This is the bare-level requirement for the Inforprim, but it can also do much more.
Obviously, the Infoprim can also store previous builds - it is up to the PM. These can be Copy/No Mod/Transfer so that anybody can walk up and pull out a previous version, rez it, and look at the differences between the current version and past versions. It can also include a running commentary - a Community Notecard. A LM to the build (or any other place) can be placed in the Community Notecard. There can also be a Request Notecard for changes that are needed just like on Wikipedia.
Future upgrades to the functionality of Infoprims in general can be easily implemented by distributing the new scripts to the PMs, who will update them as with any build.
- - - -
So the process from the PM’s standpoint is simple: A build is created on land you manage, and the builder submits the build to you as an object in your inventory along with a Notecard. You save the builder’s Notecard, the build and a standard Notecard that has instructions, rules, contact info, etc. into an object of your design - this will be the Infoprim (make sure to designate it as a ‘give Notecard’ object). You place the Infoprim near the build with Copy/No Mod/Transfer. When a new version is dropped into your inventory by the next builder you simply update the Inforprim. Of course you can delegate tasks (such as placing Infoprims or updating the Notecards) so long as you have all the versions of your projects in your inventory.
As a PM you are obviously part of the group that owns the land. If the group decides, the PM can change permissions on the land so that nobody can build there. If builders want to update the current build they have to do it in a sandbox and then submit it to you and then *you* will go place the object. (This would be used in cases of persistent vandalism.) Also, the group can make a rule that all objects must be saved into a Group Only Mod object and this be distributed to all group members anytime there is a new version. This can be done in a ‘digest’ (e.g. daily/weekly/monthly) format if there is too much activity and people are complaining about being spammed, and maybe you have committees for certain aspects or areas.
From the builder’s standpoint it would look like this: Go to the build and take it into your inventory. Rez it (preferably in a sandbox), edit it, save it in the proper format, and then place it where it is going to be “live”. If you want it to stay and not be rolled back make sure to drop it on the inventory of the PM, and include a Notecard specifying what you did and why. All of this will be explained by touching the Infoprim, and all the previous builds will be available to you by opening the Infoprim and copying them to your inventory (if the PM chooses to allow it).
From the Community’s Standpoint: You come upon a build you think is great. The Infoprim will tell you all about its history, and you can also compare past versions if you wish. If you have suggestions or comments the info on who to give those to will be in the Builder’s Notecard (obviously), as will past commentary in the Community Notecard.
- - - -
So that’s my 2 cents, but hopefully this can be a basis for starting to move
What a great meeting last night. It’s reassuring there are others who are just as excited about the prospect of collaborative design in SL. If you missed the meeting, Keystone Bouchard has the transcipt posted at ‘The Arch’ blog. Here are a few questions/comments i had the other night. Still opened ended, but i thought i’d post them anyway. Please let me know what you think.
- What aspects of SL’s current interface can be harnessed to allow for smoother collaboration?
- Does SL’s newly open-sourced ‘viewer code’ present new opportunities to create a better interface for 3D-collaboartion?
- Is there a way, perhaps through a SL script, to quickly rank, at a glance, what others have contributed to the build?
- In turn, is there a way to quickly see at a glance what parts of the build are more popular with the group and which are not? Perhaps the ability to edit an object is turned on relative to its rank.
- Instead of having one incarnation of a build at any one time and space, provide individual ’shards’ (dimensions in a sense) that allow individuals in the community to collect and modify the objects from the shards of other contributors. These individual shards can in turn be ranked by the Wiki community to determine what general design direction the community as a whole is leaning toward.
- Would a stated goal or specific building program for this wikibuild help the community create less of a nebulous design ‘object’? Should we draw one up? What should it be?
- I might be misunderstanding his idea, but Lys Ware had mentioned, in one of our previous meetings, of composing a series of Hyperooms (or perhaps Hyperspaces) , similar to Hyperlinks, as a method to evolve a design. Would an overall design composed of these Hyperooms be too compartmentalized or could it be conceived that these Hyperooms could overlap with each other and in turn be modified by a specific author? Would some type of combination of Shards and Hyperooms work?
- How can we catalogue and categorize what Lys Ware referred to as Metadata, for a discipline as subjective as architecture? Could a looser interface be created that would allow designers to collect the multivalent ideas that contribute to the inspiration of a design?
Will the burgeoning 3D metaverse really provide a platform for collective intelligence in design and in particular, architecture? We assume it will. This blog, however, is dedicated to exploring and fleshing out the specific measures, protocol, and tools necessary, within the metaverse and in particular Second Life, to make this ‘Wikitecture’ concept a reality.
Although I wrote the following abstract for the ‘City of the Future’ architectural competition awhile back, it addresses the implications of what an Open Collaboration in Architecture might bring to the design of our cities today and into the future.
Innovation Happens Elsewhere:
There’s no better laboratory than reality to determine if an idea holds any merit. Unfortunately testing out big ideas, such as city planning, in the real world would be an unrealistic and an expensive gesture. What if, however, the virtual realm was able to model the sensory data of reality with such a fine-tuned level of fidelity that the two worlds would appear inseparable? Well considering the exponential increase of digital processing, it seems only a matter of time. So if and when this (vir)eality comes to pass, how will our future inhabitants plan what will most likely be the most complicated organism known to man - the city? Fortunately we don’t have to wait for the future to see an inkling of how this might take shape. The burgeoning Open Source paradigm, that has brought about immensely complicated projects such as the Linux Operating System, can offer clues as to how we can approach the task of ‘debugging’ our cities. Like today’s operating systems, the vast network of interrelationships within our future cites will become so vast, no overarching top-down visionary strategy can possibly address all the issues successfully. Not that power is necessarily bad, but it does, over time, inevitably become blind (through the phenomenon of ‘group think’[1]) to innovative solutions. Architecture and city planning, like many fields of knowledge, is not immune to this phenomenon. Jane Jacob’s urban theories from a journalistic perspective provide an excellent example of how common sense innovation can come from outside the system of ‘calibrated’ thinking. Our objective, if selected for this competition, would be to demonstrate that the localized, bottom-up strategies of the Open Source paradigm[2] can bring about an insured level of beneficial innovation toward the design of cities today and into the future.
To be specific, the venue in which we would like to demonstrate this Open Source strategy is a MMORPG (massively-multiplayer-online-role-playing-game) known as ‘Second Life’[3]. SL is not necessarily a game in the strictest sense because there’s no defined objective, but is instead, a white virtual-world canvass where ‘developers’ can design and build anything their imagination can muster either individually or collaboratively at the same time and space. Just as MUDs (text-based multi-user domains) have allowed for an unprecedented level of collaboration in forming Open Source projects such as Linux, so can metaverses, such as SL, offer a new way of approaching the ‘programming’ and designing of our 3-dimensional cities.
Although through this process, a visionary vignette of the future of Chicago will emerge, our core intention, which we feel is more revealing, is to highlight ‘how’ Chicago, as well as other cities throughout the world, could be designed in the future. We would like an opportunity to demonstrate on national TV, in the short time frame provided, how this Open Source paradigm can, at even the most basic level, create, as the great urbanist Jane Jacobs coined, a “city that 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.”
“Homogeneous groups, particular small ones, are often victim of what the psychologist Irving Janis called “groupthink.” After a detailed study of a series of American foreign-policy fiascoes, including the Bay of Pigs invasion and the failure of anticipate Pearl Harbor, Janis argued that when decision makers are too much alike¾in worldview and mindset¾they easily fall prey to groupthink. Homogeneous groups become cohesive more easily then diverse groups, and as they become more cohesive they also become more dependent on the group, more insulated from outside opinions, and therefore more convinced that the group’s judgement on important issues must be right. These kinds of groups, Janis suggested, share an illusion of invulnerability, a willingness to rationalize away possible counterarguments to the group’s position, and a conviction that dissent is not useful.”
James Surowiecki, The Wisdom of Crowds, (New York: Random House, 2004): 36-37
Perhaps overly simplifying the argument, the modification of a typical definition of Open Source Software is quite revealing nonetheless in how this paradigm can be applied toward a new approach in city planning.
By making the source code (model) for the software (city) available to all, any programmer (designer) can modify it to better suit their needs and redistribute the improved version to others users. By working together, a community of both users (citizens) and developers (designers) can improve the functionality and quality of the software (city). Filtered through the lens of the ‘Wisdom of Crowds’ the best ideas will eventually float to the top.
Ron Goldman & Richard P. Gabriel, Innovation Happens Elsewhere, (San Francisco: Morgan Kaufmann, 2005): 29
“Diversity and independence are important because the best collective decision are the product of disagreement and contest, not consensus or compromise. An intelligent group, especially when confronted with cognition problems, does not ask its members to modify their positions in order to let the group reach a decision everyone can be happy with. Instead, it figures out how to use mechanism¾like market prices, or intelligent voting systems¾to aggregate and produce collective judgments that represent not what any one person in the group thinks but rather, in some sense, what they all think. Paradoxically, the best way for a group to be smart is for each person in it to think and act as independently as possible.” James Surowiecki, The Wisdom of Crowds, (New York: Random House, 2004): XIX-XX
Although the following website has yet to be updated in last couple years, it does provide a wealth of information on how an Open Source paradigm can be applied to architecture. http://www.suite75.net/blog/maze/
A few article links that give an overview of what Second Life is and its implications.
http://www.chron.com/disp/story.mpl/tech/weekly/2478955.html
http://www.fourth-estate.com/2005/11/the_dessert_of_.html
http://www.wired.com/news/games/0,2101,65052,00.html?tw=wn_tophead_3
http://lindenlab.com/ProductFactSheet.pdf
http://www.escapistmagazine.com/issue/19/11
