<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">
<channel>
	<title>Comments for work</title>
	
	<link>http://work.permanentriot.com</link>
	<description>mostly play</description>
	<lastBuildDate>Wed, 01 Feb 2012 05:19:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/CommentsForWork" /><feedburner:info uri="commentsforwork" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:browserFriendly></feedburner:browserFriendly><item>
		<title>Comment on Infant insomnia visualization by the wife</title>
		<link>http://work.permanentriot.com/2012/01/infant-insomnia-visualization/comment-page-1/#comment-1430</link>
		<dc:creator>the wife</dc:creator>
		<pubDate>Wed, 01 Feb 2012 05:19:02 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/2012/01/infant-insomnia-visualization/#comment-1430</guid>
		<description>sadly most of the 1 1/2 - 2 hour chunks of awake time in the middle of the night actually *are* awake time ... it's only the 2-3 hour chunks that are (usually) missing data.  clearly something must be done.  I for one cannot survive on this little sleep.  I don't know how the baby is doing it.</description>
		<content:encoded><![CDATA[<p>sadly most of the 1 1/2 &#8211; 2 hour chunks of awake time in the middle of the night actually *are* awake time &#8230; it&#8217;s only the 2-3 hour chunks that are (usually) missing data.  clearly something must be done.  I for one cannot survive on this little sleep.  I don&#8217;t know how the baby is doing it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What Makes Design Computational by at0mb0y</title>
		<link>http://work.permanentriot.com/2011/07/what-makes-design-computational/comment-page-1/#comment-1237</link>
		<dc:creator>at0mb0y</dc:creator>
		<pubDate>Fri, 09 Dec 2011 17:56:01 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=530#comment-1237</guid>
		<description>Hi I really like your blog. I'm interested in the same stuff and I had the same reflexion about  the relation between these terminology that I would like to share.
 What do you say about the difference between Algorithmic and Parametric? they are in someways intricate in there application.  We can dumbly consider parameters as variable  and said that they are in algorithm. And in the other hand Parametric use algorithm to reach the goal of adapting the shape according to the parameters. (its really dumb definition, it's like defining programming as data aspect or the operation made on) 

What I want to express by this is: finally define by the use came at resume everything to everything. And as you said everything end to be digital design.

I think the definition should come from the intent in the use. If you want use computation concept as an inspiration of your design you are computational designer, or a computable pattern oriented designer. Even nice software with nice GUI or user friendly doesn't change the intent of their own design quest of a kind of rationality.
But this is not a mannerism this, I don't mean they will do everything with Vim or emacs from scratch to produce there design. They can use nice software, but the slight difference with other is : they are really interested in the concept brought by computer science (and in somewhat the comeback of the ghost of Alexander who had his part of influence on the computer science development.) They are looking on  the architectural concept friendly part in the computer science

 If you don't care about what happens inside the computer and you just want the power of the computation in your hand you are digital designer. And you inherit in some ways from the deconstructivist point of view

So to continue my definition by intent, I would say parametric-ism is a will of over control of your design. You want to control it in a very precise manner. This control help you to keep the cost, to adapt the project over to the tribulation of reality.

In algorithmic approach you want to loose a bit of control to be surprise by your own design. You research the generative and unpredictable aspects of algorithms. 

You can combine this definition to define your manner of design  : a digital algorithmic design (want to be surprise, use nature inspired algorithm _ More UCLA trend) or a computational algorithmic design (want to be surprise but want to fit in a logic of a rational design lying on computer science concept_ more MIT trend)

So now it's useful to have different name to express different things… It merge with the feeling of jojeg07</description>
		<content:encoded><![CDATA[<p>Hi I really like your blog. I&#8217;m interested in the same stuff and I had the same reflexion about  the relation between these terminology that I would like to share.<br />
 What do you say about the difference between Algorithmic and Parametric? they are in someways intricate in there application.  We can dumbly consider parameters as variable  and said that they are in algorithm. And in the other hand Parametric use algorithm to reach the goal of adapting the shape according to the parameters. (its really dumb definition, it&#8217;s like defining programming as data aspect or the operation made on) </p>
<p>What I want to express by this is: finally define by the use came at resume everything to everything. And as you said everything end to be digital design.</p>
<p>I think the definition should come from the intent in the use. If you want use computation concept as an inspiration of your design you are computational designer, or a computable pattern oriented designer. Even nice software with nice GUI or user friendly doesn&#8217;t change the intent of their own design quest of a kind of rationality.<br />
But this is not a mannerism this, I don&#8217;t mean they will do everything with Vim or emacs from scratch to produce there design. They can use nice software, but the slight difference with other is : they are really interested in the concept brought by computer science (and in somewhat the comeback of the ghost of Alexander who had his part of influence on the computer science development.) They are looking on  the architectural concept friendly part in the computer science</p>
<p> If you don&#8217;t care about what happens inside the computer and you just want the power of the computation in your hand you are digital designer. And you inherit in some ways from the deconstructivist point of view</p>
<p>So to continue my definition by intent, I would say parametric-ism is a will of over control of your design. You want to control it in a very precise manner. This control help you to keep the cost, to adapt the project over to the tribulation of reality.</p>
<p>In algorithmic approach you want to loose a bit of control to be surprise by your own design. You research the generative and unpredictable aspects of algorithms. </p>
<p>You can combine this definition to define your manner of design  : a digital algorithmic design (want to be surprise, use nature inspired algorithm _ More UCLA trend) or a computational algorithmic design (want to be surprise but want to fit in a logic of a rational design lying on computer science concept_ more MIT trend)</p>
<p>So now it&#8217;s useful to have different name to express different things… It merge with the feeling of jojeg07</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Thesis Presentation: Pt.1: Data Visualization and Cognitive Co-Processors by CAD’s uneasy relationship with tablets « Digital Morphogenesis | Evolving architecture through computation</title>
		<link>http://work.permanentriot.com/2011/05/thesis-presentation-pt-1-data-visualization-and-cognitive-co-processors/comment-page-1/#comment-1235</link>
		<dc:creator>CAD’s uneasy relationship with tablets « Digital Morphogenesis | Evolving architecture through computation</dc:creator>
		<pubDate>Fri, 09 Dec 2011 05:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=484#comment-1235</guid>
		<description>[...] The CAD offerings on the iPad are currently pretty dismal, mostly because the touch interface has not found a place beside the precise, memory intensive desktop counterparts. It has taken 18 months for the iPad to be a primary consumption device but the CAD industry is moving much slower than this. On the other-hand the games industry is moving very quickly and we see games for the iPad that have architectural aspects like Touch Physics, Zen Bound, Cut the Rope, World of Goo, MineCraft and even Angry Birds (although admittedly about the destruction of architecture). These might hint at where the industry (Autodesk?) is going, as Ben Regnier asks, “why the hell don’t I get to use this at work?” (Work, mostly play) [...]</description>
		<content:encoded><![CDATA[<p>[...] The CAD offerings on the iPad are currently pretty dismal, mostly because the touch interface has not found a place beside the precise, memory intensive desktop counterparts. It has taken 18 months for the iPad to be a primary consumption device but the CAD industry is moving much slower than this. On the other-hand the games industry is moving very quickly and we see games for the iPad that have architectural aspects like Touch Physics, Zen Bound, Cut the Rope, World of Goo, MineCraft and even Angry Birds (although admittedly about the destruction of architecture). These might hint at where the industry (Autodesk?) is going, as Ben Regnier asks, &#8220;why the hell don&#8217;t I get to use this at work?&#8221; (Work, mostly play) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Patterns and Design by Daniel</title>
		<link>http://work.permanentriot.com/2011/10/patterns-and-design/comment-page-1/#comment-1203</link>
		<dc:creator>Daniel</dc:creator>
		<pubDate>Thu, 17 Nov 2011 10:44:35 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=539#comment-1203</guid>
		<description>Hey Ben,

I hadn't previously considered how dramatically the concept of design patterns was modified on the 40 year journey away from architecture and back again. Thank you for sharing your thoughts. It is interesting to see how the scale of patterns has changed, from very general rules of design (don't build anything over 4 stories) to very specific methods of organising geometry. Even in programming, design patterns never really got beyond this stage, even though programming a blog is arguably much less complicated and more repetitive than designing architecture. One way this has been addressed is with increasing abstractions and open source libraries. All the open-source projects I have seen in architecture have left me pretty sceptical but again this might be a scale issue and small, less ambitious projects may be a more successful path for extending the current design patterns.

Daniel</description>
		<content:encoded><![CDATA[<p>Hey Ben,</p>
<p>I hadn&#8217;t previously considered how dramatically the concept of design patterns was modified on the 40 year journey away from architecture and back again. Thank you for sharing your thoughts. It is interesting to see how the scale of patterns has changed, from very general rules of design (don&#8217;t build anything over 4 stories) to very specific methods of organising geometry. Even in programming, design patterns never really got beyond this stage, even though programming a blog is arguably much less complicated and more repetitive than designing architecture. One way this has been addressed is with increasing abstractions and open source libraries. All the open-source projects I have seen in architecture have left me pretty sceptical but again this might be a scale issue and small, less ambitious projects may be a more successful path for extending the current design patterns.</p>
<p>Daniel</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What Makes Design Computational by Marc Teer</title>
		<link>http://work.permanentriot.com/2011/07/what-makes-design-computational/comment-page-1/#comment-991</link>
		<dc:creator>Marc Teer</dc:creator>
		<pubDate>Wed, 27 Jul 2011 15:30:22 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=530#comment-991</guid>
		<description>Thanks for writing this, Ben.  I have been looking for a break down like this for some time now.  You know you are in the vicinity of something new when language hasn't quite yet caught up...
Marc</description>
		<content:encoded><![CDATA[<p>Thanks for writing this, Ben.  I have been looking for a break down like this for some time now.  You know you are in the vicinity of something new when language hasn&#8217;t quite yet caught up&#8230;<br />
Marc</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Dollas Dollas by Archer Midland</title>
		<link>http://work.permanentriot.com/2011/02/dollas-dollas/comment-page-1/#comment-975</link>
		<dc:creator>Archer Midland</dc:creator>
		<pubDate>Thu, 21 Jul 2011 21:27:40 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=419#comment-975</guid>
		<description>I just feel sorry for the 29 year old getting 200 dollars a year.</description>
		<content:encoded><![CDATA[<p>I just feel sorry for the 29 year old getting 200 dollars a year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Thesis Presentation : Pt. 3: Stuff I Made, Next Steps by Ben</title>
		<link>http://work.permanentriot.com/2011/06/thesis-presentation-pt-3-stuff-i-made-next-steps/comment-page-1/#comment-928</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Sat, 02 Jul 2011 22:38:26 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=512#comment-928</guid>
		<description>Daniel,
This is part of the reason I focused on schematic design environments - the early phases of design necessarily involve working and reworking, so losing information in translation between programs isn't as much of an issue. I would rather see a design examined in 10 different environments than kept rigidly within a single one to keep a handle on versioning. 
The two trends that I'm currently keeping an eye one are: 1. the acceptance and development of "fast-and-loose" digital sketching environments, such as the ones I've described above, and 2. The rapidly evolving status of digital parametric and geometric standards.
The second one seems to be the real issue. File standards for conceptual design could conceivably be handled as an agglomeration of the file types we already have (OpenNurbs+xml+tabular data), packaged with some kind of data management filetype that handles associations (not dissimilar to sidecar files you see embedded with image files). But parametric software of the type used in design development, coordination, and documentation is much more finicky, due to the somewhat fragile nature of tree structures. For this reason I can't help but feel that the life span of the directed acyclical graph as the model for parametric design software is limited. I'm not sure what we could replace it with, and it would be a monumental ground-up project to come up with a new paradigm, but the benefits would be enormous.

Finally, I have to say that I am very suspicious of the practicality of any kind of direct design-fabrication link. I have yet to meet a fabricator who is willing to take a designer's drawings and build using their geometry directly, even if it was produced in SolidWorks or CATIA. The best way to understand a design is to rebuild it from the ground up, and for a project to be well-considered a certain amount of rebuilding between phases is probably inevitable.</description>
		<content:encoded><![CDATA[<p>Daniel,<br />
This is part of the reason I focused on schematic design environments &#8211; the early phases of design necessarily involve working and reworking, so losing information in translation between programs isn&#8217;t as much of an issue. I would rather see a design examined in 10 different environments than kept rigidly within a single one to keep a handle on versioning.<br />
The two trends that I&#8217;m currently keeping an eye one are: 1. the acceptance and development of &#8220;fast-and-loose&#8221; digital sketching environments, such as the ones I&#8217;ve described above, and 2. The rapidly evolving status of digital parametric and geometric standards.<br />
The second one seems to be the real issue. File standards for conceptual design could conceivably be handled as an agglomeration of the file types we already have (OpenNurbs+xml+tabular data), packaged with some kind of data management filetype that handles associations (not dissimilar to sidecar files you see embedded with image files). But parametric software of the type used in design development, coordination, and documentation is much more finicky, due to the somewhat fragile nature of tree structures. For this reason I can&#8217;t help but feel that the life span of the directed acyclical graph as the model for parametric design software is limited. I&#8217;m not sure what we could replace it with, and it would be a monumental ground-up project to come up with a new paradigm, but the benefits would be enormous.</p>
<p>Finally, I have to say that I am very suspicious of the practicality of any kind of direct design-fabrication link. I have yet to meet a fabricator who is willing to take a designer&#8217;s drawings and build using their geometry directly, even if it was produced in SolidWorks or CATIA. The best way to understand a design is to rebuild it from the ground up, and for a project to be well-considered a certain amount of rebuilding between phases is probably inevitable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Thesis Presentation : Pt. 3: Stuff I Made, Next Steps by Daniel Davis</title>
		<link>http://work.permanentriot.com/2011/06/thesis-presentation-pt-3-stuff-i-made-next-steps/comment-page-1/#comment-907</link>
		<dc:creator>Daniel Davis</dc:creator>
		<pubDate>Tue, 28 Jun 2011 04:54:59 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=512#comment-907</guid>
		<description>hi Ben,

This series is a really great and digestible summary of your thesis. I have to agree that we are about to see a "revolution in lightweight, interactive digital design environments" but one thing that makes me slightly pessimistic is data interoperability. 

One benefit of the monolithic mega app is that it can guarantee certain assumptions about the data. Anytime I have stepped outside of these confines, by roundtripping a design between software, it inevitably degrades into a data management issue. So while the technology and libraries have advanced to the point where an individual can write on a whim what would have taken a software team a month of planning 15 years ago, I wonder how these apps will integrate into the larger eco-system... Do you have any feeling for how this will play out? how the smaller apps link together to become a workflow?

Best of luck for your new adventure, keep us posted with what you get up to,

Daniel</description>
		<content:encoded><![CDATA[<p>hi Ben,</p>
<p>This series is a really great and digestible summary of your thesis. I have to agree that we are about to see a &#8220;revolution in lightweight, interactive digital design environments&#8221; but one thing that makes me slightly pessimistic is data interoperability. </p>
<p>One benefit of the monolithic mega app is that it can guarantee certain assumptions about the data. Anytime I have stepped outside of these confines, by roundtripping a design between software, it inevitably degrades into a data management issue. So while the technology and libraries have advanced to the point where an individual can write on a whim what would have taken a software team a month of planning 15 years ago, I wonder how these apps will integrate into the larger eco-system&#8230; Do you have any feeling for how this will play out? how the smaller apps link together to become a workflow?</p>
<p>Best of luck for your new adventure, keep us posted with what you get up to,</p>
<p>Daniel</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Yet More Applets – now with springs! by Thesis Presentation : Pt. 3: Stuff I Made, Next Steps « work</title>
		<link>http://work.permanentriot.com/2011/03/yet-more-applets-now-with-springs/comment-page-1/#comment-898</link>
		<dc:creator>Thesis Presentation : Pt. 3: Stuff I Made, Next Steps « work</dc:creator>
		<pubDate>Sat, 25 Jun 2011 03:20:50 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=428#comment-898</guid>
		<description>[...] next project presented has also been presented previously on this [...]</description>
		<content:encoded><![CDATA[<p>[...] next project presented has also been presented previously on this [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on CS171 Final Project – Treemapping Architectural Program Documents by Thesis Presentation : Pt. 3: Stuff I Made, Next Steps « work</title>
		<link>http://work.permanentriot.com/2011/04/cs171-final-project-treemapping-architectural-program-documents/comment-page-1/#comment-897</link>
		<dc:creator>Thesis Presentation : Pt. 3: Stuff I Made, Next Steps « work</dc:creator>
		<pubDate>Sat, 25 Jun 2011 03:19:44 +0000</pubDate>
		<guid isPermaLink="false">http://work.permanentriot.com/?p=442#comment-897</guid>
		<description>[...] blogged about this project previously so I won't go into too much detail. The project did help to explore the tension between having a [...]</description>
		<content:encoded><![CDATA[<p>[...] blogged about this project previously so I won&#8217;t go into too much detail. The project did help to explore the tension between having a [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

