The two sat together awkwardly. The memory of what happened sat ajar between them. He thought that he should stroke her hand to comfort her but he stopped himself once he realized his palms were sweating profusely. Her brow was tense, and her knees tightly clamped. "this isn't how it is in stories", she thought.
For the past 3 weeks she watched him longingly. She admired from a distance the graceful way he walked, his calming smile, the sense of gentle warmth he projected. She frequently imagined what it must be like to be embraced by him. She would never see love the same way again.
He nervously looked out the window. Hoping for a blissful end to this moment, he considered jumping out. Unfortunately, the window was stuck fast. He was recalled to what his heart felt; like a frightened sparrow beating against the glass of his chest.
Since the day she arrived on campus, he was enamoured. Her beauty was both captivating and intimidating. His excruciatingly gentle and repressed nature meant he would never feel comfortable approaching her. If he were to so much as say “hello”, he would make himself feel as though he were causing some terrible kind of violence upon the poor girl. If he were to even think of her lustfully, he would never forgive himself. Now, everything would be different.
The smell of sticky skin permeated the air. The weather was uncomfortably warm and humid. She unwillingly leaned into him as the bus turned. “how long until my stop?” she thought.
Wednesday, February 24, 2010
Saturday, January 2, 2010
The mating habits of the christmas reindeer
The ritual begins when the population of reindeer shed their summer coats, revealing the golden shimmering skin underneath. The reindeer then congregate, forming two large orbs (one male, one female). The golden orgy froths and frenzies for 12 days climaxing in a spectacular "fireworks" show in which the gendered gametes are projected from each orb at extremely high speed. The force of the collision forms a mushroom cloud, and destroys the christmas village. The new Santa Clause is formed at ground zero, which then distributes reindeer spores in multicoloured box shaped packages all around the world. Once the santa completes its jolly task, he returns to the spawning ground and melts into a highly fertile mound from which grows the first tree of the new christmas village, marking the spot to which the reindeer will return for next year's mating season.
Monday, December 21, 2009
Canvas Accessibility.
There has been some discussion going on about Accessibility in the html5 Canvas Api.
You can see such discussion here:
http://www.paciellogroup.com/blog/?p=362
http://www.brucelawson.co.uk/2009/canvas-accessibility-and-svg/
http://krijnhoetmer.nl/irc-logs/whatwg/20090710#l-20
http://lists.w3.org/Archives/Public/public-html/2009Jul/0372.html
http://esw.w3.org/topic/HTML/AddedElementCanvas
In case you don't know, the canvas API provides a postscript-like drawing api to javascript running inside webpages. It was introduced by apple to provide a richer graphical experience for the "dashboard" feature introduced in their OS X Tiger.
The argument on one side seems to be that if you don't bake accessibility right into the API such that programmers don't have to do anything particularly special to make it accessible, then people just won't do accessibility.
There's the extreme position that the canvas API just should never have been added to browsers in the first place, and it shouldn't be in any standard, because it's inherently not accessible.
Then there's reactions to the extreme positions, that argue that sometimes we just need to make content that is inherently not accessible to everyone, and this is okay, and they are legitimate forms of expression. And besides, we don't ask that everyone put wheelchair accessible ramps on their houses, and so we shouldn't require every single website be accessible.
Of course there already is a simple accessibility mechanism built into the canvas tag: Simply put some plain text inside the canvas tag as fallback content. If a client doesn't understand the canvas tag, it will simply display the text content.
A counter example to that approach that is being used, and which I believe sparked the debate is Bespin. Bespin implemented a widget/gui system that runs entirely inside a single canvas tag. They did this for performance, and for control over the gui experience. Static text content is not a sufficient fallback for such a program.
Here's my opinion: It will be a grave mistake to get distracted by projects like Bespin into thinking that the canvas api's accessibility features are lacking. A widget system is only one potential use for the canvas tag, and gearing an accessiblity design around this one use case will cripple the canvas API, and ultimately, I believe, make accessibility worse for uses that are NOT widget systems.
The truth is that I don't think there's any way to know, from the perspective of a browser that is receiving canvas API instructions, precisely what the meaning of those instructions are. Yes, it could be something like bespin, or it could just be a simple animation. It could be a graph, or it could be some abstract artwork. You could ask the programmer to provide hints in the API calls, but that's not really any better than the "tack on" accessibility that the accessibility proponents speak out against. However without such hints, all you see is "Curve, curve, rectangle, image, textbox" etc. etc. No way to know whether you can interact with anything, no way to know what the text in a textbox is referring to, and no way to know what nature of image a sequence of shapes is constructing.
A low level drawing API is the wrong target for accessibility. You might as well try and make the PNG image format "accessible" by allowing a screen reader to read out the color of each pixel, or making SVG accessible by making it read out loud each curve and shape in sequence.
For bespin, what you need to make accessible is its widget toolkit. That's the level of abstraction where you have some actual useful information. That's where you know whether something is a menu or a button or a text-box. There's already a standard called "aria" that aims to make dynamic widget toolkits in html accessible. The limitation in this case though, is ARIA's assumption that you'll have some kind of 1:1 correspondence between HTML tags and widgets, and its dependance on your ability to assign attributes to each of those html tags.
I think what we really need is some kind of low level accessibility API, at a level equal to the canvas API, but not cannibalizing it, and without attempting to combine them, or make them into the same API. Then to make programmers want to use it, you need to make it useful for things other than Accessibility. Here's a suggestion:
Let's provide a low level javascript API that makes it relatively straightforward to turn your javascript program, embedded in an html page, into a command line utility, an interactive terminal program, a webservice, or even the basis for a desktop application using a native OS widget toolkit. Just add a few extra API calls, and you get to reuse your efforts in multiple and many different contexts, accessible interfaces just being one of them by chance.
What's the best way to do that? I'm not sure exactly, but I think it's a more productive direction to explore than the futile task of trying to make abstract low level drawing commands mean something to a computer: Something which I think can only be achieved via advanced artificial intelligence of the sort that is perpetually 10 years away.
My instinct is to encourage MVC style programming via the design of the in browser API for constructing applications, the same way that Apple's cocoa encourages good MVC design by simply making it the path of least resistance. This would involve encouraging programmers to build a clean "domain model" version of their javascript programs, and making it incredibly easy to express the logic of that program through rich UI's (potentially using the canvas tag), or via a command line program/interactive console program/webservice/accessible client without changing the code of their "model" tier. Go further: make a model tier simply work on its own without any gui programming. Then adding a rich gui with graphics is simply enhancement. Make this the easiest way to write a program, and they will come. Consider the analogy:
html : css :: javascript models : canvasApi
Nobody complains that CSS is not accessible. Why is that?
One thing I think we should definately not do: Standardise an "accessible" version of the canvas API that doesn't have a single implementation, and hasn't yet gone through the trials and tribulations of real world practice.
You can see such discussion here:
http://www.paciellogroup.com/blog/?p=362
http://www.brucelawson.co.uk/2009/canvas-accessibility-and-svg/
http://krijnhoetmer.nl/irc-logs/whatwg/20090710#l-20
http://lists.w3.org/Archives/Public/public-html/2009Jul/0372.html
http://esw.w3.org/topic/HTML/AddedElementCanvas
In case you don't know, the canvas API provides a postscript-like drawing api to javascript running inside webpages. It was introduced by apple to provide a richer graphical experience for the "dashboard" feature introduced in their OS X Tiger.
The argument on one side seems to be that if you don't bake accessibility right into the API such that programmers don't have to do anything particularly special to make it accessible, then people just won't do accessibility.
There's the extreme position that the canvas API just should never have been added to browsers in the first place, and it shouldn't be in any standard, because it's inherently not accessible.
Then there's reactions to the extreme positions, that argue that sometimes we just need to make content that is inherently not accessible to everyone, and this is okay, and they are legitimate forms of expression. And besides, we don't ask that everyone put wheelchair accessible ramps on their houses, and so we shouldn't require every single website be accessible.
Of course there already is a simple accessibility mechanism built into the canvas tag: Simply put some plain text inside the canvas tag as fallback content. If a client doesn't understand the canvas tag, it will simply display the text content.
A counter example to that approach that is being used, and which I believe sparked the debate is Bespin. Bespin implemented a widget/gui system that runs entirely inside a single canvas tag. They did this for performance, and for control over the gui experience. Static text content is not a sufficient fallback for such a program.
Here's my opinion: It will be a grave mistake to get distracted by projects like Bespin into thinking that the canvas api's accessibility features are lacking. A widget system is only one potential use for the canvas tag, and gearing an accessiblity design around this one use case will cripple the canvas API, and ultimately, I believe, make accessibility worse for uses that are NOT widget systems.
The truth is that I don't think there's any way to know, from the perspective of a browser that is receiving canvas API instructions, precisely what the meaning of those instructions are. Yes, it could be something like bespin, or it could just be a simple animation. It could be a graph, or it could be some abstract artwork. You could ask the programmer to provide hints in the API calls, but that's not really any better than the "tack on" accessibility that the accessibility proponents speak out against. However without such hints, all you see is "Curve, curve, rectangle, image, textbox" etc. etc. No way to know whether you can interact with anything, no way to know what the text in a textbox is referring to, and no way to know what nature of image a sequence of shapes is constructing.
A low level drawing API is the wrong target for accessibility. You might as well try and make the PNG image format "accessible" by allowing a screen reader to read out the color of each pixel, or making SVG accessible by making it read out loud each curve and shape in sequence.
For bespin, what you need to make accessible is its widget toolkit. That's the level of abstraction where you have some actual useful information. That's where you know whether something is a menu or a button or a text-box. There's already a standard called "aria" that aims to make dynamic widget toolkits in html accessible. The limitation in this case though, is ARIA's assumption that you'll have some kind of 1:1 correspondence between HTML tags and widgets, and its dependance on your ability to assign attributes to each of those html tags.
I think what we really need is some kind of low level accessibility API, at a level equal to the canvas API, but not cannibalizing it, and without attempting to combine them, or make them into the same API. Then to make programmers want to use it, you need to make it useful for things other than Accessibility. Here's a suggestion:
Let's provide a low level javascript API that makes it relatively straightforward to turn your javascript program, embedded in an html page, into a command line utility, an interactive terminal program, a webservice, or even the basis for a desktop application using a native OS widget toolkit. Just add a few extra API calls, and you get to reuse your efforts in multiple and many different contexts, accessible interfaces just being one of them by chance.
What's the best way to do that? I'm not sure exactly, but I think it's a more productive direction to explore than the futile task of trying to make abstract low level drawing commands mean something to a computer: Something which I think can only be achieved via advanced artificial intelligence of the sort that is perpetually 10 years away.
My instinct is to encourage MVC style programming via the design of the in browser API for constructing applications, the same way that Apple's cocoa encourages good MVC design by simply making it the path of least resistance. This would involve encouraging programmers to build a clean "domain model" version of their javascript programs, and making it incredibly easy to express the logic of that program through rich UI's (potentially using the canvas tag), or via a command line program/interactive console program/webservice/accessible client without changing the code of their "model" tier. Go further: make a model tier simply work on its own without any gui programming. Then adding a rich gui with graphics is simply enhancement. Make this the easiest way to write a program, and they will come. Consider the analogy:
html : css :: javascript models : canvasApi
Nobody complains that CSS is not accessible. Why is that?
One thing I think we should definately not do: Standardise an "accessible" version of the canvas API that doesn't have a single implementation, and hasn't yet gone through the trials and tribulations of real world practice.
Thursday, August 6, 2009
Another javascript pitfall: Hoisting
The problem is that, whether you realise it or not, javascript invisibly moves all the var declarations to the top of the function scope.
so if you have a function like this
the alert window will contain undefined. because internally, it's been changed into this:
this is called "hoisting". The reason Crockford so strongly advocates var declarations go at the top, is that it makes the code visibly match what it's going to do, instead of allowing invisible and unexpected behavior to occur. function definitions are also hoisted to the top of the scope.
Putting a var inside an if statement is not against "the rules" of the language, but it means that, because of var hoisting, that var will be defined regardless of whether the if statement's condition is satisfied. Javascript also does not have block scope, so declaring a variable inside a block is doubly confusing to those who come from languages that do have block scope, because of hoisting.
Keep in mind also that hoisting does not include the assignment, so the var declarations will be moved to the top, and left undefined until they're assigned later, as in the example above.
This is a feature that must have seemed like a good idea at the time, but it has turned out to be more confusing than helpful.
so if you have a function like this
var i = 5
function testvar () {
alert(i);
var i=3;
}
testvar();
the alert window will contain undefined. because internally, it's been changed into this:
var i = 5
function testvar () {
var i;
alert(i);
i=3;
}
testvar();
this is called "hoisting". The reason Crockford so strongly advocates var declarations go at the top, is that it makes the code visibly match what it's going to do, instead of allowing invisible and unexpected behavior to occur. function definitions are also hoisted to the top of the scope.
Putting a var inside an if statement is not against "the rules" of the language, but it means that, because of var hoisting, that var will be defined regardless of whether the if statement's condition is satisfied. Javascript also does not have block scope, so declaring a variable inside a block is doubly confusing to those who come from languages that do have block scope, because of hoisting.
Keep in mind also that hoisting does not include the assignment, so the var declarations will be moved to the top, and left undefined until they're assigned later, as in the example above.
This is a feature that must have seemed like a good idea at the time, but it has turned out to be more confusing than helpful.
Sunday, August 2, 2009
Insomniac Theater, A dream
I had a dream about a particular cinema. Not one that I know if in the waking world, but one that I visited quite avidly in this dream world.
At this theater, you could purchase a ticket to see a contemporary movie at around 11:30pm at the regular price. Then, you could stay at the theater on until 6am, and watch classic/old/public domain movies and cartoons for free.
The theater would recoup the cost of this through sales at the snacks counter. This might actually work, sleep deprivation can make people quite hungry.
At this theater, you could purchase a ticket to see a contemporary movie at around 11:30pm at the regular price. Then, you could stay at the theater on until 6am, and watch classic/old/public domain movies and cartoons for free.
The theater would recoup the cost of this through sales at the snacks counter. This might actually work, sleep deprivation can make people quite hungry.
Friday, May 8, 2009
Autodesk Animator
UPDATE: New website, animatorpro.org , Source code now online.
Here's a little story about a neat old computer program, and how I plan to save it from the brink of digital death.
For the past few years I've been fascinated by this program. Way back in the beginning, I became aware of the existence of dedicated communities devoted to solely pixel art.
One of the communities, pixelation, had a highly regarded tutorial titled "so you want to be a pixel artist?"
(Links are to mirrors, the original site is long gone). When I read that tutorial was the first time I became aware of the fact that there was a program called "Autodesk Animator". The native format of Animator (fli, flc) was certainly ubiquitous in the 1990's. Even today, Mac OS X doesn't need any special software to play FLI files, quicktime handles them natively. I have also been a participant in the pov-ray community, which used independent dos utilities to string together ray-traced frames into Animator's FLI and FLC format. Why? It was the very first widely available delta compressed video format!
What really grabbed my interest, was this spectacular animation by a guy named Paul Robertson.(NSFW!) who allegedly used Autodesk Animator to make it.
So cargo cultist that I am, I set about attempting to obtain the software. This is really difficult to do, it turns out. Eventually I succeeded. (*whistles). The software can only be run on a modern computer by means of emulation. DosBox is quite capable of running the software. Here's me on the DosBox forums trying to make that experience suck less.
The software is really very much like another contemporary peice of software called Deluxe Paint. Between Autodesk Animator, and Deluxe Paint, you can account for about 90%*(making shit up) of the game artwork produced between 1989 and 1999. These were *the* pixel art programs. They belong to a class of paint program designed around the limitations of computers that can only display small amounts of colors. A style of paint program that has really fallen into obscurity ever since the photoshops of the world took over with their fancy 24-bit color modes. (oh and by the way, Dr. Katz, Home Movies, and Science Court were made in Animator, also, most of these youtube videos, and also, my cool dinosaur animation)
What sets Animator apart from its contemporaries is its direct keyboard control over animation functions, a very useful Sprite animation mode, and a built in scripting language named PocoScript.
What sets it apart from Modern paint programs is that while it is only capable of producing 256 color images and animations, it has a vast number of tools, inks, filters, and effects that modern programs cannot use in their highly crippled 8-bit modes. In addition, the functions available for manipulating that limited palette are unmatched by any other program I've seen. These properties make it ideally suited for producing art for platforms with limited capacity (such as game consoles, mobile phones, toys, etc) in other words, "pixel art". In its own time, this was thought of as a severe limitation. Today, this is its advantage- this is its characteristic difference.
Just one problem.
So, I'm going to do something about it! I had an idea. In my research, I found out quite a bit about the history of this program. I found out that before it was a PC program named Autodesk Animator, it was an Atari ST program named "Cyberpaint'. Before that it was Aegis Animator, and Flicker, and a conglomeration of other small paint programs and experiments, all authored by a guy named Jim Kent, who had a funny habit of negotating software contracts that let him keep the rights to the source code. Hmm. Interesting little story about Jim Kent. In the year 2000, he mapped the human genome using a cluster of 40 commodity PC's in his basement, Beating out a biotech firm by a day, and thus saving the technology, and our genes from patents. Oh yeah, and he likes open source software.
So I decided to email him, asking if he might, maybe, kind of, consider maybe open sourcing our favorite program. This was his response:
Oh, and by the way...
So, he kept his rights to the source code, and now, he is granting me access to the source code, to make it available to you all! Well not so fast. He also asked me to get in touch with Gary Yost to ensure that he didn't object. (Former owner of Yost Group who licensed the original software to Autodesk), Well okay, that wasn't so easy, since he's now a big shot vice president in a tiny little company called Mental Images
But I managed, and I got his support too! So now that all the relevant parties are up to speed with my idea let's go!
Hold on, though, there's some chores to do first before I can release it to the public. I know I know, blah blah blah. First off, there's a bunch of material in these little zip files which suspiciously looks like stuff that Jim Kent did not write. There's piles and piles of documentation that looks suspiciously.. .copyright autodesk. There's piles of fonts licensed from-- Anim8 inc, a company that I can find ZERO information about. (help?) and Sample artwork that I can't use, because I don't know who made it.
There's also the technical challenges. It would be nice before I release the source code, if I knew all the tools and software that it depends on, and how to compile it. It would be even better if I could adapt the code to compile with tools that are Free and Open Source, rather than tools that are proprietary, out of date, and impossible to find
So I know it's frustrating, but I'm going to have to sit on the code for a short while, so I can sort these issues out. I'm soliciting for anyone that can help with writing documentation, any artists that are willing to make sample artwork using the software, any lawyers that are willing to offer me advice on how to avoid stabbing myself in the foot, and anyone who is a particularly clever programmer that knows anything about programming for MSDOS, or is willing to try their hand at pocoscript to make some sample scripts. I'm kind of a clever cookie myself, and given enough time I can probably get a lot of this stuff done on my own, but it will take me a loooong time without help. I will detail the technical challenges in an upcoming post for those interested, and document my progress through this new project.
Here's a little story about a neat old computer program, and how I plan to save it from the brink of digital death.
For the past few years I've been fascinated by this program. Way back in the beginning, I became aware of the existence of dedicated communities devoted to solely pixel art.
One of the communities, pixelation, had a highly regarded tutorial titled "so you want to be a pixel artist?"
(Links are to mirrors, the original site is long gone). When I read that tutorial was the first time I became aware of the fact that there was a program called "Autodesk Animator". The native format of Animator (fli, flc) was certainly ubiquitous in the 1990's. Even today, Mac OS X doesn't need any special software to play FLI files, quicktime handles them natively. I have also been a participant in the pov-ray community, which used independent dos utilities to string together ray-traced frames into Animator's FLI and FLC format. Why? It was the very first widely available delta compressed video format!
What really grabbed my interest, was this spectacular animation by a guy named Paul Robertson.(NSFW!) who allegedly used Autodesk Animator to make it.
So cargo cultist that I am, I set about attempting to obtain the software. This is really difficult to do, it turns out. Eventually I succeeded. (*whistles). The software can only be run on a modern computer by means of emulation. DosBox is quite capable of running the software. Here's me on the DosBox forums trying to make that experience suck less.
The software is really very much like another contemporary peice of software called Deluxe Paint. Between Autodesk Animator, and Deluxe Paint, you can account for about 90%*(making shit up) of the game artwork produced between 1989 and 1999. These were *the* pixel art programs. They belong to a class of paint program designed around the limitations of computers that can only display small amounts of colors. A style of paint program that has really fallen into obscurity ever since the photoshops of the world took over with their fancy 24-bit color modes. (oh and by the way, Dr. Katz, Home Movies, and Science Court were made in Animator, also, most of these youtube videos, and also, my cool dinosaur animation)
What sets Animator apart from its contemporaries is its direct keyboard control over animation functions, a very useful Sprite animation mode, and a built in scripting language named PocoScript.
What sets it apart from Modern paint programs is that while it is only capable of producing 256 color images and animations, it has a vast number of tools, inks, filters, and effects that modern programs cannot use in their highly crippled 8-bit modes. In addition, the functions available for manipulating that limited palette are unmatched by any other program I've seen. These properties make it ideally suited for producing art for platforms with limited capacity (such as game consoles, mobile phones, toys, etc) in other words, "pixel art". In its own time, this was thought of as a severe limitation. Today, this is its advantage- this is its characteristic difference.
Just one problem.
So, I'm going to do something about it! I had an idea. In my research, I found out quite a bit about the history of this program. I found out that before it was a PC program named Autodesk Animator, it was an Atari ST program named "Cyberpaint'. Before that it was Aegis Animator, and Flicker, and a conglomeration of other small paint programs and experiments, all authored by a guy named Jim Kent, who had a funny habit of negotating software contracts that let him keep the rights to the source code. Hmm. Interesting little story about Jim Kent. In the year 2000, he mapped the human genome using a cluster of 40 commodity PC's in his basement, Beating out a biotech firm by a day, and thus saving the technology, and our genes from patents. Oh yeah, and he likes open source software.
So I decided to email him, asking if he might, maybe, kind of, consider maybe open sourcing our favorite program. This was his response:
Oh, and by the way...
So, he kept his rights to the source code, and now, he is granting me access to the source code, to make it available to you all! Well not so fast. He also asked me to get in touch with Gary Yost to ensure that he didn't object. (Former owner of Yost Group who licensed the original software to Autodesk), Well okay, that wasn't so easy, since he's now a big shot vice president in a tiny little company called Mental Images
But I managed, and I got his support too! So now that all the relevant parties are up to speed with my idea let's go!
Hold on, though, there's some chores to do first before I can release it to the public. I know I know, blah blah blah. First off, there's a bunch of material in these little zip files which suspiciously looks like stuff that Jim Kent did not write. There's piles and piles of documentation that looks suspiciously.. .copyright autodesk. There's piles of fonts licensed from-- Anim8 inc, a company that I can find ZERO information about. (help?) and Sample artwork that I can't use, because I don't know who made it.
There's also the technical challenges. It would be nice before I release the source code, if I knew all the tools and software that it depends on, and how to compile it. It would be even better if I could adapt the code to compile with tools that are Free and Open Source, rather than tools that are proprietary, out of date, and impossible to find
So I know it's frustrating, but I'm going to have to sit on the code for a short while, so I can sort these issues out. I'm soliciting for anyone that can help with writing documentation, any artists that are willing to make sample artwork using the software, any lawyers that are willing to offer me advice on how to avoid stabbing myself in the foot, and anyone who is a particularly clever programmer that knows anything about programming for MSDOS, or is willing to try their hand at pocoscript to make some sample scripts. I'm kind of a clever cookie myself, and given enough time I can probably get a lot of this stuff done on my own, but it will take me a loooong time without help. I will detail the technical challenges in an upcoming post for those interested, and document my progress through this new project.
Thursday, April 9, 2009
Something I've learned
When it comes to huge complicated things like software, it is almost always better to build on previous efforts than to try to demolish those previous efforts to start from scratch.
This is best encapsulated in the following quote, via Daring Fireball
—John Gall
This is best encapsulated in the following quote, via Daring Fireball
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
—John Gall
Subscribe to:
Posts (Atom)