Reading an old post that I didn't get around to publishing before, a new droplet has formed where the last one dried.
The gist of the first idea was to actively colour the letters on a page, to employ the brain's colour-recognition to improve spelling and reading ability. The flaw I found in reading further was that dyslexia and synaesthesia (seeing certain letters as coloured) are related.
In particular, this quote stuck out:
"My daughter, aged 11 is dyslexic and has grapheme-colour synesthesia. The colors negatively affect her ability to read and to spell, since some of the letters have the same color. E and U are both green, for example. She also tends to group the colors and hence inserts letters into words because she thinks their colors “go together”." - Mary G.
The Idea
Mary G's daughter seems to see spelling as a series of colours, and can thus happily swap E and U. However, there are likely to be other aspects of shape that affect the colour. For example, what colour is a spikier E, or a U with a wiggle in it? Intuitively, the changed shape would affect the letter's perceived colour, which might help Mary G's daughter. If an entire font was created based on a fairly standard font, in which certain letters had particular changes made, that girl and others like her might find reading easier, and might make recognising incorrect spellings easier too.
Flaws?
Inevitably, as this is based on intuition, I'm probably wrong. If the girl perceives all Es and all Us as the same colour, regardless of font or handwritten, this won't help.
Alternatives
One alternative might be to attach simple musical notes to the different letters, making sure they harmonise, but that problem groups like E and U do not sound similar. As she types, the flow of notes will be recognisably right or wrong for a given spelling.
Pointlessness
Admittedly, the girl could just rely on Word to correct her spelling all her life. She will also need to learn to spell when writing, and paper can't do customised sound effects.
But she could do a spelling bee with a little humming.
Saturday, January 24, 2009
An email to Kyle Neath on IP and Capital
Reading That's My Property on Kyle's Warpspire blog, I saw some parallels with recent ponderings on capital versus cash flow.
Kyle,
Firstly, props for the blog, quite inspiring to see someone out there and getting on with things. Maybe I just like it because you're on my level. (I read your blog because you remind me of me - what a sentiment.)
Just been reading your thoughts on IP, and thought I'd draw some parallels with capital investment. I've been reading and thinking about capital, interest rates and salary, and it seems that the best thing is to try to turn a chunk of capital into an income, in a better way than just spending it in small chunks (mirroring your point on VC-hunting startups these days).
Suppose I have an idea. Not just any idea, but one of those 'this could change *everything* [for people like me trying to do what I'm trying to do right now]' ideas. The ones people get really precious about and fail to make use of for fear of exploitation. To me, that's like a chunk of money. Now, you can either use it as capital, and try to wring future returns out of it by renting it to other people (licensing), for which you need lawyers, or you can build your own company on it. Either way, it was only ever one idea, one chunk of money. It is limited in how much it can change the world, or get you early retirement.
Capital is limited. Much better is a flow of income. Saving £200 a month is better than investing £20,000, after four or five years. In a similar way, I treat ideas like a flow, not capital. I have some great ideas I'm wild about, but if I haven't done anything with them myself after a while, I will give them away. More ideas will come, formed and shaped by the experiences I have.
Ideas are always over-valued. Google was founded on one idea, sure, but they built on that initial investment with many, many others, and a lot of hard work.
I'm hoping to build a portfolio of the ideas I have, not to boast or to sell, but to convince someone, someday, that these things do not stop falling out of my head, and that it's worth paying me for a time so that I focus on *their* problems. Until then, I'm working on refining the filters, stimuli and breadth of search space available to my imagination so that what does fall out of it always improves in quality and usefulness.
I am, however, always wrong to some degree. Where am I wrong here?
Phil
Kyle,
Firstly, props for the blog, quite inspiring to see someone out there and getting on with things. Maybe I just like it because you're on my level. (I read your blog because you remind me of me - what a sentiment.)
Just been reading your thoughts on IP, and thought I'd draw some parallels with capital investment. I've been reading and thinking about capital, interest rates and salary, and it seems that the best thing is to try to turn a chunk of capital into an income, in a better way than just spending it in small chunks (mirroring your point on VC-hunting startups these days).
Suppose I have an idea. Not just any idea, but one of those 'this could change *everything* [for people like me trying to do what I'm trying to do right now]' ideas. The ones people get really precious about and fail to make use of for fear of exploitation. To me, that's like a chunk of money. Now, you can either use it as capital, and try to wring future returns out of it by renting it to other people (licensing), for which you need lawyers, or you can build your own company on it. Either way, it was only ever one idea, one chunk of money. It is limited in how much it can change the world, or get you early retirement.
Capital is limited. Much better is a flow of income. Saving £200 a month is better than investing £20,000, after four or five years. In a similar way, I treat ideas like a flow, not capital. I have some great ideas I'm wild about, but if I haven't done anything with them myself after a while, I will give them away. More ideas will come, formed and shaped by the experiences I have.
Ideas are always over-valued. Google was founded on one idea, sure, but they built on that initial investment with many, many others, and a lot of hard work.
I'm hoping to build a portfolio of the ideas I have, not to boast or to sell, but to convince someone, someday, that these things do not stop falling out of my head, and that it's worth paying me for a time so that I focus on *their* problems. Until then, I'm working on refining the filters, stimuli and breadth of search space available to my imagination so that what does fall out of it always improves in quality and usefulness.
I am, however, always wrong to some degree. Where am I wrong here?
Phil
Friday, January 16, 2009
Duck-typing vs static with interfaces
Reading Jason Baker's thoughts on the issue, here is my response:
Personally, I've been pondering duck typing vs interfaces for a while. It seems that the choice is between a catch-all (duck typing) and a square hole (interfaces). Interfaces are great for static languages, but are more restrictive at design time than going for duck typing. At the same time, duck typing means that an increasing number of tests are needed to make sure the system copes with different usage.
But what if we restrict ourselves to web services? A datastream (MIME, xml, etc) is passed in, and the service provider has an SLA contract for expecting it to 'work'. But since we're dealing with externally supplied input, we do all our input-checking at the start, to make sure it's all sanitised. After that, we have effectively already done the checking we need (if we've done it well).
Now, do you take the static+interface approach, because you already know what the input is like, or do you take the duck-typing approach, because we've already sanitised the input, and have our TDD tests aligned with our input sanitisation?
My answer would be to go with duck-typing here. If we've defined our SLA well, we have excluded non-compliant input data, which will be turned down at the point of reception into the system. Thus we can dispense with the overheads of interfaces, since we can (Atwood style) throw hardware at the interpreted language speed issue.
Personally, I've been pondering duck typing vs interfaces for a while. It seems that the choice is between a catch-all (duck typing) and a square hole (interfaces). Interfaces are great for static languages, but are more restrictive at design time than going for duck typing. At the same time, duck typing means that an increasing number of tests are needed to make sure the system copes with different usage.
But what if we restrict ourselves to web services? A datastream (MIME, xml, etc) is passed in, and the service provider has an SLA contract for expecting it to 'work'. But since we're dealing with externally supplied input, we do all our input-checking at the start, to make sure it's all sanitised. After that, we have effectively already done the checking we need (if we've done it well).
Now, do you take the static+interface approach, because you already know what the input is like, or do you take the duck-typing approach, because we've already sanitised the input, and have our TDD tests aligned with our input sanitisation?
My answer would be to go with duck-typing here. If we've defined our SLA well, we have excluded non-compliant input data, which will be turned down at the point of reception into the system. Thus we can dispense with the overheads of interfaces, since we can (Atwood style) throw hardware at the interpreted language speed issue.
Subscribe to:
Posts (Atom)