You are viewing an old revision of this post, from April 13, 2010 @ 21:42:14. See below for differences between this version and the current revision.
There’s been lots of discussion recently about the fact that certain computing platforms are less open than some people would prefer, with many people being up in arms about this fact. Once, I would have been one of those people; these days, I’m not (though seeing the reduction in openness does make me sad), and I’m trying to tease out why.
The key concept here is that freedom to use software or hardware in ways that you choose isn’t just another feature that a piece of software or hardware may or may not have: it’s a separate and parallel class of good. And, for many people, it is a very strong class of good: there are a lot of people in my social circles who, given the presence of a free tool for a job, don’t seriously consider using a non-free tool at all. I never considered using non-free programming tools for years, for example, or using Windows instead of Linux.
That above example is for a particularly strong version of openness, namely freedom as used by the Free Software Foundation: the ability to not only use the software to produce whatever you want but to be able to modify it so you can expand its range of use. But openness is a continuum, and there are less extreme but still valuable positions along it: I remember when growing up reading about a compiler whose developer charged people for distributing software built by it, and this felt wrong to me at the time even though I never thought twice about the fact that I couldn’t get source code to the compiler. And I would also prefer to use a compression codec with a publicly available standard over one with a closed standard, even though the former might be just as expensive to use (e.g. because of patent licenses).
But I use non-free software a lot more than I used to; my use of non-free software got a big boost as my volume of video game playing increased, but I also use non-free software in many other areas as well. Video games give one example where free software loses so badly on the feature comparison as to not be worth considering, but that doesn’t apply to all the software I use: e.g. why do I use Tweetie as my Twitter client and Things as my list manager in the presence of many open source alternatives?
I think what’s going on for me is this: yes, features and freedom are both separate and important goods to me. But, where you have two dimensions for evaluation, you have the possibility of more than two dimensions, and a third dimension has started to come to the fore for me. I’m not sure exactly what to call it: at first I was thinking I’d use the term ‘beauty’, but that’s a bit stronger than what I mean. ‘Aesthetics’ isn’t a bad term, so maybe I’ll end up going with that, but for now, I’m leaning towards the term ‘habitability’. (Inspired by Richard Gabriel’s term ‘habitable code’, though he uses that to refer to the source code itself rather than the software or hardware involved; while I’m borrowing the adjective, I don’t claim that I am (or am not) using it in an analogous way.)
Basically, there is software that I feel happy to be sitting down and using, and there’s software that grates at me (sometimes only barely, sometimes quite violently) when I have to interact with it. I might be happy about the software because it does a particularly good job of meeting and even anticipating my needs; I might be happy about using the software because of a strong, well-thought-out vision that motivates it (even though that vision may entail removing features that, in the abstract, I’d want); I might be happy using the software because it’s a pleasure to look at. But, in all instances, the thought of using the software makes me happy; whereas there’s a bunch of software out there that I shy away from using, that runs the gamut from actively pissing me off to just not feeling right. I’m using the word ‘software’ here, but everything in this paragraph applies equally well to hardware. (And, in many prominent recent instances, to a mixture of software and hardware working well together.)
So this notion of habitable software is very important to me right now, equally so to functional software and open software. And, unfortunately, right now I’m having a particularly hard time right now finding instances where all three of these meet; this makes me sad.
Is this a new feeling for me? At first, I thought it was, but now I’m not so sure. I first started seriously programming doing non-application software from, say, 1987 to 1994. And, in that time period, open software was actually pretty awesome in terms of habitability: Unix was a great platform to be programming on, Emacs was a great editor, the GNU toolchain was very solid, Unix’s networkability was so much better than anything available for normal desktop use as to be beyond compare, and even X Windows was just fine, given the other alternatives. So you really could get all three of that trio at once; I’m no historian, but I think you could probably make a pretty good case that openness (and even freeness in the FSF sense) contributed actively to functionality and habitability in that case.
It’s a couple of decades later now, though; unfortunately, a lot of that world has stagnated in the interim. Unix is still a good foundation to build on (my favorite general-purpose computing platforms are all Unix-based), and its networking has flourished in ways that would have been hard to imagine at the time; Emacs and GCC and X Windows have all improved, but not nearly as much as I would have liked, however. If I were doing certain kinds of server development, I would find it acceptable (though still grating at times); otherwise, not so much. (Though I’m pretty sure I’ll always have a soft spot for Emacs!)
So the needs for a computing ecosystem has changed; I’ve changed too, though. Certainly playing video games has had a lot to do with my shift in viewpoint, both because they give examples where open alternatives aren’t at all competitive and because they give aesthetics a more central role. And not being on a student income means that it’s a lot easier for me to buy software and hardware than it once was.
But agile has played at least an important role in my shift as those factors. One reason is its emphasis on the ease and pleasure of working with the code itself (so I guess that habitable code analogy isn’t too far off): I value that in my programming, shouldn’t I value that in my programming environment more broadly? Also, the programming techniques that it suggests have also pulled me out of my old Emacs / C habitat: I want to use different programming languages (many of which Emacs supports badly), I want automated refactoring (good luck doing that in Emacs). (Though I should point out that much of what I want here is supported by open tools; they’re just different ones, and ones that come with their own set of habitability problems.) And, finally, agile insists on putting business and external design considerations at an equally important level to technical considerations when developing software; it’s no accident that the golden age I mentioned above was a golden age exactly for a community where the same people could judge both of those considerations well.
And I could go further afield, too. I seem to be unable to go more than four or five blog posts in a row these days without mentioning Christopher Alexander; he’s convinced me that, to build spaces that you feel good living in, you need to take account of your environment as a whole, instead of using freedom as an excuse to do whatever the hell you want. And then there’s global warming: while I think that my house will remain habitable for the next several decades, untrammeled freedoms are putting habitability at risk.
So, at least in the computing arena, I’ll put functionality, openness, and habitability as a trio of goods, the absence of any of which leaves me with a system that doesn’t feel right. I suspect I could get that trio to help me analyze other contexts, too.
I’d hoped that writing this would lead to my feeling more at ease. And, to some extent, it did: I’m happy enough with choices that I’ve made that pick out two of those criteria, in the absence of solutions that fit all three. But, having said that, I’m still not thrilled: it still doesn’t feel right for me to say that solutions that aren’t open are fine. What I would really like is for people working on open solutions, on free solutions (in computing arenas or more broadly) to have habitability front and center in their vision of the world they’re trying to build. Freedom is great, but how we use that freedom is a choice: let’s choose to build something beautiful.
Post Revisions:
- April 13, 2010 @ 21:46:48 [Current Revision] by David Carlton
- April 13, 2010 @ 21:46:18 by David Carlton
- April 13, 2010 @ 21:43:24 by David Carlton
- April 13, 2010 @ 21:42:31 by David Carlton
- April 13, 2010 @ 21:42:14 by David Carlton
- April 13, 2010 @ 21:40:18 by David Carlton
Changes:
| April 13, 2010 @ 21:42:14 | Current Revision | ||
|---|---|---|---|
| Content | |||
| Unchanged: There's been lots of discussion recently about the fact that certain computing platforms are less open than some people would prefer, with many people being up in arms about this fact. Once, I would have been one of those people; these days, I'm not (though seeing the reduction in openness does make me sad), and I'm trying to tease out why. | Unchanged: There's been lots of discussion recently about the fact that certain computing platforms are less open than some people would prefer, with many people being up in arms about this fact. Once, I would have been one of those people; these days, I'm not (though seeing the reduction in openness does make me sad), and I'm trying to tease out why. | ||
| Unchanged: The key concept here is that freedom to use software or hardware in ways that you choose isn't just another feature that a piece of software or hardware may or may not have: it's a separate and parallel class of good. And, for many people, it is a very strong class of good: there are a lot of people in my social circles who, given the presence of a free tool for a job, don't seriously consider using a non-free tool at all. I never considered using non-free programming tools for years, for example, or using Windows instead of Linux. | Unchanged: The key concept here is that freedom to use software or hardware in ways that you choose isn't just another feature that a piece of software or hardware may or may not have: it's a separate and parallel class of good. And, for many people, it is a very strong class of good: there are a lot of people in my social circles who, given the presence of a free tool for a job, don't seriously consider using a non-free tool at all. I never considered using non-free programming tools for years, for example, or using Windows instead of Linux. | ||
| Unchanged: That above example is for a particularly strong version of openness, namely freedom as used by the <a href="http:// www.gnu.org/philosophy/free- sw.html">Free Software Foundation</a>: the ability to not only use the software to produce whatever you want but to be able to modify it so you can expand its range of use. But openness is a continuum, and there are less extreme but still valuable positions along it: I remember when growing up reading about a compiler whose developer charged people for distributing software built by it, and this felt wrong to me at the time even though I never thought twice about the fact that I couldn't get source code to the compiler. And I would also prefer to use a compression codec with a publicly available standard over one with a closed standard, even though the former might be just as expensive to use (e.g. because of patent licenses). | Unchanged: That above example is for a particularly strong version of openness, namely freedom as used by the <a href="http:// www.gnu.org/philosophy/free- sw.html">Free Software Foundation</a>: the ability to not only use the software to produce whatever you want but to be able to modify it so you can expand its range of use. But openness is a continuum, and there are less extreme but still valuable positions along it: I remember when growing up reading about a compiler whose developer charged people for distributing software built by it, and this felt wrong to me at the time even though I never thought twice about the fact that I couldn't get source code to the compiler. And I would also prefer to use a compression codec with a publicly available standard over one with a closed standard, even though the former might be just as expensive to use (e.g. because of patent licenses). | ||
| Unchanged: But I use non-free software a lot more than I used to; my use of non-free software got a big boost as my volume of video game playing increased, but I also use non-free software in many other areas as well. Video games give one example where free software loses so badly on the feature comparison as to not be worth considering, but that doesn't apply to all the software I use: e.g. why do I use Tweetie as my Twitter client and Things as my list manager in the presence of many open source alternatives? | Unchanged: But I use non-free software a lot more than I used to; my use of non-free software got a big boost as my volume of video game playing increased, but I also use non-free software in many other areas as well. Video games give one example where free software loses so badly on the feature comparison as to not be worth considering, but that doesn't apply to all the software I use: e.g. why do I use Tweetie as my Twitter client and Things as my list manager in the presence of many open source alternatives? | ||
| Unchanged: I think what's going on for me is this: yes, features and freedom are both separate and important goods to me. But, where you have two dimensions for evaluation, you have the possibility of more than two dimensions, and a third dimension has started to come to the fore for me. I'm not sure exactly what to call it: at first I was thinking I'd use the term 'beauty', but that's a bit stronger than what I mean. 'Aesthetics' isn't a bad term, so maybe I'll end up going with that, but for now, I'm leaning towards the term 'habitability'. (Inspired by <a href="http:// www.bactrian.org/~carlton/ dbcdb/1153/">Richard Gabriel's term 'habitable code'</a>, though he uses that to refer to the source code itself rather than the software or hardware involved; while I'm borrowing the adjective, I don't claim that I am (or am not) using it in an analogous way.) | Unchanged: I think what's going on for me is this: yes, features and freedom are both separate and important goods to me. But, where you have two dimensions for evaluation, you have the possibility of more than two dimensions, and a third dimension has started to come to the fore for me. I'm not sure exactly what to call it: at first I was thinking I'd use the term 'beauty', but that's a bit stronger than what I mean. 'Aesthetics' isn't a bad term, so maybe I'll end up going with that, but for now, I'm leaning towards the term 'habitability'. (Inspired by <a href="http:// www.bactrian.org/~carlton/ dbcdb/1153/">Richard Gabriel's term 'habitable code'</a>, though he uses that to refer to the source code itself rather than the software or hardware involved; while I'm borrowing the adjective, I don't claim that I am (or am not) using it in an analogous way.) | ||
| Unchanged: Basically, there is software that I feel happy to be sitting down and using, and there's software that grates at me (sometimes only barely, sometimes quite violently) when I have to interact with it. I might be happy about the software because it does a particularly good job of meeting and even anticipating my needs; I might be happy about using the software because of a strong, well-thought-out vision that motivates it (even though that vision may entail removing features that, in the abstract, I'd want); I might be happy using the software because it's a pleasure to look at. But, in all instances, the thought of using the software makes me happy; whereas there's a bunch of software out there that I shy away from using, that runs the gamut from actively pissing me off to just not feeling right. I'm using the word 'software' here, but everything in this paragraph applies equally well to hardware. (And, in many prominent recent instances, to a mixture of software and hardware working well together.) | Unchanged: Basically, there is software that I feel happy to be sitting down and using, and there's software that grates at me (sometimes only barely, sometimes quite violently) when I have to interact with it. I might be happy about the software because it does a particularly good job of meeting and even anticipating my needs; I might be happy about using the software because of a strong, well-thought-out vision that motivates it (even though that vision may entail removing features that, in the abstract, I'd want); I might be happy using the software because it's a pleasure to look at. But, in all instances, the thought of using the software makes me happy; whereas there's a bunch of software out there that I shy away from using, that runs the gamut from actively pissing me off to just not feeling right. I'm using the word 'software' here, but everything in this paragraph applies equally well to hardware. (And, in many prominent recent instances, to a mixture of software and hardware working well together.) | ||
| Unchanged: So this notion of habitable software is very important to me right now, equally so to functional software and open software. And, unfortunately, right now I'm having a particularly hard time right now finding instances where all three of these meet; this makes me sad. | Unchanged: So this notion of habitable software is very important to me right now, equally so to functional software and open software. And, unfortunately, right now I'm having a particularly hard time right now finding instances where all three of these meet; this makes me sad. | ||
| Unchanged: Is this a new feeling for me? At first, I thought it was, but now I'm not so sure. I first started seriously programming doing non-application software from, say, 1987 to 1994. And, in that time period, open software was actually pretty awesome in terms of habitability: Unix was a great platform to be programming on, Emacs was a great editor, the GNU toolchain was very solid, Unix's networkability was so much better than anything available for normal desktop use as to be beyond compare, and even X Windows was just fine, given the other alternatives. So you really could get all three of that trio at once; I'm no historian, but I think you could probably make a pretty good case that openness (and even freeness in the FSF sense) contributed actively to functionality and habitability in that case. | Unchanged: Is this a new feeling for me? At first, I thought it was, but now I'm not so sure. I first started seriously programming doing non-application software from, say, 1987 to 1994. And, in that time period, open software was actually pretty awesome in terms of habitability: Unix was a great platform to be programming on, Emacs was a great editor, the GNU toolchain was very solid, Unix's networkability was so much better than anything available for normal desktop use as to be beyond compare, and even X Windows was just fine, given the other alternatives. So you really could get all three of that trio at once; I'm no historian, but I think you could probably make a pretty good case that openness (and even freeness in the FSF sense) contributed actively to functionality and habitability in that case. | ||
| Unchanged: It's a couple of decades later now, though; unfortunately, a lot of that world has stagnated in the interim. Unix is still a good foundation to build on (my favorite general-purpose computing platforms are all Unix-based), and its networking has flourished in ways that would have been hard to imagine at the time; Emacs and GCC and X Windows have all improved, but not nearly as much as I would have liked, however. If I were doing certain kinds of server development, I would find it acceptable (though still grating at times); otherwise, not so much. (Though I'm pretty sure I'll always have a soft spot for Emacs!) | Unchanged: It's a couple of decades later now, though; unfortunately, a lot of that world has stagnated in the interim. Unix is still a good foundation to build on (my favorite general-purpose computing platforms are all Unix-based), and its networking has flourished in ways that would have been hard to imagine at the time; Emacs and GCC and X Windows have all improved, but not nearly as much as I would have liked, however. If I were doing certain kinds of server development, I would find it acceptable (though still grating at times); otherwise, not so much. (Though I'm pretty sure I'll always have a soft spot for Emacs!) | ||
| Unchanged: So the needs for a computing ecosystem has changed; I've changed too, though. Certainly playing video games has had a lot to do with my shift in viewpoint, both because they give examples where open alternatives aren't at all competitive and because they give aesthetics a more central role. And not being on a student income means that it's a lot easier for me to buy software and hardware than it once was. | Unchanged: So the needs for a computing ecosystem has changed; I've changed too, though. Certainly playing video games has had a lot to do with my shift in viewpoint, both because they give examples where open alternatives aren't at all competitive and because they give aesthetics a more central role. And not being on a student income means that it's a lot easier for me to buy software and hardware than it once was. | ||
| Unchanged: But agile has played at least an important role in my shift as those factors. One reason is its emphasis on the ease and pleasure of working with the code itself (so I guess that habitable code analogy isn't too far off): I value that in my programming, shouldn't I value that in my programming environment more broadly? Also, the programming techniques that it suggests have also pulled me out of my old Emacs / C habitat: I want to use different programming languages (many of which Emacs supports badly), I want automated refactoring (good luck doing that in Emacs). (Though I should point out that much of what I want here is supported by open tools; they're just different ones, and ones that come with their own set of habitability problems.) And, finally, agile insists on putting business and external design considerations at an equally important level to technical considerations when developing software; it's no accident that the golden age I mentioned above was a golden age exactly for a community where the same people could judge both of those considerations well. | Unchanged: But agile has played at least an important role in my shift as those factors. One reason is its emphasis on the ease and pleasure of working with the code itself (so I guess that habitable code analogy isn't too far off): I value that in my programming, shouldn't I value that in my programming environment more broadly? Also, the programming techniques that it suggests have also pulled me out of my old Emacs / C habitat: I want to use different programming languages (many of which Emacs supports badly), I want automated refactoring (good luck doing that in Emacs). (Though I should point out that much of what I want here is supported by open tools; they're just different ones, and ones that come with their own set of habitability problems.) And, finally, agile insists on putting business and external design considerations at an equally important level to technical considerations when developing software; it's no accident that the golden age I mentioned above was a golden age exactly for a community where the same people could judge both of those considerations well. | ||
| Deleted: | Added: I could go further afield, too. I seem to be unable to go more than four or five blog posts in a row these days without mentioning <a href="http:// www.bactrian.org/~carlton/ dbcdb/305/">Christopher Alexander</a>; he's convinced me that, to build spaces that you feel good living in, you need to take account of your environment as a whole, instead of using freedom as an excuse to do whatever the hell you want. And then there's global warming: while I <em>think</em> that my house will remain habitable for the next several decades, untrammeled freedoms are putting habitability at risk in a very literal way. | ||
| Deleted: So, at least in the computing arena, I'll | Added: So, at least in the computing arena, I'll propose functionality, openness, and habitability as a trio of goods, the absence of any of which leaves me with a system that doesn't feel right. I suspect I could get that trio to help me analyze other contexts, too. | ||
| Deleted: I'd hoped that writing this would lead to my feeling more at ease. And, to some extent, it | Added: I'd hoped that writing this would lead to my feeling more at ease. And, to some extent, it has: I'm happy enough with choices that I've made that involve selecting two out of those three criteria, in the absence of solutions that fit all three. But, having said that, I'm still not thrilled: it still doesn't feel right for me to say that solutions that aren't open are fine. What I would really like is for people working on open solutions, on free solutions (in computing arenas or more broadly) to have habitability front and center in their vision of the world they're trying to build. | ||
| Added: Freedom is great, but how we use that freedom is a choice: let's choose to build something beautiful. | |||
Note: Spaces may be added to comparison text to allow better line wrapping.
Posts
As an appreciator of Christopher Alexander’s work, as well as the general problem of inhabitation in modernity (the subject of my dissertation!), I resonate with almost everything you’ve said here.
There is something to be said for creating a “livable” space – one in which we can feel ‘at home’ in without giving it much thought. Certainly Alexander is right about one thing if I interpret him rightly: who the hell would want to live in one of Frank Gehry’s post-structuralist monstrosities?
At the same time, I am suspicious of the idea that just because something doesn’t “feel right”, we as users/programmers/creators are justified in suggesting that it is not sufficiently beautiful/habitable. If anything, I think “this doesn’t feel right to me” or “this isn’t user-friendly” is the user’s cop-out for a lack of creative drive (just as the designer’s “freedom” is a cop-out from true historical/social understanding). In other words, I disagree strongly with the whole movement of pseudo-academics who are now slavishly following Donald Norman’s theory of “user-centered design”, and I think it’s very important to distinguish Christopher Alexander’s architectural theory from UCD. Not that you’re doing any of this mind you – but mixing the language of “feels good” with “good design” is tricky business.
The whole point with habitable software is that we come to inhabit the software; it is not immediately available for habitation. We have to develop the right habits in order to live in it rightly; in other words, our using Emacs/Unix/GCC/Makefiles all begin to cohere a certain style of doing things that we see as good. More generally, the software sets up a place for habitation, but it’s up to us to develop the right habits for inhabitation. So talking about “habitable software” isn’t enough – we have to talk about habitable software and those who inhabit it. Because trust me, there are a few thousand people in the world who will tell you that Emacs is a horrific editor for everyday tasks, and don’t appreciate its sublimated aspects as you do :) Beauty isn’t found in software in other words – it is partly the contribution of a beautiful way of programming/playing with it. Perhaps that is always what I’ve found lacking in architectural theory: people.
But I digress. All of your initial points were spot on for me. I more saw it as a space to think aloud. Thanks for the wonderful post.
4/13/2010 @ 11:16 pm
Wait, not everybody likes Emacs? I’m shocked, shocked to hear that!
So, here’s another somewhat related comment on the issue: for Richard Gabriel (whose book, incidentally, is available at http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf ), a key aspect of habitable software (habitable for the programmer, not necessarily for its users) is the possibility of piecemeal growth. And that’s actually one of the reasons why I shied away from claiming that I was using the term in the same way as Gabriel. I love incremental development, and lots of the software that I love I find habitable exactly because I can incrementally mold it to suit my changing usage patterns (Emacs and Unix both being excellent examples). But there’s also lots of habitable software that I don’t get to do that with.
Though, as you point out, that doesn’t mean that molding doesn’t happen: what often happens is that I can see a vision in the software, and I end up molding my usage patterns to meet that vision rather than the other way around.
Certainly I agree that it doesn’t make sense to talk about habitable software in the absence of those who inhabit it. For software to be habitable, somebody (perhaps its initial designer) has to be happy to live with it, has to find it at hand when and how she wants it to be (perhaps at a deeper level rather than a surface level), has to feel at home using it. The process of designing/developing such habitable software probably will be iterative, as Gabriel says; as an end user, though, I may be presented with a finished result. (And, if the software evolves in further releases, it’s at least as likely to do so in a way that decreases its habitability as that increases its habitability, but that’s another discussion…)
And in the static case, I suspect that the fact that the software is habitable for somebody else means that I’m more likely to perceive the possibility of its being habitable for me, and to end up adjusting to it accordingly.
4/14/2010 @ 7:39 pm
Wow, Alexander’s foreword to Gabriel’s book is a work of art in itself. I’m really looking forward to reading Gabriel’s book, although I hopefully can find an OOP copy of it (not a fan of reading PDFs).
I think I understand your point regarding not choosing sides when it comes to a particular form of software development. Perhaps that is what inhabitation is, at least for programming: a flexible, co-constitutive, molding approach to oneself and one’s development environment. I *really* like your approach to “seeing a vision in the software” and molding yourself (usage, expectations, creative desires) in order to suit the software, rather than trying to force the program into doing something outside of its domain.
My attempt, although I want to be careful to not conflate programming with game-playing, is to show how players can develop that kind of approach to video games. I like seeing players who appropriate the ‘vision’ of the game by reshaping their own goals and desires in light of it. Borrowing from Gaston Bachelard, I see a good reader of poetry as doing the same: allowing the poet’s words to invoke an image in the imagination that for a moment becomes partly their own. In those moments where we are co-extensive with the software, poetry and games we play with, I think we are finally “inhabiting” that space. Or at least damned close!
I really like the idea that the programmer/writer/developer has to be willing to live within the software before others can resonate with that vision. I think that any genuinely expressive piece of work has that quality: the creator had a vision that they themselves believed to be worthwhile and livable.
(Mulling what you’ve said over in my mind) – while the end-user is in a sense presented with the “final product”, the creative contribution they bring to “using” the software in a unique way continues to interest me — even “uninhabitable” software (I can’t think of anything at the moment) has the potential to become habitable, given the right kind of user.
What I suspect, however, is that the vast majority of programmers/gamers/readers *do not* inhabit their SDKs/games/books. Inhabitation by definition requires a certain openness, willingness to change, be surprised by novel things. Most people I know just say “Oh screw it. I’ll just play something else” and that’s the end of that dialogue.
Looks like I’ve got some more reading to do. Woohoo!
4/14/2010 @ 8:43 pm
I really like your game / poetry / Bachelard paragraph. The rest is good, too, but that one really helps show how games can be useful in understanding this whole concept of habitable software, by providing a bookend on one side. (With, perhaps, Emacs or a Smalltalk system at the other side?)
I’d love to see you talk about this and other ideas from your dissertation more on your blog. Or maybe you have been, and I haven’t been paying attention; are there posts that you could point at for me to read?
4/14/2010 @ 9:00 pm
I’ve tried to avoid much theoretical talk on my blog, simply because it tends to turn away folks not much interested in intellingo. Instead I’ve tried to integrate the underlying thought into some of the posts, and that has worked to *some* degree over the years…
I think I’ve managed to capture something in these posts:
http://www.artfulgamer.com/2009/09/04/games-we-can-dwell-within/
(an early attempt at understanding what ‘interaction’ means in games; I play with the problem of spatial inhabitation)
http://www.artfulgamer.com/2010/03/11/when-do-you-call-a-game-a-game/
(what are the practices involving in actually playing a game; in trying to inhabit it?)
http://www.artfulgamer.com/2009/09/23/an-expedition-into-the-lost-world-of-exploration-toejam-earl/
(trying to inhabit ‘Toejam & Earl’ specifically, and understanding its expressive value; what kind of gameplay does it demand from me?)
Certainly the dissertation is coming together slowly so I’ll be in a much better place to post something when it’s done. :)
4/16/2010 @ 10:30 pm
Thanks for the links!
4/18/2010 @ 7:54 pm
[…] with on closed systems: I’d like to run this on my phone, and I can’t. There are reasons why I’ve moved away from open systems over the last few years, but that move still makes me […]
8/15/2011 @ 9:42 pm