A team of Carleton researchers is trying to find out why so many computer games shy away from using nonlinear storytelling techniques – that is, techniques that help present stories out of chronological order. Traditional media like films and novels use all kinds of interesting nonlinear techniques, like those found in Run Lola Run, Groundhog Day and Memento. Many games tend to stick to fairly simple techniques like flashbacks, but more sophisticated approaches could result in more games with critically acclaimed stories.Read the rest here!
Wednesday, December 19, 2012
Research Article About Me: Creating Compelling Computer Games
There's a nice story about my research on the Carleton website. I'm particularly happy to see it because it hasn't been easy to figure out my exact thesis project, and it feels good to have finally found my path.
Monday, December 17, 2012
Celebrating One Whole Year
Yesterday was Molly's first birthday, and we had a wonderful family celebration. Looking back, I realized just how much I've accomplished this year! With Christmas and New Year's around the corner, what a perfect time to reflect on all the good things.
In the last year, I have, in no particular order:
In the last year, I have, in no particular order:
- Recovered quickly from an unwanted but complication-free c-section.
- Had 8 months of leave to be with Molly.
- Taught my mini-course on games and computer science for girls.
- Ran a study in my mini-course about teaching computer science with story, and wrote and submitted a paper about it.
- Brought Molly car camping twice.
- Figured out my thesis project.
- Set up an awesome back room play area for Molly.
- Got my wisdom teeth out.
- Had my first of two eye surgeries to help halt my keratoconus.
- Taught a Processing workshop for Girl Develop It.
- Gave a talk at a local sci-fi convention.
- Did a TEDx talk on women in tech.
- Travelled to Baltimore for this year's Grace Hopper Celebration of Women in Computing.
- Submitted and presented a paper on my augmented reality work.
- Got a great team together for Gram's House, and helped move that project forward.
- Got a draft together of a paper on nonlinear stories in traditional media and games.
- Finished my QR code iOS app, and am about to submit it to the App Store.
- Edit to add: Interviewed and got short-listed for a faculty teaching position.
Friday, December 14, 2012
An Update on Tracking My Time
You may recall back in September that I was bringing back time sheets to help myself manage my time between looking after my baby girl and doing schoolwork. Now that a semester has passed, I can reflect on how that actually went.
I did manage to keep track of my time usage quite accurately the entire term, which even I'm impressed by. Granted, I did not use a stopwatch for long, but if anything, the times I recorded were less than actual time spent. This week I decided to take a break from it since things are winding down for the holidays, but I have a tab in my Google spreadsheet for every week until now.
One of the most interesting things that has resulted from time tracking is seeing how many hours I put into research work and TA'ing. I averaged about 20 hours per week, with 25 hours in really good weeks. I admit this seems kind of low at first glance, even to me. But it doesn't mean I worked 4 hours a day for 5 days. Rather, 20 hours is the exact amount of time I spent on task after removing any and all distractions. Put that way, it makes more sense.
Even if I am spending less time on research than before (which I don't think is true, to be honest), I have actually felt a lot more productive in terms of actually finishing things. Just the act of writing down times has been a huge help in cutting out procrastination because I feel more accountable than ever (for example, I have somehow avoided withdrawal symptoms from not looking at Reddit at all for a few months!). I've also gotten better at working on things in smaller bursts, which hasn't been easy when it comes to programming and paper writing.
All in all, the time tracking has obviously been very beneficial to me, so I'll give it another go next semester as well!
Don't Forget To Punch In / Philo Nordlund
I did manage to keep track of my time usage quite accurately the entire term, which even I'm impressed by. Granted, I did not use a stopwatch for long, but if anything, the times I recorded were less than actual time spent. This week I decided to take a break from it since things are winding down for the holidays, but I have a tab in my Google spreadsheet for every week until now.
One of the most interesting things that has resulted from time tracking is seeing how many hours I put into research work and TA'ing. I averaged about 20 hours per week, with 25 hours in really good weeks. I admit this seems kind of low at first glance, even to me. But it doesn't mean I worked 4 hours a day for 5 days. Rather, 20 hours is the exact amount of time I spent on task after removing any and all distractions. Put that way, it makes more sense.
Even if I am spending less time on research than before (which I don't think is true, to be honest), I have actually felt a lot more productive in terms of actually finishing things. Just the act of writing down times has been a huge help in cutting out procrastination because I feel more accountable than ever (for example, I have somehow avoided withdrawal symptoms from not looking at Reddit at all for a few months!). I've also gotten better at working on things in smaller bursts, which hasn't been easy when it comes to programming and paper writing.
All in all, the time tracking has obviously been very beneficial to me, so I'll give it another go next semester as well!
Tuesday, December 11, 2012
The Zombie Game That's Not Really About Zombies
My brother got me a copy of The Walking Dead, which includes all five of the episodes that were previously released separately. He said he got it for three reasons: he likes the associated TV show and wanted to borrow it later, it got great reviews, and it advertised a story that is tailored to the choices you make. This last reason was quite thoughtful, given my interest in games and stories for my thesis!
We started playing right away, and have thus far completed two and a half episodes. Two interesting observations I've made so far are how much like a game this game isn't, and how it's really not about the zombies.
I say it's not much like a game because there isn't a whole lot of gameplay. It's said to be a point-and-click adventure game, and it does have many scenes that fit that genre. But it also has many (many) cut scenes, and any time you have to "fight" a zombie, the buttons sequences demanded of you are pretty amateur compared to most shooter zombie games (which, to be honest, works perfectly well for me!). There also isn't really any choice outside of the dialog options available to you - everything else is very constrained, right down to the camera angles. The funny thing is that none of this bothers me at all because the story is so engrossing.
Which brings me to the point about the zombies. Yes, the premise of the game is that zombies have taken over, making for extreme and dire conditions. And yes, zombies make appearances, and you even have to fight them off once in a while. But that isn't really the main point. It's really about the dynamics of a group trying desperately to survive. Of the lengths people will go to protect their families. Of the horrors you are suddenly willing to commit given the circumstances. In other words, it's really about the story.
I think that this game could be a breakthrough. Although I don't know for sure yet how much the story actually changes according to my choices, it does a great job of making me believe it changes a lot. This seems to replace my need for gameplay freedom, and makes the many cut scenes interesting instead of boring. The fact that the game won several awards, including Game of the Year, suggests that even many so-called hard core gamers must agree. I think this is remarkable, given that The Walking Dead is really more of an interactive cinema experience than a game.
There is hope for the future of interactive storytelling!
We started playing right away, and have thus far completed two and a half episodes. Two interesting observations I've made so far are how much like a game this game isn't, and how it's really not about the zombies.
I say it's not much like a game because there isn't a whole lot of gameplay. It's said to be a point-and-click adventure game, and it does have many scenes that fit that genre. But it also has many (many) cut scenes, and any time you have to "fight" a zombie, the buttons sequences demanded of you are pretty amateur compared to most shooter zombie games (which, to be honest, works perfectly well for me!). There also isn't really any choice outside of the dialog options available to you - everything else is very constrained, right down to the camera angles. The funny thing is that none of this bothers me at all because the story is so engrossing.
Which brings me to the point about the zombies. Yes, the premise of the game is that zombies have taken over, making for extreme and dire conditions. And yes, zombies make appearances, and you even have to fight them off once in a while. But that isn't really the main point. It's really about the dynamics of a group trying desperately to survive. Of the lengths people will go to protect their families. Of the horrors you are suddenly willing to commit given the circumstances. In other words, it's really about the story.
I think that this game could be a breakthrough. Although I don't know for sure yet how much the story actually changes according to my choices, it does a great job of making me believe it changes a lot. This seems to replace my need for gameplay freedom, and makes the many cut scenes interesting instead of boring. The fact that the game won several awards, including Game of the Year, suggests that even many so-called hard core gamers must agree. I think this is remarkable, given that The Walking Dead is really more of an interactive cinema experience than a game.
There is hope for the future of interactive storytelling!
Wednesday, December 5, 2012
Review / Think Like a Programmer: An Introduction to Creative Problem Solving
Programming involves a particular flavour of problem solving. If you're a beginner trying to get better at it, an educator teaching beginners, or just someone who enjoys thinking about thinking, then I may have just the book for you: Think Like a Programmer from No Starch Press.
This book is, as its subtitle promises, an introduction to creative problem solving. It starts with a chapter on general problem solving techniques such as breaking problems into smaller pieces and looking for answers in what you already know. It then devotes a chapter to solving non-programming problems with code. After that, most of the book covers some of the basic problem types all programmers encounter, including arrays, dynamic memory, class design, recursion, and code reuse. The last chapter summarizes general techniques for thinking like a programmer.
I read this book as someone interested in computer science education, particularly for beginners. But despite the fact that I'm an experienced programmer of ten years, I actually enjoyed reading about things I already know how to do. It ended up being an interesting exercise in thinking about thinking, and it brought my attention back to some of the details about programming that I now take for granted.
The author has an easy-to-understand, approachable, discussion-based style of writing. There is a good progression through topics — as a course instructor, you could certainly mirror the flow of the book even if you didn't want to use it as the official text. The numerous diagrams are clear and genuinely useful. I also love that good programming practices are embedded in the discussion, and that many other aspects of CS (for example, data structures) make an appearance in a natural way.
One of the chapters I was most curious about is the one on recursion, given how difficult this topic can be to teach. I liked that this topic was introduced with a detailed real-life example of head and tail recursion. I'm not sure if I was never explicitly taught these concepts or if I've come to take them for granted by now, but I have at the very least not thought about the difference in a long time. I appreciated bringing these ideas back to my conscious mind, and felt like the discussion should be helpful to beginners. I also liked the suggestion to solve problems as if there was no recursion, and to just trust the recursive call to do its thing. (Incidentally, you can read this chapter online, where it is offered as a sample.)
There were a few things I didn't like as much, such as the unnecessarily long paragraphs. I also thought some of the sample problems were cliched and rather dull (how many of us actually care about keeping track of student records?). Each chapter begins with a very fast review of relevant C++ syntax, and while I understand why this is done, I find it ends up being too sparse to be useful to anyone who actually needs it.
Probably the thing I struggle with the most is the choice of C++. I actually think C++ is a reasonable early language for computer science majors (at least in terms of what's currently available), and the rationale for choosing it for the book is sound. However, I don't really know of many post-secondary programs that teach C++ first. The problem is that the book would become a lot less relevant after the first course or two in a good CS program since the concepts will already have been covered, but it's difficult to make use of it unless you already know some C++.
Nonetheless, given to a new programmer at the right time, I think the book has the potential to be very valuable. It comes highly recommended in my mind.
This book is, as its subtitle promises, an introduction to creative problem solving. It starts with a chapter on general problem solving techniques such as breaking problems into smaller pieces and looking for answers in what you already know. It then devotes a chapter to solving non-programming problems with code. After that, most of the book covers some of the basic problem types all programmers encounter, including arrays, dynamic memory, class design, recursion, and code reuse. The last chapter summarizes general techniques for thinking like a programmer.
I read this book as someone interested in computer science education, particularly for beginners. But despite the fact that I'm an experienced programmer of ten years, I actually enjoyed reading about things I already know how to do. It ended up being an interesting exercise in thinking about thinking, and it brought my attention back to some of the details about programming that I now take for granted.
The author has an easy-to-understand, approachable, discussion-based style of writing. There is a good progression through topics — as a course instructor, you could certainly mirror the flow of the book even if you didn't want to use it as the official text. The numerous diagrams are clear and genuinely useful. I also love that good programming practices are embedded in the discussion, and that many other aspects of CS (for example, data structures) make an appearance in a natural way.
One of the chapters I was most curious about is the one on recursion, given how difficult this topic can be to teach. I liked that this topic was introduced with a detailed real-life example of head and tail recursion. I'm not sure if I was never explicitly taught these concepts or if I've come to take them for granted by now, but I have at the very least not thought about the difference in a long time. I appreciated bringing these ideas back to my conscious mind, and felt like the discussion should be helpful to beginners. I also liked the suggestion to solve problems as if there was no recursion, and to just trust the recursive call to do its thing. (Incidentally, you can read this chapter online, where it is offered as a sample.)
There were a few things I didn't like as much, such as the unnecessarily long paragraphs. I also thought some of the sample problems were cliched and rather dull (how many of us actually care about keeping track of student records?). Each chapter begins with a very fast review of relevant C++ syntax, and while I understand why this is done, I find it ends up being too sparse to be useful to anyone who actually needs it.
Probably the thing I struggle with the most is the choice of C++. I actually think C++ is a reasonable early language for computer science majors (at least in terms of what's currently available), and the rationale for choosing it for the book is sound. However, I don't really know of many post-secondary programs that teach C++ first. The problem is that the book would become a lot less relevant after the first course or two in a good CS program since the concepts will already have been covered, but it's difficult to make use of it unless you already know some C++.
Nonetheless, given to a new programmer at the right time, I think the book has the potential to be very valuable. It comes highly recommended in my mind.
Thursday, November 29, 2012
Proof Overtime Is Bad
I am against overtime. I do as little of it as possible. And now I have proof that this philosophy actually makes sense!
Before any potential future employers find this and take my resume off the pile, let me explain. Knowing how long I can work before getting tired is important to me. If I go too long, then I'm likely to just make things worse. Plus, if I know I only have a set amount of time to get things done, I can focus better - there is no later. The standard 8 or 9 hour day seems to work perfectly well for me.
That's not to say that I'm not willing to put in some extra time around a deadline, of course. I have stayed late a few times during my co-op terms and I've worked into the evening on school stuff more than once (though I've only ever done one all-nighter, and it wasn't even strictly necessary). I just ensure this is very much the exception and not the norm.
So, back to this proof I mentioned. The IGDA has a great article on why perpetual crunch modes just don't work. Most other industries started figuring this out 100 years ago (hence why the 40 hour work week is fairly standard). Research literally proves that after a certain number of hours worked in a single week, output goes down when compared to a more regular work week. Working more just doesn't pay.
High tech can be a brutal field when it comes to overtime expectations. My strategy? Don't make working longer a precedent. If you do, then that amount of work will be expected of you. But, of course, the more you work long hours, the less you'll do over time, making you want to work longer to make up for it, making you accomplish less... and so it goes...
The Sleeping Geek Kitten - Angers - / Nathonline-Beta
Before any potential future employers find this and take my resume off the pile, let me explain. Knowing how long I can work before getting tired is important to me. If I go too long, then I'm likely to just make things worse. Plus, if I know I only have a set amount of time to get things done, I can focus better - there is no later. The standard 8 or 9 hour day seems to work perfectly well for me.
That's not to say that I'm not willing to put in some extra time around a deadline, of course. I have stayed late a few times during my co-op terms and I've worked into the evening on school stuff more than once (though I've only ever done one all-nighter, and it wasn't even strictly necessary). I just ensure this is very much the exception and not the norm.
So, back to this proof I mentioned. The IGDA has a great article on why perpetual crunch modes just don't work. Most other industries started figuring this out 100 years ago (hence why the 40 hour work week is fairly standard). Research literally proves that after a certain number of hours worked in a single week, output goes down when compared to a more regular work week. Working more just doesn't pay.
High tech can be a brutal field when it comes to overtime expectations. My strategy? Don't make working longer a precedent. If you do, then that amount of work will be expected of you. But, of course, the more you work long hours, the less you'll do over time, making you want to work longer to make up for it, making you accomplish less... and so it goes...
Monday, November 26, 2012
Resources for Testing Game Story Ideas
I will soon be trying out simple nonlinear narrative ideas for my thesis research, and wanted to find (freely available) tools that will make doing so much easier. Here are a few, some of which are great for beginners and non-programmers. (Know of any other great tools? Let me know in the comments!)
inklewriter
If you want to create branching stories quickly and easily, this free graphical tool might just be for you. It's not likely to be useful for me without access to its source code, but non-programmers should have some fun with it.
Ren'Py
This is how Ren'Py describes itself:
Fabula
As per the Fabula website:
Orx
According to the Orx project site:
inklewriter
If you want to create branching stories quickly and easily, this free graphical tool might just be for you. It's not likely to be useful for me without access to its source code, but non-programmers should have some fun with it.
Ren'Py
This is how Ren'Py describes itself:
Ren'Py is a visual novel engine that helps you use words, images, and sounds to tell stories with the computer. These can be both visual novels and life simulation games. The easy to learn script language allows you to efficiently write large visual novels, while its Python scripting is enough for complex simulation games.I like that beginners can use its simple scripting language to create interesting stories, and that I will be able to use Python to make more sophisticated games. This is probably the first tool I'm going to download and try since it should be really fast to get going on the simplest of ideas.
Fabula
As per the Fabula website:
Fabula is an Open Source Python Game Engine suitable for adventure, role-playing and strategy games and digital interactive storytelling. Fabula can be used as a library to develop your own games. As an alternative, you can use the Pygame-based graphical editor and the default game engine that come with fabula.With this tool, you get into programmer's territory, but still get a lot for free. I like that the engine was designed with storytelling in mind, and that like Ren'Py it uses Python, which should make it fairly easy to work with. I will likely give this one a try early on as well.
Orx
According to the Orx project site:
Orx is an open source, portable, lightweight, plugin-based, data-driven and extremely easy to use 2D-oriented game engine. It has been created to allow fast creation of games and prototypes.The reason I include this project is because I think 2D is the way to go to test story ideas, and such an engine would make creating a 2D game much easier. If the other tools aren't flexible enough to customize things as much as desired, then this might be the way to go (assuming you understand C/C++ programming). I probably won't use this one right away since I don't need the power, but I have a feeling it could come in handy later on.
Wednesday, November 21, 2012
Things I Like About Python
Back in May I wrote a popular post about which was a better beginners language: Processing or Python. Although I concluded that Processing was better for the audiences I tend to have in mind (that is, nontechnical members of the general public), that doesn't mean I think Python is a bad language.
I finally had the opportunity to use Python for my own project. I have been making a simple iOS QR code scavenger hunt / story game as a (very) side project for a while now, and am trying to give it the final push to completion. The game is defined in a plist file. I wanted to generate the QR codes automatically from the data in that plist. I also wanted to arrange the generated images into contact sheets with the text associated with each code written underneath. I figured this was the perfect opportunity to use Python for a real purpose instead of just as a teaching language.
The very best thing about Python is the fact that no matter what singular unit of work you need to do, you can almost always find freely available code online that does it. QR generator? Check. Contact sheet creation? Check. Help with the imaging library, including drawing text? Check. Put the pieces together and do some customization to suit my purposes, and I was off to the races.
I also like the 'scriptiness' of the language. I felt that I didn't need to work hard to make robust and reusable code. So long as it worked for my purpose here, that was good enough. This is a rare feeling for me. I usually feel compelled to make the code as general and 'nice' as possible. I loved being able to do what I wanted quickly and not worrying about what the result looked like.
But that's sort of a downside, too. When I stepped back to look at the code from a beginner's perspective, I noted how messy and likely difficult to understand it had become. I remember reading that Python inherently helped developers write good code (thanks to, for example, indentation to signify blocks of code). But this experience made me believe the opposite - it's so easy to write fast code that it can quickly end up being kind of ugly.
I also had a heck of a time getting everything set up on my Macbook. Python comes installed on OSX, but it's usually kind of old. So I downloaded and installed Python 3. After wrestling with the OS to get it to actually use that version for most Python-related things, I quickly found that the libraries I was trying to use didn't really work with this version. After several hours I ended up reverting back to the newest release of version 2. If I was a beginner trying to accomplish some relatively simple task, I would have been turned off the whole thing pretty quickly, if I even understood how to set up the environment in the first place (and I doubt much of the general public would, given how much time you are likely to spend at the command line).
So, all in all, I really like Python for my own purposes as an experienced programmer. But I'm still favouring Processing (or, even better, something like Scratch or some not-yet-existing language theorized by Bret Victor) as a beginner language. I could see Python being really handy once the basics are taught and some confidence is built, but I am still fairly sure I wouldn't want to begin with it if I had a choice.
The very best thing about Python is the fact that no matter what singular unit of work you need to do, you can almost always find freely available code online that does it. QR generator? Check. Contact sheet creation? Check. Help with the imaging library, including drawing text? Check. Put the pieces together and do some customization to suit my purposes, and I was off to the races.
I also like the 'scriptiness' of the language. I felt that I didn't need to work hard to make robust and reusable code. So long as it worked for my purpose here, that was good enough. This is a rare feeling for me. I usually feel compelled to make the code as general and 'nice' as possible. I loved being able to do what I wanted quickly and not worrying about what the result looked like.
But that's sort of a downside, too. When I stepped back to look at the code from a beginner's perspective, I noted how messy and likely difficult to understand it had become. I remember reading that Python inherently helped developers write good code (thanks to, for example, indentation to signify blocks of code). But this experience made me believe the opposite - it's so easy to write fast code that it can quickly end up being kind of ugly.
I also had a heck of a time getting everything set up on my Macbook. Python comes installed on OSX, but it's usually kind of old. So I downloaded and installed Python 3. After wrestling with the OS to get it to actually use that version for most Python-related things, I quickly found that the libraries I was trying to use didn't really work with this version. After several hours I ended up reverting back to the newest release of version 2. If I was a beginner trying to accomplish some relatively simple task, I would have been turned off the whole thing pretty quickly, if I even understood how to set up the environment in the first place (and I doubt much of the general public would, given how much time you are likely to spend at the command line).
So, all in all, I really like Python for my own purposes as an experienced programmer. But I'm still favouring Processing (or, even better, something like Scratch or some not-yet-existing language theorized by Bret Victor) as a beginner language. I could see Python being really handy once the basics are taught and some confidence is built, but I am still fairly sure I wouldn't want to begin with it if I had a choice.
Monday, November 12, 2012
Indie Game: The Movie
I am very grateful that I will (hopefully) be lucky enough to see my vision for my Gram's House game developed professionally with research grants. After watching Indie Game: The Movie, this sentiment has only increased. Though the documentary only presents one experience of independent game production, it's not an experience I particularly want to have.
I thought that this documentary was really well done. The filmmakers did a great job of finding a good story with tension and drama in the development process. I felt such relief when good things finally happened to each of them.
The elation experienced particularly by the Super Meat Boy creators got me thinking: what happens to those who spend a few hellish years trying to finish their masterpiece, but end up with little to show for it? I wonder how often the risks pay off? I'm sure not everyone drops everything to work on their game, and even those that do probably don't always forego any sort of life balance to do it. But I would not want to see anyone experience risking everything and losing.
Of course, great success doesn't always bring happiness. Braid's creator was shown to be fairly (even deeply) disappointed even after his game broke indie records. People loved his game, but they didn't get it. The reviews focused on superficial mechanical elements, but not the deeper meaning.
Which brings me to the issue of games as art. After listening to all the game creators talk about how much their games reflect themselves, how the games express what they think and feel, I don't know how how anyone could say that games can't be art. If you aren't yet convinced yourself, watch the movie and listen for those moments.
Overall, I definitely recommend this movie, and hope more like it will be made to show a variety of indie game creation experiences.
I thought that this documentary was really well done. The filmmakers did a great job of finding a good story with tension and drama in the development process. I felt such relief when good things finally happened to each of them.
The elation experienced particularly by the Super Meat Boy creators got me thinking: what happens to those who spend a few hellish years trying to finish their masterpiece, but end up with little to show for it? I wonder how often the risks pay off? I'm sure not everyone drops everything to work on their game, and even those that do probably don't always forego any sort of life balance to do it. But I would not want to see anyone experience risking everything and losing.
Of course, great success doesn't always bring happiness. Braid's creator was shown to be fairly (even deeply) disappointed even after his game broke indie records. People loved his game, but they didn't get it. The reviews focused on superficial mechanical elements, but not the deeper meaning.
Which brings me to the issue of games as art. After listening to all the game creators talk about how much their games reflect themselves, how the games express what they think and feel, I don't know how how anyone could say that games can't be art. If you aren't yet convinced yourself, watch the movie and listen for those moments.
Overall, I definitely recommend this movie, and hope more like it will be made to show a variety of indie game creation experiences.
Friday, November 9, 2012
Seeking Nominations for the 2013 Women of Vision Awards
I serve on the Advisory Board of the Anita Borg Institute, an organization focused on increasing women's participation in the technology workforce --- as technologists, and as technical leaders. One important aspect of our work is recognizing the contributions of amazing women technical leaders all over the world. We do this through the Women of Vision program.
We are now accepting nominations for the 2013 Women of Vision awards.
We could greatly use your help identifying women who deserve recognition, and facilitating their nomination. These women are incredible achievers whose stories inspire us, and whose example can be held up as a role model for thousands of other technical women. A bit of background:
These awards recognize outstanding women for Leadership, Social Impact, and Innovation. See the full descriptions of these award categories online.
Last year we honoured these amazing women:
Please think about a woman at your organization or school (or anywhere, really) who deserves to be honoured for her career achievements, and nominate her! Please contact me if there is any way I can help you with this action.
The deadline to submit a nomination is December 14, 2012.
Also be sure to save the date for the 8th annual Women of Vision Awards Banquet on May 9, 2013 in Santa Clara, California. Registration passes and table sponsorships will be available for purchase soon.
We are now accepting nominations for the 2013 Women of Vision awards.
We could greatly use your help identifying women who deserve recognition, and facilitating their nomination. These women are incredible achievers whose stories inspire us, and whose example can be held up as a role model for thousands of other technical women. A bit of background:
These awards recognize outstanding women for Leadership, Social Impact, and Innovation. See the full descriptions of these award categories online.
Last year we honoured these amazing women:
- Sarita Adve, Professor of Computer Science, University of Illinois at Urbana-Champaign, for Innovation.
- Sarah Revi Sterling, Faculty Director, ATLAS Institute at the University of Colorado at Boulder, for Social Impact.
- Jennifer Chayes, Distinguished Scientist and Managing Director, Microsoft Research New England, for Leadership.
Please think about a woman at your organization or school (or anywhere, really) who deserves to be honoured for her career achievements, and nominate her! Please contact me if there is any way I can help you with this action.
The deadline to submit a nomination is December 14, 2012.
Also be sure to save the date for the 8th annual Women of Vision Awards Banquet on May 9, 2013 in Santa Clara, California. Registration passes and table sponsorships will be available for purchase soon.
Monday, November 5, 2012
I'm Going To Be a TEDx Speaker
I'm happy that I'm starting to get noticed when it comes to my public speaking abilities. My latest speaking request was for a local edition of TED on December 2: TEDxSandyHillWomen. A fellow speaker had been at my Processing workshop and thought I'd enjoy talking about women in tech.
I haven't decided exactly what I'll talk about yet, but you can be sure I'll be following my own strict presentation policies (including having little or no text on my slides). I might go with the "It's Not About the Numbers" theme I sometimes talk about. More to come!
I am going to be a TEDx speaker in Ottawa! I'm going to talk about women in tech in some form or another. Excited! ted.com/tedx/events/66…
— Gail Carmichael (@gailcarmichael) November 4, 2012
I haven't decided exactly what I'll talk about yet, but you can be sure I'll be following my own strict presentation policies (including having little or no text on my slides). I might go with the "It's Not About the Numbers" theme I sometimes talk about. More to come!
Tuesday, October 30, 2012
Two Interesting Games With a Message
I found a couple of interesting games after reading Kotaku's recent article The Complicated Truth Behind Games That Want to Change the World. One has more gameplay time than the other, but both can be experienced in a short period of time, making them worth a quick look.
Sweatshop
The first game is called Sweatshop. It is essentially a tower defence-style game where you place workers instead of towers to create items of knock-off clothing instead of kill enemies. You start with a child worker that costs less than others. As you move up through the levels, you get different types of pricier but quicker workers to place, such as a shirt maker or a hat maker. You need to place them around the conveyor belt strategically so that they are able to finish creating and packaging each item before it reaches the end.
The thing that intrigued me about this game was whether it used procedural rhetoric to make its point. From the Kotaku article:
Unmanned
Unmanned, on the other hand, is more of a story-based game experience. The game is presented with a split screen. In the screenshot above, which comes from the opening sequence, the main character is shown on the left asleep, and what seems to be his dream appears on the right. Much of the time, one side of the screen is dedicated to dialog and dialog choices. Though you can earn medals by choosing the right dialog, this example is much less game-like than Sweatshop.
Kotaku doesn't say much about this one; just that it's "nothing short of remarkable." The story follows a man who is apparently a soldier. He seems to be working to stop terrorist activity. You follow him through a typical day, where at one point he's on the cell phone talking to his wife (?) about their son, and after work he's playing war games with that son. You get a disjointed feel for his character, and you help build it through your dialog choices. There is much left unsaid so that you fill in the blanks, and I think that is what makes this experience so potentially powerful.
Sweatshop
The first game is called Sweatshop. It is essentially a tower defence-style game where you place workers instead of towers to create items of knock-off clothing instead of kill enemies. You start with a child worker that costs less than others. As you move up through the levels, you get different types of pricier but quicker workers to place, such as a shirt maker or a hat maker. You need to place them around the conveyor belt strategically so that they are able to finish creating and packaging each item before it reaches the end.
The thing that intrigued me about this game was whether it used procedural rhetoric to make its point. From the Kotaku article:
The game aims to educate players on workplace conditions around the world. "I think its strength comes from putting you in the role of the manager, someone who is still a guilty party but has some capacity for empathy," she [Mattie Brice, social justice activist and game critic] explained. "The game forces you to be efficient and min/max to keep profits high, and usually has you doing some unethical things to your workers. Instead of having an artificial story put on top of a detached mechanic or so, the game twists how you already interact with tower defense and uses that to create a connection to what's going on."So it seems there is an argument for this. To maximize profits and thus win the game, you have to be unethical and act as they really do in sweatshops. I think designers of games for change need to pay more attention to procedural rhetoric if we want to see more good games of this type.
Unmanned
Unmanned, on the other hand, is more of a story-based game experience. The game is presented with a split screen. In the screenshot above, which comes from the opening sequence, the main character is shown on the left asleep, and what seems to be his dream appears on the right. Much of the time, one side of the screen is dedicated to dialog and dialog choices. Though you can earn medals by choosing the right dialog, this example is much less game-like than Sweatshop.
Kotaku doesn't say much about this one; just that it's "nothing short of remarkable." The story follows a man who is apparently a soldier. He seems to be working to stop terrorist activity. You follow him through a typical day, where at one point he's on the cell phone talking to his wife (?) about their son, and after work he's playing war games with that son. You get a disjointed feel for his character, and you help build it through your dialog choices. There is much left unsaid so that you fill in the blanks, and I think that is what makes this experience so potentially powerful.
Thursday, October 25, 2012
Research Snapshot for Fall 2012
Now that I'm back in school full time, it's a good time to have a look at where I am research-wise. Here are some of the projects I'm working on and what progress I've made. (My last snapshot was from Fall 2011, before I went on maternity leave, and has more detail about some of these projects.)
Cognitive Advantages of Augmented Reality
My work in this area was finally published with a learning spin at E-Learn. You can check out the final abstract and paper on my website or read about it on this blog to see some possible future directions others can take.
Gram's House
Since last fall, this project has moved forward a bit. One of our team members ran a pilot project that just wrapped up. The study compared a slightly updated version of Gram's House that tracks player stats, and a new game created by my colleague's students. It will be very interesting to see the data that was collected during the study.
In the meantime, we are also finding some new researchers who want to try for an NSF (or other) grant to further develop the project. We've got a few ideas on how to make our project stand out among the many trying to do things like this with games, and I'm excited to see where we go!
Although not everything is public right now, you can track the project on my website.
Teaching and Learning Computer Science With Story
This project centred on the study we did in this past year's mini-course. The study went well and we learned some interesting things (like the fact that story had little or not benefit over context). However, the paper we submitted to SIGCSE was not accepted.
We are in the process of deciding what to do next, but I am leaning toward taking what we learned, doing a follow up study, and submitting to next year's conference. I am not sure if I'd like to stick to the middle school age group or try something in an undergrad class.
Nonlinear Story in Games
This is the thread of research that will be my thesis. In fact, my supervisor liked the ideas I had put together while on leave, so I have a good, solid direction now! In a nutshell, I want to use procedural rhetoric as a way to break apart story episodes in a reasonable way, and learning theory to dynamically arrange those pieces as well as entire episodes.
Before delving too deeply into my specific ideas, however, I'm going to finish some work I started last fall. We're looking at nonlinear stories (that is, stories whose events are presented out of chronological order) and comparing them to nonlinear stories in games. We are trying to see why games shy away from more sophisticated uses of nonlinear stories, which may lead to new ideas on how to do it.
Cognitive Advantages of Augmented Reality
My work in this area was finally published with a learning spin at E-Learn. You can check out the final abstract and paper on my website or read about it on this blog to see some possible future directions others can take.
Gram's House
Since last fall, this project has moved forward a bit. One of our team members ran a pilot project that just wrapped up. The study compared a slightly updated version of Gram's House that tracks player stats, and a new game created by my colleague's students. It will be very interesting to see the data that was collected during the study.
In the meantime, we are also finding some new researchers who want to try for an NSF (or other) grant to further develop the project. We've got a few ideas on how to make our project stand out among the many trying to do things like this with games, and I'm excited to see where we go!
Although not everything is public right now, you can track the project on my website.
Teaching and Learning Computer Science With Story
This project centred on the study we did in this past year's mini-course. The study went well and we learned some interesting things (like the fact that story had little or not benefit over context). However, the paper we submitted to SIGCSE was not accepted.
We are in the process of deciding what to do next, but I am leaning toward taking what we learned, doing a follow up study, and submitting to next year's conference. I am not sure if I'd like to stick to the middle school age group or try something in an undergrad class.
Nonlinear Story in Games
This is the thread of research that will be my thesis. In fact, my supervisor liked the ideas I had put together while on leave, so I have a good, solid direction now! In a nutshell, I want to use procedural rhetoric as a way to break apart story episodes in a reasonable way, and learning theory to dynamically arrange those pieces as well as entire episodes.
Before delving too deeply into my specific ideas, however, I'm going to finish some work I started last fall. We're looking at nonlinear stories (that is, stories whose events are presented out of chronological order) and comparing them to nonlinear stories in games. We are trying to see why games shy away from more sophisticated uses of nonlinear stories, which may lead to new ideas on how to do it.
Friday, October 19, 2012
Passing the CU-WISE Torch
I'm one of the original founders of our Carleton University Women in Science and Engineering group. I stayed on the exec for a few years, stepping down only when I was pregnant, since I knew I wasn't going to be there the whole year. I was the last remaining original exec. The transition into new leadership was tricky at first, but I couldn't be more proud of what the new generation of CU-WISE is doing!
I put a lot of effort into making CU-WISE successful and, more importantly, sustainable. From ensuring we had an up-to-date web presence, to creating a consistent brand, to planning outreach events and events for current students, to getting our mentoring program off the ground... I did a lot. When I left, they needed more than one person to replace me! Despite my efforts in documenting everything, it was difficult at first for those who remained to get off the ground.
After a bit of struggle last year, CU-WISE is totally rocking it this year. We finally scored some coveted office space, which the new co-chairs have set up very nicely. They use it to meet in person weekly, something we never did before (but should have). One of our past execs has offered to get the mentoring program going again remotely, despite being a post-doc at another institution now. There are several really interesting new events planned, including outreach events that build off of what I had created in the past. Things are looking amazing. The only thing that's needed is a few more executive members to help the current team out!
So why do I tell you all this? Yes, I did want to share my pride, but I also wanted to encourage anyone else who wonders whether all the effort is worth it. It is! If you're trying to get a women in science and/or engineering program off the ground at your school or workplace, give it all you can reasonably give. Document everything so others can take over later. And if you're finding nobody is able to carry the torch at first, don't fret - persevere, and you'll see the fruits of your effort in no time. You'll be amazed at what comes next.
I put a lot of effort into making CU-WISE successful and, more importantly, sustainable. From ensuring we had an up-to-date web presence, to creating a consistent brand, to planning outreach events and events for current students, to getting our mentoring program off the ground... I did a lot. When I left, they needed more than one person to replace me! Despite my efforts in documenting everything, it was difficult at first for those who remained to get off the ground.
After a bit of struggle last year, CU-WISE is totally rocking it this year. We finally scored some coveted office space, which the new co-chairs have set up very nicely. They use it to meet in person weekly, something we never did before (but should have). One of our past execs has offered to get the mentoring program going again remotely, despite being a post-doc at another institution now. There are several really interesting new events planned, including outreach events that build off of what I had created in the past. Things are looking amazing. The only thing that's needed is a few more executive members to help the current team out!
So why do I tell you all this? Yes, I did want to share my pride, but I also wanted to encourage anyone else who wonders whether all the effort is worth it. It is! If you're trying to get a women in science and/or engineering program off the ground at your school or workplace, give it all you can reasonably give. Document everything so others can take over later. And if you're finding nobody is able to carry the torch at first, don't fret - persevere, and you'll see the fruits of your effort in no time. You'll be amazed at what comes next.
Friday, October 12, 2012
My Brief Visit to E-Learn
I went to Montreal on Wednesday to present my work on what makes augmented reality good for learning (and in general, really). The conference was the World Conference on E-Learning in Corporate, Government, Healthcare & Higher Education (or just E-Learn for short). It was an interesting experience, but in the end, not entirely satisfying for me personally.
I only attended E-Learn for the day since it would have been difficult to bring the baby along this time, and Montreal is only 2.5 hours away on the train. This meant that I missed all the keynotes and, because I also had to pump milk twice while there, many of the regular sessions. Some of the sessions I did see were so poorly presented that I don't even know what they were about anymore.
I felt like I did a good job of my talk. (The slides are above, but they are fairly minimal and are missing the transitions. If you're interested in this work, definitely check out its research page, where you can read the full paper.) Unfortunately, it seemed that the audience wasn't quite right. My work is more geared toward those building augmented reality systems, while the people who attended my talk seemed to be those who want to use AR. So here I was convincing them how great AR could be for them, but had little to offer in easy, ready-for-the-classroom solutions. I felt kind of down about it by the end.
Luckily, a few people came and talked to me later in the day, and that boosted my spirits. Some just commented that they enjoyed the talk, and others were itching to collaborate. For instance, the chair of the session told me he requested it because he thought my topic was interesting. He mentioned he wanted to do something with QR codes. Since the little QR code app I've been working on here and there is almost app-store ready, I figured we may as well try it out for his needs. At the same time, we could try to employ the advice in the paper to help validate it experimentally. I'm looking forward to getting in touch with him soon. There was also a lady from Carleton that might be able to make use of my work, and we'll meet up for coffee sometime soon.
The most interesting talk I caught after my own was by one of the founders of an ed-tech company from Toronto called Spongelab. They do educational games, but that wasn't what the talk was about. Instead, the focus was a recently released science education content community, which is what you see when you visit the main website. It's a place for sharing and organizing resources to use in STEM education, and is free and open for everyone to use. It looks quite promising, though there is currently nothing for computer science and only a bit for engineering (perhaps something we can work to fix?). If you're an educator in STEM, I recommend checking it out.
Maybe it's because I was there for such a short time, but I didn't get a lot out of attending E-Learn. I can see why others would like it, but I doubt I'd want to go again unless I had a paper that was really well suited to their program. But that's ok - I am glad to have my AR work out there, and will look forward to the potential collaborations that come out of it!
I only attended E-Learn for the day since it would have been difficult to bring the baby along this time, and Montreal is only 2.5 hours away on the train. This meant that I missed all the keynotes and, because I also had to pump milk twice while there, many of the regular sessions. Some of the sessions I did see were so poorly presented that I don't even know what they were about anymore.
I felt like I did a good job of my talk. (The slides are above, but they are fairly minimal and are missing the transitions. If you're interested in this work, definitely check out its research page, where you can read the full paper.) Unfortunately, it seemed that the audience wasn't quite right. My work is more geared toward those building augmented reality systems, while the people who attended my talk seemed to be those who want to use AR. So here I was convincing them how great AR could be for them, but had little to offer in easy, ready-for-the-classroom solutions. I felt kind of down about it by the end.
Luckily, a few people came and talked to me later in the day, and that boosted my spirits. Some just commented that they enjoyed the talk, and others were itching to collaborate. For instance, the chair of the session told me he requested it because he thought my topic was interesting. He mentioned he wanted to do something with QR codes. Since the little QR code app I've been working on here and there is almost app-store ready, I figured we may as well try it out for his needs. At the same time, we could try to employ the advice in the paper to help validate it experimentally. I'm looking forward to getting in touch with him soon. There was also a lady from Carleton that might be able to make use of my work, and we'll meet up for coffee sometime soon.
The most interesting talk I caught after my own was by one of the founders of an ed-tech company from Toronto called Spongelab. They do educational games, but that wasn't what the talk was about. Instead, the focus was a recently released science education content community, which is what you see when you visit the main website. It's a place for sharing and organizing resources to use in STEM education, and is free and open for everyone to use. It looks quite promising, though there is currently nothing for computer science and only a bit for engineering (perhaps something we can work to fix?). If you're an educator in STEM, I recommend checking it out.
Maybe it's because I was there for such a short time, but I didn't get a lot out of attending E-Learn. I can see why others would like it, but I doubt I'd want to go again unless I had a paper that was really well suited to their program. But that's ok - I am glad to have my AR work out there, and will look forward to the potential collaborations that come out of it!
Sunday, October 7, 2012
NSF Funding Opportunities and Effective Proposal Writing Strategies (GHC12)
Even though I'm a Canadian grad student, the Grace Hopper session on National Science Foundation (NSF) opportunities was very relevant to me. As my collaborators and I try to put together a team and plan for my Gram's House project, we are looking toward putting in a grant application. So at this talk, I was looking for inside tips from the panellists representing NSF that might help increase our chances of success.
The presentation gave a good overview of the various programs available from NSF, but rather than reiterate those here, I encourage you to look at the funding portion of NSF's website. The program I am most interested in was Computing Education for the 21st Century since I thought that would be the best fit for Gram's House.
One interesting statistic on the applications for NSF grants: the percentage of women applying tends to be low, but the acceptance rate of men and women according to how many applied is more or less equal. Turns out this is because when women are rejected, they often stop there. But when men are rejected, they get mad, and try again. And again. However many times it takes. I'll have to keep this in mind as we try to move our project forward.
As for strategies for success, it's important to remember there's no magic formula. It's useful to keep in mind some of the key questions reviewers will want answered:
Some of the advice the presenters gave for developing your bright idea includes:
The top 5 strengths of successful proposals:
Another couple of tips that I did not know about include the ability to speak with the program manager on the phone for advice (they encourage it!) and the ability to ask NSF for access to successfully funded applications. I think I will do both for our project.
It is going to be an interesting experience applying for NSF funding, but if we can eventually make it happen, it will be so very worth the effort. I am looking forward to seeing Gram's House realized in a professionally developed game and testing its impact.
The presentation gave a good overview of the various programs available from NSF, but rather than reiterate those here, I encourage you to look at the funding portion of NSF's website. The program I am most interested in was Computing Education for the 21st Century since I thought that would be the best fit for Gram's House.
One interesting statistic on the applications for NSF grants: the percentage of women applying tends to be low, but the acceptance rate of men and women according to how many applied is more or less equal. Turns out this is because when women are rejected, they often stop there. But when men are rejected, they get mad, and try again. And again. However many times it takes. I'll have to keep this in mind as we try to move our project forward.
As for strategies for success, it's important to remember there's no magic formula. It's useful to keep in mind some of the key questions reviewers will want answered:
- What do you intend to do?
- How important is the work? (probably the single most important part)
- What has already been done? (also extremely important)
- How are you going to do the work?
- Does it fit into the solicitation? (note that you can actually indicate a secondary program, so take advantage!)
Some of the advice the presenters gave for developing your bright idea includes:
- survey the literature - if not relevant to a particular body of work, cite it and say why it’s not relevant
- contact other investigators working on the same subject - collaboration opportunities?
- prepare a brief concept paper
- discuss with colleagues and mentors
- determine available resources
- realistically assess your needs
- develop preliminary results
- if you don’t have preliminary results, it’s probably not going to do well
- present to your colleagues, mentors, and students
- present to non-experts! If a non-expert can understand, that’s a good start
- determine possible funding sources
- NSF responsible for 80% of funding in terms of size - seek out the other 20%
- understand the ground rules
- read solicitations carefully
The top 5 strengths of successful proposals:
- Important, timely topics and responsive to needs
- Expertise in the area, solid prior work
- Sufficient detail and clear plans
- Innovative, novel, with potential for big impact
- Convincing broader impact
- don’t just write about it - actually think about it and do it!
Another couple of tips that I did not know about include the ability to speak with the program manager on the phone for advice (they encourage it!) and the ability to ask NSF for access to successfully funded applications. I think I will do both for our project.
It is going to be an interesting experience applying for NSF funding, but if we can eventually make it happen, it will be so very worth the effort. I am looking forward to seeing Gram's House realized in a professionally developed game and testing its impact.
Go Lean, Go Agile: Are We There Yet? (GHC12)
The concept of agile development has always fascinated me, particularly because I haven't had the opportunity yet to work on an agile team. (This despite having done five 4-month co-op terms during my undergrad.) So, the panel presentation on lean and agile development at GHC12 was definitely on my list.
The panellists included Mario Moreira (an Agile and Configuration Management industry expert), Rae Wang (Senior Program Manager at Microsoft currently working in Exchange Online), Jill Wetzler (lead software developer and scrum master at salesforce.com), and Janet Swedal (Senior Director in the Technology organization for Thomson Reuters). Their experience and insight was amazing.
The big theme for the talk was the challenges of adopting agile in your team. Sometimes teams really have no choice but to go agile given the frequency of releases to customers and opportunities for feedback. But it's not easy to implement the change; it requires an all-in buy-in from team members to the executives, for example.
The speakers explained some of the benefits of going agile: agile development encourages incremental / iterative development, adaptive planning, rapid and flexible response to change, etc… The collaboration and communication the methodology encourages is seen by some as the number one benefit. In fact, research has shown that the communication differences between men and women all but disappear in agile teams.
An interesting issue brought up through audience questioning was that of technical debt. How do you ensure that bugs are fixed and code gets refactored when needed? The speakers suggest taking a methodological approach: have a refactoring strategy at the beginning of a project, and turn this work into a technical story. Refactoring and bug fixing can also be part of the 'done' criteria of a particular story. You can also take an entire sprint to work on bugs, or rotate resources to fix bugs. You have to make it a priority before you end up with a mountain of debt.
I know a few people who have worked on agile teams. I found this presentation very interesting because I could see why some of the problems they were complaining about might be showing up. For instance, one team didn't appear to be taking technical debt seriously enough. I also wondered if all the teams I know about were actually well suited to being agile (another common thread of discussion in the presentation). It seems that the way they divide work might be contributing to lower quality output for the sake of being agile, and it's not clear whether they work in a particularly iterative way.
But all this is mostly speculation, since I am not entirely familiar with the methodology yet. When I get a chance, I look forward to reading up more on agile, and potentially trying to use it in my own thesis work as well as any team projects I am involved with in the future.
The panellists included Mario Moreira (an Agile and Configuration Management industry expert), Rae Wang (Senior Program Manager at Microsoft currently working in Exchange Online), Jill Wetzler (lead software developer and scrum master at salesforce.com), and Janet Swedal (Senior Director in the Technology organization for Thomson Reuters). Their experience and insight was amazing.
The big theme for the talk was the challenges of adopting agile in your team. Sometimes teams really have no choice but to go agile given the frequency of releases to customers and opportunities for feedback. But it's not easy to implement the change; it requires an all-in buy-in from team members to the executives, for example.
The speakers explained some of the benefits of going agile: agile development encourages incremental / iterative development, adaptive planning, rapid and flexible response to change, etc… The collaboration and communication the methodology encourages is seen by some as the number one benefit. In fact, research has shown that the communication differences between men and women all but disappear in agile teams.
An interesting issue brought up through audience questioning was that of technical debt. How do you ensure that bugs are fixed and code gets refactored when needed? The speakers suggest taking a methodological approach: have a refactoring strategy at the beginning of a project, and turn this work into a technical story. Refactoring and bug fixing can also be part of the 'done' criteria of a particular story. You can also take an entire sprint to work on bugs, or rotate resources to fix bugs. You have to make it a priority before you end up with a mountain of debt.
I know a few people who have worked on agile teams. I found this presentation very interesting because I could see why some of the problems they were complaining about might be showing up. For instance, one team didn't appear to be taking technical debt seriously enough. I also wondered if all the teams I know about were actually well suited to being agile (another common thread of discussion in the presentation). It seems that the way they divide work might be contributing to lower quality output for the sake of being agile, and it's not clear whether they work in a particularly iterative way.
But all this is mostly speculation, since I am not entirely familiar with the methodology yet. When I get a chance, I look forward to reading up more on agile, and potentially trying to use it in my own thesis work as well as any team projects I am involved with in the future.
Thursday, October 4, 2012
Lili Cheng: Creativity, Learning, and Social Software (GHC12)
Who knew a past in physical architecture would suit a career in technology research so well! Lili Cheng — general manager of Microsoft Research's FUSE labs — did! And she told us all about it in her talk at Grace Hopper today.
Lili had started her career in irrigation, worked on Canary Wharf in London, and was involved with tree-like designs for buildings in Tokyo. She learned that your past stays with you and continues to inform you. The combination of natural and machine-made systems are unpredictable, human, and evolve over time; this idea applies to architecture and social media.
Lili gave us a whirlwind tour of the projects her group has done, including Kodu and Montage.
Kodu was inspired by the fact that kids don't make enough on PC's, but they do play a lot of games. The group wanted to know whether they could make creating a game simple enough for five-year-olds to do it. The kids who use the graphical, event-driven language don't learn programming per se, but they do learn logic and programming concepts.
I've known about Kodu for some time now, but never had the chance to try it. Now that I realize it's free on the PC, I'm inspired to have another look. Perhaps it would be a good alternative to GameMaker for my mini-course. It seems that it's used a lot in K-12, but for some reason I don't heard about it in a concrete way very often around me. I'm not sure what that means; either other options are more suitable or I'm just not listening to the right people to hear about it.
Montage was a neat project that I hadn't heard about before. It works by typing in a search term, and getting back a newspaper-like collection of items about that topic. The neat thing is that the whole thing is editable; you can change the layout and the content. The collection includes articles, images, and Tweets found online. You can save and share your creation with others via the So.Cl (pronounced social) site, which is technically a different project that happens to allow you to create montages in a more social way.
My first thought on Montage was that it reminded me of Paper.li, right down to the silly name and URL. I wouldn't ever have known what Paper.li was if it weren't for the fact that others had included Tweets I'd made in their daily newspapers. I still don't know if they curate the content manually or automatically. I wonder if Montage is intended to be used the same way, and whether it has any similar mechanisms for allowing people whose content is included to discover the site. If nothing else, it does look like a fun way to search and share interesting content in a Pinterest sort of way.
Hearing Lili talk about all the amazing things she and her team has done was really inspiring. It got Andrew and I talking about putting together a five year plan that might allow us to do more interesting things in the future. It also really encouraged me to consider trying for an internship with Microsoft Research once the baby gets older. Maybe my varied interests will come in handy like Lili's past career did for her!
Lili had started her career in irrigation, worked on Canary Wharf in London, and was involved with tree-like designs for buildings in Tokyo. She learned that your past stays with you and continues to inform you. The combination of natural and machine-made systems are unpredictable, human, and evolve over time; this idea applies to architecture and social media.
Lili gave us a whirlwind tour of the projects her group has done, including Kodu and Montage.
Kodu was inspired by the fact that kids don't make enough on PC's, but they do play a lot of games. The group wanted to know whether they could make creating a game simple enough for five-year-olds to do it. The kids who use the graphical, event-driven language don't learn programming per se, but they do learn logic and programming concepts.
I've known about Kodu for some time now, but never had the chance to try it. Now that I realize it's free on the PC, I'm inspired to have another look. Perhaps it would be a good alternative to GameMaker for my mini-course. It seems that it's used a lot in K-12, but for some reason I don't heard about it in a concrete way very often around me. I'm not sure what that means; either other options are more suitable or I'm just not listening to the right people to hear about it.
Montage was a neat project that I hadn't heard about before. It works by typing in a search term, and getting back a newspaper-like collection of items about that topic. The neat thing is that the whole thing is editable; you can change the layout and the content. The collection includes articles, images, and Tweets found online. You can save and share your creation with others via the So.Cl (pronounced social) site, which is technically a different project that happens to allow you to create montages in a more social way.
My first thought on Montage was that it reminded me of Paper.li, right down to the silly name and URL. I wouldn't ever have known what Paper.li was if it weren't for the fact that others had included Tweets I'd made in their daily newspapers. I still don't know if they curate the content manually or automatically. I wonder if Montage is intended to be used the same way, and whether it has any similar mechanisms for allowing people whose content is included to discover the site. If nothing else, it does look like a fun way to search and share interesting content in a Pinterest sort of way.
Hearing Lili talk about all the amazing things she and her team has done was really inspiring. It got Andrew and I talking about putting together a five year plan that might allow us to do more interesting things in the future. It also really encouraged me to consider trying for an internship with Microsoft Research once the baby gets older. Maybe my varied interests will come in handy like Lili's past career did for her!
The Road to GHC12
After a one-year hiatus, I'm back at the Grace Hopper Celebration of Women in Computing! We took a road trip down to Baltimore, and despite a feverish baby and some rainy weather, we got to see some fun things.
We started off in Stowe, Vermont. We went there because it's a popular ski resort for people in our area, given the size of the mountain and relatively short drive.
While there we drove to the top of Mount Mansfield and hiked along the top toward the summit. We didn't make it the whole way before the rain started. Granted, it was just a drizzle when we turned around, but with the baby on Andrew's back we didn't want to risk it getting worse. The visibility was pretty bad anyway.
On the way back down, I got a nice photo of the gorgeous fall colours. I'm glad the weather didn't completely obscure this view!
Molly's fever broke when we were done in Stowe. On our way to Connecticut, we stopped by King Arthur Flour. Our strategy for deciding how much to buy -- we wanted a lot! -- was to ask ourselves how much it would cost to ship it to Canada if we didn't get it.
We stayed in Norwalk, Connecticut because it was halfway between Stowe and Baltimore (we didn't want to drive too long any given day because of the baby). We stopped by the aquarium, and were happy to see that Molly actually interacted with the fish.
We made it to Baltimore late Tuesday night and are enjoying the conference very much so far. Looking forward to posting about the awesome sessions we've attended soon!
We started off in Stowe, Vermont. We went there because it's a popular ski resort for people in our area, given the size of the mountain and relatively short drive.
While there we drove to the top of Mount Mansfield and hiked along the top toward the summit. We didn't make it the whole way before the rain started. Granted, it was just a drizzle when we turned around, but with the baby on Andrew's back we didn't want to risk it getting worse. The visibility was pretty bad anyway.
On the way back down, I got a nice photo of the gorgeous fall colours. I'm glad the weather didn't completely obscure this view!
Molly's fever broke when we were done in Stowe. On our way to Connecticut, we stopped by King Arthur Flour. Our strategy for deciding how much to buy -- we wanted a lot! -- was to ask ourselves how much it would cost to ship it to Canada if we didn't get it.
We stayed in Norwalk, Connecticut because it was halfway between Stowe and Baltimore (we didn't want to drive too long any given day because of the baby). We stopped by the aquarium, and were happy to see that Molly actually interacted with the fish.
We made it to Baltimore late Tuesday night and are enjoying the conference very much so far. Looking forward to posting about the awesome sessions we've attended soon!
Friday, September 28, 2012
My Processing Workshop Materials
Last weekend I taught a one-day workshop called 'Create Interactive Art and More! Learn to Program with Processing.' I developed the materials from scratch for the workshop and hope to use them again. Overall the day went quite well, but as always, there are things to improve.
In the morning, I did a round of intros from the group. This was for two reasons: first, to allow those who were late to make their way in (the weather wasn't great and even I had a hard time finding the door to get in), and second to build a sense of community. Although this took a little longer than I would have liked, it seems that both goals were met. I had some students say how great it was to see how many other non-programmers and artists were there.
The morning largely involved me talking about a programming concept using some analogy, and then getting the students to type in some example code. I had them play around with the specifics of the code to learn about how Processing worked experimentally rather than just hearing me describe the syntax.
This worked fairly well, though there were times I would have liked to move on a bit quicker. One challenge was getting everyone's attention while they were playing with code. Sometimes the TA's would continue helping someone even when I wanted to tell the class something; next time, I should be sure to ask the TA's to pause for a bit when I need to move on. The analogies themselves seemed to work well.
In the afternoon, I had some programming concepts to finish covering. Next time, I should schedule more than two hours for this portion of the workshop.
After the formal part, I got the students to look at four tutorials I had written up. To make the tutorials, I had first programmed four little projects in Processing, then tried to put myself in a beginner's shoes to describe the steps to writing the code.
I tried to keep the tutorials fairly simple, though my last tutorial for a memory game ended up being much more complex. I decided to finish the tutorial for that one anyway just in case there were some folks who had programmed before (and there were).
My goal in writing the tutorials was to entice the students to ask questions during the class. I wanted to use a 'just-in-time' teaching technique where things would come up as questions the TA's could help with while they worked through the tutorials. So there were definitely things in the tutorials that weren't discussed much or at all in the formal portion of the workshop.
However, it seems that my tutorials weren't quite clear enough. Students had a bit of trouble knowing exactly what to do if they hadn't programmed before. So, since the workshop has ended, I have modified all but the memory game tutorials, adding specific, highlighted instructions on what to do.
My course notes and tutorials are all available online so the students can try them after the workshop as well. If you'd like to give Processing a try, or just see whether I've done a good job with the tutorials, I'd love to have you look at them and post feedback as a comment here on the blog.
I'm hoping to collect some more data on how well the workshop went through a survey I sent out to the participants. It has been challenging to get many responses, but hopefully they'll continue to come in. I am already considering running the same workshop (with improvements) next semester, perhaps targeted toward students, so hopefully I can get some more data then as well.
In the morning, I did a round of intros from the group. This was for two reasons: first, to allow those who were late to make their way in (the weather wasn't great and even I had a hard time finding the door to get in), and second to build a sense of community. Although this took a little longer than I would have liked, it seems that both goals were met. I had some students say how great it was to see how many other non-programmers and artists were there.
The morning largely involved me talking about a programming concept using some analogy, and then getting the students to type in some example code. I had them play around with the specifics of the code to learn about how Processing worked experimentally rather than just hearing me describe the syntax.
This worked fairly well, though there were times I would have liked to move on a bit quicker. One challenge was getting everyone's attention while they were playing with code. Sometimes the TA's would continue helping someone even when I wanted to tell the class something; next time, I should be sure to ask the TA's to pause for a bit when I need to move on. The analogies themselves seemed to work well.
In the afternoon, I had some programming concepts to finish covering. Next time, I should schedule more than two hours for this portion of the workshop.
After the formal part, I got the students to look at four tutorials I had written up. To make the tutorials, I had first programmed four little projects in Processing, then tried to put myself in a beginner's shoes to describe the steps to writing the code.
I tried to keep the tutorials fairly simple, though my last tutorial for a memory game ended up being much more complex. I decided to finish the tutorial for that one anyway just in case there were some folks who had programmed before (and there were).
My goal in writing the tutorials was to entice the students to ask questions during the class. I wanted to use a 'just-in-time' teaching technique where things would come up as questions the TA's could help with while they worked through the tutorials. So there were definitely things in the tutorials that weren't discussed much or at all in the formal portion of the workshop.
However, it seems that my tutorials weren't quite clear enough. Students had a bit of trouble knowing exactly what to do if they hadn't programmed before. So, since the workshop has ended, I have modified all but the memory game tutorials, adding specific, highlighted instructions on what to do.
My course notes and tutorials are all available online so the students can try them after the workshop as well. If you'd like to give Processing a try, or just see whether I've done a good job with the tutorials, I'd love to have you look at them and post feedback as a comment here on the blog.
I'm hoping to collect some more data on how well the workshop went through a survey I sent out to the participants. It has been challenging to get many responses, but hopefully they'll continue to come in. I am already considering running the same workshop (with improvements) next semester, perhaps targeted toward students, so hopefully I can get some more data then as well.
Tuesday, September 25, 2012
Interactive Storytelling Talk at a Local Sci-Fi Con
An unexpected opportunity presented itself when I was asked to speak at a local sci-fi convention, Can-Con. A friend had referred me as a potential academic speaker who could talk about augmented reality. But, since my thesis topic had taken a turn toward nonlinear narrative and interactive storytelling, and because I figured this audience would enjoy this topic, that's what I ended up speaking about instead.
I focused on the big question of what it would take to create the holodeck in terms of storytelling. My aim was to explore the creative and technical side to answer which area we needed a breakthrough in most. My personal opinion is that we need a creative breakthrough first; there's a lot of technology out there that hasn't resulted in many particularly compelling stories. I think we need to figure out how to write for this medium in a mainstream kind of way before we can truly determine what needs to improve technology-wise.
I had a small but attentive and interactive audience, which made the talk not only a pleasure to give, but useful for me, too. I got quite a few good ideas and references that will help me in my thesis work. The conference seems pretty interesting in itself, so if you're interested in sci-fi, you should check out next year's edition!
I had a small but attentive and interactive audience, which made the talk not only a pleasure to give, but useful for me, too. I got quite a few good ideas and references that will help me in my thesis work. The conference seems pretty interesting in itself, so if you're interested in sci-fi, you should check out next year's edition!
Thursday, September 20, 2012
To Be Published: Understanding the Power of Augmented Reality for Learning
I'm pleased to say that my work on cognitive theories and augmented reality is finally going to be published. 'Understanding the Power of Augmented Reality for Learning' was accepted as a full research paper for the 2012 World Conference on E-Learning in Corporate, Government, Healthcare, and Higher Education, happening this October in Montreal.
This paper has gone through several iterations, each one better than the last. The version being published here has a learning slant, and although this wasn't the focus when we started, I'm happy it ended up here given my passion for education.
But that's not to say that the ideas are not applicable to other domains. In fact, I'm hoping that some of you will take the next step. I'd really love to see future work build on this, applying the advice we put forward to future projects and digging deeper into these cognitive theories and others. If you're interested in moving the research forward, feel free to contact me and I'll share some more ideas (I won't be doing this line of research for my thesis anymore).
Without further ado, here is the abstract and a link to the preprint version of the paper.
This paper has gone through several iterations, each one better than the last. The version being published here has a learning slant, and although this wasn't the focus when we started, I'm happy it ended up here given my passion for education.
But that's not to say that the ideas are not applicable to other domains. In fact, I'm hoping that some of you will take the next step. I'd really love to see future work build on this, applying the advice we put forward to future projects and digging deeper into these cognitive theories and others. If you're interested in moving the research forward, feel free to contact me and I'll share some more ideas (I won't be doing this line of research for my thesis anymore).
Without further ado, here is the abstract and a link to the preprint version of the paper.
Abstract: Augmented reality has recently become a popular interface for various learning applications, but it is not always clear that AR is the right choice. We provide a theoretical grounding that explains the underlying value of AR for learning and identify when it is a suitable interface. Our list of operational design advantages includes AR's use of reality, virtual flexibility, invisible interface, and spatial awareness. This list is backed by four underlying cognitive theories: mental models and distributed, situated, and embodied cognition. We argue that the more design advantages a learning system incorporates, the better AR works as an interface. We also identify a set of questions to be used in the design and evaluation of AR projects. With this, we can begin to design AR for learning more purposefully.
Tuesday, September 18, 2012
Making the Most of Conference Travel
When I'm lucky enough to go to a conference through school, I try to make the most of the time spent in a new place. This year, the Grace Hopper Celebration of Women in Computing is being held in Baltimore, which is driving distance for us, so the whole family is going! As usual, we're going to take in some sights along the way.
Although I don't always need to plan ahead when travelling somewhere (much to the surprise of one friend I spent time with in San Francisco last year), here's what I do when I choose to:
Although I don't always need to plan ahead when travelling somewhere (much to the surprise of one friend I spent time with in San Francisco last year), here's what I do when I choose to:
- Create a new map in My Places on Google Maps.
- Add the conference hotel and event location to the map. I like to use the schoolhouse icon for the actual conference, and the bed icon for all lodging. You can change the icons by editing the map, clicking on the location you want to edit, and then clicking on the icon.
- If driving, look at the route and see what's nearby. For this trip, we decided we wanted to stay a couple of nights in Vermont; even though it's not directly on the way, it's close enough, and the fall colours will hopefully be spectacular.
- For everywhere you are staying, research interesting sights to see and restaurants you want to eat at. Mark all of these on the map. You can filter down later if you want to put together a schedule for yourself, or you can just pick and choose while you're there. Having it all on the map will help figure out distances and driving/walking/public transit routes.
- If you really want to make sure you're organized, create a Google Doc (or similar) for yourself to track your itinerary, research on hotels and sight-seeing, and conference scheduling. I've been doing all that and more in my document for this year's Grace Hopper, but I'll soon start using the conference's mobile app to get even more organized.
Tuesday, September 11, 2012
Grad School + Baby: Why Tracking Time is Useful
Last week was the official start to the fall semester, which also marks my official return to being a student. This time, things are a little different: I have a baby to look after in addition to figuring out my thesis. I'm turning to some time tracking techniques I've used in the past to ensure I still get the chance to do fun things with the family (like camping).
My most valuable tool in tracking time is Google Docs spreadsheets. They are accessible everywhere, and I love that I can have a tab open in my browser all the time to quickly make note of time-related things (I pin my spreadsheets as 'app tabs' in Firefox so they don't clutter my workspace).
Lately, I've been keeping a spreadsheet to track when the baby sleeps. Up until now, we've always let her nap whenever she fell asleep, wake up when she felt like it, and put her to bed when we went to bed. But as I start to have others look after her, it'll be well worth having more of a routine (babies love routines anyway). By noting when she sleeps, I'm hoping to notice patterns so I can start to get her into a set routine. We've already managed to (mostly) get her bedtime routine started around 9pm, so that's a good start!
I'm also resurrecting the time sheet I used a few years ago to manage my school-related time. Basically, I list the activities I'm working on for a week, separating them into thesis-specific tasks and other endeavours. These days, I'm using the stopwatch on my phone to track my time exactly, since I get interrupted often when I'm alone with the baby. You can check out this semester's template here. I'm hoping this will help me determine where I need to put more effort, and help me get used to a much more disjointed way of working.
This semester is a bit of an experiment to see whether I can work in new ways and whether my intention of mixing me watching the baby with having family come watch her will work. We'll see what happens by Christmas!
My most valuable tool in tracking time is Google Docs spreadsheets. They are accessible everywhere, and I love that I can have a tab open in my browser all the time to quickly make note of time-related things (I pin my spreadsheets as 'app tabs' in Firefox so they don't clutter my workspace).
Lately, I've been keeping a spreadsheet to track when the baby sleeps. Up until now, we've always let her nap whenever she fell asleep, wake up when she felt like it, and put her to bed when we went to bed. But as I start to have others look after her, it'll be well worth having more of a routine (babies love routines anyway). By noting when she sleeps, I'm hoping to notice patterns so I can start to get her into a set routine. We've already managed to (mostly) get her bedtime routine started around 9pm, so that's a good start!
I'm also resurrecting the time sheet I used a few years ago to manage my school-related time. Basically, I list the activities I'm working on for a week, separating them into thesis-specific tasks and other endeavours. These days, I'm using the stopwatch on my phone to track my time exactly, since I get interrupted often when I'm alone with the baby. You can check out this semester's template here. I'm hoping this will help me determine where I need to put more effort, and help me get used to a much more disjointed way of working.
This semester is a bit of an experiment to see whether I can work in new ways and whether my intention of mixing me watching the baby with having family come watch her will work. We'll see what happens by Christmas!
Thursday, September 6, 2012
Anita's Quilt Launches Today
I'm excited to announce that a project I've been working on all year with some awesome women from the Anita Borg Institute for Women and Technology is launching today! We believe a personal story has the power to inspire, transform and shape others' stories.
Here is some info from the committee who put this together:
Here is some info from the committee who put this together:
Anita's Quilt is an ongoing dialog of inspirational stories from women in tech supporting each other and individually striving to have more impact as technologists.Help to spread the inspiration and forward the message to your communities!
Today we begin publishing personal stories of actions that have increased impact. We start with a set of stories that highlight inspiring Systers. There are thousands of Systers (current and past) eligible to write stories, but we solicited just a few for this launch.
We are starting out with a story from Robin - Her Systers Keeper - on the general history and accomplishments of the Systers community, and will have new Systers stories through the Anniversary celebration at the Grace Hopper Celebration.
- Visit http://anitasquilt.org
- Facebook: Like Anita Borg Institute for Women and Technology
- Twitter: Follow @anitasquilt @systers_org @anitaborg_org
- RSS: http://anitasquilt.org/feed/
Tuesday, September 4, 2012
The First Time I Don't Want to Go Back to School
Today is the first day back to school for a lot of people. It's been the same for me for many years, given that I have yet to leave school behind for good. But this time, I don't really want to go back quite yet.
I was only able to take 8 months of maternity leave. Well, I suppose I could have taken a whole year, but we decided that we couldn't afford to miss my income that long. (Even though most people in Canada get a bit of employment insurance while on leave, I didn't due to being a student.) That 8 months didn't last nearly long enough.
The good news is that the transition into student life shouldn't be too abrupt. I've actually been working on a couple of projects this summer, giving me a bit of a head start. I've also got a taste of how things might go with me and Molly at home while I work.
I'm not getting full time day care. I'm going to try working while looking after her some of the week, go into campus while her grandparents look after her once a week, and have her other grandfather entertain her a couple of afternoons while I work at home.
It will be interesting to see how this works out. If it does, I will be very grateful that I can be working but not miss all of Molly's firsts. (She's got a lot of them out of the way, including crawling, pulling herself up, cruising, and even standing a bit on her own, but she's still got walking and talking to do!)
And if it doesn't... well, I'll still be grateful that I got even the 8 months. Not every country is so lucky to have good maternity leave policies and attitudes.
I was only able to take 8 months of maternity leave. Well, I suppose I could have taken a whole year, but we decided that we couldn't afford to miss my income that long. (Even though most people in Canada get a bit of employment insurance while on leave, I didn't due to being a student.) That 8 months didn't last nearly long enough.
The good news is that the transition into student life shouldn't be too abrupt. I've actually been working on a couple of projects this summer, giving me a bit of a head start. I've also got a taste of how things might go with me and Molly at home while I work.
I'm not getting full time day care. I'm going to try working while looking after her some of the week, go into campus while her grandparents look after her once a week, and have her other grandfather entertain her a couple of afternoons while I work at home.
It will be interesting to see how this works out. If it does, I will be very grateful that I can be working but not miss all of Molly's firsts. (She's got a lot of them out of the way, including crawling, pulling herself up, cruising, and even standing a bit on her own, but she's still got walking and talking to do!)
And if it doesn't... well, I'll still be grateful that I got even the 8 months. Not every country is so lucky to have good maternity leave policies and attitudes.
Thursday, August 30, 2012
Bit by Bit: A Young Woman's Guide to Entering and Succeeding in High Tech Careers
A new book all about high tech careers for women has finally found its way onto Amazon! I was interviewed for this book (Bit by Bit: A Young Woman's Guide to Entering and Succeeding in High Tech Careers), along with many other awesome women (some of whom I know).
I haven't had the chance to read my copy yet, but I will post a review
when I do. In the meantime, if you or someone you know has even
considered getting into high tech, I recommend picking it up yourself. In addition to the interviews, the book explains a few of the various job roles that are out there. It will also give you the top ten reason you should consider a career in tech, and what skills you need to get there.
Tuesday, August 28, 2012
Startup Weekend... In Book Form!
I've wondered before if I'd like being an entrepreneur. I've come up with a few ideas that could get me started. I have even entered a social-good version of a business case competition (and walked away a finalist). But I want to know more before making the plunge. So I got a copy of the book Startup Weekend: How to Take a Company from Concept to Creation in 54 Hours.
What's in the Book
The book's introduction walks the reader through the history of Startup Weekend, emphasizing the need for trust among peers. Without trust, a startup is impossible, given the risks involved.
The first real chapter discusses action-based networking, and why traditional networking events (complete with standing around sipping wine) aren't terribly useful. You need to work together with people you don't normally meet to get the most useful contacts.
Next, the book covers how to effectively pitch your idea and recruit your team members. In 60 seconds, you need to say who you are, the problem you want to solve, your proposed solution, and what help you will need.
The third chapter is about experiential education, and is where the bulk of what you actually do at a Startup Weekend is described. The emphasis on "learning by doing" really entices the reader to want to attend the event in person.
The last two chapters are about the startup business model and the startup ecosystem. They briefly touch on some of the key mistakes that entrepreneurs make, and the steps an entrepreneur can take from deciding to make the startup leap to getting funding to, if they're lucky, IPO and Fortune 500.
My Take
Looking back at what the book actually covers, I have to think I must have got a lot out of it. But, to be honest, I didn't get what I was hoping for.
The book's prose had a style that said a lot of general things without details. Part of the reason for this is the inclusion of the many little stories woven throughout. I do like that the stories give specific examples of the kinds of startups people were working on, and they did help build excitement about attending the weekend event. But they also caused what specific advice there was to get lost easily in the text.
Something the book would have greatly benefited from is a concrete summary list of the information contained in each chapter. Something that the reader could easily refer back to as they attempted their own startup.
In the end, the book is not terribly useful as a reference guide on startups. It does drum up excitement about attending a Startup Weekend, and it does touch on some of the elements of entrepreneurship without going into detail.
Maybe that was its purpose, in which case it succeeds in its mission. But still, I leave wishing for more. I am not sure I am any closer to my answer of whether I want to be an entrepreneur.
What's in the Book
The book's introduction walks the reader through the history of Startup Weekend, emphasizing the need for trust among peers. Without trust, a startup is impossible, given the risks involved.
The first real chapter discusses action-based networking, and why traditional networking events (complete with standing around sipping wine) aren't terribly useful. You need to work together with people you don't normally meet to get the most useful contacts.
Next, the book covers how to effectively pitch your idea and recruit your team members. In 60 seconds, you need to say who you are, the problem you want to solve, your proposed solution, and what help you will need.
The third chapter is about experiential education, and is where the bulk of what you actually do at a Startup Weekend is described. The emphasis on "learning by doing" really entices the reader to want to attend the event in person.
The last two chapters are about the startup business model and the startup ecosystem. They briefly touch on some of the key mistakes that entrepreneurs make, and the steps an entrepreneur can take from deciding to make the startup leap to getting funding to, if they're lucky, IPO and Fortune 500.
My Take
Looking back at what the book actually covers, I have to think I must have got a lot out of it. But, to be honest, I didn't get what I was hoping for.
The book's prose had a style that said a lot of general things without details. Part of the reason for this is the inclusion of the many little stories woven throughout. I do like that the stories give specific examples of the kinds of startups people were working on, and they did help build excitement about attending the weekend event. But they also caused what specific advice there was to get lost easily in the text.
Something the book would have greatly benefited from is a concrete summary list of the information contained in each chapter. Something that the reader could easily refer back to as they attempted their own startup.
In the end, the book is not terribly useful as a reference guide on startups. It does drum up excitement about attending a Startup Weekend, and it does touch on some of the elements of entrepreneurship without going into detail.
Maybe that was its purpose, in which case it succeeds in its mission. But still, I leave wishing for more. I am not sure I am any closer to my answer of whether I want to be an entrepreneur.
Monday, August 20, 2012
The Promise Behind Khan's Computer Science Offerings
I haven't tried them yet. I thought it would be interesting to reflect on the latest addition to Khan Academy before I actually did the tutorials, and then see how my opinion differed afterwards. If the write-up by John Resig, the guy who lead the initiative, is any indication, I am guessing I will like the new computer science content very much. Which is good, because I haven't been all that impressed with Khan Academy thus far.
Based on Resig's description, here is what I'm excited about...
Easy to get going. Everything works in the browser, so there's nothing to download or install.
Side-by-side coding and output. You write code on one side of the screen, and you see the results immediately on the right. This reminds me of languages like Scratch and Blockly.
Live updating. When you make changes, the program doesn't start again from the beginning; the changes are reflected in the output right away. This also reminds me of Scratch, and has been something I tried to take advantage of in my programming workshops.
Visual output. The JavaScript Processing library, Processing.js, makes this happen. Visual output is way more fun than text printed out at a command line.
Helpful error messages. "We build off of the existing linting that we do to try and provide extra levels of hinting. We do spelling correction, provide argument suggestions, and try to make suggestions for common beginner mistakes." And the errors are apparently shown with a cute cartoon character, making them less intimidating.
Collaboration and community. Although more inspired by open source communities, the model of remixing and sharing reminds me a lot of what the Scratch community does. I think this aspect is a large motivator for students to keep on going, and is one reason I have often turned to Scratch over other choices.
Promise of more CS-centric lessons. Most of the current content is basic programming, but the team is intending to expand into more computer science specific territory over time. I suppose it remains to be seen how well they do this, but my fingers are crossed.
So, we'll see how well all this works when I actually get down and try the lessons. In the meantime, I can't help but think that designing the content would be a dream job for me. Maybe one day I'll have an opportunity to work on something like this.
Based on Resig's description, here is what I'm excited about...
Easy to get going. Everything works in the browser, so there's nothing to download or install.
Side-by-side coding and output. You write code on one side of the screen, and you see the results immediately on the right. This reminds me of languages like Scratch and Blockly.
Live updating. When you make changes, the program doesn't start again from the beginning; the changes are reflected in the output right away. This also reminds me of Scratch, and has been something I tried to take advantage of in my programming workshops.
Visual output. The JavaScript Processing library, Processing.js, makes this happen. Visual output is way more fun than text printed out at a command line.
Helpful error messages. "We build off of the existing linting that we do to try and provide extra levels of hinting. We do spelling correction, provide argument suggestions, and try to make suggestions for common beginner mistakes." And the errors are apparently shown with a cute cartoon character, making them less intimidating.
Collaboration and community. Although more inspired by open source communities, the model of remixing and sharing reminds me a lot of what the Scratch community does. I think this aspect is a large motivator for students to keep on going, and is one reason I have often turned to Scratch over other choices.
Promise of more CS-centric lessons. Most of the current content is basic programming, but the team is intending to expand into more computer science specific territory over time. I suppose it remains to be seen how well they do this, but my fingers are crossed.
So, we'll see how well all this works when I actually get down and try the lessons. In the meantime, I can't help but think that designing the content would be a dream job for me. Maybe one day I'll have an opportunity to work on something like this.