overautomation and cognitive modelling
Jul. 3rd, 2005 02:20 pmI tend to create procedures for routine tasks, and I tend to perform them very absent-mindedly. Maybe this is related to being impatient.
Since I've moved to Amsterdam, locking my bike is a good example. In the beginning, I was too lazy to lock both locks, but now it's second nature to me.
Anyway, this Friday I biked to the suburb of Diemen, which is farther East than any other place I've biked. I found a small garden next to a pond, and I sat down to try to meditate, just watch my breath for a few minutes.
Because I was right there, I didn't lock my bike. When I got the bike again to leave, I locked the bike and tried to move it... then I noticed something strange: the bike wouldn't move even though I thought I had just unlocked it. Then I unlock it again.
The point is that I treat the locking/unlocking process as a switch. When I want to get up and leave, my goal is no longer to "unlock the bike", but to "put the lock on the other setting". I could operate by having a goal of "get on bike" preconditioned by "make sure bike is unlocked", but then I would have to check which setting the lock was in. It's a smaller cognitive load for me to keep my "knowledge in the world" and employ this automated procedure, which works 95% of the time. I think it's not because the checking would cost me time and attention, but because remembering to check is a cognitive load.
Btw, I've forgotten the term used in ACT-R to describe the process by which two production rules collapse into one. This is related "proceduralization of declarative knowledge".
Since I've moved to Amsterdam, locking my bike is a good example. In the beginning, I was too lazy to lock both locks, but now it's second nature to me.
Anyway, this Friday I biked to the suburb of Diemen, which is farther East than any other place I've biked. I found a small garden next to a pond, and I sat down to try to meditate, just watch my breath for a few minutes.
Because I was right there, I didn't lock my bike. When I got the bike again to leave, I locked the bike and tried to move it... then I noticed something strange: the bike wouldn't move even though I thought I had just unlocked it. Then I unlock it again.
The point is that I treat the locking/unlocking process as a switch. When I want to get up and leave, my goal is no longer to "unlock the bike", but to "put the lock on the other setting". I could operate by having a goal of "get on bike" preconditioned by "make sure bike is unlocked", but then I would have to check which setting the lock was in. It's a smaller cognitive load for me to keep my "knowledge in the world" and employ this automated procedure, which works 95% of the time. I think it's not because the checking would cost me time and attention, but because remembering to check is a cognitive load.
Btw, I've forgotten the term used in ACT-R to describe the process by which two production rules collapse into one. This is related "proceduralization of declarative knowledge".
(no subject)
Date: 2005-07-03 09:20 pm (UTC)Crap oh crap, I really should know that; I took Anderson's class...
Ok, I cheated and checked the ACT-R website. It's called "production compilation", described here.
(no subject)
Date: 2005-07-04 09:52 am (UTC)