<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://savelkoul.net/cs/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Automated home: Applying Interaction Design on DSLs</title><link>http://savelkoul.net/cs/blogs/antoine/archive/2009/10/03/automated-home-applying-interaction-design-on-dsls.aspx</link><description>In my previous posts I have given an impression of the current situation (how the hardware is connected, which software I use). It is very tempting to dig into hardware and software details now, but during previous experiences with designing DSLs I learned</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.2)</generator><item><title>re: Automated home: Applying Interaction Design on DSLs</title><link>http://savelkoul.net/cs/blogs/antoine/archive/2009/10/03/automated-home-applying-interaction-design-on-dsls.aspx#216</link><pubDate>Thu, 08 Oct 2009 09:16:57 GMT</pubDate><guid isPermaLink="false">c85263ac-6350-4393-b21e-03dd809752eb:216</guid><dc:creator>Steven Kelly</dc:creator><description>&lt;p&gt;Hi Antoine,&lt;/p&gt;
&lt;p&gt;You wrote: &amp;quot;A lot of papers and articles about designing DSLs will start with an analysis of the PROBLEM DOMAIN by discussing complete hardware designs and software architectures&amp;quot;&lt;/p&gt;
&lt;p&gt;I guess you meant &amp;quot;solution domain&amp;quot;: the domain of the concepts, tools, libraries, programming languages and platforms of a developer building a system by coding it.&lt;/p&gt;
&lt;p&gt;The problem domain is the user's or domain expert's view of the system, precisely the area you talk about in the rest of your post, and by far the best place to look when building a DSM language. &lt;/p&gt;</description></item></channel></rss>